diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000000..1cd9745822 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,4 @@ +/articles/quickstart @auth0/dx-sdks-engineer +/articles/libraries @auth0/dx-sdks-engineer +/articles/cms @auth0/dx-sdks-engineer +/articles/quickstart/webapp/express @pdillon diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 49861ab9d9..bd61ed03a3 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,8 +1,3 @@ diff --git a/.github/workflows/check-content-version.yml b/.github/workflows/check-content-version.yml new file mode 100644 index 0000000000..8d471da8b9 --- /dev/null +++ b/.github/workflows/check-content-version.yml @@ -0,0 +1,22 @@ +name: Check Content Version + +on: + schedule: + - cron: '0 * * * *' # Runs every hour + workflow_dispatch: # Allows manual trigger from GitHub Actions tab + +jobs: + run-script: + runs-on: ubuntu-latest + + steps: + - name: Checkout repository + uses: actions/checkout@v3 + + - name: Make script executable + run: chmod +x scripts/check-version.sh + shell: bash + + - name: Run check-version.sh script + run: scripts/check-version.sh + shell: bash \ No newline at end of file diff --git a/.github/workflows/clean-redirects-pr.yml b/.github/workflows/clean-redirects-pr.yml new file mode 100644 index 0000000000..06b704805c --- /dev/null +++ b/.github/workflows/clean-redirects-pr.yml @@ -0,0 +1,34 @@ +# Cleanup redirects config file. +name: Redirects cleanup PR + +on: + schedule: + - cron: '0 7 * * 1' + workflow_dispatch: + +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: Get current date + id: date + run: echo "current_date=$(date +'%Y-%m-%d')" >> $GITHUB_ENV + - name: Checkout + uses: actions/checkout@v2 + - uses: actions/setup-node@v2 + with: + node-version: '14.17' + cache: 'yarn' + - run: yarn + - run: yarn run clean-redirects + - name: Create Pull Request + id: cpr + uses: peter-evans/create-pull-request@v3 + with: + commit-message: Redirects config cleanup ${{ env.current_date }} + committer: GitHub + author: ${{ github.actor }} <${{ github.actor }}@users.noreply.github.com> + signoff: false + branch: clean_redirects_action_${{ env.current_date }} + delete-branch: true + title: 'Redirects config cleanup ${{ env.current_date }}' \ No newline at end of file diff --git a/.github/workflows/integration-tests.yml b/.github/workflows/integration-tests.yml new file mode 100644 index 0000000000..3c1be5f76d --- /dev/null +++ b/.github/workflows/integration-tests.yml @@ -0,0 +1,34 @@ +name: Integration Tests +on: + pull_request: + branches: master + +concurrency: + group: pr-integration-tests-${{ github.event.pull_request.id }} + cancel-in-progress: true + +jobs: + tests: + name: Trigger Tests + runs-on: ubuntu-latest + steps: + - name: Check out code + uses: actions/checkout@v2 + with: + fetch-depth: 0 + - name: Get branch name + id: branch-name + uses: tj-actions/branch-names@6c999acf206f5561e19f46301bb310e9e70d8815 # v7.0.7 on 2025-03-20 + - name: Wait for Tests Results + uses: convictional/trigger-workflow-and-wait@v1.6.1 + with: + owner: ${{ secrets.NOTIFY_ORG }} + repo: ${{ secrets.NOTIFY_REPO }} + github_token: ${{ secrets.NOTIFY_PAT_TOKEN }} + workflow_file_name: integration-tests.yml + ref: master + wait_interval: 90 + client_payload: '{ "docsBranch": "${{ steps.branch-name.outputs.current_branch }}", "pullRequest": "${{ github.event.pull_request.number }}", "postStatus": "true" }' + propagate_failure: true + trigger_workflow: true + wait_workflow: true diff --git a/.github/workflows/push-notify.yml b/.github/workflows/push-notify.yml new file mode 100644 index 0000000000..a47e96380d --- /dev/null +++ b/.github/workflows/push-notify.yml @@ -0,0 +1,21 @@ +name: Push Notify +on: + workflow_dispatch: + push: + branches: + - main + - master +jobs: + dispatch: + runs-on: ubuntu-latest + steps: + - name: Webhook Notify + uses: actions/github-script@v6 + with: + github-token: ${{ secrets.NOTIFY_PAT_TOKEN }} + script: | + await github.rest.repos.createDispatchEvent({ + owner: '${{ secrets.NOTIFY_ORG }}', + repo: '${{ secrets.NOTIFY_REPO }}', + event_type: 'docs_repo_webhook' + }) \ No newline at end of file diff --git a/.github/workflows/semgrep.yml b/.github/workflows/semgrep.yml new file mode 100644 index 0000000000..19d6073644 --- /dev/null +++ b/.github/workflows/semgrep.yml @@ -0,0 +1,15 @@ +name: Semgrep +on: + pull_request: {} +jobs: + semgrep: + name: Scan + runs-on: ubuntu-latest + container: + image: returntocorp/semgrep + if: (github.actor != 'dependabot[bot]' && github.actor != 'snyk-bot') + steps: + - uses: actions/checkout@v3 + - run: semgrep ci + env: + SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }} \ No newline at end of file diff --git a/.gitignore b/.gitignore index 3cc3b832ec..58ce0eb185 100644 --- a/.gitignore +++ b/.gitignore @@ -8,3 +8,17 @@ config.json # IDE .idea + +# Visual Studio Code +.vscode + +# Sublime Text +*.sublime-project +*.sublime-workspace + +# Vim +*.swp +*.swo +Session.vim +.netrwhist +.vscode \ No newline at end of file diff --git a/.prettierrc b/.prettierrc new file mode 100644 index 0000000000..6e01ce3ba0 --- /dev/null +++ b/.prettierrc @@ -0,0 +1,6 @@ +{ + "singleQuote": true, + "arrowParens": "always", + "printWidth": 120, + "trailingComma": "es5" +} \ No newline at end of file diff --git a/.vscode/settings.json b/.vscode/settings.json deleted file mode 100644 index 0aa52fd8a6..0000000000 --- a/.vscode/settings.json +++ /dev/null @@ -1,4 +0,0 @@ -// Place your settings in this file to overwrite default and user settings. -{ - "editor.formatOnSave": false -} diff --git a/.vscode/spell.json b/.vscode/spell.json deleted file mode 100644 index e5133a8669..0000000000 --- a/.vscode/spell.json +++ /dev/null @@ -1 +0,0 @@ -{"language":"en","ignoreWordsList":["NuGet","RS256","Auth0","GitHub"],"mistakeTypeToStatus":{"Passive voice":"Hint","Spelling":"Error","Complex Expression":"Disable","Hidden Verbs":"Information","Hyphen Required":"Disable","Redundant Expression":"Disable","Did you mean...":"Disable","Repeated Word":"Warning","Missing apostrophe":"Warning","Cliches":"Disable","Missing Word":"Disable","Make I uppercase":"Warning"},"languageIDs":["markdown","text"],"ignoreRegExp":["/\\(.*\\.(jpg|jpeg|png|md|gif|JPG|JPEG|PNG|MD|GIF)\\)/g","/((http|https|ftp|git)\\S*)/g"]} \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6866c05e4..0418e709cf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -42,7 +42,7 @@ The following is a set of guidelines for contributing to the Auth0 documentation * Read and follow the [Style Guide](STYLEGUIDE.md). * Consult the [Words](WORDS.md) document for Auth0 specific spellings and definitions. * Always use relative URLs for internal `auth0.com/docs` links. For example, if the absolute path to the document is `https://auth0.com/docs/identityproviders`, use `/identityproviders`. These links will be correctly formatted in the build process. -* Do not hard code links to Auth0 sites like `docs.auth0.com` or `manage.auth0.com`. Instead, use [Parameter Aliases](#parameter-aliases), such as `${manage_url}`. +* Do not hard code links to Auth0 sites like `docs.auth0.com` or `manage.auth0.com`. Instead, use [Document Variables](#document-variables), such as `${manage_url}`. * Name files with all lowercase using dashes (-) to separate words. If using a date in the file name, it should be in the format YYYY-MM-DD. For example, `this-is-my-file.md` or `this-is-a-title-2015-10-01.md`. * Do not store images in external locations like Dropbox, CloudUp, or the Auth0 CDN. Link to images in this repo using a relative path `![ALT_TEXT](/media/folder/image-name.png)`. The image will be uploaded to the CDN and the link will be formatted during the build process. Do not forget to set the alternate text for each image. * Keep images to no more than 750 pixels wide. @@ -69,11 +69,33 @@ Additionally, you can send variables to the included document: ## Markdown -Markdown on this site conforms to the [CommonMark](http://commonmark.org/) spec. Additionally, there are a few custom markdown features available as described below. +Markdown on this site conforms to the [CommonMark](http://commonmark.org/) spec. Additionally, there are a few custom Markdown features available as described below. + +You should [test your Markdown](http://markdownlivepreview.com) to ensure the formatting is correct. ### Headings -One common mistake with formatting of headings is to not include a space between the hashes and the text. Some markdown processors allow this, but we do not. You must put a space as shown below. +Add one to six `#` symbols before your heading text to create your header. The number of # you use determines the size of the heading. + +``` +# H1 +## H2 +### H3 +#### H4 +##### H5 +###### H6 +``` + +The header text above renders as follows: + +# H1 +## H2 +### H3 +#### H4 +##### H5 +###### H6 + +One common mistake with formatting of headings is to not include a space between the hashes and the text. Some Markdown processors allow this, but we do not. You must put a space as shown below. INVALID: `#My Heading` @@ -82,8 +104,8 @@ VALID: `# My Heading` ### UI Components General advice: -- Don't add custom UI components with HTML unless it's really necessary. -- Don't add any element before the main title. If you want to show some general information for the whole doc put the element after the main title. +- Do not add custom UI components with HTML unless it's really necessary. +- Do not add any element before the main title. If you want to show some general information for the whole doc put the element after the main title. - Try to keep the amount of UI components on your docs to a minimum. They make the documentation more difficult to read and cut the reading flow. - Only use the `blockquote` element (`>` in markdown) to represent actual quotes. Use a `note` or a `panel` if you want to highlight the information. @@ -95,7 +117,7 @@ Only use this if the content is brief (one to four lines), if not use the `panel ```markdown ::: note - If you need a refresher on the OAuth 2.0 protocol, you can go through our OAuth 2.0 article. +If you need a refresher on the OAuth 2.0 protocol, you can go through our OAuth 2.0 article. ::: ``` @@ -145,7 +167,7 @@ Description ::: ::: 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 client (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the [Implicit Grant flow](/api-auth/grant/implicit) is more appropriate in that case. +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 client (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. ::: ``` @@ -168,7 +190,7 @@ Try to keep the list length to a minimum (up to 5 links). ![Next steps list](https://user-images.githubusercontent.com/6318057/27233085-b116f28a-528e-11e7-9ac3-4463a9c5db3d.png) ### HTTP Request Snippets -You can add a [HAR request format](http://www.softwareishard.com/blog/har-12-spec/#request) snippet to make an example HTTP request availible in a variety of languages. This will generate a tab view showing the HTTP request in various languages. +You can add a [HAR request format](http://www.softwareishard.com/blog/har-12-spec/#request) snippet to make an example HTTP request available in a variety of languages. This will generate a tab view showing the HTTP request in various languages. The library we use is [HTTP Snippet](https://github.com/Kong/httpsnippet). @@ -266,7 +288,7 @@ For close-ups and other screenshots that do not include the browser window, appl You can set various properties of articles in the front matter of the document. Each document should have the `title` and `description` properties set. You can set other variables depending on the document. -`toc` adds a table of content dropdown at the top of the document, that lists all the paragraphs of the doc. By default it's disabled. Set it to `true` to display the dropdown. +`toc` adds a table of content dropdown at the top of the document, that lists all the paragraphs of the doc. By default it is disabled. Set it to `true` to display the dropdown. Example front matter: @@ -280,7 +302,7 @@ toc: true #### URLs -Document urls are by default in the same format as the forlder structure after the `articles` folder. So for example if you document is stored at `articles/my-folder/document.md`, the url would be `/docs/my-folder/document`. +Document urls are by default in the same format as the folder structure after the `articles` folder. So for example if you document is stored at `articles/my-folder/document.md`, the url would be `/docs/my-folder/document`. If you create a folder that will have multiple articles, the best practice is to set the default document as `index.md`. However, the url must be set in that document to a friendly url. For example, if you have a document `/articles/my-folder/index.md`, you should set the url to be `/my-folder`. @@ -297,14 +319,14 @@ url: /path/to/document We use a pre-commit hook that lints the edited files to ensure a consistent style in the docs. We use [markdownlint](https://github.com/DavidAnson/markdownlint) with the rules specified in the `.markdownlint.json` file in the root of the repo to do this. You can [check more about the linting rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md). -You won't be able to commit if your edited file don't follow these guidelines. +You will not be able to commit if your edited file does not follow these guidelines. -If you are using VS Code as your code editor, it's highly recommended to install the [MarkdownLint VS Code Extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint). +If you are using VS Code as your code editor, it is highly recommended to install the [MarkdownLint VS Code Extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint). ## Sidebar When you are adding a new article you should always add a link to it in the `config/sidebar.yml` file. -It's really important to represent all our articles in the sidebar because this will help the user see where they are inside the documentation. +It is really important to represent all our articles in the sidebar because this will help the user see where they are inside the documentation. You can add titles to the sidebar using the attribute `category`: @@ -368,11 +390,11 @@ To create and submit a job to Wordy: You will need to provide the following pieces of information: * **Language**: Set to *English (US)*. -* **Content rewrite**: Select this option if you are okay with your editor rewriting your text for improved flow and natural use of langauge. If this option is *not* selected, your editor will simply check for spelling, grammar, punctuation, consistency, and structure. -* **Brief to editor**: Provide any information you'd like your editor to keep in mind when editing your work. For a starter snippet, please see our sample on [Notes to Wordy Editors](wordy-guide.md) +* **Content rewrite**: Select this option if you are okay with your editor rewriting your text for improved flow and natural use of language. If this option is *not* selected, your editor will simply check for spelling, grammar, punctuation, consistency, and structure. +* **Brief to editor**: Provide any information you would like your editor to keep in mind when editing your work. For a starter snippet, please see our sample on [Notes to Wordy Editors](wordy-guide.md) * **Save my brief and language settings for future jobs**: Select this box to persist your chosen settings. 5. Upload files. You may choose to upload external files containing your text or paste in the text you want edited. -6. After you've completed the above steps, you'll get an instant price quote and an approximate delivery time for your job. If this is acceptable to you, click on **Create Job** to begin the editing process. +6. After you have completed the above steps, you will get an instant price quote and an approximate delivery time for your job. If this is acceptable to you, click on **Create Job** to begin the editing process. ### Word Count and Wordy Submissions @@ -386,7 +408,7 @@ It is helpful to include some instructions for the Wordy editors to let them kno ### Notes -* You can cancel a job if it hasn’t been picked up by an editor. If the job has been picked up, you can contact the editor and request a cancellation, though it is at the editor's discretion whether or not to cancel the job. +* You can cancel a job if it has not been picked up by an editor. If the job has been picked up, you can contact the editor and request a cancellation, though it is at the editor's discretion whether or not to cancel the job. * During the editing process, you can contact your editor from the job's page. You can include last-minute instructions, corrections, and so on. Conversely, your editor can contact you during the process if they have any questions about your text. You will be notified by email if you receive any messages. * If you are unsatisfied with the work completed by your editor, you can send your work back. This includes issues where you find errors in the text or the instructions in your brief haven't been followed. You can contact your editor by using the **Conversation History** feature on the job's page. @@ -474,7 +496,7 @@ hidden_articles: ### Quickstart Guidelines -Each framework will have a set of articles that comprise the quickstarts. The set of articles each framework will have depends on the function of each. Below is an outline of the documentats that should be created for each framework. +Each framework will have a set of articles that comprise the quickstarts. The set of articles each framework will have depends on the function of each. Below is an outline of the documents that should be created for each framework. #### Library References @@ -484,19 +506,19 @@ Additionally, many libraries may also need manual documentation showing more sop #### Quickstarts Articles -Each framework will have a set of articles that comprise the quickstarts. The set of articles each framework will have depends on the function of each. Below is an outline of the documentats that should be created for each framework. +Each framework will have a set of articles that comprise the quickstarts. The set of articles each framework will have depends on the function of each. Below is an outline of the documents that should be created for each framework. ##### Native 0. Intro - Introduction and summary of what the quickstart is about and a Table of Contents 1. Login - Shows how to create an auth0 application, add the login widget to your code, setup everything, and perform a login. 2. Login with Custom UI - Using head-less library to do login without Lock -3. Session Handling - How to store tokens, refresh tokens, and logout +3. Session Handling - How to store tokens, Refresh Tokens, and logout 4. User Profile - How to access the user profile from within the app. The core concepts of this are how to retrieve profile data as well as any claims that are present in the token. 5. Linking Accounts - How to link two accounts using both the lock widget or using the API manually. 6. Rules - Using rules to change what is in the token. This document is likely shared with all quickstarts[a]. 7. Authorization - How to pull scope or other access control claims from the token and use those claims to authorize a user to perform certain actions in the application.[b] -8. Calling Your API - How to take the access token from +8. Calling Your API - How to take the Access Token from 9. MFA - how to add MFA to your app. This should probably be a single document that is shared with all native apps[c]. 10. Customizing Lock - Document explaining the basics of how to custom lock. There are full documents about this as well that show the complete details. @@ -510,7 +532,7 @@ Each framework will have a set of articles that comprise the quickstarts. The se 5. Linking Accounts - How to link two accounts using both the lock widget or using the API manually. 6. Rules - Using rules to change what is in the token. This document is likely shared with all quickstarts. 7. Authorization - How to pull scope or other access control claims from the token and use those claims to authorize a user to perform certain actions in the application. -8. Multifactor Authentication - how to add MFA to your app. This should probably be a single document that is shared with all native apps. +8. Multi-factor Authentication - how to add MFA to your app. This should probably be a single document that is shared with all native apps. 9. Customizing Lock - Document explaining the basics of how to custom lock. There are full documents about this as well that show the complete details. ##### SPA @@ -523,7 +545,7 @@ Each framework will have a set of articles that comprise the quickstarts. The se 5. Linking Accounts - How to link two accounts using both the lock widget or using the API manually. 6. Rules - Using rules to change what is in the token. This document is likely shared with all quickstarts. 7. Authorization - How to pull scope or other access control claims from the token and use those claims to authorize a user to perform certain actions in the application. This section will include information on how to use rules and authorization together. -8. Calling Your API - How to take the access token from +8. Calling Your API - How to take the Access Token from 9. MFA - how to add MFA to your app. This should probably be a single document that is shared with all native apps. 10. Customizing Lock - Document explaining the basics of how to customize lock. There are full documents about this as well that show the complete details. @@ -534,7 +556,7 @@ Each framework will have a set of articles that comprise the quickstarts. The se #### Libraries -As appropriate every framework/language should have libraries to help with common functions. THese libraries will include things like: +As appropriate, every framework/language should have libraries to help with common functions. These libraries will include things like: * Management API Libraries * Authentication API Libraries @@ -563,7 +585,7 @@ In this way, each section of the quickstart has a sample showing the appropriate ##### Sample README’s -The README for each sample folder should be written to reflect the objectives of the sample and should also show some important code snippets. The goal is to give the reader context in a quick and concise way while outlining exactly what learning outcomes can be expected. It’s important to make content within each README specific to the subject sample. +The README for each sample folder should be written to reflect the objectives of the sample and should also show some important code snippets. The goal is to give the reader context in a quick and concise way while outlining exactly what learning outcomes can be expected. It is important to make content within each README specific to the subject sample. * **Example**: 02-User-Profile * **Title**: “User Profile” @@ -587,18 +609,18 @@ Each sample repo should have appropriate CI setup. You should use the appropriat In the case of things like iOS and Android samples, we should build with multiple version of Android/Xcode, etc. You can see an example here: 1. No need to write code or specialized guide for mobile -2. We don't have a lot of stuff finished to be doing this one in mobile. +2. We do not have a lot of stuff finished to be doing this one in mobile. 3. No need to write code or specialized guide for mobile until we allow users to enroll mfa from mobile apps. Currently is web only ### Seed Projects -Each quickstart should have a seed project. The seed projects are hosted in github in the `auth0-samples` organization. In order to add a seed project to a quickstart simply use the `_package` include. +Each quickstart should have a seed project. The seed projects are hosted on github in the `auth0-samples` organization. In order to add a seed project to a quickstart simply use the `_package` include. The seed project packager service replaces placeholder configuration values with the values of the user's real application. This means the sample is ready to use without additional configuration. The strings that get set are shown below. These values can be replaced in any file in the repo. Common examples of where you would include these values are in a `.env` file or `auth0-variables.js` file. In addition to replacement in the file directly, you can also include a template file in the form of `filename.ext.example` such as `auth0-variables.js.example`. The packager will do the replacement and remove the `.example` extension from the file. -**NOTE:** It is a best practice to use the `.example` method and include the 'real' file in the '.gitignore' so that if the end-user turns the sample into a git repo, the Auth0 keys wont get checked into source control. You should include the `.gitignore` file in the actual seed project folder, not at the repo root. This way it is included in the seed package. +**NOTE:** It is a best practice to use the `.example` method and include the 'real' file in the '.gitignore' so that if the end-user turns the sample into a git repo, the Auth0 keys won't get checked into source control. You should include the `.gitignore` file in the actual seed project folder, not at the repo root. This way it is included in the seed package. | Key Name | Replace Value | Description | | :------| :-----------| :-----------| @@ -608,7 +630,7 @@ These values can be replaced in any file in the repo. Common examples of where y | `TENANT` | `{TENANT}` | The tenant name of the currentAuth0 account. | `CALLBACK_URL` | `{CALLBACK_URL}` | This sets the callback url for the application. | | `MOBILE_CUSTOM_SCHEME` | `{MOBILE_CUSTOM_SCHEME}` | This a unique ID for mobile apps. The string is `a0` + the value of the client ID. | -| `RANDOM_STRING_64` | `{RANDOM_STRING_64}` | This is a random string. Typically used for things like encryption keys, etc. For security reasons we set this with a reasonable default so if end-users forget to change them, they wont all be something like `YOUR_ENCRYPTION_KEY`. | +| `RANDOM_STRING_64` | `{RANDOM_STRING_64}` | This is a random string. Typically used for things like encryption keys, etc. For security reasons, we set this with a reasonable default so if end-users forget to change them, they won't all be something like `YOUR_ENCRYPTION_KEY`. | Example `.env` file: @@ -757,10 +779,9 @@ When writing docs you can use the following variables instead of hard-coding the | Variable | Description | Default Value | | :---------------------------- | :----------------------------------------- | :-------------------------------------- | | `manage_url` | The url to the management portal. | `https://manage.auth0.com` | -| `auth0js_url` | The url to the auth0.js v7 CDN location. | | +| `auth0js_url` | The url to the auth0.js CDN location. | | | `auth0js_urlv8` | The url to the auth0.js v8 CDN location. | | | `lock_url` | The url to the Lock script CDN location. | | -| `lock_passwordless_url` | The url to the Passwordless Lock script CDN location. | | | `env.DOMAIN_URL_SUPPORT` | Support Center URL | `https://support.auth0.com` | ### User Specific Variables @@ -867,7 +888,7 @@ example/ index.yml ``` -This limitation is a result of the implementation of `AutoVersionPlugin`, and how the paths are calculated for the different versions. Fixing this is possible, but makes things a little more tricky, so I decided to cut it from the first version of the feature. If it's a desired behavior we can always add it later. +This limitation is a result of the implementation of `AutoVersionPlugin`, and how the paths are calculated for the different versions. Fixing this is possible, but makes things a little more tricky, so I decided to cut it from the first version of the feature. If it is a desired behavior we can always add it later. #### Case Sensitive diff --git a/LICENSE b/LICENSE index 0d651713af..9595798aa0 100644 --- a/LICENSE +++ b/LICENSE @@ -1,6 +1,6 @@ The MIT License (MIT) -Copyright (c) 2015 Auth0, Inc. (http://auth0.com) +Copyright (c) 2015-present Auth0, Inc. (http://auth0.com) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/README.md b/README.md index 46ec9f5e12..1388ddcc84 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,29 @@ # Auth0 Documentation -This is the repository for the Auth0 documentation. + +This repository contains the Auth0 Quickstarts, but most other documentation content in this repository is no longer up to date, and is not the source of content at https://auth0.com/docs. Pull requests and issues for Quickstarts can still be submitted here, but most other content is no longer hosted on GitHub and therefore no longer open-source. If you are an Auth0 employee trying to make a change to other documentation, please [submit a ticket](https://auth0team.atlassian.net/servicedesk/customer/portal/9) or contact the Documentation Team to request access to our content management system. + **Please review the [Contributing Guidelines](CONTRIBUTING.md) before sending a PR or opening an issue.** -## Running the Docs Site -You can run and test the docs site locally (you will need access - only employees). For instructions on running the site and testing see the [README](https://github.com/auth0/auth0-docs/blob/master/README.md) (requires Auth0 team access). +* If you are looking for the application that *hosts* the Docs content, see [auth0-docs](https://github.com/auth0/auth0-docs). +* If you would like to modify the Management API v2 API docs, they are generated from the [api2](https://github.com/auth0/api2) repository. + +Both of the above repositories require team access. + +## Editing Docs Content +Auth0 Docs are no longer maintained in this Github repository. Employees can request access to our content management system to update Docs directly. Outside contributors can submit requests under the [Issues](https://github.com/auth0/docs/issues) section in this repository. + +## Editing Quickstart Content + +* You can edit the Quickstarts by using the GitHub web editor and editing a file. This is best suited for typos and small changes. +* You can also pull down the `/docs` repo to your computer via Git and edit files in your local editor before pushing a new branch (or a branch to your own fork of the project). You can then go to GitHub.com and start a PR. We will be able to review the changes in a Heroku test application prior to merging. +* Lastly, you can [run and test the docs site locally](https://github.com/auth0/auth0-docs/blob/master/README.md) (access available to Auth0 employees only). This option is best suited for repeat contributors or for complex contributions. You gain the benefit of locally testing and viewing your changed or added pages, navigation, and config, but you also gain the complexity of dealing with the local docs app, setting it up, and keeping it updated. + +Regardless of which option you use, please review any relevant sections of the [Contributing Guidelines](CONTRIBUTING.md) before sending a PR. ## Issue Reporting -If you found a bug or have a feature request, please report it in this repository's [issues](https://github.com/auth0/docs/issues) section. Please do not report security vulnerabilities on the public GitHub issue tracker. The [Responsible Disclosure Program](https://auth0.com/whitehat) details the procedure for disclosing security issues. +If you find a bug or inaccuracy in the documentation content, please report it in this repository's [issues](https://github.com/auth0/docs/issues) section. Please do not report security vulnerabilities on the public GitHub issue tracker. The [Responsible Disclosure Program](https://auth0.com/whitehat) details the procedure for disclosing security issues. ## Author diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md index 65e8b094e0..12a59bbc8c 100644 --- a/STYLEGUIDE.md +++ b/STYLEGUIDE.md @@ -2,59 +2,59 @@ This style guide covers the terminology and content specific to Auth0, along with some comments on common writing issues. -For general software-industry styles and terminology, see the [Microsoft Manual of Style](https://eucalyptus.atlassian.net/wiki/download/attachments/76611622/microsoft_manual_of_style_fourth_edition.pdf?version=2&modificationDate=1424379604164&api=v2). +For general software-industry styles and terminology, see the [Microsoft Writing Style Guide](https://docs.microsoft.com/en-us/style-guide/welcome/). ## Voice -* Address the reader directly: "you". Use "we" only for Auth0's recommendations. -* Use active voice. -* For instructions, use imperative mood. +* Address the reader directly: "you". Use "we" only for Auth0's recommendations. +* Use the active voice. +* For instructions, use the imperative mood. | **Incorrect** | **Correct** | | --- | --- | | User authentication data should be saved.| Save user authentication data. | -| Saving user authentication data is recommended. | We recommend that you save user authentication data. | +| Saving user authentication data is recommended. | We recommend that you save user authentication data. | -* Use gender-neutral pronouns: "they", "their". +* Use gender-neutral pronouns: "they", "their". | **Incorrect** | **Correct** | | --- | --- | | The user enters his password. | The user enters their password. | -* Avoid gerunds in headings and main body. +* Avoid gerunds in headings and the main body. | **Incorrect** | **Correct** | | --- | --- | -| Saving User Authentication Data | Save User Authentication Data | -| Setting up the authorization process requires an ID token and a valid access token. | To set up the authorization process, you need an ID token and a valid access token. | +| Saving User Authentication Data. | Save User Authentication Data. | +| Setting up the authorization process requires an ID Token and a valid Access Token. | To set up the authorization process, you need an ID Token and a valid Access Token. | ## Body text -* Keep paragraphs short for internet reading. +* Keep paragraphs short for internet reading. * Provide only the information necessary to understand and perform the steps. | **Incorrect** | **Correct** | | --- | --- | | Authentication using JSON Web Tokens is stateless by nature, meaning that there is no information about the user's session stored on your server.| Authentication using JSON Web Tokens is stateless. This means that when you use it, no information about user session is stored on your server. | -| In this way, setting up a session for the user on the client side is simply a matter of saving the `access_token`, `id_token`, and a time that the `access_token` expires at in browser storage. | To set up a session for the user on the client side, save the following information in browser storage: `access_token`, `id_token`, `expires_in`. | +| In this way, setting up a session for the user on the client side is simply a matter of saving the Access Token, ID Token, and a time that the Access Token expires at in browser storage. | To set up a session for the user on the client side, save the following information in browser storage: `access_token`, `id_token`, `expires_in`. | -* When mentioning several elements, use bulleted lists. -* Subheads are not independent statements. Repeat the information from the subhead in the paragraph. +* When mentioning several elements, use bulleted lists. +* Subheads are not independent statements. Repeat the information from the subhead in the paragraph. * Avoid abbreviations. | **Incorrect** | **Correct** | | --- | --- | | Don't hardcode paths in your application, e.g., the callback URL. | Don't hardcode paths in your application, for example, the callback URL. | -| Save all the important credentials: the access token, the refresh token, etc. in a safe location. | Save all the important credentials, such as the access and refresh token, in a safe location. | +| Save all the important credentials: the Access Token, the Refresh Token, etc. in a safe location. | Save all the important credentials, such as the Access and Refresh Token, in a safe location. | -* Avoid contractions. Use complete words to be more authoritative. +* Avoid contractions. Use complete words to be more authoritative. | **Incorrect** | **Correct** | | --- | --- | | Can't | Cannot | * Don't overuse adjectives. Never use more than two in a sentence. -* Don't overuse adverbs. +* Don't overuse adverbs. | **Incorrect** | **Correct** | | --- | --- | @@ -64,21 +64,21 @@ For general software-industry styles and terminology, see the [Microsoft Manual ## Punctuation * Use colons to introduce code or examples: "Install the dependencies using yarn: `code_snippet`" -* Use hyphens between adjectives and the verbs they modify. Don't use a hyphen if the adjective ends with "ly". +* Use hyphens between adjectives and the verbs they modify. Don't use a hyphen if the adjective ends with "ly". | **Incorrect** | **Correct** | | --- | --- | | "an easy to remember rule" | "an easy-to-remember rule" | | "commonly-used adjectives" | "commonly used adjectives" | -* When you are quoting something in a sentence, keep the punctuation inside the quotation marks. -* When you are quoting code, do not add any punctuation inside the quotation marks. +* When you are quoting something in a sentence, keep the punctuation inside the quotation marks. +* When you are quoting code, do not add any punctuation inside the quotation marks. ## Formatting * Use title case for first-level headings: "Log In with a Social Identity" * Use sentence case for subheads: "About the login process" -* Use **Bold** for UI elements, such as menu items and field names. +* Use **Bold** for UI elements, such as menu items and field names. | **Incorrect** | **Correct** | | --- | --- | @@ -90,17 +90,17 @@ For general software-industry styles and terminology, see the [Microsoft Manual | **Incorrect** | **Correct** | | --- | --- | | Save the "idToken" value in your client properties. | Save the `idToken` value in your client properties. | -| An `idToken` helps you identify the user. | An ID token helps you identify the user. | +| An `idToken` helps you identify the user. | An ID Token helps you identify the user. | -* The text of a link must include the title of the linked page. This helps the reader decide if they want to click on the link. +* The text of a link must include the title of the linked page. This helps the reader decide if they want to click on the link. | **Incorrect** | **Correct** | | --- | --- | | You can read more about this feature [here](/rules). | Read more about this feature in the [Rules documentation](/rules). | * Use blockquotes only for quotes. Don't use them for component styles. -* When you are referring to specific dates, abbreviate the following months: January (Jan.), February (Feb.), August (Aug.), September (Sept.), October (Oct.), November (Nov.), December (Dec.). -* When you are referring to a month alone or a month and a year, don't abbreviate the month. +* When you are referring to specific dates, abbreviate the following months: January (Jan.), February (Feb.), August (Aug.), September (Sept.), October (Oct.), November (Nov.), December (Dec.). +* When you are referring to a month alone or a month and a year, don't abbreviate the month. | **Incorrect** | **Correct** | | --- | --- | @@ -110,10 +110,20 @@ For general software-industry styles and terminology, see the [Microsoft Manual | Mar. 15 | March 15 | | 15 March 2048 | March 15, 2048 | -* Spell out whole numbers from zero to nine. -* Write numerically numbers from 10 up and fractions. -* Spell out any number that starts a sentence. -* If one number follows another immediately, spell out the first number. +* Endpoint names should be capitalized when used in-text: Discovery endpoint, Authorization endpoint, Token endpoint. +* Endpoints with names longer than one or two words should also be capitalized with the exception of prepositions and articles (i.e. with, to, the, a, an) such as Update a Hook endpoint. +* Endpoint names denoted as a path should not be capitalized but should be in monospace font: `/authorize,` `/post_user_import,` `/clients.` + +| **Incorrect** | **Correct** | +| --- | --- | +| You will need to access the discovery endpoint. | You will need to access the Discovery endpoint.| +| The get user endpoint allows you to search based on a variety of criteria. | The Get User endpoint allows you to search based on a variety of criteria. | +| The POST /login/callback endpoint can accept a sing-on SAML request from an identity provider. | The POST '/login/callback' endpoint can accept a sing-on SAML request from an identity provider. | + +* Spell out whole numbers from zero to nine. +* Write numerically numbers from 10 up and fractions. +* Spell out any number that starts a sentence. +* If one number follows another immediately, spell out the first number. | **Incorrect** | **Correct** | | --- | --- | @@ -122,16 +132,16 @@ For general software-industry styles and terminology, see the [Microsoft Manual | 14 plugins are available. | Fourteen plugins are available. | | Configure 12 50GB drives | Configure twelve 50GB drives. | -* For additional information that is up to four lines long, use [notes](/blob/master/CONTRIBUTING.md#note). -* For additional information that is longer than four lines, use [panels](https://github.com/auth0/docs/blob/master/CONTRIBUTING.md#panels). -* For critical security information up to four lines long, use [warnings](https://github.com/auth0/docs/blob/master/CONTRIBUTING.md#warning). -* For critical security information longer than four lines, use [panel warnings](https://github.com/auth0/docs/blob/master/CONTRIBUTING.md#panel-warning). +* For additional information that is up to four lines long, use [notes](CONTRIBUTING.md#note). +* For additional information that is longer than four lines, use [panels](CONTRIBUTING.md#panels). +* For critical security information up to four lines long, use [warnings](CONTRIBUTING.md#warning). +* For critical security information longer than four lines, use [panel warnings](CONTRIBUTING.md#panel-warning). ## Vocabulary -* If an action is required, use "must". -* If an action is available, use "can". -* If an action is optional, use "may". +* If an action is required, use "must". +* If an action is available, use "can". +* If an action is optional, use "may". | **Incorrect** | **Correct** | | --- | --- | @@ -139,8 +149,8 @@ For general software-industry styles and terminology, see the [Microsoft Manual | You might want to use scopes to limit access to your resources. | To limit access to your resources, use scopes. | | Creating more access roles is possible. | You may want to create more access roles. | -* Use "log in" and "log out" as verbs. Do not use "log into". -* Use "login" and "logout" as nouns. Do not use "login to". +* Use "log in" and "log out" as verbs. Do not use "log into". +* Use "login" and "logout" as nouns. Do not use "login to". | **Incorrect** | **Correct** | | --- | --- | @@ -155,8 +165,8 @@ For general software-industry styles and terminology, see the [Microsoft Manual | Setup the login screen. | Set up the login screen. | | Edit the login screen set-up to display the **Log in** button. | Edit the login screen setup to display the **Log in** button. | -* Use "multifactor authentication" instead of "multi-factor authentication". -* Use "email address" instead of "e-mail address". +* Use "multi-factor authentication" instead of "multifactor authentication". +* Use "email address" instead of "e-mail address". * Use "website" instead of "web site". * Use "click on" when referring to text links in a webpage or UI. Use "click" when referring to a button. @@ -166,7 +176,7 @@ For general software-industry styles and terminology, see the [Microsoft Manual | Click **Go to Settings** at the bottom of the page to access the settings section. | Click on **Go to Settings** at the bottom of the page to access the settings section. | * Depending on the situation, the reader can "gain access", "grant access", or "allow access". -* Refer to the developer's customer as the "user". +* Refer to the developer's customer as the "user". * If you need to use the name of a fictional company, use "ExampleCo". * When you use a group of nouns as an adjective, use a hyphen. @@ -176,13 +186,13 @@ For general software-industry styles and terminology, see the [Microsoft Manual | The run-time engine must be running to execute the application. | The runtime engine must be running to execute the application. | | Write code for the client-side. | Write code for the client side. | | Write the client side code. | Write the client-side code. | -| Save the logged in user's access token. | Save the logged-in user's access token. | +| Save the logged in user's Access Token. | Save the logged-in user's Access Token. | ### The dashboard -* Dashboard: the [Auth0 management console](${manage_url}) -* The dashboard elements are called "section", "tab", "field". -* Dashboard-related terminology: +* Dashboard: the [Auth0 management console](${manage_url}). +* The dashboard elements are called "section", "tab", "field". +* Dashboard-related terminology: ![](/media/readme/structure.png) ### The application @@ -191,4 +201,4 @@ For general software-industry styles and terminology, see the [Microsoft Manual * Tenant: a logical isolation unit of the products we offer. Examples of Auth0 tenants: `foo.auth0.com`, `bar.auth0.com` * Auth0 tenants: regular cloud tenants * Subscription: a contract or service plan. Examples of subscriptions: trial, free, developer or developer-pro -* Private instances: appliance instances \ No newline at end of file +* Private Cloud/Managed Private Cloud: single-tenant deployment diff --git a/WORDS.md b/WORDS.md index 6e754976ff..4764298894 100644 --- a/WORDS.md +++ b/WORDS.md @@ -4,7 +4,7 @@ This document contains spellings and definitions as they are to be used in the A - **Login / Log in**: Use *log in* as a verb, or *login* as a noun. Do NOT use *log into* or *login to*. - **Logout / Log out**: Use *log out* as a verb, or *logout* as a noun. - **Setup / Set up**: Use *set up* as a verb, or *setup* as a noun. -- **Multifactor**: Use instead of multi-factor in the case of multifactor authentication. +- **Multi-factor**: Use *multi-factor* instead of *multifactor* in the case of multi-factor authentication. - **Rollout / Roll out**: Use *rollout* as a noun and *roll out* as a verb. Do not use `roll-out`. - **Email**: Use the un-hyphenated "email" to refer to an email address. - **Click**: Use "Click on" when referring to text links in a webpage or UI, "Click" when referring to a button. For example: Click **Save**. Click on **This link**. @@ -39,10 +39,10 @@ When writing about tokens, capitalize specific token names as follows: * Access Token * Refresh Token -#### Within Appliance subscriptions +#### Within Private Cloud subscriptions * **Auth0 tenants** refers to regular cloud tenants -* **Private instances** refers to appliance instances +* **Private Cloud** or **Managed Private Cloud** refers to a single-tenant deployment ### TL;DR diff --git a/app.json b/app.json index 0b45ad2eb6..838727dbce 100644 --- a/app.json +++ b/app.json @@ -2,6 +2,12 @@ "name": "auth0-docs-content", "scripts": { }, + "formation": { + "web": { + "quantity": 1, + "size": "standard-2x" + } + }, "env": { "NPM_CONFIG_PRODUCTION": { "required": true @@ -15,6 +21,9 @@ "HEROKU_APP_NAME": { "required": true }, + "HEROKU_PARENT_APP_NAME": { + "required": true + }, "GIT_SSH_KEY": { "required": true } diff --git a/articles/_includes/_api-auth-customize-tokens.md b/articles/_includes/_api-auth-customize-tokens.md index 460c8a3a61..0c5ca2a2e3 100644 --- a/articles/_includes/_api-auth-customize-tokens.md +++ b/articles/_includes/_api-auth-customize-tokens.md @@ -15,5 +15,5 @@ function(user, context, callback) { ``` ::: panel-warning Namespacing Custom Claims -Auth0 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). This means that 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 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`. You can [add namespaced claims using Rules](#optional-customize-the-tokens). +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/articles/_includes/_api_auth_intro.md b/articles/_includes/_api_auth_intro.md index ede006191a..c7b3365570 100644 --- a/articles/_includes/_api_auth_intro.md +++ b/articles/_includes/_api_auth_intro.md @@ -1,2 +1,3 @@ -This tutorial shows you how to use the authorization features in the OAuth 2.0 framework to limit access to your or third-party applications. -For more information, read the [API authorization](/api-auth) documentation. \ No newline at end of file +::: note +**New to Auth0?** Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework. +::: diff --git a/articles/_includes/_callback_url.md b/articles/_includes/_callback_url.md index 662815992b..3d4851c568 100644 --- a/articles/_includes/_callback_url.md +++ b/articles/_includes/_callback_url.md @@ -1,5 +1,5 @@ -## Configure Callback URLs + -A callback URL is a URL in your application where Auth0 redirects the user after they have authenticated. +### Configure Callback URLs -You need to whitelist the callback URL for your app in the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). If you do not set any callback URL, your users will see a mismatch error when they log in. \ No newline at end of file +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. If this field is not set, users will be unable to log in to the application and will get an error. diff --git a/articles/_includes/_checksession_polling.md b/articles/_includes/_checksession_polling.md new file mode 100644 index 0000000000..9030fb5770 --- /dev/null +++ b/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/articles/_includes/_co_authenticate_errors.md b/articles/_includes/_co_authenticate_errors.md index 3f0ba837a4..af87d27465 100644 --- a/articles/_includes/_co_authenticate_errors.md +++ b/articles/_includes/_co_authenticate_errors.md @@ -12,7 +12,6 @@ The error description is human readable. It **should not be parsed by any code** | 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 | Invalid user credentials. | | 403 | access_denied | Wrong email or password. | | 403 | access_denied | Authentication error | | 403 | blocked_user | Blocked user | diff --git a/articles/_includes/_contact-sales.md b/articles/_includes/_contact-sales.md index 5cbeffc9e2..b5a08e1e82 100644 --- a/articles/_includes/_contact-sales.md +++ b/articles/_includes/_contact-sales.md @@ -1,3 +1,3 @@ ## More Information -If you have specific support requirements or need more information on the Professional Services we offer, please [contact sales](https://auth0.com/?contact=true). +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/articles/_includes/_create_resource_server.md b/articles/_includes/_create_resource_server.md index 95ca7cf19e..e879837b6a 100644 --- a/articles/_includes/_create_resource_server.md +++ b/articles/_includes/_create_resource_server.md @@ -1,10 +1,10 @@ ## 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)](/jwks) standard and also view the [public key](https://${account.namespace}/.well-known/jwks.json) for your Auth0 account (https://${account.namespace}/.well-known/jwks.json). +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. +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. @@ -12,7 +12,7 @@ Install the dependencies. 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. +Create a middleware which uses **express-jwt** and **jwks-rsa** to verify the Access Token against your JWKS endpoint. ```js const express = require('express'); @@ -21,7 +21,7 @@ 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 singing keys provided by the JWKS endpoint. + // 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, @@ -47,4 +47,4 @@ 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. \ No newline at end of file +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/articles/_includes/_deprecate-delegation.md b/articles/_includes/_deprecate-delegation.md new file mode 100644 index 0000000000..7317d51f14 --- /dev/null +++ b/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/articles/_includes/_deprecate-impersonation.md b/articles/_includes/_deprecate-impersonation.md index 616d8c4284..4f58b1bb31 100644 --- a/articles/_includes/_deprecate-impersonation.md +++ b/articles/_includes/_deprecate-impersonation.md @@ -1,3 +1,3 @@ -:::warning -Impersonation has been deprecated and will not be enabled for customers any longer. The functionality will continue to work for the customers that have it already enabled. If this changes customers will be notified beforehand and given ample time to migrate. -::: \ No newline at end of file +::: 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/articles/_includes/_email-domain-blacklist.md b/articles/_includes/_email-domain-blacklist.md new file mode 100644 index 0000000000..1fdcdd1fc2 --- /dev/null +++ b/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/articles/_includes/_embedded_login_warning.md b/articles/_includes/_embedded_login_warning.md new file mode 100644 index 0000000000..f37d242c2d --- /dev/null +++ b/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/articles/_includes/_enable-third-party-apps-info.md b/articles/_includes/_enable-third-party-apps-info.md new file mode 100644 index 0000000000..e540021871 --- /dev/null +++ b/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/articles/_includes/_enforce-claim-namespacing.md b/articles/_includes/_enforce-claim-namespacing.md new file mode 100644 index 0000000000..3b593d6ccf --- /dev/null +++ b/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/articles/_includes/_http-method.html b/articles/_includes/_http-method.html index 42cf02bee8..cacd38d8f0 100644 --- a/articles/_includes/_http-method.html +++ b/articles/_includes/_http-method.html @@ -1,4 +1,4 @@ -
+

${http_method} ${path} -

\ No newline at end of file + \ No newline at end of file diff --git a/articles/_includes/_ip_whitelist.md b/articles/_includes/_ip_whitelist.md new file mode 100644 index 0000000000..a3d9ad21b8 --- /dev/null +++ b/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/articles/_includes/_libraries_support_frameworks.html b/articles/_includes/_libraries_support_frameworks.html index f9a1dccec6..b14527fae5 100644 --- a/articles/_includes/_libraries_support_frameworks.html +++ b/articles/_includes/_libraries_support_frameworks.html @@ -23,27 +23,7 @@
Supported
- Auth0 Spring MVC - v1 -
Supported
- - - Auth0 Spring Security MVC - v1 -
Supported
- - - Auth0 Spring Security API - v1 -
Supported
- - - Auth0 ASP.NET 4.5 Owin - v2 -
Supported
- - - Auth0 ASP.NET + Auth0 Java MVC Common v1
Supported
@@ -57,15 +37,5 @@ v3
Supported
- - Auth0 with UWP applications - v1 -
Community
- - - Auth0 application for Winforms and WPF - v0.9 -
Community
- diff --git a/articles/_includes/_libraries_support_lock.html b/articles/_includes/_libraries_support_lock.html index 54a62fd2f9..b23b2b155f 100644 --- a/articles/_includes/_libraries_support_lock.html +++ b/articles/_includes/_libraries_support_lock.html @@ -18,7 +18,7 @@
Supported
- + Lock.Android v1
Bug fixes
@@ -27,7 +27,7 @@ v2
Supported
- + Lock for iOS v1 v1
Bug fixes
diff --git a/articles/_includes/_libraries_support_sdks.html b/articles/_includes/_libraries_support_sdks.html index 662bb4932a..9fae1bad76 100644 --- a/articles/_includes/_libraries_support_sdks.html +++ b/articles/_includes/_libraries_support_sdks.html @@ -7,6 +7,16 @@ + + Auth0 Single Page Application SDK + v1 +
Supported
+ + + Auth0 React SDK + v1 +
Supported
+ Auth0.js v9 @@ -27,11 +37,6 @@ v4
Supported
- - - v3 -
Supported
- Auth0 Java v1 @@ -49,7 +54,7 @@ Auth0 PHP - v5 + v7.3
Supported
diff --git a/articles/_includes/_linking_accounts.md b/articles/_includes/_linking_accounts.md index 0ad13c36e4..547909a2a2 100644 --- a/articles/_includes/_linking_accounts.md +++ b/articles/_includes/_linking_accounts.md @@ -1,11 +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. For a detailed description of linking accounts, see the [full documentation](https://auth0.com/docs/link-accounts). +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 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. +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'`. \ No newline at end of file +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/articles/_includes/_lock_auth0js_deprecations_notice.md b/articles/_includes/_lock_auth0js_deprecations_notice.md index f989f7af01..9e03f9bb98 100644 --- a/articles/_includes/_lock_auth0js_deprecations_notice.md +++ b/articles/_includes/_lock_auth0js_deprecations_notice.md @@ -1,3 +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. The [Deprecation Guidance](/migrations/guides/legacy-lock-api-deprecation) page provides details about update recommendations. +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/articles/_includes/_login_auth0_hosted_login_page.md b/articles/_includes/_login_auth0_hosted_login_page.md index f4b21646f3..78c16d5875 100644 --- a/articles/_includes/_login_auth0_hosted_login_page.md +++ b/articles/_includes/_login_auth0_hosted_login_page.md @@ -1 +1 @@ -Auth0's [universal login](/hosted-pages/login) is the easiest way to set up authentication in your application. \ No newline at end of file +Auth0's [Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. diff --git a/articles/_includes/_logout_url.md b/articles/_includes/_logout_url.md new file mode 100644 index 0000000000..ed3e9ac189 --- /dev/null +++ b/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. 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/articles/_includes/_metadata_on_signup_warning.md b/articles/_includes/_metadata_on_signup_warning.md new file mode 100644 index 0000000000..1af9aab000 --- /dev/null +++ b/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/articles/_includes/_native_passwordless_warning.md b/articles/_includes/_native_passwordless_warning.md index 1465cf3fa5..04eaae8300 100644 --- a/articles/_includes/_native_passwordless_warning.md +++ b/articles/_includes/_native_passwordless_warning.md @@ -1,3 +1,3 @@ ::: warning -Passwordless functionality should not be embedded in native apps until Auth0 libraries can be updated to properly support it. Until that time, passwordless authentication can still be achieved by using [universal login](/connections/passwordless/native-passwordless-universal) via the web. +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/articles/_includes/_new_api.html b/articles/_includes/_new_api.html index 5ef9d7f6ff..924a36341f 100644 --- a/articles/_includes/_new_api.html +++ b/articles/_includes/_new_api.html @@ -1,5 +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.

+

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.

+

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/articles/_includes/_new_app.md b/articles/_includes/_new_app.md index 16b5983caf..4d390027eb 100644 --- a/articles/_includes/_new_app.md +++ b/articles/_includes/_new_app.md @@ -1,20 +1,28 @@ -## Get Your Application Keys +## Configure Auth0 +### Get Your Application Keys -<% if (!account.userName) { %> -The first step for integrating Auth0 in your app is to create an [account](${manage_url}/login). When you sign up for Auth0, you will be invited to create a new application. +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 section in the Auth0 dashboard. -<% } else { %> -When you signed up for Auth0, you created a new application. +<% 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 will need some details about this application to communicate with Auth0. You can get them from the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 dashboard. - + You need the following information: -* **Client ID** + * **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. If you have more than one application in your account, the sample comes with the values for your **Default App**. +If you download the sample from the top of this page, these details are filled out for you. ::: - -![App Dashboard](/media/articles/dashboard/client_settings.png) +<% } %> diff --git a/articles/_includes/_parental-consent.md b/articles/_includes/_parental-consent.md new file mode 100644 index 0000000000..eaa0337c61 --- /dev/null +++ b/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/articles/_includes/_rbac_methods.md b/articles/_includes/_rbac_methods.md new file mode 100644 index 0000000000..57feb5baa3 --- /dev/null +++ b/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/articles/_includes/_rbac_vs_extensions.md b/articles/_includes/_rbac_vs_extensions.md new file mode 100644 index 0000000000..58e7c0af76 --- /dev/null +++ b/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/articles/_includes/_refresh_token_rotation_panel.md b/articles/_includes/_refresh_token_rotation_panel.md new file mode 100644 index 0000000000..bb3221d0ff --- /dev/null +++ b/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/articles/_includes/_refresh_token_rotation_recommended.md b/articles/_includes/_refresh_token_rotation_recommended.md new file mode 100644 index 0000000000..5f52feeac1 --- /dev/null +++ b/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/articles/_includes/_samesite_none.md b/articles/_includes/_samesite_none.md new file mode 100644 index 0000000000..9449a343c0 --- /dev/null +++ b/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/articles/_includes/_test-this-endpoint.md b/articles/_includes/_test-this-endpoint.md index a6c6a1ff29..e2d873ea5d 100644 --- a/articles/_includes/_test-this-endpoint.md +++ b/articles/_includes/_test-this-endpoint.md @@ -1,5 +1,4 @@ -You can use our **Authentication API Debugger** extension to test this endpoint. In order to do so you need to be logged in and have installed the [Authentication API Debugger extension](/extensions/authentication-api-debugger). - + Click on **Install Debugger** to go to the article that explains how (you only have to do this once). <% diff --git a/articles/_includes/_token_signature.md b/articles/_includes/_token_signature.md new file mode 100644 index 0000000000..6af09f7685 --- /dev/null +++ b/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/articles/_includes/_users_update_normalized_profile_attributes.md b/articles/_includes/_users_update_normalized_profile_attributes.md new file mode 100644 index 0000000000..822a2e3d50 --- /dev/null +++ b/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/articles/_includes/_uses-delegation.md b/articles/_includes/_uses-delegation.md new file mode 100644 index 0000000000..2a157656f4 --- /dev/null +++ b/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/articles/_includes/_version_warning_api.md b/articles/_includes/_version_warning_api.md new file mode 100644 index 0000000000..bf86f5773c --- /dev/null +++ b/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/articles/_includes/_version_warning_auth0js.md b/articles/_includes/_version_warning_auth0js.md index e8dab61d10..3c6104e535 100644 --- a/articles/_includes/_version_warning_auth0js.md +++ b/articles/_includes/_version_warning_auth0js.md @@ -1,3 +1,3 @@ ::: version-warning -This document covers a deprecated version of Auth0.js. We recommend that you [migrate to Auth0.js v9](/libraries/auth0js/v9/migration-guide) as soon as possible. +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/articles/_includes/_version_warning_lock.md b/articles/_includes/_version_warning_lock.md index ed25f1ef8c..707490b682 100644 --- a/articles/_includes/_version_warning_lock.md +++ b/articles/_includes/_version_warning_lock.md @@ -1,3 +1,3 @@ ::: version-warning -This document covers a deprecated version of Lock. We recommend that you [migrate to Lock v11](/libraries/lock/v11/migration-guide) as soon as possible. +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/articles/_includes/_web_origins.md b/articles/_includes/_web_origins.md new file mode 100644 index 0000000000..27ba7150f1 --- /dev/null +++ b/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. 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. \ No newline at end of file diff --git a/articles/_includes/_webtask.md b/articles/_includes/_webtask.md new file mode 100644 index 0000000000..71356fc124 --- /dev/null +++ b/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/articles/addons/azure-blob-storage.md b/articles/addons/azure-blob-storage.md index 87b5cd1634..fa945a5c8b 100644 --- a/articles/addons/azure-blob-storage.md +++ b/articles/addons/azure-blob-storage.md @@ -1,21 +1,29 @@ --- 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 -tags: +topics: - quickstart + - azure + - addons articles: - authenticate -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Blob Storage. +contentType: how-to +description: Learn how to use Auth0 to authenticate and authorize Azure Blob Storage. +useCase: integrate-third-party-apps --- -# Azure Blob Storage Addon +# Azure Blob Storage Add-on -Here's a sample call to the delegation endpoint to get the SAS: +<%= 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 @@ -43,7 +51,7 @@ The result of calling the delegation endpoint will be something like: } ``` -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. +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/articles/addons/azure-mobile-services.md b/articles/addons/azure-mobile-services.md index 3e5f8dbbf0..2d88dd226a 100644 --- a/articles/addons/azure-mobile-services.md +++ b/articles/addons/azure-mobile-services.md @@ -1,6 +1,8 @@ --- -addon: Azure Mobile Services +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: @@ -12,14 +14,28 @@ alias: - windows-azure-vm - azure-websites - azure-vm -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Mobile Services. +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). --- -# Azure Mobile Services Addon +# Windows Azure Mobile Services Add-on + +<%= include('../_includes/_uses-delegation') %> ## 1. Create an application -WAMS endpoints can be used from anywhere. For example: [Android](/native-platforms/android), [iOS](/native-platforms/ios-objc), [Windows UWP C#](/native-platforms/windows-uwp-csharp), [JavaScript](/application-platforms/vanillajs) or [Windows Phone](/native-platforms/windowsphone). You can use any of these tutorials for configuring an app that interacts with WAMS. +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. @@ -37,7 +53,7 @@ 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 for with WAMS. +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. @@ -45,7 +61,7 @@ The `GetDelegationToken` call allows your app to interact with multiple WAMS 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. Using the user identity in the WAMS backend +## 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: diff --git a/articles/addons/azure-sb.md b/articles/addons/azure-sb.md index b2f233a130..da89208289 100644 --- a/articles/addons/azure-sb.md +++ b/articles/addons/azure-sb.md @@ -1,20 +1,28 @@ --- 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 -tags: +topics: - quickstart + - azure + - addons articles: - authenticate -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Service Bus. +contentType: how-to +useCase: integrate-third-party-apps +description: Learn how to use Auth0 to authenticate and authorize Azure Service Bus. --- -# Azure Service Bus Addon +# Azure Service Bus Add-on -Here's a sample call to the delegation endpoint to get the SAS: +<%= 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 diff --git a/articles/addons/index.md b/articles/addons/index.md index 2e30ba35c6..bd86928457 100644 --- a/articles/addons/index.md +++ b/articles/addons/index.md @@ -1,26 +1,48 @@ --- url: /addons -description: How to setup Application Addons, like Amazon Web Services and Azure Blob Storage, with your Auth0 app. +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 --- -# Auth0 Application Addons +# Add-ons -Addons are plugins associated with an Application in Auth0. Usually, they are 3rd party APIs used by the application that Auth0 generates Access Tokens for (such as Salesforce, Azure Service Bus, Azure Mobile Services, SAP, and so on). +<%= include('../_includes/_uses-delegation') %> -## How to configure an Addon +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). -Go to [Dashboard > Applications > Settings > Addons](${manage_url}/#/applications/${account.clientId}/addons) page and use the toggle to enable the add-on you want to configure. +Some typical scenarios for using add-ons include: -![Application Addons](/media/addons/manage-addons.png) +* **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. -Each integration is different and requires different parameters and configuration. Once the addon is activated, you will see tailored instructions with details on how to integrate with it in the dashboard. +* **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. -## Additional information for specific Addons +![Addons Example Diagram](/media/articles/applications/applications-addon-types.png) -- Amazon Web Services: For more info on how to use delegation with the AWS API Gateway, see the [AWS API Gateway](/integrations/aws-api-gateway/delegation) Tutorial -- [Azure Blob Storage](/addons/azure-blob-storage) -- [Azure Mobile Services](/addons/azure-mobile-services) -- [Azure Service Bus](/addons/azure-sb) -- [Salesforce (sandbox)](/addons/salesforce-sandbox) -- [Salesforce](/addons/salesforce) -- [SAP OData](/addons/sap-odata) +## 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/articles/addons/salesforce-sandbox.md b/articles/addons/salesforce-sandbox.md index b6a21106ce..79bd815fe1 100644 --- a/articles/addons/salesforce-sandbox.md +++ b/articles/addons/salesforce-sandbox.md @@ -1,19 +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: This tutorial will show you how to use the Auth0 to authenticate and authorize your Salesforce (Sandbox) services. +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) Addon +# 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. +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. + 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/articles/addons/salesforce.md b/articles/addons/salesforce.md index 4ecd389fa9..54aa6bb93e 100644 --- a/articles/addons/salesforce.md +++ b/articles/addons/salesforce.md @@ -1,16 +1,25 @@ --- addon: Salesforce +title: Salesforce Add-on alias: - salesforce url: addons/salesforce thirdParty: true +public: false image: /media/addons/salesforce.svg -description: This tutorial will show you how to use the Auth0 to authenticate and authorize your Salesforce services. +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 Addon +# 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. +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: @@ -23,7 +32,7 @@ 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. + 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/articles/addons/sap-odata.md b/articles/addons/sap-odata.md index b86909de42..4c5db1bcce 100644 --- a/articles/addons/sap-odata.md +++ b/articles/addons/sap-odata.md @@ -1,20 +1,30 @@ --- addon: SAP OData +title: SAP OData Add-on alias: - sap url: /addons/sap-odata image: /media/addons/sap_api.svg -description: This tutorial will show you how to use the Auth0 to authenticate and authorize your SAP OData services. +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 Addon +# 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. + 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/articles/analytics/_includes/_install.md b/articles/analytics/_includes/_install.md new file mode 100755 index 0000000000..4e86feb323 --- /dev/null +++ b/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/articles/analytics/_includes/_usage.md b/articles/analytics/_includes/_usage.md new file mode 100755 index 0000000000..9d4a7485c2 --- /dev/null +++ b/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/articles/analytics/guides/facebook-analytics.md b/articles/analytics/guides/facebook-analytics.md new file mode 100644 index 0000000000..bc4093476f --- /dev/null +++ b/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/articles/analytics/guides/google-analytics.md b/articles/analytics/guides/google-analytics.md new file mode 100644 index 0000000000..4367921202 --- /dev/null +++ b/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/articles/analytics/index.md b/articles/analytics/index.md new file mode 100755 index 0000000000..b40e0508b0 --- /dev/null +++ b/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/articles/analytics/integrations/_install.md b/articles/analytics/integrations/_install.md deleted file mode 100644 index a89abef1c4..0000000000 --- a/articles/analytics/integrations/_install.md +++ /dev/null @@ -1,17 +0,0 @@ -## 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.2.0 use `https://cdn.auth0.com/js/analytics/1.2.0/analytics.min.js`. To find the latest release, see the [releases on github](https://github.com/auth0/auth0-analytics.js/releases/). -::: \ No newline at end of file diff --git a/articles/analytics/integrations/_usage.md b/articles/analytics/integrations/_usage.md deleted file mode 100644 index 756e06685b..0000000000 --- a/articles/analytics/integrations/_usage.md +++ /dev/null @@ -1,19 +0,0 @@ -## Usage -After installation on your site there is nothing else you need to do to start collecting data. Auth0 Analytics will immedately 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 availible 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/v10/api). diff --git a/articles/analytics/integrations/facebook-analytics/index.md b/articles/analytics/integrations/facebook-analytics/index.md deleted file mode 100644 index 73c4463346..0000000000 --- a/articles/analytics/integrations/facebook-analytics/index.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -description: This article explains how to install and configure the Facebook Analytics for Auth0 integration. ---- -# Facebook Analytics for Auth0 - -This article explains how to install and configure the **Facebook Analytics for Auth0** integration. You can use this integration on your own page that is using [Lock](/libraries/lock) or you can use this on the [hosted Lock pages](/hosted-pages/login). Additionally, you will find instructions on how to configure funnels and reports inside of Facebook Analytics to get the most out of this integration. - -<%= include('../_install', { name: "Facebook Analytics" }) %> - -## Setup - -There are several ways you can use the Facebook Analytics integration. 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. - -### Using 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. - -``` - -``` - -### Using 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 availible. The configuration for using the pixel is shown below. - -``` - -``` - -<%= include('../_usage', { name: "Facebook Analytics" }) %> - -## Reporting - -For the most up to date information on using Facebook Analytics, check out the [Facebook Analytics documentation](https://www.facebook.com/help/analytics/1710582659188030). - -We recommend [creating funnels](https://www.facebook.com/help/analytics/935921203105136) to measure the success of your aquistion and registration flows using these new events. diff --git a/articles/analytics/integrations/google-analytics/index.md b/articles/analytics/integrations/google-analytics/index.md deleted file mode 100644 index ab2a5a414e..0000000000 --- a/articles/analytics/integrations/google-analytics/index.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -description: This article explains how to install and configure the Google Analytics for Auth0 integration. ---- -# Google Analytics for 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 or you can use this on the hosted Lock pages. Additionally, you will find instructions on how to configure funnels and reports inside of Google Analytics to get the most out of this integration. - -<%= include('../_install', { name: "Google Analytics" }) %> - -## Setup - -There are several ways you can use the Google Analytics integration. If you already have the Google Analytics Script on your site, configure Auth0 Analytics with the `preload` option as shown below. If you don't have Google Analytics loaded you need to set your Google Analytics ID using the Google Analytics configuration below. - -### Google Analytics Script Already Loaded (Recommended) - -If you have already loaded the Google Analytics script loaded on your site, configure Auth0 Analytics to not load it again as shown below. - -``` - -``` - -### No Google Analytics Script - -If you are not using Google Analytics already you can have the Auth0 Analytics script load Google Analytics for you. To do this you need to set your Google Analytics ID in the options as shown below. - -``` - -``` - -<%= include('../_usage', { name: "Google Analytics" }) %> - -## Reporting - -For the most up to date information on using Google Analytics, check out the [Google Analytics documentation](https://support.google.com/analytics). diff --git a/articles/analytics/integrations/index.md b/articles/analytics/integrations/index.md deleted file mode 100644 index 34325341e5..0000000000 --- a/articles/analytics/integrations/index.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -url: /analytics/integrations -section: articles -classes: topic-page -title: Analytics Integrations ---- - -
-
-

Analytics Integrations

-

- How to setup and configure analytics integrations with Auth0. -

-
- -Analytics tools help you track users on your site or application. The Auth0 Analytics integrations enable 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. - -
    -
  • - Facebook Analytics Integration -

    - This document will show you how to integrate Facebook Analytics into your application using either the Facebook JavaScript SDK or the Facebook Pixel. -

    -
    • -
  • - Google Analytics Integration -

    - This document will show you how to integrate Google Analytics into your application. -

    -
    • -
diff --git a/articles/anomaly-detection/breached-passwords.md b/articles/anomaly-detection/breached-passwords.md deleted file mode 100644 index 21e8182710..0000000000 --- a/articles/anomaly-detection/breached-passwords.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -description: Explains why a user received a breached password email and general web security tips. ---- - -# Breached Password Security - -## What happened that I received an email saying "Please change your password immediately"? - -Your account could have possibly been hacked, compromised or stolen by a third party application that experienced a security breach. This breach did not happen to this account, but based on available data, your credentials may have been released. Since many people reuse passwords, we wanted to make sure you stay protected. - -You may also want to change your password at any other sites that you suspect you used a shared password. -Here are 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) - -## General Security Tips - -You can't prevent certain sites from security breaches, but there are some things you can do to help keep your accounts safe. - -* **Check your emails carefully** -Make sure to check where an email is coming from, and the links that they provide. Often phishing emails do not include your name but something generic such as "Dear Customer". Always do a password reset through the actual site itself. -* **Never enter personal or financial information in an email** -Emails in general are not very secure, so this is not a good way to communicate sensitive information. A trusted company/application would not ask for your information in this way. Also watch out to make sure you are not entering confidential information through false the links provided in emails. A secure website always starts with “https”. -* **Never download files from unreliable sources** -Most web browsers detect suspicious sites, when you try to access a malicious site, an alert message will appear. Never download files from suspicious emails or websites. -* **Do not reuse passwords** -When one site has a breach of user data, if you use the same credentials elsewhere, your information in other sites can also be accessed. There are many password tools out there to help you keep track of passwords. -* **Use strong passwords** -The longer a password is, the harder it becomes to guess. 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 your applications, web browsers and operating system up to date can help prevent security breaches. \ No newline at end of file diff --git a/articles/anomaly-detection/concepts/breached-passwords.md b/articles/anomaly-detection/concepts/breached-passwords.md new file mode 100644 index 0000000000..92f077dc01 --- /dev/null +++ b/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/articles/anomaly-detection/guides/customize-blocked-account-emails.md b/articles/anomaly-detection/guides/customize-blocked-account-emails.md new file mode 100644 index 0000000000..1347250973 --- /dev/null +++ b/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/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md b/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md new file mode 100644 index 0000000000..e40844c3be --- /dev/null +++ b/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/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md b/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md new file mode 100644 index 0000000000..c4d5d0b291 --- /dev/null +++ b/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/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md b/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md new file mode 100644 index 0000000000..7096901ab2 --- /dev/null +++ b/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/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md b/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md new file mode 100644 index 0000000000..fd88341413 --- /dev/null +++ b/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/articles/anomaly-detection/index.md b/articles/anomaly-detection/index.md index c2dbc44f3d..9dc98e5ece 100644 --- a/articles/anomaly-detection/index.md +++ b/articles/anomaly-detection/index.md @@ -1,113 +1,73 @@ --- -toc: true -description: Explains all the types of Anomaly Detection provided by Auth0 and how to enable them. -url: /anomaly-detection +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 provides built-in tools to 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 your preferences on the notifications that get sent and you can decide whether to block a suspicious IP address or not. - -## What Anomaly Detection Provides - -Currently Auth0 has three types of **shields** you can enable to handle anomalies and attacks. 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 3rd party service. +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. -## Shields +Auth0 has two types of **shields** to handle anomalies and attacks. -### Brute-Force Protection -There are two different triggers for the brute-force protection shield, for two slightly different attack scenarios. +* [Brute-force protection](#brute-force-protection) +* [Breached password detection](#breached-password-detection) -**Trigger:** *10* failed login attempts into a single account from the same IP address. +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. -**Actions**: -* Send an email to the affected user (The email can be [customized](#customize-the-blocked-account-email)) -* Block the suspicious IP address +Customize the actions in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly). -::: panel Note -The way this anomaly protection works is that if user with "user_id1" signs in from IP1 and fails to login consecutively for 10 attempts their login from this IP - IP1 will be blocked. Another user, say "user_id2" signing in from the same IP (IP1) will not be blocked. The mechanism to clear this block is described below. - -Currently the default trigger amount of 10 cannot be changed. +::: 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). ::: -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. - - -**Trigger:** *100* failed login attempts from a single IP address using different usernames, all with incorrect passwords in 24 hours. Or *50* sign ups attempts per minute from the same IP address. - -**Actions:** -* Notify dashboard administrator(s) -* Block suspicious addresses - -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. More specifically, you will gain 100 attempts / 24 hours * 60 minutes = 1 additional attempt every 25 minutes. - -Auth0 does email the dashboard administrator(s) when this block is triggered. Within this email there's a link the owner can click on to remove the block. - -#### Restrictions Regarding Brute-Force Protection - -Both of these anomaly types depend on the IP address of the user. Because of this, the following use cases are *not* supported: - -1. 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. -2. 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. -3. 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. - -### Breached Password Detection - -Every day malicious hackers penetrate websites and applications, exposing thousands of email and passwords. Given that it's quite 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 credentials. - -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, your users can be notified and/or blocked from logging in if we suspect their credentials were part of a published security breach. - -**Trigger:** Auth0 suspects that a specific user's credentials were included in a major public security breach. - -**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 - -This block remains in place until the user changes their password. - -:::note -Watch our [Breached Password Detection 101 video tutorial](https://auth0.com/resources/videos/learn-about-breached-password-detection). -::: - -## Setting Your Preferences - -To customize the **actions** that get taken from the **triggers**, go to the [Anomaly Detection](${manage_url}/#/anomaly) section on the dashboard. - -![](/media/articles/anomaly-detection/anomaly-detection-overview.png) +## Brute-force protection -You can use the toggle to disable all the actions of a certain shield. Or to enable/disable certain actions, click on the shield that has the action in it that you wish to change. +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. -Then you can use the toggle to enable/disable an action. +* 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 -### Brute-force Protection +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. -![](/media/articles/anomaly-detection/brute-force-shield.png) +## Breached password detection -Here you can also add any IP addresses to the **Whitelist** field to avoid erroneously triggering the protection. +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). -Click **Save** when you have finished. +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). -### Breached-password Detection +## Frequently asked questions -![](/media/articles/anomaly-detection/breached-password-shield.png) +* **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. -Click **Save** when you have finished. +* **Is there a limit to the number of times a user will be notified?** +Users will only be notified once per hour. -### Customize the Blocked Account Email +* **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. -When Auth0 sends an email to a user to notify them of the block, the message contains a link to re-enable the origin of the request. Notice that Auth0 never blocks the user itself, just the attempts from the suspicious origin. +* **For how long is the reset password link, included in the breached password email, valid?** +Password reset links are valid for 5 days. -The email sent to the user looks like this: +* **Is there a test dataset of breached passwords?** +You can test with **leak-test@example.com** as the email and **Paaf213XXYYZZ** as the password. -![Email Example](/media/articles/brute-force-protection/bfp-2015-12-29_1832.png) +* **Does the breached password detection work when logging in using the Resource Owner password grant?** +Yes. -The template used for this message can be customized on the [Dashboard](${manage_url}/#/emails) under __Emails > Templates > Blocked Account Email__. +* **Does the breached password detection feature work with a custom database?** +Yes. -[Learn more about Customizing your Emails](/email/templates) +* **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/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md b/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md new file mode 100644 index 0000000000..c7e0e93b8b --- /dev/null +++ b/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/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md b/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md new file mode 100644 index 0000000000..3342464d8f --- /dev/null +++ b/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/articles/api-auth/_includes/_ropg-warning.md b/articles/api-auth/_includes/_ropg-warning.md new file mode 100644 index 0000000000..c19c5320ac --- /dev/null +++ b/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/articles/api-auth/apis.md b/articles/api-auth/apis.md index efde495062..da33b407f4 100644 --- a/articles/api-auth/apis.md +++ b/articles/api-auth/apis.md @@ -4,24 +4,24 @@ 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 -<%= include('../_includes/_pipeline2') %> - -## Overview - 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](/tokens/access-token). The same Access Token can be used to access the API's resources without having to authenticate again, until it expires. +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. +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. - -::: note -For more information on tokens please refer to: [Tokens used by Auth0](/tokens). -::: +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 @@ -39,9 +39,9 @@ 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. 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. This value **cannot be modified** afterwards. +- **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. For more details on the signing algorithms go to the [Signing Algorithms paragraph](#signing-algorithms). +- **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. @@ -49,19 +49,16 @@ Once you do so you will be navigated to the *Quick Start* of your API. Here you ![API Quick Starts](/media/articles/api/overview/quickstarts-view.png) -::: note -Keep in mind that we are working on building quickstarts for more stacks, apart from those currently available. -::: 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). +- **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 your Machine to Machine Applications. You can authorize which Machine to Machine Applications can request Access Tokens for your API. You can optionally select a subset of the defined scopes to further limit the access that an authorized your application has. Only Machine to Machine Applications require explicit permission. That is because, when you authorize a Machine to Machine Applications to access an API, Auth0 is creating an Application Grant for that application. For more details on this case refer to: [Setting up a Client Credentials Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard). +- **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 Machine to Machine Applications to check that everything is working as expected. +- **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 @@ -73,52 +70,16 @@ Click on the *Settings* tab of your [API](${manage_url}/#/apis) to review the av - **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. +- **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 **callbackURL** is `localhost` or `127.0.0.1` the consent dialog will always be displayed. +- **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. For more details on the signing algorithms see the [Signing Algorithms paragraph](#signing-algorithms) below. - -### 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 Tokens (JWTs) in Auth0](/jwt#what-is-the-json-web-token-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`. +- **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). -- **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. +## Keep reading -- **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 secret key is compromised (e.g. by the application) 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. - -::: panel Verify an RS256 signed token -Go to [Dashboard > Applications](${manage_url}/#/applications). Open the **Settings** of your applications, scroll down and open **Advanced Settings**. Open the **Certificates** tab and you will find the Public Key in the **Signing Certificate** field. - -If you want to use the Public Key to verify a JWT signature on [JWT.io](https://jwt.io/), you can copy the Public Key and paste it in the **Public Key or Certificate** field under the **Verify Signature** section on the [JWT.io](https://jwt.io/) website. - -If you want to verify the signature of a token from one of your applications, we recommend that you get the Public Key from your tenant's [JSON Web Key Set (JWKS)](/jwks). Your tenant's JWKS is `https://${account.namespace}/.well-known/jwks.json`. -::: - -For a more detailed overview of the JWT signing algorithms refer to: [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/). - -## Keep Reading - -::: next-steps - [API Authorization landing page](/api-auth) - [Identify the proper OAuth 2.0 flow for your use case](/api-auth/which-oauth-flow-to-use) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) -::: +- [Tokens](/tokens) diff --git a/articles/api-auth/blacklists-vs-grants.md b/articles/api-auth/blacklists-vs-grants.md index 11b22821aa..8a8fbedf29 100644 --- a/articles/api-auth/blacklists-vs-grants.md +++ b/articles/api-auth/blacklists-vs-grants.md @@ -1,10 +1,20 @@ --- -description: This document covers blacklists vs. grants when it comes handling tokens. +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 non-interactive [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](/tokens/access-token) that lasts for a month. +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? @@ -20,14 +30,10 @@ We will then compare the two methods and provide our recommendations. 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. -::: note -Please see the Auth0 blog for an in-depth treatment on [Blacklisting JSON Web Token API Keys](https://auth0.com/blog/blacklist-json-web-token-api-keys/). -::: - -Auth0-issued tokens are [JWTs](/jwt), 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. +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](/rule). Here's a simple example using UUID: +You can add `jti` via a [rule](/rules). Here's a simple example using UUID: ```js function (user, context, callback) { diff --git a/articles/api-auth/config/using-the-auth0-dashboard.md b/articles/api-auth/config/using-the-auth0-dashboard.md index e459277d3a..dde2b216f6 100644 --- a/articles/api-auth/config/using-the-auth0-dashboard.md +++ b/articles/api-auth/config/using-the-auth0-dashboard.md @@ -1,46 +1,33 @@ --- -description: How to set up a Client Credentials Grant using the Auth0 Dashboard +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 a Client Credentials Grant using the Dashboard +# Set Up Client Credentials Grants Using the Dashboard -<%= include('../../_includes/_pipeline2') %> +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). -1. Open the Auth0 Management Dashboard and browse to the [Applications section](${manage_url}/#/applications). +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. -2. Click on **Create Application** to begin creating a new application (if you have multiple applications needing access to the API, you'll need to create an Auth0 app for *each*). You'll be asked what type of application you'd like to create, so select **Machine to Machine Application**. Click **Create** to proceed. +To authorize the applications to call an API: -![Create an Application](/media/articles/api-auth/create-client.png) +1. Open the Auth0 Management Dashboard and browse to the [API section](${manage_url}/#/apis). -3. Navigate to the [API section](${manage_url}/#/apis) and create a new API. +2. Select the API you want to invoke using the **Client Credentials** Grant. -Enter a friendly name and an identifier. Ideally, this identifier should be the public endpoint of the API, but any valid URN is acceptable. This API will be represented by your **Resource Server**. +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. -The selection of the **Signing Algorithm** will dictate how the API will validate the Access Tokens it receives: -* HS256 (symmetric): signed using the resource server's signing secret -* RS256 (asymmetric): signed using Auth0's private key for your account. Verification is done using the corresponding public key, which can be found at the following standard [JWKS (JSON Web Key set)](/jwks) URL: [https://${account.namespace}/.well-known/jwks.json](https://${account.namespace}/.well-known/jwks.json) +![Authorize the Application](/media/articles/api-auth/apis-authorize-client-tab.png) -![Create an API](/media/articles/api-auth/apis-create.png) - -::: note -There will already be an `Auth0 Management API` that represents Auth0's APIv2. You can authorize applications to request tokens from this API as well. -::: - -4. (Optional) Define some scopes by browsing to the **Scopes** tab. A scope is a claim that may be issued as part of the Access Token. With this information, the API can enforce fine-grained authorization. - - ![Define Scopes](/media/articles/api-auth/apis-scope-tab.png) - -5. Authorize a consumer application. Under the **Machine to Machine Application** tab, you can authorize your applications that will be the consumers of the API. This will create a `client grant` for each application and will allow you to generate Access Tokens for these applications to call your API. Optionally, you can select a subset of scopes to be granted to this application as part of the Access Token. Scopes allow the API to enforce fine-grained authorization. - - ![Authorize the Application](/media/articles/api-auth/apis-authorize-client-tab.png) - -6. Setup your API to accept Access Tokens. The **Quickstart** tab provides you with code snippets for different languages and will guide you through bootstrapping your API, depending on the selected **Signing Algorithm**. +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 -:::next-steps -* [How to implement the Client Credentials Grant](/api-auth/tutorials/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#custom-claims) -::: +* [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/articles/api-auth/config/using-the-management-api.md b/articles/api-auth/config/using-the-management-api.md index f27b638dda..fc9e75f35a 100644 --- a/articles/api-auth/config/using-the-management-api.md +++ b/articles/api-auth/config/using-the-management-api.md @@ -1,86 +1,34 @@ --- -title: Set up a Client Credentials Grant using the Management API -description: How to set up a Client Credentials Grant using the Management API. +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 a Client Credentials Grant using the Management API +# Set Up Client Credentials Grants Using the Management API -<%= include('../../_includes/_pipeline2') %> +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). -If you do not want to use the Auth0 Dashboard to create a Resource Server or you need to create one programmatically, you can use our Management API v2. +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. -You will need the following: - -- A Management APIv2 token with the appropriate scopes. For details on how to get one refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens). -- The Application information (`Client_Id` and `Client_Secret`) for the Machine to Machine Application that should already be created and visible in your [Auth0 dashboard](${manage_url}/#/applications). - -## 1. Create your Resource Server - -Let's start by creating the Resource Server. This is the entity that represents the API that you want to issue Access Tokens for, identified by a friendly name and a URN identifier. - -The following restrictions apply to the identifier: -- It must be a valid URN. -- It cannot be modified after creation. -- It must be unique throughout your tenant. - -We recommend using your public API endpoint as an identifier. - -To create a Resource Server send a `POST` request to the [/resource-servers endpoint of the Management APIv2](/api/management/v2#!/Resource_Servers/post_resource_servers) with an `access_token` that has the resource server scope (`scope:resource_server`). - -The following example uses _"My Sample API"_ as the name and _"https://my-api-uri"_ as the identifier. +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. -```har -{ - "method": "POST", - "url": "https://${account.namespace}/api/v2/resource-servers", - "headers": [ - { "name": "Content-Type", "value": "application/json" }, - { "name": "authorization", "value": "Bearer Auth0_MGMT_API_ACCESS_TOKEN" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"name\":\"My Sample API\",\"identifier\": \"https://my-api-urn\",\"signing_alg\": \"RS256\",\"scopes\": [{ \"value\": \"sample-scope\", \"description\": \"Description for Sample Scope\"}]}" - } -} -``` - -::: note - You can include multiple scopes. This array represents the universe of scopes your API will support. You can modify this later by issuing a PATCH operation. -::: - -Sample response: +You will need the following: -```json -{ - "id": "56f0131ffdf1c311694f4cc7", - "name": "My Sample API", - "identifier": "https://my-api-urn", - "scopes": [ - { - "value": "sample-scope", - "description": "Description for Sample Scope" - } - ], - "signing_alg": "RS256", - "signing_secret": "FF1prn9UxZotnolsDVwEJhqqyRmwdSu5", - "token_lifetime": 86400 -} -``` +- 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). -Note the following: -- The `identifier` value (`https://my-api-urn`) will be used from now on as the `audience` for any OAuth 2.0 grant, that wants to access this API. -- The algorithm that your API will use to sign tokens will be the __RS256__ (`signing_alg`). -- The secret used to sign the tokens will be `FF1prn9UxZotnolsDVwEJhqqyRmwdSu5` (`signing_secret`). -- The generated tokens will expire after `86400` seconds (`token_lifetime`). +- The application information (`Client_Id` and `Client_Secret`) for the application you want to authorize [Auth0 dashboard](${manage_url}/#/applications). -## 2. Authorize the Application +- The API identifier for the API you want to invoke (${manage_url}/#/apis). -Now that the API and the Application are defined in Auth0, you can create a trust relationship between them. To do so, authorize the Application to access the API, while defining the scopes that should be given to the Application (meaning the actions the Application will be able to perform on the API). +## 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 an `access_token` that has the create application grants scope (`create:client_grantss`). +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`. +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 { @@ -110,12 +58,12 @@ Sample response: } ``` -That's it, you are done! Now that all the elements are in place, you can request Access Tokens for your API from Auth0. +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 -* [How to implement the Client Credentials Grant](/api-auth/tutorials/client-credentials) +* [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#custom-claims) +* [How to add custom claims to a token using Rules](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) ::: diff --git a/articles/api-auth/dynamic-client-registration.md b/articles/api-auth/dynamic-client-registration.md index 06f3be5a3f..6bac759f08 100644 --- a/articles/api-auth/dynamic-client-registration.md +++ b/articles/api-auth/dynamic-client-registration.md @@ -1,35 +1,30 @@ --- -title: Dynamic Client Registration -description: How to dynamically register clients with Auth0 using the Management API +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 -<%= include('../_includes/_pipeline2') %> - -Dynamic Client Registration enables you to register clients dynamically. These clients can be either [first-party or third-party clients](/clients/client-types#first-vs-third-party-clients). +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 -By default, the feature is disabled for all tenants. To change this, you have to: - -- update your tenant settings -- promote the connections you will use with your dynamic clients to **domain connections**, and -- update your client's login page (if you use [Lock](/libraries/lock/v11)) - ::: warning -Auth0 supports **Open Dynamic Registration**, which means that if you enable this feature, **anyone** will be able to create clients in your tenant without a token. +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. ::: -### Update tenant settings - -Set the `enable_dynamic_client_registration` flag to `true` in your tenant's settings. +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 Client Registration** toggle on your tenant's [Advanced Settings page](${manage_url}/#/tenant/advanced). +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). @@ -38,130 +33,61 @@ Alternatively, you can update this flag using the [Update tenant settings endpoi "method": "PATCH", "url": "https://${account.namespace}/api/v2/tenants/settings", "headers": [ - { "name": "Content-Type", "value": "client/json" }, + { "name": "Content-Type", "value": "application/json" }, { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }, { "name": "Cache-Control", "value": "no-cache" } ], "postData": { - "mimeType": "client/json", + "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 [How to get a Management APIv2 Token](/api/management/v2/tokens#how-to-get-a-management-apiv2-token) for details on how to do so. - -### Promote connections - -Clients registered via the [Dynamic Client Registration Endpoint](#register-your-client) can only authenticate users using connections flagged as **Domain Connections**. These connections will be open for any dynamic client to allow users to authenticate. - -You can promote a connection to domain level using the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). - -```har -{ - "method": "PATCH", - "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID", - "headers": [ - { "name": "Content-Type", "value": "client/json" }, - { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }, - { "name": "Cache-Control", "value": "no-cache" } - ], - "postData": { - "mimeType": "client/json", - "text" : "{ \"is_domain_connection\": true }" - } -} -``` - -Where: -- `API2_ACCESS_TOKEN`: [Α valid Auth0 API2 token](/api/management/v2/tokens#how-to-get-a-management-apiv2-token) with the scope `update:connections` -- `CONNECTION_ID`: Τhe Id of the connection to be promoted - - -### Update the login page - -To use the Auth0's [Universal Login](/hosted-pages/login) with the Dynamic Client feature, you need to use at least version `10.7.x` of Lock, and set `__useTenantInfo: config.isThirdPartyClient` when instantiating Lock. - -Sample script: - -```html - -... - -``` +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 client. +In this section we will see how you can dynamically register and configure an application. -### Register your client +### Register your application -In order to dynamically register an client with Auth0, you need to send an HTTP `POST` message to the Client 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](/tokens/access-token). +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 client with the name `My Dynamic Client` and the callback URLs `https://client.example.com/callback` and `https://client.example.com/callback2`, use the following snippet. +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": "client/json" } + { "name": "Content-Type", "value": "application/json" } ], "postData": { - "mimeType": "client/json", - "text": "{\"client_name\":\"My Dynamic Client\",\"redirect_uris\": [\"https://client.example.com/callback\", \"https://client.example.com/callback2\"]}" + "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 Client to be created +- **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). +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 client information. +The response includes the basic application information. ```json HTTP/1.1 201 Created -Content-Type: client/json +Content-Type: application/json { - "client_name": "My Dynamic Client", + "client_name": "My Dynamic Application", "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2", "client_secret": "Q5O...33P", "redirect_uris": [ - "https://client.example.com/callback", - "https://client.example.com/callback2" + "https://application.example.com/callback", + "https://application.example.com/callback2" ], "client_secret_expires_at": 0 } @@ -169,20 +95,20 @@ Content-Type: client/json 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 clients to authenticate to the [token endpoint](/api/authentication#get-token) and for signing and validating [ID Tokens](/tokens/id-token). -- **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 client never expires. +- **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](/client-auth) and [authorization](/api-auth) flows. +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 client settings. In case this is necessary, they need to contact the tenant owner with their request. +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 client +### Configure your application -Now that you have a Client ID and Secret, you can configure your client to authenticate users with Auth0. +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 Grant](/api-auth/tutorials/implicit-grant). For a list of tutorials on how to authenticate and authorize users, based on your client type, see the [API Authorization](/api-auth) page. +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 client to send the user to the authorization URL: +First, you need to configure your application to send the user to the authorization URL: ```text https://${account.namespace}/authorize? @@ -191,22 +117,22 @@ https://${account.namespace}/authorize? response_type={RESPONSE_TYPE}& client_id=${account.clientId}& redirect_uri=${account.callback}& - nonce={CRYPTOGRAPHIC_NONCE} + nonce={NONCE} state={OPAQUE_VALUE} ``` Where: -- **audience** (optional): The target API for which the Client Client is requesting access on behalf of the user. Set this parameter if you need API access. +- **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 client'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 Client Settings of your client. -- **state**: An opaque value the clients add to the initial request that the authorization server includes when redirecting the back to the client. This value must be used by the client to prevent CSRF attacks. +- **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: @@ -217,6 +143,6 @@ For example: ``` -This call will redirect the user to Auth0, and upon successful authentication, back to your client (specifically to the **redirect_uri**). +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](/api-auth/tutorials/implicit-grant#2-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. +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/articles/api-auth/faq.md b/articles/api-auth/faq.md index cf2c3592ba..d5fea1d7e6 100644 --- a/articles/api-auth/faq.md +++ b/articles/api-auth/faq.md @@ -1,22 +1,28 @@ --- 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 -## Can I execute a user consent flow? - -Yes! We are working on creating documentation and tutorials for implementing this flow. In the meantime, if you need assistance or more information please contact our [Support Center](${env.DOMAIN_URL_SUPPORT}). - ## 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. +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? -**A** Sure! You have two options: +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). diff --git a/articles/api-auth/grant/authorization-code-pkce.md b/articles/api-auth/grant/authorization-code-pkce.md index 770fbfe1c2..fb575ab2c1 100644 --- a/articles/api-auth/grant/authorization-code-pkce.md +++ b/articles/api-auth/grant/authorization-code-pkce.md @@ -1,11 +1,17 @@ --- -description: Describes the call APIs from mobile apps using the Authentication Code Grant (PKCE). +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 --- -# Calling APIs from Mobile Apps +# Call APIs from Mobile Apps -<%= include('../../_includes/_pipeline2') %> - -In order 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. +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. @@ -13,7 +19,7 @@ If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth ## 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](/tokens/access-token) (and possibly a [Refresh Token](/tokens/refresh-token)). +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. @@ -21,18 +27,18 @@ With PKCE, the application creates, for every authorization request, a cryptogra ![Authorization Code Grant using PKCE](/media/articles/api-auth/authorization-code-grant-pkce.png) - 1. The native app 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. + 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 app with an `authorization_code` in the querystring. + 2. Auth0 redirects the user to the native application with an `authorization_code` in the querystring. - 3. The native app 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-). + 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`). + 4. Auth0 validates this information and returns an Access Token (and optionally a Refresh Token). - 5. The native app can use the `access_token` to call the API on behalf of the user. + 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 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. +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 @@ -50,7 +56,6 @@ For details on how to implement this, refer to [Execute an Authorization Code Gr ::: 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) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) +- [Tokens](/tokens) - [Application Authentication for Mobile & Desktop Apps](/application-auth/mobile-desktop) -- [Tokens used by Auth0](/tokens) ::: diff --git a/articles/api-auth/grant/authorization-code.md b/articles/api-auth/grant/authorization-code.md index 031086debd..45412c6e0b 100644 --- a/articles/api-auth/grant/authorization-code.md +++ b/articles/api-auth/grant/authorization-code.md @@ -1,9 +1,14 @@ --- -description: Describes how to call APIs from regular web apps using the Authentication Code Grant. +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 --- -# Calling APIs from Server-side Web Apps - -<%= include('../../_includes/_pipeline2') %> +# 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. @@ -13,21 +18,21 @@ If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth ## 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/access-token), and optionally an [id_token](/tokens/id-token) and a [refresh_token](/tokens/refresh_token). The web app can now use this `access_token` to call the API on behalf of the user. +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 applicaion (for example: post messages, list contacts, and so forth). +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. 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. +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. @@ -49,7 +54,6 @@ For details on how to implement this, refer to [Execute an Authorization Code Gr ::: next-steps - [How to implement an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant) - [How to configure an API in Auth0](/apis) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) +- [Tokens](/tokens) - [Application Authentication for Server-side Web Apps](/application-auth/server-side-web) -- [Tokens used by Auth0](/tokens) ::: diff --git a/articles/api-auth/grant/client-credentials.md b/articles/api-auth/grant/client-credentials.md index fe6b1df851..8fa8cd26d3 100644 --- a/articles/api-auth/grant/client-credentials.md +++ b/articles/api-auth/grant/client-credentials.md @@ -1,42 +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 --- -# Calling APIs from a Service +# Client Credentials Grant -<%= include('../../_includes/_pipeline2') %> +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. -The OAuth 2.0 grant that machine-to-machine interfaces utilize in order to access an API, is the **Client Credentials Grant**. In this document we will see how this flow works. +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. -::: 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 - -With **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) a Non Interactive Client (a CLI, a daemon, or a Service running on your backend), can directly ask Auth0 for an `access_token`, by using its Client Credentials (__Client Id__ and __Client Secret__) to authenticate. In this case the token represents the Non Interactive Client itself, instead of an end user. +## 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. 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. +1. The application can use the Access Token to call the API on behalf of itself. ::: note -In OAuth 2.0 terms, the non interactive 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. +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). Before you do so, you have to set up the Grant first either [using the Dashboard](/api-auth/config/using-the-auth0-dashboard) or [using the Management API](/api-auth/config/using-the-management-api). +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) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-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) -- [Tokens used by Auth0](/tokens) ::: diff --git a/articles/api-auth/grant/hybrid.md b/articles/api-auth/grant/hybrid.md new file mode 100644 index 0000000000..496e658d8b --- /dev/null +++ b/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/articles/api-auth/grant/implicit.md b/articles/api-auth/grant/implicit.md index 65762fd8fd..bf1a08f84c 100644 --- a/articles/api-auth/grant/implicit.md +++ b/articles/api-auth/grant/implicit.md @@ -2,12 +2,17 @@ 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 -<%= include('../../_includes/_pipeline2') %> - -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. +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. @@ -15,9 +20,9 @@ If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth ## 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/access-token) 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)). +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. +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) @@ -25,9 +30,9 @@ Once the user authenticates, the application receives the `access_token` in the 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/access-token) (and optionally an [id_token](/tokens/id-token)) 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. 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. + 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. @@ -45,7 +50,7 @@ For details on how to implement this, refer to [How to implement the Implicit Gr ## Silent Authentication -If you need to authenticate your users without a login page (for example, when the user is already logged in via [SSO](/sso) scenario) or get a new `access_token` (thus simulate refreshing an expired token), you can use 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). @@ -55,6 +60,6 @@ For details on how to implement this, refer to [Silent Authentication](/api-auth * [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) -* [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) +* [Tokens](/tokens) * [Application Authentication for Client-side Web Apps](/application-auth/client-side-web) ::: diff --git a/articles/api-auth/grant/password.md b/articles/api-auth/grant/password.md index 82597c5860..3da4c9a514 100644 --- a/articles/api-auth/grant/password.md +++ b/articles/api-auth/grant/password.md @@ -1,33 +1,29 @@ --- 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/_pipeline2') %> +<%= include('../_includes/_ropg-warning') %> -Highly trusted applications can use this flow 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. +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. -You should use this flow **only if** the following apply: -- The application is absolutely trusted with the user's credentials. For [client side](/api-auth/grant/implicit) applications and [mobile apps](/api-auth/grant/authorization-code-pkce) we recommend using web flows instead. -- Using a redirect-based flow is not possible. If this is not the case and redirects are possible in your application you should use the [Authorization Code Grant](/api-auth/grant/authorization-code) instead. - -::: 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 **Resource Owner Password Grant** (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 obtain an Access Token, and optionally a Refresh Token. This grant should only be used when there is a high degree of trust between the user and the application and when other authorization flows are not available. - -This grant type can eliminate the need for the application to store the user credentials for future use, by exchanging the credentials with a long-lived Access Token or Refresh Token. +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. + 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. @@ -35,9 +31,9 @@ In OAuth 2.0 terms, the web app is the Client, the end user the Resource Owner, ## How to implement the flow -For details on how to implement this using Auth0, refer to [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant). +For details on how to implement this using Auth0, see [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant). -## Realm Support +## 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`. @@ -47,7 +43,7 @@ For more information on how to implement this extension grant refer to [Executin ## 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). +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 @@ -57,17 +53,15 @@ Due to the implied trust in these grants (a user providing his or her password t 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, refer to [Execute the Resource Owner Password Grant: Customize the Tokens](/api-auth/tutorials/password-grant#optional-customize-the-tokens). +For details on how to implement this, see [Customize the Tokens](/api-auth/tutorials/password-grant#optional-customize-the-tokens). -## MFA Support +## MFA support and anomaly detection -For details on how to implement multifactor authentication, refer to [Multifactor Αuthentication and Resource Owner Password](/api-auth/tutorials/multifactor-resource-owner-password). +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 -::: next-steps -* [How to Execute a Resource Owner Password Grant](/api-auth/tutorials/password-grant) -* [How to use MFA with Resource Owner Password Grant](/api-auth/tutorials/multifactor-resource-owner-password) -* [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) -* [How to use Resource Owner Password Grant from the server side together with Anomaly Detection](/api-auth/tutorials/using-resource-owner-password-from-server-side) -::: +* [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant) +* [Tokens](/tokens) diff --git a/articles/api-auth/index.md b/articles/api-auth/index.md index 778f80c4b4..2c2bdf84b6 100644 --- a/articles/api-auth/index.md +++ b/articles/api-auth/index.md @@ -3,6 +3,13 @@ url: /api-auth section: articles classes: topic-page title: API Authorization +topics: + - api-authentication + - oidc +contentType: index +useCase: + - secure-api + - call-api ---
@@ -13,31 +20,13 @@ title: API Authorization

-::: 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. -::: +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. -At some point, your APIs will need to allow limited access to users, servers, or servers on behalf of users. +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. -Auth0's API authorization features allow you to 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. - -Using Auth0, you can easily support different flows in your own APIs without worrying about the OAuth 2.0/OpenID Connect 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.
    -
  • - Introducing OIDC Conformant Authentication -

    - This document presents an overview of the latest new features and changes in our authentication flows, explain why they were made and points to other detailed tutorials to help you adopt these changes. -

    -
    • -
  • - OIDC Conformant Authentication Adoption Guide -

    - This guide details all the latest new features and changes and provides suggestions on how to adapt your existing applications. -

    -
  • Which OAuth 2.0 flow should I use?

    @@ -45,44 +34,44 @@ Using Auth0, you can easily support different flows in your own APIs without wor

  • - Calling APIs from Server-side Web Apps + Call Your API from a Regular Web App

    If your application executes on a server and you want to configure it to use OAuth 2.0 to access an API, read these docs.

  • - Calling APIs from Mobile Apps + Call Your API from a Native/Mobile App

    If your application is a native app and you want to configure it to use OAuth 2.0 to access an API, read these docs.

  • - Calling APIs from Client-side Web Apps + Call Your API from a Single-Page App

    If your application is a JavaScript-centric app executing on the browser, and you want to configure it to use OAuth 2.0 to access an API, read these docs.

  • - Calling APIs from a Service + Call Your API from a Machine-to-Machine App

    If you want to implement server-to-server interaction, and you want to configure it to use OAuth 2.0, read these docs.

  • - Why you should always use Access Tokens to secure an API + Tokens

    - Learn about the differences between Αccess Τoken and ID Τoken and why the latter should never be used to secure an API. + Learn about the types of tokens related to identity and authentication and how they are used by Auth0.

  • @@ -154,15 +146,15 @@ Using Auth0, you can easily support different flows in your own APIs without wor

  • - Verify Access Tokens + Validate Access Tokens

    Learn what an API has to do in order to verify a Bearer Access Token.

  • - Restrict User/Application Requests for API Scopes + Restrict Access to APIs

    - Learn how to restrict users/applications from requesting API scopes for which they don't have access. + Learn how to restrict users/applications from accessing APIs.

  • @@ -172,9 +164,9 @@ Using Auth0, you can easily support different flows in your own APIs without wor

  • - How to Represent Multiple APIs Using a Single Auth0 API + Represent Multiple APIs Using a Single Logical API in Auth0

    - Learn how to represent multiple APIs using a single Auth0 API. + Learn how to represent multiple APIs using a single logical API.

  • diff --git a/articles/api-auth/intro.md b/articles/api-auth/intro.md index b2a027e8ae..77aa80441c 100644 --- a/articles/api-auth/intro.md +++ b/articles/api-auth/intro.md @@ -1,23 +1,29 @@ --- -title: Introducing OIDC Conformant Authentication 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 --- -# Introducing OIDC Conformant Authentication +# 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, explain why they were made and point you to other detailed tutorials to help you adopt these changes. +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), 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). +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 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 using Auth0 as a [SAML or WS-Federation identity provider](/protocols/saml/saml-idp-generic) to your application (that is, you're not using OIDC/OAuth), then you do not need to make any changes. +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 @@ -45,19 +51,19 @@ So far, third-party applications cannot be created from the dashboard. They must For more information, refer to [User consent and third-party applications](/api-auth/user-consent). ::: -### Calling APIs from a Service (machine-to-machine) +### 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 programatically and securely obtain access to an API. +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 [Calling APIs from a Service](/api-auth/grant/client-credentials). +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 on refer to [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis). +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). @@ -65,24 +71,24 @@ For more information, refer to [Calling your APIs with Auth0 tokens](/api-auth/t ### 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 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). +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](/api-auth/tutorials/adoption/scope-custom-claims) to avoid possible collisions with standard OIDC claims. +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 Client Credentials, and Rules for the rest of the grants: -- __Client Credentials__: [Customize Tokens using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) -- __Resource Owner__: [Customize Tokens using Rules](/api-auth/grant/password#customizing-the-returned-tokens) -- __Implicit Grant__: [Customize Tokens using Rules](/api-auth/tutorials/implicit-grant#optional-customize-the-tokens) -- __Authorization Code__: [Customize Tokens using Rules](/api-auth/tutorials/authorization-code-grant#optional-customize-the-tokens) -- __Authorization Code (PKCE)__: [Customize Tokens using Rules](/api-auth/tutorials/authorization-code-grant-pkce#optional-customize-the-tokens) +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) +### Single Sign-on (SSO) -Initiating an 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](/hosted-pages/login). Users must be redirected to the login page and then redirected to your application once authentication is complete. +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. @@ -99,15 +105,15 @@ Not all [OAuth 2.0 grants](/protocols/oauth2#authorization-grant-types) support - Authorization Code + Authorization Code Yes - Authorization Code (PKCE) + Authorization Code (PKCE) Yes - Implicit + Implicit Yes @@ -118,7 +124,7 @@ Not all [OAuth 2.0 grants](/protocols/oauth2#authorization-grant-types) support ::: note -For more information, refer to [OIDC Single sign-on](/api-auth/tutorials/adoption/single-sign-on). +For more information, refer to [OIDC Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on). ::: ### Authorization Code Grant @@ -127,8 +133,8 @@ 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](/jwt), 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. +- 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). @@ -142,8 +148,8 @@ Some changes were introduced in the implementation of Implicit grant: - 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](/jwt), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter. +- 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 @@ -158,8 +164,8 @@ Some changes were introduced in the implementation of Resource Owner Password gr - 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](/jwt), 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/application-types#public-applications). +- 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 @@ -168,6 +174,8 @@ For more information, refer to [Resource Owner Password Credentials exchange](/a ### 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 @@ -175,13 +183,11 @@ For more information, refer to [Resource Owner Password Credentials exchange](/a 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. -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. - ### 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). +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) under **Hosted Pages -> Login -> Default Templates**, or customize it to fit specific requirements. +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 @@ -198,7 +204,7 @@ Native applications need to use Universal Login (with an Auth0-hosted login page 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-client) or [/token](/api/authentication#get-token) endpoints +- 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. @@ -206,7 +212,7 @@ To mark your application as OIDC Conformant: go to [Dashboard](${manage_url}) > ![OIDC Conformant flag](/media/articles/api-auth/oidc-conformant-flag.png) -To use the `audience` param instead, configure your app to send it when initiating an authorization request. +To use the `audience` parameter instead, configure your app to send it when initiating an authorization request. ## Legacy vs New @@ -242,12 +248,12 @@ To use the `audience` param instead, configure your app to send it when initiati Add arbitrary claims in Tokens Supported - Supported. The namespaced format has to be used. + Supported. The namespaced format has to be used. SSO Supported - Not supported for Resource Owner grant. For the rest, universal login must be employed and users redirected to the login page. + Not supported for Resource Owner grant. For the rest, Universal Login must be employed and users redirected to the login page. Access Token format @@ -314,10 +320,8 @@ should be used instead with "grant_type": "refresh_token" -## Keep Reading +## Keep reading -::: next-steps * [API Authorization index](/api-auth) -* [Why you should use Access Tokens to secure APIs?](/api-auth/why-use-access-tokens-to-secure-apis) -* [Tokens used by Auth0](/tokens) -::: +* [Tokens](/tokens) + diff --git a/articles/api-auth/passwordless.md b/articles/api-auth/passwordless.md index 8b3cda06bb..cc007bfeb4 100644 --- a/articles/api-auth/passwordless.md +++ b/articles/api-auth/passwordless.md @@ -1,14 +1,20 @@ --- 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') %> -## About Passwordless Authentication - -Passwordless connections allow users to login without the need to remember a password. +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. @@ -16,6 +22,6 @@ Without passwords, your application will not need to implement a password-reset ## OIDC Conformant Passwordless -Auth0 currently supports [OIDC-conformant](/api-auth/tutorials/adoption) passwordless authentication using [universal login](/hosted-pages/login) as well as in embedded web authentication scenarios using the newest [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js) libraries. +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 (with Auth0-hosted login page). Customers can use the Lock (Passwordless) template in the [Dashboard](${manage_url}) under **Hosted Pages > Default Templates**, or customize it to fit specific requirements. +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/articles/api-auth/restrict-access-api.md b/articles/api-auth/restrict-access-api.md new file mode 100644 index 0000000000..ae857bd87b --- /dev/null +++ b/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/articles/api-auth/restrict-requests-for-scopes.md b/articles/api-auth/restrict-requests-for-scopes.md deleted file mode 100644 index 42debc5963..0000000000 --- a/articles/api-auth/restrict-requests-for-scopes.md +++ /dev/null @@ -1,62 +0,0 @@ ---- - description: Writing rules to restrict user/client access to an API ---- - -# Restrict Application or User Requests for API Scopes - -By default, any user associated with an [Auth0 application](/applications) can request an API's [scope(s)](/scopes#api-scopes). If you would like to restrict access to the API's scopes based on the user's role, application association, location, and so on, you can do so via [rules](/rules). Then, if a restricted user attempts to request scopes not permitted to them, they will receive an `HTTP 401` response. - -## Example: Deny access based on the API audience - -The following [rule](/rules), demonstrates how you would deny access on an API, depending on the `audience` parameter. In this example, we deny access to all users, if the API they are trying to access has the `audience` set to `http://todoapi2.api`. - -```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); -} -``` - -::: note -The value of an API's `audience` is displayed at the **API Audience** field, at [Dashboard > APIs](${manage_url}/#/apis). -::: - -## Example: Deny access based on the Client ID - -The following [rule](/rules), demonstrates how you would deny access on an API, depending on the application the user is associated with. In this example, we deny access to all users, if the application through which they login, has an ID equal to `CLIENT_ID` (this is equivalent to disabling **all** Connections for the application). - -```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); -} -``` - -::: note -The value of a client's Id is displayed at the **Client ID** field, at [Dashboard > Applications](${manage_url}/#/applications). -::: diff --git a/articles/api-auth/token-renewal-in-safari.md b/articles/api-auth/token-renewal-in-safari.md new file mode 100644 index 0000000000..88742f553a --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/_index.md b/articles/api-auth/tutorials/adoption/_index.md index 63ca6e0e51..40760b5d79 100644 --- a/articles/api-auth/tutorials/adoption/_index.md +++ b/articles/api-auth/tutorials/adoption/_index.md @@ -1,14 +1,13 @@ -* [Calling your APIs with Auth0 tokens](/api-auth/tutorials/adoption/api-tokens) -* [User consent and third-party applications](/api-auth/user-consent) -* [Custom user profile claims and `scope`](/api-auth/tutorials/adoption/scope-custom-claims) -* [Single sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on) +* [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) + - [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) -* [Delegation (deprecated)](/api-auth/tutorials/adoption/delegation) -* [Passwordless authentication](/api-auth/passwordless) -* [List of breaking changes for OIDC-conformant applications](/api-auth/tutorials/adoption/oidc-conformant) +* [Passwordless Authentication](/api-auth/passwordless) +* [OIDC-Conformant Applications](/api-auth/tutorials/adoption/oidc-conformant) diff --git a/articles/api-auth/tutorials/adoption/api-tokens.md b/articles/api-auth/tutorials/adoption/api-tokens.md index 925393abcc..8c310789ec 100644 --- a/articles/api-auth/tutorials/adoption/api-tokens.md +++ b/articles/api-auth/tutorials/adoption/api-tokens.md @@ -1,24 +1,35 @@ --- -title: Calling your APIs with Auth0 tokens +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 your APIs with Auth0 tokens +# Call APIs with Auth0 Tokens <%= include('./_about.md') %> -With the OIDC-conformant pipeline, [all APIs should be secured with Access Tokens, not ID tokens](/api-auth/why-use-access-tokens-to-secure-apis). In this article, we discuss what this means and what you need to do if you're using Auth0 tokens with your APIs. +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. +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](/api-auth/grant/client-credentials), since applications -can authenticate as themselves](/api-auth/grant/client-credentials (that is, they are not acting on behalf of any user) to programmatically and securely obtain an API token. +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. +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 @@ -45,7 +56,7 @@ One way to understand how Access and ID Tokens differ in their behavior is to lo 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. +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. @@ -72,7 +83,7 @@ The Access Token is meant to **authorize** the user to the **API (resource serve 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. +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 @@ -81,13 +92,13 @@ With the OIDC-conformant pipeline, the **scope** parameter [behaves differently] 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) +* 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](/tokens/delegation), you should also be using a multi-application solution, each authenticating to the same resource server. +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: +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 @@ -96,6 +107,6 @@ If your applications do not depend on external APIs and you just need to authent For more information on API authentication and authorization refer to API Authorization. ::: -## Further reading +## Keep reading -<%= include('./_index.md') %> \ No newline at end of file +<%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/authorization-code.md b/articles/api-auth/tutorials/adoption/authorization-code.md index dba7c59740..692a46e71f 100644 --- a/articles/api-auth/tutorials/adoption/authorization-code.md +++ b/articles/api-auth/tutorials/adoption/authorization-code.md @@ -1,12 +1,20 @@ --- description: OIDC-conformant Authorization Code grant +topics: + - api-authentication + - oidc + - authorization-code +contentType: concept +useCase: + - secure-api + - call-api --- -# Authorization Code grant +# Authorization Code Grant <%= include('./_about.md') %> -The [Authorization Code grant](/api-auth/grant/authorization-code) is used by server-side applications that are capable of securely storing secrets, or by [native applications through PKCE](/api-auth/grant/authorization-code-pkce). +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 @@ -28,7 +36,7 @@ This document describes the differences of this flow between the legacy and OIDC &redirect_uri=https://app.example.com/callback &device=my-device-name
    @@ -42,7 +50,7 @@ This document describes the differences of this flow between the legacy and OIDC
    • favorite_color is no longer a valid scope value.
    • The device parameter is removed.
      • -
    • The audience parameter is optional.
      • +
    • The audience parameter is optional.
    @@ -64,15 +72,38 @@ Location: https://app.example.com/callback? An authorization code can be exchanged in the same way in both pipelines: -```text -POST /oauth/token HTTP/1.1 -Content-Type: application/json +```har { - "grant_type": "authorization_code", - "client_id": "123", - "client_secret": "...", - "code": "SplxlOBeZQQYbYS6WxSbIA", - "redirect_uri": "https://app.example.com/callback" + "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}" + } + ] + } } ``` @@ -99,8 +130,8 @@ Pragma: no-cache "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.
      • +
    • 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.
    @@ -116,7 +147,7 @@ Pragma: no-cache "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.
      • +
    • 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.
    @@ -157,7 +188,7 @@ Pragma: no-cache "https://app.example.com/favorite_color": "blue" }
      -
    • The favorite_color claim must be namespaced and added through a rule.
      • +
    • The favorite_color claim must be namespaced and added through a rule.
    @@ -193,12 +224,12 @@ Pragma: no-cache "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.
      • +
    • 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.
    -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/client-credentials.md b/articles/api-auth/tutorials/adoption/client-credentials.md index 2ef6dad266..bc6189bcf3 100644 --- a/articles/api-auth/tutorials/adoption/client-credentials.md +++ b/articles/api-auth/tutorials/adoption/client-credentials.md @@ -1,21 +1,29 @@ --- title: Client Credentials exchange +topics: + - api-authentication + - oidc + - client-credentials +contentType: concept +useCase: + - secure-api + - call-api --- -# Client Credentials exchange +# Client Credentials Exchange <%= include('./_about.md') %> -The [Client Credentials exchange](/api-auth/grant/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. +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 APIs from Client-side Web Apps. + For more information on how to execute a Client Credentials exchange, refer to Call API Using the Client Credentials Flow. ::: -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/delegation.md b/articles/api-auth/tutorials/adoption/delegation.md index 0a243eeb85..8fea9b651a 100644 --- a/articles/api-auth/tutorials/adoption/delegation.md +++ b/articles/api-auth/tutorials/adoption/delegation.md @@ -1,15 +1,25 @@ --- 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 +# 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 +* 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. @@ -22,6 +32,6 @@ At the moment there is no OIDC-compliant mechanism to obtain third-party API tok 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. -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/implicit.md b/articles/api-auth/tutorials/adoption/implicit.md index 6758f17245..451729f8b3 100644 --- a/articles/api-auth/tutorials/adoption/implicit.md +++ b/articles/api-auth/tutorials/adoption/implicit.md @@ -1,12 +1,20 @@ --- -title: OIDC-conformant Implicit grant +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 +# Implicit Grant <%= include('./_about.md') %> -The [Implicit grant](/api-auth/grant/implicit) is used by applications that are incapable of securely storing secrets, such as single-page JavaScript applications. +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 @@ -28,7 +36,7 @@ This document describes the differences of this flow between the legacy and OIDC &redirect_uri=https://app.example.com &device=my-device-name
    @@ -41,11 +49,11 @@ This document describes the differences of this flow between the legacy and OIDC &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.
      • +
    • 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.
      • +
    • The audience parameter is optional.
      • +
    • The nonce parameter must be a cryptographically-secure random string.
    @@ -84,7 +92,7 @@ Location: https://app.example.com/# &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.
      • +
    • 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.
    @@ -128,7 +136,7 @@ Location: https://app.example.com/# "nonce": "jxdlsjfi0fa" } @@ -165,13 +173,13 @@ Location: https://app.example.com/# "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.
      • +
    • 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.
    -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/index.md b/articles/api-auth/tutorials/adoption/index.md index 8007cacb77..eb7827dc97 100644 --- a/articles/api-auth/tutorials/adoption/index.md +++ b/articles/api-auth/tutorials/adoption/index.md @@ -1,6 +1,13 @@ --- 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 @@ -15,7 +22,7 @@ This guide details all the upcoming changes, **some of which will be breaking**, 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) to your application (that is, not through OIDC/OAuth), then you do not need to make any changes. +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). @@ -23,7 +30,7 @@ To make this guide accessible to everyone, any authentication flows will be desc 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. +- 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_). @@ -45,6 +52,6 @@ We understand that making changes to the core authentication logic of your appli 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. -## Compare differences between the two pipelines +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/oidc-conformant.md b/articles/api-auth/tutorials/adoption/oidc-conformant.md index fac12b6fd0..a8a601f4ad 100644 --- a/articles/api-auth/tutorials/adoption/oidc-conformant.md +++ b/articles/api-auth/tutorials/adoption/oidc-conformant.md @@ -1,9 +1,15 @@ --- -title: OIDC-conformant applications description: List of breaking changes for OIDC-conformant applications +topics: + - api-authentication + - oidc +contentType: concept +useCase: + - secure-api + - call-api --- -# OIDC-conformant applications +# OIDC-Conformant Applications <%= include('./_about.md') %> @@ -14,30 +20,31 @@ In order to make the transition to the [OIDC-conformant authentication pipeline] 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 in favor of [silent authentication](/api-auth/tutorials/adoption/implicit): - - Refresh Tokens on authentication with the [implicit grant](/api-auth/tutorials/adoption/implicit) +* 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. +* [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. +* 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. + - 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 and added to ID Tokens or Access Tokens via rules. - - Custom scope values can be defined by a [resource server (API)](/api-auth/tutorials/adoption/api-tokens). + - 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. +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: @@ -45,6 +52,6 @@ If your application doesn't need a resource server but you want opt-in to the ne https://${account.namespace}/userinfo ``` -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/password.md b/articles/api-auth/tutorials/adoption/password.md index 99221fe23b..15834e8bba 100644 --- a/articles/api-auth/tutorials/adoption/password.md +++ b/articles/api-auth/tutorials/adoption/password.md @@ -1,7 +1,17 @@ --- -title: OIDC-conformant Resource Owner Password Credentials exchange +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 +# Resource Owner Password Credentials Exchange + +<%= include('../../_includes/_ropg-warning.md') %> <%= include('./_about.md') %> @@ -32,21 +42,15 @@ Content-Type: application/json "device": "my-device-name" } 
    POST /oauth/token HTTP 1.1
-Content-Type: application/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"
-}
    +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.
      • @@ -98,8 +102,8 @@ Pragma: no-cache "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.
        • +
      • 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.
    @@ -142,7 +146,7 @@ Pragma: no-cache }
    • 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.
      • +
    • The favorite_color claim must be namespaced and added through a rule.
    @@ -178,7 +182,7 @@ Pragma: no-cache "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.
      • +
    • 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.
    @@ -189,6 +193,6 @@ Pragma: no-cache 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. -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/refresh-tokens.md b/articles/api-auth/tutorials/adoption/refresh-tokens.md index fe50b40c64..fa8d7447b6 100644 --- a/articles/api-auth/tutorials/adoption/refresh-tokens.md +++ b/articles/api-auth/tutorials/adoption/refresh-tokens.md @@ -1,27 +1,35 @@ --- -title: OIDC-conformant Refresh Token use +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 +# OIDC-Conformant Refresh Tokens <%= include('./_about.md') %> -There are some changes to how Refresh Tokens are used in the OIDC-conformant authentication pipeline: +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. - Use [silent authentication](/api-auth/tutorials/silent-authentication) (such as `prompt=none`) instead. -* Refresh Tokens should only be used by [confidential applications](/applications/application-types#confidential-applications). However, they can also be used by Native (public) applications to obtain Refresh Tokens for mobile apps. -* The `/delegation` endpoint is considered deprecated. To obtain new tokens from a Refresh Token, the `/oauth/token` endpoint should be used instead: +* 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'
 {
@@ -32,17 +40,11 @@ Content-Type: 'application/json'
 }
    -
    + 
    POST /oauth/token
-Content-Type: application/json
-{
-  "grant_type": "refresh_token",
-  "refresh_token": "...",
-  "client_id": "...",
-  "client_secret": "...",
-  "scope": "openid profile",
-  "audience": "https://api.example.com"
-}
+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.
    @@ -51,6 +53,6 @@ Content-Type: application/json 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. -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/scope-custom-claims.md b/articles/api-auth/tutorials/adoption/scope-custom-claims.md index 43cc9e60ac..10b72653ed 100644 --- a/articles/api-auth/tutorials/adoption/scope-custom-claims.md +++ b/articles/api-auth/tutorials/adoption/scope-custom-claims.md @@ -1,14 +1,24 @@ --- -title: User profile claims and scope +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 scope +# User Profile Claims and the `scope` Parameter <%= include('./_about.md') %> -The behavior of the `scope` parameter has been changed to conform to the [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims). +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). +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 @@ -16,7 +26,7 @@ The OIDC specification defines a [set of standard claims](https://openid.net/spe ## 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. +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. @@ -34,7 +44,7 @@ This would be the profile stored by Auth0: } ``` -This is a [*normalized user profile*](/user-profile/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: +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 { @@ -48,7 +58,7 @@ This is a [*normalized user profile*](/user-profile/normalized), which is a prot } ``` -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: +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) { @@ -59,18 +69,33 @@ function (user, context, callback) { } ``` +::: 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 non-namespaced claims will be silently excluded from tokens. +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. +::: -If you need to add custom claims to the Access Token, the same applies but using `context.accessToken` instead. +## Token refresh flow and custom claims -Please note that adding custom claims to ID 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. +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. -## Further reading +## Keep reading <%= include('./_index.md') %> diff --git a/articles/api-auth/tutorials/adoption/single-sign-on.md b/articles/api-auth/tutorials/adoption/single-sign-on.md index 5955fd4412..f421306e27 100644 --- a/articles/api-auth/tutorials/adoption/single-sign-on.md +++ b/articles/api-auth/tutorials/adoption/single-sign-on.md @@ -1,24 +1,30 @@ --- -title: OIDC Single sign-on +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 --- -# Single sign-on +# OIDC Single Sign-On <%= include('./_about.md') %> -Single sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically. +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](/hosted-pages/login) and redirect users to the login page. +This means that for SSO to happen, you must employ Universal Login and redirect users to the login page. -We are planning on providing support for SSO from applications in future releases. - -## How SSO works +## 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](/api-auth/grant/authorization-code) or [implicit](/api-auth/grant/implicit) grants, depending on the type of application. +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. @@ -32,13 +38,13 @@ OIDC-conformant applications must use [silent authentication](/api-auth/tutorial ## Authentication flows without SSO -SSO sessions are managed by Auth0 setting a cookie on your Auth0 domain. +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 grant](/api-auth/grant/authorization-code) -* [Implicit grant](/api-auth/grant/implicit) +* [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: @@ -46,8 +52,11 @@ The following flows are request-based and are currently not capable of SSO: ## 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. +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. -You can read further about [customizing your domain](/custom-domains) if you require it, to help maintain a uniform experience for your users. +## Keep reading + +* [Custom Domains](/custom-domains) +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) diff --git a/articles/api-auth/tutorials/authorization-code-grant-pkce.md b/articles/api-auth/tutorials/authorization-code-grant-pkce.md index 019e24b629..e93cd3913b 100644 --- a/articles/api-auth/tutorials/authorization-code-grant-pkce.md +++ b/articles/api-auth/tutorials/authorization-code-grant-pkce.md @@ -1,20 +1,27 @@ --- 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 -<%= include('../../_includes/_pipeline2') %> - ::: note -This tutorial will help you implement the Authorization Code (PKCE) grant. If you are looking for some theory on the flow refer to [Calling APIs from Mobile App](/api-auth/grant/authorization-code-pkce). +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/Application-grant-types) is set appropriately +* 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 @@ -153,7 +160,7 @@ 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](/scopes) that 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, 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)). The custom scopes must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims). For more information on this, refer to the [Namespacing Custom Claims](#optional-customize-the-tokens) panel. +* `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`. @@ -179,18 +186,39 @@ For example: ## 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`: +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/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"code_verifier\": \"YOUR_GENERATED_CODE_VERIFIER\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"com.myclientapp://myclientapp.com/callback\", }" + "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}" + } + ] } } ``` @@ -214,15 +242,15 @@ The response contains `access_token`, `refresh_token`, `id_token`, and `token_ty } ``` -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. For more information about Refresh Tokens and how to use them, see [our documentation](/tokens/refresh-token). +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` in the Dashboard. +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: +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 { @@ -237,9 +265,9 @@ Once you have the `access_token`, you can use it to make calls to the API, by pa ## 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. +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 refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). ## Optional: Customize the Tokens @@ -249,16 +277,13 @@ If you wish to execute special logic unique to the Authorization Code (PKCE) gra ## Sample application -For an example implementation see the [Mobile + API](/architecture-scenarios/application/mobile-api) architecture scenario. +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 -::: next-steps -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) +- [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) -- [Tokens used by Auth0](/tokens) -::: diff --git a/articles/api-auth/tutorials/authorization-code-grant.md b/articles/api-auth/tutorials/authorization-code-grant.md index 5717deb3c1..5ecd2127c1 100644 --- a/articles/api-auth/tutorials/authorization-code-grant.md +++ b/articles/api-auth/tutorials/authorization-code-grant.md @@ -1,11 +1,17 @@ --- 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 -<%= include('../../_includes/_pipeline2') %> - ::: 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). ::: @@ -14,7 +20,7 @@ The __Authorization Code__ is an OAuth 2.0 grant that [regular web apps](/quicks Before beginning this tutorial, please: -* Check that your Application's [Grant Type property](/applications/application-grant-types) is set appropriately +* 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 @@ -35,13 +41,13 @@ 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](/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, 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)). The custom scopes must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims). For more information on this, refer to the [Namespacing Custom Claims](#optional-customize-the-tokens) panel. +* `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, [click here to learn more](/protocols/oauth-state). +* `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). @@ -59,18 +65,39 @@ Note that if you alter the value in `scope`, Auth0 will require consent to be gi ## 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): +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/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${account.callback}\"}" + "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}" + } + ] } } ``` @@ -94,15 +121,15 @@ The response contains the `access_token`, `refresh_token`, `id_token`, and `toke } ``` -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. For more information about Refresh Tokens and how to use them, see [our documentation](/tokens/refresh-token). +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 Grant flow](/api-auth/grant/implicit) is more appropriate in that case. +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: +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 { @@ -117,9 +144,9 @@ Once the `access_token` has been obtained it can be used to make calls to the AP ## 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. +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 refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). ## Optional: Customize the Tokens @@ -129,10 +156,7 @@ If you wish to execute special logic unique to the Authorization Code grant, you ## Keep Reading -::: next-steps -- [How to refresh a token](/tokens/refresh-token) +- [Refresh Tokens](/tokens/concepts/refresh-token) - [How to configure an API in Auth0](/apis) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) - [Application Authentication for Server-side Web Apps](/application-auth/server-side-web) -- [Tokens used by Auth0](/tokens) -::: +- [Tokens](/tokens) diff --git a/articles/api-auth/tutorials/client-credentials.md b/articles/api-auth/tutorials/client-credentials.md index 75827d2fbc..567e903447 100644 --- a/articles/api-auth/tutorials/client-credentials.md +++ b/articles/api-auth/tutorials/client-credentials.md @@ -1,16 +1,26 @@ --- -title: How to implement the Client Credentials Grant -description: How to call an API from a server process using OAuth 2.0 and the Client Credentials grant +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 --- -# How to Implement the Client Credentials Grant +# Implement the Client Credentials Grant -<%= include('../../_includes/_pipeline2') %> +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: -* Check that your Application's [Grant Type property](/applications/application-grant-types) is set appropriately -* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 +* 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 @@ -21,11 +31,28 @@ To ask Auth0 for tokens for any of your authorized applications, perform a `POST "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"audience\": \"YOUR_API_IDENTIFIER\"}" + "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" + } + ] } } ``` @@ -33,11 +60,11 @@ To ask Auth0 for tokens for any of your authorized applications, perform a `POST Where: * `grant_type`: This must be `client_credentials`. -* `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). +* `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). +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 { @@ -52,7 +79,7 @@ If you [decode the `access_token`](https://jwt.io/#debugger-io) you will see tha ```json { "iss": "https://${account.namespace}/", - "sub": "YOUR_NON_INTERACTIVE_CLIENT_ID@clients", + "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, @@ -62,30 +89,25 @@ If you [decode the `access_token`](https://jwt.io/#debugger-io) you will see tha ## Modify scopes and claims -You can change the scopes and add custom claims to the `access_token` you got, using [Hooks](/hooks). +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 actually Webtasks, 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. +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. +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, refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +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. +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 -::: next-steps -- [Calling APIs from a Service](/api-auth/grant/client-credentials) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) -- [How to change the scopes and add custom claims to the tokens using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) -- [Tokens used by Auth0](/tokens) -::: +- [Use Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks) +- [Tokens](/tokens) diff --git a/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md b/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md index 925a2160c7..e8c5f642f2 100644 --- a/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md +++ b/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md @@ -2,34 +2,38 @@ 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 --- -# Using Hooks with Client Credentials Grant +# Use Hooks with Client Credentials Grant -<%= include('../../../_includes/_pipeline2') %> +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. -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. -## Overview - -Hooks allow you to customize the behavior of Auth0 using Node.js code. - -They are actually [Webtasks](https://webtask.io/), 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](/hooks/dashboard) or the [Auth0 Command Line Interface (CLI)](/hooks/cli). In this article we will see how you can do either. +You can manage Hooks using the Auth0 Dashboard or the Management API. ## Before you start -Please ensure that: +Create the following: -- You have created an [API defined with the appropriate scopes](${manage_url}/#/apis) -- You have created a [machine to machine application](${manage_url}/#/applications) that is authorized to use the API created in the previous step +- [API defined with the appropriate scopes](${manage_url}/#/apis) +- [Machine-to-machine application](/applications) authorized to use the API -If you haven't done these yet, refer to these docs for details: -- How to set up a Client Credentials Grant: +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) -- [How to execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) +- [Execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) ## Use the Dashboard @@ -47,11 +51,11 @@ If you haven't done these yet, refer to these docs for details: 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 Webtask Editor. +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 Webtask 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. +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) { @@ -64,64 +68,22 @@ You can create more than one hooks per extensibility point but __only one__ can ``` This sample hook will: - - add an arbitrary claim (`https://foo.com/claim`) to the `access_token` + - 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 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](/api-auth/tutorials/adoption/scope-custom-claims) 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 `claim`, you would name the claim `https://foo.com/claim`, instead of just `claim`. + 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. ::: - ![Webtask Editor](/media/articles/api-auth/hooks/cc-webtask-editor.png) + ![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. -## Use the Auth0 CLI - -1. Make sure you have installed the Webtask CLI. You can find detailed instructions in the [Dashboard's Webtask page](${manage_url}/#/account/webtasks). - -2. Create a file with your Node.js code. For our example, we will name the file `myrule.js` and copy the following code: - - ```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); - }; - ``` - -3. Create the Webtask. The command is the following: - - ```text - auth0 create -t credentials-exchange -n client-credentials-exchange-hook -p ${account.namespace}-default file.js - ``` - - Let's break this down: - - `auth0`: The binary to use. - - `create`: The sub-command for creating or updating a Hook. Run in your terminal `auth0 -h` to see the rest. - - `-t credentials-exchange`: The hook type. For this use case, set to `credentials-exchange`. - - `-n client-credentials-exchange-hook`: The webtask's name. Set this to your preference, we chose `client-credentials-exchange-hook`. - - `-p ${account.namespace}-default`: Your account's profile name. Get this value from _Step 2_ of the instructions on the [Dashboard's Webtask page](${manage_url}/#/account/webtasks). - - `file.js`: The name of the file you created in the previous step. - - Run the command. - -4. You will see a message that your hook was created, but in disabled state. To enable the hook, run the command: - - ```text - auth0 enable --profile ${account.namespace}-default client-credentials-exchange-hook - ``` - - Where `client-credentials-exchange-hook` is the name of the webtask, and `${account.namespace}-default` the name of your profile (the same as the one used in the previous step). - -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 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. @@ -130,11 +92,28 @@ To get a token, make a `POST` request at the `https://${account.namespace}/oauth "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"audience\": \"YOUR_API_IDENTIFIER\"}" + "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" + } + ] } } ``` @@ -160,11 +139,11 @@ Content-Type: application/json } ``` -Copy the `access_token`. +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. +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) @@ -174,7 +153,7 @@ Look into the last two items of the __Payload__. Both have been set by our hook: ## 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. +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) @@ -187,9 +166,9 @@ Use the Auth0 CLI to: - [Enable or disable Hooks](/auth0-hooks/cli/enable-disable) - [Review Logs](/auth0-hooks/cli/logs) -## Webtask Input Parameters +## Input Parameters -As you saw in our example, the webtask takes five input parameters. You can use these values for your custom logic. +The hook takes five input parameters. You can use these values for your custom logic. Let's see what each one contains. @@ -222,14 +201,12 @@ Let's see what each one contains. } ``` -- __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')))`. +- __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 -:::next-steps * [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 Credentials Grant using the Dashboard](/api-auth/config/using-the-auth0-dashboard) -* [How to set up a Client Credentials Grant using the Management API](/api-auth/config/using-the-management-api) +* [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/articles/api-auth/tutorials/hybrid-flow.md b/articles/api-auth/tutorials/hybrid-flow.md new file mode 100644 index 0000000000..c00ef7443e --- /dev/null +++ b/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/articles/api-auth/tutorials/implicit-grant.md b/articles/api-auth/tutorials/implicit-grant.md index 19e7340a64..07c8ccc2c5 100644 --- a/articles/api-auth/tutorials/implicit-grant.md +++ b/articles/api-auth/tutorials/implicit-grant.md @@ -1,11 +1,16 @@ --- -title: How to implement the Implicit Grant -description: How to execute an Implicit Grant flow from a SPA Client application. +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 --- -# How to implement the Implicit Grant - -<%= include('../../_includes/_pipeline2') %> +# 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). @@ -15,7 +20,7 @@ The __Implicit Grant__ is an OAuth 2.0 flow that [client-side apps](/quickstart/ Before you begin this tutorial, do the following: -* Check that your Application's [Grant Type property](/applications/application-grant-types) is set appropriately +* 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 @@ -39,19 +44,19 @@ 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 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`). Note that user's consent will be requested, every time the `scope` value changes. The custom scopes must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims). For more information on this, refer to the [Namespacing Custom Claims](#optional-customize-the-tokens) panel. +* `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`. +* `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). +* `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, [click here to learn more](/protocols/oauth-state). +* `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`. @@ -65,7 +70,14 @@ For example: ## 2. Extract the Access Token -After Auth0 has redirected back to the app, you can extract the `access_token` from the hash fragment of the URL: +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) { @@ -84,7 +96,7 @@ function getIdToken() { $(function () { var access_token = getAccessToken(); - // Optional: an id_token will be returned by Auth0 + // Optional: an ID Token will be returned by Auth0 // if your response_type argument contained id_token var id_token = getIdToken(); @@ -114,7 +126,7 @@ $('#get-appointments').click(function(e) { 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, refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +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 @@ -124,22 +136,19 @@ If you wish to execute special logic unique to the Implicit grant, you can look ## Optional: Silent Authentication -If you need to authenticate your users without a login page (for example, when the user is already logged in via [SSO](/sso) scenario) or get a new `access_token` (thus simulate refreshing an expired token), you can use 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. +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). +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 -::: next-steps - [How to protect your SPA against replay attacks](/api-auth/tutorials/nonce) - [How to configure an API in Auth0](/apis) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) - [Application Authentication for Client-side Web Apps](/application-auth/client-side-web) -- [Tokens used by Auth0](/tokens) -::: +- [Tokens](/tokens) diff --git a/articles/api-auth/tutorials/multifactor-resource-owner-password.md b/articles/api-auth/tutorials/multifactor-resource-owner-password.md deleted file mode 100644 index 7d5c7a66d8..0000000000 --- a/articles/api-auth/tutorials/multifactor-resource-owner-password.md +++ /dev/null @@ -1,341 +0,0 @@ ---- -title: Multifactor Authentication and Resource Owner Password -description: How to use Multifactor Authentication with Resource Owner Password Grant. -toc: true ---- -# Multifactor Authentication and the Resource Owner Password Grant - -<%= include('../../_includes/_pipeline2') %> - -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 [multifactor authentication](/multifactor-authentication) 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}). Currently, the supported providers for this flow are [Google Authenticator](/multifactor-authentication/google-auth/admin-guide#enabling-google-authenticator-for-mfa) and [Guardian](/multifactor-authentication/administrator#guardian-basics). [Duo Security](/multifactor-authentication/duo) is __not__ supported. - -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 Multifactor 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": "Multifactor 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; you can get it directly from the app / hardware device. - -- `oob`: The proof of possession is done 'out of band' via a side channel. There are several different channels, including push notification-based authenticators and SMS-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), 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. - -- [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 Multifactor 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 Multifactor 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) 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](/docs/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 currently only available for the Guardian Provider. -::: - -![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/json' }, - body: - { grant_type: 'password', - username: 'USERNAME', - password: 'PASSWORD', - audience: 'API_IDENTIFIER', - scope: 'SCOPE', - 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.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/json' }, - body: - { 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' }, - json: true }; - - 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/json' }, - body: - { 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' }, - json: true }; - - 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/json' }, - body: - { mfa_token: mfa_token, - recovery_code: recovery_code, - otp: otp, - grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code', - client_id: '${account.clientId}', - client_secret: 'YOUR_CLIENT_SECRET' }, - json: true }; - - 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 otp code - console.error('Invalid recovery_code'); - } else { - console.error('Something went wrong'); - } - }); -} -``` - -## MFA API - -Please see the [MFA API section](/multifactor-authentication/api) for detailed information on Auth0's MFA API endpoints. diff --git a/articles/api-auth/tutorials/nonce.md b/articles/api-auth/tutorials/nonce.md index d72074bec1..c83e542ae8 100644 --- a/articles/api-auth/tutorials/nonce.md +++ b/articles/api-auth/tutorials/nonce.md @@ -1,29 +1,52 @@ --- -description: How to securely generate and validate a cryptographic nonce for use with the Implicit Grant +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 Grant +# Mitigate Replay Attacks When Using the Implicit Flow -<%= include('../../_includes/_pipeline2') %> +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). -When using the [Implicit Grant](/api-auth/grant/implicit), a [cryptographic nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) must be sent on authentication requests in order to mitigate replay attacks [as required by the OpenID Connect 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. +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 -[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. +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 bytes = new Uint8Array(length); - var random = window.crypto.getRandomValues(bytes); - var result = []; - var charset = '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZabcdefghijklmnopqrstuvwxyz-._~' - random.forEach(function (c) { - result.push(charset[c % charset.length]); - }); - return result.join(''); + 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; } ``` diff --git a/articles/api-auth/tutorials/password-grant.md b/articles/api-auth/tutorials/password-grant.md index a8d5652461..f8ef39ba44 100644 --- a/articles/api-auth/tutorials/password-grant.md +++ b/articles/api-auth/tutorials/password-grant.md @@ -1,23 +1,31 @@ --- -title: How to implement the Resource Owner Password Grant -description: Step-by-step guide on how to implement the OAuth 2.0 Resource Owner Password Grant +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 --- -# How to implement the Resource Owner Password Grant +# Implement the Resource Owner Password Grant -<%= include('../../_includes/_pipeline2') %> +<%= include('../_includes/_ropg-warning') %> -In this tutorial we will go through the steps required to implement the Resource Owner Password Grant. - -You should use this flow **only if** the following apply: -- The application is absolutely trusted with the user's credentials. For [client side](/api-auth/grant/implicit) applications and [mobile apps](/api-auth/grant/authorization-code-pkce) we recommend using web flows instead. -- Using a redirect-based flow is not possible. If this is not the case and redirects are possible in your application you should use the [Authorization Code Grant](/api-auth/grant/authorization-code) instead. +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 property](/applications/application-grant-types) is set appropriately -* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 -* Check that the [Default Audience and/or Default Directory](/dashboard/dashboard-tenant-settings#api-authorization-settings) has been set appropriately +* 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 @@ -38,11 +46,40 @@ In order to execute the flow the application needs to acquire the Resource Owner "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"password\",\"username\": \"user@example.com\",\"password\": \"pwd\",\"audience\": \"https://someapi.com/api\", \"scope\": \"read:sample\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\"}" + "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" + } + ] } } ``` @@ -55,9 +92,9 @@ Where: * `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](/scopes) the application is asking for. Multiple scopes are separated with whitespace. +* `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) (86400 seconds, which means 24 hours). +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 { @@ -70,18 +107,18 @@ The response contains a [signed JSON Web Token](/jwt), the token's type (which i 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 **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, 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. +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 +### 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`. +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. @@ -94,22 +131,55 @@ To use this variation you will have to change the following request parameters: "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"http://auth0.com/oauth/grant-type/password-realm\",\"username\": \"user@example.com\",\"password\": \"pwd\",\"audience\": \"https://someapi.com/api\", \"scope\": \"read:sample\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"realm\": \"employees\"}" + "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), [Windows Azure AD](/connections/enterprise/azure-active-directory) and [ADFS](/connections/enterprise/adfs) connections. +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: +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 { @@ -124,9 +194,9 @@ Once the `access_token` has been obtained it can be used to make calls to the Re ## 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. +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, refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +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 @@ -136,7 +206,7 @@ If you wish to execute special logic unique to the Password exchange, you can lo ## Optional: Configure MFA -In case you need stronger authentication, than username and password, you can configure MultiFactor Authentication (MFA) using the Resource Owner Password Grant. For details on how to implement this refer to [Multifactor Authentication and Resource Owner Password](/api-auth/tutorials/multifactor-resource-owner-password). +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 @@ -144,9 +214,6 @@ When using this flow from server-side applications, some anomaly detection featu ## Keep reading -::: next-steps * [Call APIs from Highly Trusted Applications](/api-auth/grant/password) * [How to configure an API in Auth0](/apis) -* [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) -* [Tokens used by Auth0](/tokens) -::: +* [Tokens](/tokens) diff --git a/articles/api-auth/tutorials/represent-multiple-apis.md b/articles/api-auth/tutorials/represent-multiple-apis.md index 6f81456900..5eaf10b709 100644 --- a/articles/api-auth/tutorials/represent-multiple-apis.md +++ b/articles/api-auth/tutorials/represent-multiple-apis.md @@ -1,106 +1,126 @@ --- - description: How to use multiple APIs and represent them as a single API in Auth0. + +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 --- -# How to Represent Multiple APIs Using a Single Auth0 API +# Represent Multiple APIs Using a Single Logical API -To simplify your authentication process, you can create a single [API](/apis) using the Auth0 Dashboard to represent all of your existing APIs. Doing this allows you to implement just one authentication flow. You can then control access to the individual APIs by assigning the appropriate scopes. +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 article shows you how to use and represent multiple APIs as a single Resource Server in Auth0 using a [sample application you can download](https://github.com/auth0-samples/auth0-api-auth-implicit-sample) if you would like to follow along as you read. +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 contains: +The sample application uses a microservices architecture and contains: + +* 1 Single-Page Application (SPA) +* 2 APIs (services), called `contacts` and `calendar` -* 1 Single Page Application (SPA); -* 2 APIs (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. -We will represent the two APIs using just one Auth0 API called `Organizer Service`. We will then create two namespaced scopes to demonstrate how you can use the [Implicit Grant](/api-auth/grant/implicit) to access the `calendar` and `contacts` APIs from the SPA. The SPA also uses [Lock](/libraries/lock) to implement the signin screen. +## Prerequisites -Please see the `README` for additional information on setting up the sample on your local environment. +Before beginning this tutorial: -## The Auth0 Application +* [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. -If you don't already have an Auth0 Application (of type **Single Page Web Applications**) with the **OIDC Conformant** flag enabled, you'll need to create one. This represents your application. +## Steps -1. In the [Auth0 Dashboard](${manage_url}), click on [Applications](${manage_url}/#/applications) in the left-hand navigation bar. Click **Create Application**. -2. 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**. When done, click on **Create** to proceed. -3. Navigate to the [Auth0 Application Settings](${manage_url}/#/applications/${account.clientId}/settings) page. Add `http://localhost:3000` and `http://localhost:3000/callback.html` to the Allowed Callback URLs field of your [Auth0 Application Settings](${manage_url}/#/applications/${account.clientId}/settings). -4. Scroll to the bottom of the [Settings](${manage_url}/#/applications/${account.clientId}/settings) page, where you'll find the *Advanced Settings* section. Under the *OAuth* tab, enable the **OIDC Conformant** Flag under the *OAuth* area of *Advanced Settings*. +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 +## Enable a connection for your Application -[Connections](/identityproviders) are sources of users to your application, and if you don't have a sample Connection you can use with your newly-created Application, you will need to configure one. For the purposes of this sample, we'll create a simple [Database Connection](/connections/database) that asks only for the user's email address and a password. +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. In the [Auth0 Dashboard](${manage_url}), click on [Connections > Database](${manage_url}/#/connections/database) in the left-hand navigation bar. Click **Create DB Connection**. +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. Once your Connection is ready, click over to the *Applications* tab, and enable the Connection for your Application. +3. Click the **Applications** tab, and enable the Connection. -### Create a Test User +## Create a test user -If you're working with a newly-created Connection, you won't have any users associated with the Connection. Before you can test your sample's login process, you'll need to create and associate a user with your Connection. +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. In the [Auth0 Dashboard](${manage_url}), click on [Users](${manage_url}/#/users) in the left-hand navigation bar. Click **Create User**. +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** to proceed. - -## Create the Auth0 API +3. Click **Save**. -Log in to your Auth0 Dashboard, and navigate to the APIs section. +## Register a logical API in Auth0 -::: note - For detailed information on working with APIs in the Dashboard, refer to APIs. -::: +Register a single logical [API](/apis) that you will use to represent the multiple APIs contained within the sample application. -Click **Create API**. +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) -You will be prompted to provide a **name** and **identifier**, as well as choose the **signing algorithm**, for your new API. +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 purposes of this article, we'll call our API `Organizer Service` and set its unique identifier to `organize`. By default, the signing algorithm for the tokens this API issues is **RS256**, which we will leave as is. +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. -![](/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png) +When finished, click **Create**. -Once you've provided the required details, click **Create** to proceed. +![](/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png) -### Configure the Auth0 API +## Configure scopes for the logical API -After Auth0 creates your API, you'll be directed to its *Quick Start* page. At this point, you'll need to create the appropriate **Scopes**, which you can do via the *Scopes* page. +To allow the logical API to represent the APIs included within the sample application, you will need to create the proper scopes. -![](/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png) +Scopes allow you to define which API actions will be accessible to calling applications. One scope will represent one API/action combination. -Scopes allow you to define the API data accessible to your applications. You'll need one scope for each API represented and action. For example, if you want to `read` and `delete` from an API called `samples`, you'll need to create the following scopes: +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` -For our sample application, we'll add two scopes: +You can think of each one as a microservice. -* `read:calendar`; -* `read:contacts`. +1. In your newly-created logical API, click the **Scopes** (or **Permissions**) tab. -You can think of each one as a microservice. +![](/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png) -![](/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png) +2. Add two scopes: + +* `read:calendar` +* `read:contacts` + +**Save** your changes. -Add these two scopes to your API and **Save** your changes. +![](/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png) -## Grant Access to the Auth0 API +## Grant access to the logical API -You are now ready to provide access to your APIs by granting Access Tokens to the Auth0 API. By including specific scopes, you can control an application to some or all of the APIs represented by the Auth0 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 Grant](/api-auth/grant/implicit) to reflect the sample. You can, however, use whichever flow best suits your needs. +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 to your API by executing a [client credentials exchange](/api-auth/grant/client-credentials). -* If you are building a **Native App**, you can implement the use of [Authorization Codes using PKCE](/api-auth/grant/authorization-code-pkce). +* 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). ::: -The app initiates the flow and redirects the browser to Auth0 (specifically to the `/authorize` endpoint), so the user can authenticate. +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? @@ -112,21 +132,21 @@ redirect_uri=http://localhost:3000& nonce=NONCE ``` -For additional information on the call's parameters, refer to the [docs on executing an implementing the Implicit Grant](/api-auth/tutorials/implicit-grant#1-get-the-user-s-authorization). - -The SPA executes this call whenever the user clicks **Login**. +::: 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) -Lock handles the login process. +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) -Next, Auth0 authenticates the user. If this is the first time the user goes through this flow, they will be asked to consent to the scopes that are given to the Application. In this case, the user's asked to consent to the app reading their contacts and calendar. +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) -If the user consents, Auth0 continues the authentication process, and upon completion, redirects them back to the app with an `access_token` 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 is done using JavaScript. +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) { @@ -139,8 +159,11 @@ function getAccessToken() { } ``` -The app can then use the `access_token` to call the API on behalf of the user. - -After logging in, you can see buttons that allow you to call either of your APIs. +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/articles/api-auth/tutorials/silent-authentication.md b/articles/api-auth/tutorials/silent-authentication.md index f887fb8fdc..cb23a93b46 100644 --- a/articles/api-auth/tutorials/silent-authentication.md +++ b/articles/api-auth/tutorials/silent-authentication.md @@ -1,106 +1,143 @@ --- -description: How to keep users logged in to your application +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 --- -# Silent Authentication +# Configure Silent Authentication -<%= include('../../_includes/_pipeline2') %> +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. -There are two main participants involved in a [single sign-on (SSO)](/sso) scenario: an Authorization Server (Auth0), and multiple applications. +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. -For privacy reasons, applications cannot query Auth0 directly to determine if a user has logged in via SSO. This means that users must be redirected to Auth0 for SSO authentication. +<%= include('../../_includes/_refresh_token_rotation_recommended.md') %> -However, redirecting users away from your application is usually considered disruptive and should be avoided, from a UX perspective. **Silent authentication** lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. +## Initiate Silent Authentication requests -## Initiate a Silent Authentication request - -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-client). +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=code& + ?response_type=id_token token& client_id=...& redirect_uri=...& state=...& scope=openid...& + nonce=...& + audience=...& + response_mode=...& prompt=none ``` -::: note - The specific parameters on the authentication request will depend on what kind of application is authenticating (regular web application, single page app), and so forth). -::: - -The `prompt=none` parameter will cause Auth0 to immediately redirect to the specified `redirect_uri` (callback URL) with two possible responses: - -* A successful authentication response if the user was already logged in via SSO -* An error response if the user is not logged in via SSO and therefore cannot be silently authenticated +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 response +### Successful authentication responses -If the user was already logged in via SSO, Auth0 will respond exactly as if the user had authenticated manually through the SSO login page. +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 [Authorization Code Grant](/api-auth/grant/authorization-code) (`response_type=code`, used for regular web applications), Auth0 will respond with an authorization code that can be exchanged for an ID Token and optionally an Access Token: +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} - ?code=...& + #id_token=...& + access_token=...& state=...& expires_in=... ``` -Note that this response is indistinguishable from a login performed directly without the `prompt=none` parameter. +This response is indistinguishable from a login performed directly without the `prompt=none` parameter. -### Error response +### Error responses -If the user was not logged in via SSO or their SSO session had expired, Auth0 will redirect to the specified `redirect_uri` (callback URL) with an error: +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=ERROR_CODE& error_description=ERROR_DESCRIPTION& state=... ``` -When using the [Authorization Code Grant](/api-auth/grant/authorization-code), the error response parameters are returned in the query string. When using the [Implicit Grant](/api-auth/grant/implicit), they are returned in the hash fragment instead. - The possible values for `ERROR_CODE` are defined by the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthError): -* `login_required`: The user was not logged in at Auth0, so silent authentication is not possible -* `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). +| 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 -Access Tokens are opaque to applications. This means that applications are unable to inspect the contents of Access Tokens to determine their expiration date. +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: -1. Read the `expires_in` response parameter returned by Auth0 -2. Ignore expiration dates altogether. Instead, try to renew the Access Token if your API rejects a request from the application (such as with a 401). +* 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 Grant](/api-auth/grant/implicit), the `expires_in` parameter is returned by Auth0 as a hash parameter following a successful authentication. For the [Authorization Code Grant](/api-auth/grant/code), it is returned to the backend server when performing the authorization code exchange. +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. -When the Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's SSO session has not expired. +### Error response -In the case of single-page applications, the [`checkSession` method from auth0.js](/libraries/auth0js#using-checksession-to-acquire-new-tokens) can be used to perform silent authentication within a hidden iframe, which results in no UX disruption at all. +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); +} +``` -### How to implement +See [Change Authentication Request Frequency](/mfa/guides/customize-mfa-universal-login#change-authentication-request-frequency) for details. -Implementation of token renewal will depend on the type of application and framework being used. Sample implementations for some of the common platforms can be found below: +## Keep reading -* [Plain JavaScript](/quickstart/spa/vanillajs/05-token-renewal) -* [jQuery](/quickstart/spa/jquery/05-token-renewal) -* [React](/quickstart/spa/react/05-token-renewal) -* [Angular](/quickstart/spa/angular2/05-token-renewal) -* [ASP.NET Core MVC](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Samples/silent-auth) +* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) +* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation) diff --git a/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md b/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md index ba92776416..e6a60b46de 100644 --- a/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md +++ b/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md @@ -1,20 +1,28 @@ --- -title: Using resource owner password from the server side -description: How to use Resource Owner Password Grant from the server side together with anomaly detection. +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 --- -# Using Resource Owner Password from Server side +# Use Resource Owner Password Grant From the Server Side -<%= include('../../_includes/_pipeline2') %> +<%= 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. +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#brute-force-protection) enabled from your dashboard. +Before you continue, make sure to have [brute force protection](/anomaly-detection/guides/enable-disable-brute-force-protection) enabled from your dashboard. -## The flow +## 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. @@ -31,35 +39,48 @@ Brute-force protection relies on having the original user's IP. When calling the 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 -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. +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 -### Configuring 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). -1. Navigate to your [dashboard](${manage_url}) and configure a regular web application or machine to machine application using this [tutorial](/applications#how-to-configure-an-application). +2. Choose a __Token Endpoint Authentication Method__ other than `None` under the [Settings](/dashboard/reference/settings-application) section. -2. Choose a __Token Endpoint Authentication Method__ other than `None` under the [Settings](/applications#application-settings) section. + ![Token Endpoint Authentication Method](/media/articles/api-auth/client-auth-method.png) -![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. -::: + ::: warning + Due to security considerations, the configuration stated on Step 3 will not be available for Non-Authenticated applications. + ::: -3. Scroll to the bottom and click _Show Advanced Settings_. +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): -4. Switch on __Trust Token Endpoint IP Header__ under the _OAuth_ tab to configure the application to trust the IP sent from your server. +- 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. -![Enabling Auth0-Forwarded-For](/media/articles/api-auth/enabling-auth0-forwarded-for.png) +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): -### Sending the end-user IP from your server +- 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). -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 IP is valid, Auth0 will use it as the source IP for brute-force protection. It is important to make sure the provided IP address really belongs to your end user. +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 -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. -
    +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 @@ -72,19 +93,18 @@ app.post('/api/auth', function(req, res, next) { method: 'POST', url: 'https://${account.namespace}/oauth/token', headers: { - 'content-type': 'application/json', + 'content-type': 'application/x-www-form-urlencoded', 'auth0-forwarded-for': req.ip // End user ip }, - body: { + form: { grant_type: 'password', username: 'USERNAME', password: 'PASSWORD', - audience: 'API_IDENTIFIER', + audience: 'YOUR_API_IDENTIFIER', scope: 'SCOPE', client_id: '${account.clientId}', client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated - }, - json: true + } }; request(options, function (error, response, body) { @@ -94,3 +114,15 @@ app.post('/api/auth', function(req, res, next) { }); }); ``` + +### 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/articles/api-auth/tutorials/verify-access-token.md b/articles/api-auth/tutorials/verify-access-token.md deleted file mode 100644 index b67ea77669..0000000000 --- a/articles/api-auth/tutorials/verify-access-token.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -description: How an API can verify a bearer JWT Access Token -toc: true ---- -# Verify Access Tokens for Custom APIs - -<%= include('../../_includes/_pipeline2') %> - -When a custom API receives a request with a bearer [Access Token](/tokens/access-token), the first thing to do is to validate the token. At Auth0, an Access Token used for a custom API is formatted as a [JSON Web Token](/jwt). Validating the token consists of a series of steps, and if any of these fails then the request **must** be rejected. - -This document lists all the validations that your API should perform: - -- Check that the JWT is well formed -- Check the signature -- Validate the standard claims -- Check the Application permissions (scopes) - -::: note -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. -::: - -## Parse the JWT - -First, the API needs to parse the JSON Web Token (JWT) to make sure it's well formed. If this fails the token is considered invalid and the request must be rejected. - -A well formed JWT, consists of three strings separated by dots (.): the header, the payload and the signature. Typically it looks like the following: - -![Sample JWT](/media/articles/api-auth/sample-jwt.png) - -The header and the payload are Base64Url encoded. The signature is created using these two, a secret and the hashing algorithm being used (as specified in the header: HMAC, SHA256 or RSA). - -For details on the JWT structure refer to [What is the JSON Web Token structure?](/jwt#what-is-the-json-web-token-structure-). - -### How can I parse the JWT? - -In order to parse the JWT you can either manually implement all the checks as described in the specification [RFC 7519 > 7.2 Validating a JWT](https://tools.ietf.org/html/rfc7519#section-7.2), or use one of the libraries listed in the _Libraries for Token Signing/Verification_ section of [JWT.io](https://jwt.io/). - -For example, if your API is implemented with Node.js and you want to use 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. If the parsing fails then the library will return a [JsonWebTokenError error](https://github.com/auth0/node-jsonwebtoken#jsonwebtokenerror) with the message `jwt malformed`. - -We should note here that many web frameworks (such as [ASP.NET Core](/quickstart/backend/aspnet-core-webapi) for example) have JWT middleware that handle the token validation. Most of the times this will be a better route to take, rather that resorting to use a third-party library, as the middleware typically integrates well with the framework's overall authentication mechanisms. - -### How can I visually inspect a token? - -A quick way to see what is inside a JWT is by using the [JWT.io](https://jwt.io/) website (alternatively, you can use the [JWT Debugger Chrome Extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd?hl=en)). 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. - -Just paste your token at the _Encoded_ text area and review the decoded results at the right. - -![Decode JWT with JWT.io](/media/articles/api-auth/decode-jwt.png) - -## Check the Signature Algorithm - -The API needs to check if the algorithm, as specified by the JWT header (property `alg`), matches the one expected by the API. If not, the token is considered invalid and the request must be rejected. - -In this case the mismatch might be due to mistake (it is common that the tokens are signed using the `HS256` signing algorithm, but your API is configured for `RS256`, or vice versa), but it could also be due to an attack, hence the request has to be rejected. - -### How can I check the signature algorithm? - -To check if the signature matches the API's expectations, you have to decode the JWT and retrieve the `alg` property of the JWT header. - -Alternatively, you can use one of the libraries listed in the _Libraries for Token Signing/Verification_ section of [JWT.io](https://jwt.io/). - -Following the Node.js example of the previous section, the [jwt.verify()](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback) method of the [node-jsonwebtoken library](https://github.com/auth0/node-jsonwebtoken), supports an `algorithms` argument, that contains a list of strings with the names of the allowed algorithms. - -## Verify the signature - -The API needs to verify the signature of each token. - -This is necessary 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. - -Remember that the signature is created using the header and the payload of the JWT, a secret and the hashing algorithm being used (as specified in the header: HMAC, SHA256 or RSA). The way to verify it, depends on the hashing algorithm: - -- For `HS256`, the API's __Signing Secret__ is used. You can find this information at your [API's Settings](${manage_url}/#/apis). Note that the field is only displayed for APIs that use `HS256`. -- For `RS256`, the tenant's [JSON Web Key Set (JWKS)](/jwks) is used. Your tenant's JWKS is `https://${account.namespace}/.well-known/jwks.json`. - -The most secure practice, and our recommendation, is to use `RS256`. - -### How can I verify the signature? - -To verify a token's signature, you can use one of the libraries available in [JWT.io](https://jwt.io/#libraries-io). - -Following the Node.js example of the previous section, the [jwt.verify()](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback) method supports a `secretOrPublicKey` argument. This should be populated with a string or buffer containing either the secret (for `HS256`), or the PEM encoded public key (for `RS256`). - -::: panel Where can I find my public key? -Go to [Dashboard > Applications](${manage_url}/#/applications). Open the **Settings** of your application, scroll down and open **Advanced Settings**. Open the **Certificates** tab and you will find the Public Key in the **Signing Certificate** field. - -If you want to verify the signature of a token from one of your applications, we recommend getting it by parsing your tenant's [JSON Web Key Set (JWKS)](/jwks). Your tenant's JWKS is `https://${account.namespace}/.well-known/jwks.json`. - -For more info on **RS256** and **JWKS** see [Navigating RS256 and JWKS](https://auth0.com/blog/navigating-rs256-and-jwks/). -::: - -If the verification fails you will get a `invalid signature` error. - -## Validate the Claims - -Once the API verifies the token's signature, the next step is to validate the standard claims of the token's payload. The following validations need to be made: - -- _Token expiration_: The current date/time _must_ be before the expiration date/time listed in the `exp` claim (which is a Unix timestamp). If not, the request must be rejected. -- _Token issuer_: The `iss` claim denotes the issuer of the JWT. The value _must_ match the one configured in your API. For JWTs issued by Auth0, `iss` holds your Auth0 domain with a `https://` prefix and a `/` suffix: `https://${account.namespace}/`. If you are using the [custom domains](/custom-domains) feature, the value will instead be in the following format: `https:///`. -- _Token audience_: The `aud` claim identifies the recipients that the JWT is intended for. For JWTs issued by Auth0, `aud` holds the unique identifier of the target API (field __Identifier__ at your [API's Settings](${manage_url}/#/apis)). If the API is not the intended audience of the JWT, it _must_ reject the request. - -::: panel Token issuance -Auth0 issues tokens with the **iss** claim of whichever domain you used with the request. Custom domain users might use either, their custom domain, or their Auth0 domain. For example, if you used **https://northwind.auth0.com/authorize...** to obtain an Access Token, the **iss** claim of the token you receive will be **https://northwind.auth0.com/**. If you used your custom domain **https://login.northwind.com/authorize...**, the **iss** claim value will be **https://login.northwind.com/**. - -If you get an Access Token for the [Management API](/api/management/v2) using an authorization flow with your custom domain, you **must** call the Management API using the custom domain (your token will be considered invalid otherwise). -::: - -### How can I validate the claims? - -To validate the claims, you have to decode the JWT, retrieve the claims (`exp`, `iss`, `aud`) and validate their values. - -The easiest way however, is to use one of the libraries listed in the _Libraries for Token Signing/Verification_ section of [JWT.io](https://jwt.io/). Note that not all libraries validate all the claims. In [JWT.io](https://jwt.io/) you can see which validations each library supports (look for the green check marks). - -Following the Node.js example, the [jwt.verify()](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback) method of the [node-jsonwebtoken library](https://github.com/auth0/node-jsonwebtoken), validates these claims, depending on the input arguments: - -- `audience`: set `aud` to the __Identifier__ of the API -- `issuer`: string or array of strings of valid values for the `iss` field -- `ignoreExpiration`: set to `false` to validate the expiration of the token - -## Check the Permissions - -By now you have verified that the JWT is valid. The last step is to verify that the application has the permissions required to access the protected resources. - -To do so, you need 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. - -### How can I check the permissions? - -To check the permissions granted to the application, you need to check the contents of the `scope`. - -For example, a user management API might provide three endpoints to read, create or delete a user record: `/create`, `/read` and `/delete`. We have configured this API, so each endpoint requires a specific permission (or scope): - -- The `read:users` scope provides access to the `/read` endpoint. -- The `create:users` scope provides access to the `/create` endpoint. -- The `delete:users` scope provides access to the `/delete` endpoint. - -If a request requests to access the `/create` endpoint, but the `scope` claim does NOT include the value `create:users`, then the API should reject the request with `403 Forbidden`. - -You can see how to do this, for a simple timesheets API in Node.js, in this document: [Check the Application permissions](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-application-permissions). - -## Sample Implementation - -You can find a sample API implementation, in Node.js, in [Server Application + API: Node.js Implementation for the API](/architecture-scenarios/application/server-api/api-implementation-nodejs). - -This document is part the [Server + API Architecture Scenario](/architecture-scenarios/application/server-api), an implementation of a Client Credentials grant for a hypothetical scenario. For more information on the complete solution refer to [Server + API Architecture Scenario](/architecture-scenarios/application/server-api). - - -## Read more - -- [RFC 7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519) -- [JSON Web Tokens (JWT) in Auth0](/jwt) -- [APIs in Auth0](/apis) -- [Why you should always use Access Tokens to secure an API](/api-auth/why-use-access-tokens-to-secure-apis) -- [Tokens used by Auth0](/tokens) -- [Server Application + API: Node.js Implementation for the API](/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/articles/api-auth/user-consent.md b/articles/api-auth/user-consent.md index 7d6e2aa839..75c4329390 100644 --- a/articles/api-auth/user-consent.md +++ b/articles/api-auth/user-consent.md @@ -1,38 +1,29 @@ --- -title: User consent and third-party applications +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 -<%= include('../_includes/_pipeline2') %> +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. -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. -## Types of applications - -All Auth0 applications are either first-party or third-party. - -**First-party** applications are those controlled by the same organization or person that owns the Auth0 domain. -For example, suppose you wanted to access the Contoso API; in this case, there would likely be a first-party application used for logging in at contoso.com. - -**Third-party** applications 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. - -## Creating a third-party application - -All applications created from the [management dashboard](${manage_url}/#/applications) are assumed to be first-party by default. - -At the time of writing, third-party applications cannot be created from the management dashboard. -They must be created through the management API, by setting `is_first_party: false`. +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: @@ -56,13 +47,39 @@ client_id=some_third_party_client
    -If the user chooses to allow the application, this will create a user grant which represents this user's consent to this combination of application, resource server and scopes. +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. -The application will then receive a successful authentication response from Auth0 as usual. +## Scope descriptions -Once consent has been given, the user will no longer see the consent dialog on subsequent logins. +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. -## Handling rejected permissions +![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: @@ -73,7 +90,7 @@ Location: https://fabrikam.com/contoso_social# &state=... ``` -## Skipping consent for first-party applications +## 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. @@ -84,12 +101,12 @@ Note that this option only allows __verifiable__ first-party applications to ski 127.0.0.1 myapp.example ``` -Once you do this, remember to update your application configuration URLs, such as the **Allowed Callback URLs** (found in [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings)), and the callback URL you configured in your application, to match the updated domain-mapping. +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. -## Revoking Consent +## 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. @@ -100,11 +117,18 @@ Click **Revoke** next to the appropriate application. 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. -### Forcing users to provide consent +### 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. -### Customizing the consent dialog +### Customize the consent dialog + +The consent dialog UI cannot be customized or set to a custom domain. + +## Keep reading -As of today the consent dialog UI cannot be customized or set to a custom domain. -We plan to implement this in future releases. +* [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/articles/api-auth/which-oauth-flow-to-use.md b/articles/api-auth/which-oauth-flow-to-use.md index a89e2c4447..3c2fe7f418 100644 --- a/articles/api-auth/which-oauth-flow-to-use.md +++ b/articles/api-auth/which-oauth-flow-to-use.md @@ -1,55 +1,69 @@ --- -title: Which OAuth 2.0 flow should I use? +title: Which OAuth 2.0 Flow Should I Use? toc: true -description: Helps the user identify the proper OAuth 2.0 grant for each use case. +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? +# Which OAuth 2.0 Flow Should I Use? -<%= include('../_includes/_pipeline2') %> +[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 supports several different **grants**. By grants we mean ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Application's type, but other parameters weigh in as well, like the level of trust for the Application, or the experience you want your users to have. +## OAuth 2.0 terminology -Follow this flow to identify the grant that best matches your case. - -![Flowchart for OAuth 2.0 Grants](/media/articles/api-auth/oauth2-grants-flow.png) - -::: panel Quick refresher - OAuth 2.0 terminology - **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user. -- **Application**: an application requesting access to a protected resource on behalf of the Resource Owner. +- **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 Application, for example a browser or a native application. -::: +- **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 Application the Resource Owner? +## Is the Client absolutely trusted with user credentials? -The first decision point is about whether the party that requires access to resources is a machine. In this case of machine to machine authorization, the Application is also the Resource Owner. No end-user authorization is needed in this case. An example is a cron job that uses an API to import information to a database. In this example the cron job is the Application 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. +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. -If this case matches your needs, then for more information on how this flow works and how to implement it refer to [Calling APIs from a service](/api-auth/grant/client-credentials). +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 Application a web app executing on the server? +## Is the Client a Single Page App? -If the Application is a regular web app executing on a server then the **Authorization Code Grant** is the flow you should use. Using this the Application 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 Application, without going through the user's web browser and risk exposure. +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. -If this case matches your needs, then for more information on how this flow works and how to implement it refer to [Calling APIs from server-side web apps](/api-auth/grant/authorization-code). +### Authorization Code Grant with PKCE -## Is the Application absolutely trusted with user credentials? +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. -This decision point may result to suggesting 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 Application is absolutely trusted with this information. +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. -This grant should **only** be used when redirect-based flows (like the [Authorization Code Grant](/api-auth/grant/authorization-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). +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). -## Is the Application a native app or a SPA? +### Implicit Grant -If the Application is a Single Page Application (meaning an application running in a browser using a scripting language such as Javascript) then the **Implicit Grant** should be used. In this case, instead of getting an authorization code that needs to be exchanged for an Access Token, the Application retrieves directly 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, it should be noted that **Implicit Grant** does not return a Refresh Token because the browser cannot keep it private (read the __SPAs and Refresh Tokens__ panel for a workaround). +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 [Call APIs from client-side web apps](/api-auth/grant/implicit). +For more information on how this flow works and how to implement it, refer to [Implicit Flow](/flows/concepts/implicit). -::: panel SPAs and Refresh Tokens -While SPAs cannot use [Refresh Tokens](/tokens/refresh-token), they can take advantage of other mechanics that provide the same function. A workaround to improve user experience is to use `prompt=none` when you invoke [the /authorize endpoint](/api/authentication#implicit-grant). This will not display the login dialog or the consent dialog. For more information on this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication). In addition to that if you call `/authorize` from a hidden iframe and extract the new [Access Token](/tokens/access-token) from the parent frame, then the user will not see the redirects happening. -::: +## Is the Client a Native/Mobile App? -If the Application is a native app then the **Authorization Code Grant using Proof Key for Code Exchange** should be used. This grant adds the concept of a `code_verifier` to the Authorization Code Grant. When at first the application asks for an **Authorization Code** it generates a `code_verifier` and its transformed value called `code_challenge`. The `code_challenge` is sent along with the request. A `code_challenge_method` is also sent. Afterwards, when the application 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. +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 [Calling APIs from Mobile Apps](/api-auth/grant/authorization-code-pkce). +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/articles/api-auth/why-use-access-tokens-to-secure-apis.md b/articles/api-auth/why-use-access-tokens-to-secure-apis.md deleted file mode 100644 index 67de3e521d..0000000000 --- a/articles/api-auth/why-use-access-tokens-to-secure-apis.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Why you should always use Access Tokens to secure an API -description: Explains the differences between Access Token and ID Token and why the latter should never be used to secure an API. ---- -# Why you should always use Access Tokens to secure an API - -<%= include('../_includes/_pipeline2') %> - -There is much confusion on the Web about the differences between the OpenID Connect and OAuth 2.0 specifications, and their respective tokens. As a result many developers publish insecure applications, compromising their users security. The contradicting implementations between identity providers do not help either. - -This article is an attempt to clear what is what and explain why you should always use an [Access Token](/tokens/access-token) to secure an API, and never an [ID Token](/tokens/id-token). - -## Two complementary specifications - -OAuth 2.0 is used to __grant authorization__. It enables you to authorize the Web App A to access your information from Web App B, without sharing your credentials. It was built with _only_ authorization in mind and doesn't include any authentication mechanisms (in other words, it doesn't give the Authorization Server any way of verifying who the user is). - -OpenID Connect builds on OAuth 2.0. It enables you, the user, to verify your identity and give some basic profile information, without sharing your credentials. - -An example is a to-do application which lets you log in using your Google account and can push your to-do items, as calendar entries, to your Google Calendar. The part where you authenticate your identity is implemented via OpenID Connect, while the part where you authorize the to-do application to modify your calendar by adding entries, is implemented via OAuth 2.0. - -::: note - OpenID Connect is about who someone is. OAuth 2.0 is about what they are allowed to do. -::: - -You may have noticed the _"without sharing your credentials"_ part, in our definitions of the two specifications earlier. What you do share in both cases are **tokens**. - -OpenID Connect issues an identity token, known as an `id_token`, while OAuth 2.0 issues an `access_token`. - -## How to use each token - -The `id_token` is a [JWT](/jwt) and is meant for the application only. In the example we used earlier, when you authenticate using Google, an `id_token` is sent from Google to the to-do application, that says who you are. The to-do application can parse [the token's contents](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and use this information, like your name and your profile picture, to customize the user experience. - -::: warning -You must never use the info in an `id_token` unless you have validated it! For more information refer to: [How to validate an ID Token](/tokens/id-token#validate-an-id-token). For a list of libraries you can use to verify a JWT refer to [jwt.io](https://jwt.io/). -::: - -The `access_token` can be any type of token (not necessarily a JWT) and is meant for the API. Its purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the `scope` that has been granted). In the example we used earlier, after you authenticate, and provide your consent that the to-do application can have read/write access to your calendar, an `access_token` is sent from Google to the to-do application. Each time the to-do application wants to access your Google Calendar it will make a request to the Google Calendar API, using this `access_token` in an HTTP `Authorization` header. - -::: note - Access Tokens should be treated as opaque strings by applications. They are only meant for the API. Your application should not attempt to decode them or depend on a particular access_token format. -::: - -## How NOT to use each token - -Now that we've seen what these tokens can be used for, let's see what they cannot be used for. - -- __An `access_token` cannot be used for authentication__. It holds no authenticating information about the user (in fact, the only identifying information about the user is their ID, located in the `sub` claim). It cannot tell us if the user has authenticated and when. - -- __An `id_token` cannot be used for API access__. Each token contains information on the intended audience (recipient). According to the OpenID Connect specification, the audience (claim `aud`) of each `id_token` must be the `client_id` of the application making the authentication request. If it isn't you shouldn't trust the token. An API, on the other hand, expects a token with the audience set to the API's unique identifier. So unless you are in control of both the application and the API, sending an `id_token` to an API will not work. Furthermore, the `id_token` is signed with a secret that is known to the application (since it is issued to a particular application). This means that if an API were to accept such token, it would have no way of knowing if the application has modified the token (to add more scopes) and then signed it again. - -## Compare Tokens - -To better understand what we just read, let's look at the contents of example tokens. - -The (decoded) contents of an `id_token` look 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 is meant for __authenticating the user to the application__. Note that the audience (`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 email" -} -``` - -This token is meant for __authorizing the user to the API__. As such, it is completely opaque to applications, meaning that an application should not care about the contents of this token, decode it or depend on a particular token format. 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). - -Since in many cases it is desirable to retrieve additional user information at the API, this token is also valid for calling the `/userinfo` API, which will return the user's profile information. So the intented audience (`aud` claim) of the token is either the API (`my-api-identifier`) or the `/userinfo` endpoint (`https://${account.namespace}/userinfo`). - -## Keep reading - -::: next-steps -* [The problem with OAuth for Authentication](http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html) -* [User Authentication with OAuth 2.0](https://oauth.net/articles/authentication/) -* [OAuth 2.0 Overview](/protocols/oauth2) -* [OpenID Connect Overview](/protocols/oidc) -* [Obtaining and Using Access Tokens](/tokens/access-token) -* [Obtaining and Using ID Tokens](/tokens/id-token) -::: diff --git a/articles/api/authentication/_application-reg.md b/articles/api/authentication/_application-reg.md index 3ef1f90f27..21471c3821 100644 --- a/articles/api/authentication/_application-reg.md +++ b/articles/api/authentication/_application-reg.md @@ -39,7 +39,7 @@ curl --request POST \ "link": "#dynamic-application-client-registration" }) %> -With a name and the necessary callback URLs, you can dynamically register a client with Auth0. No token is needed for this request. +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 @@ -47,4 +47,4 @@ With a name and the necessary callback URLs, you can dynamically register a clie |:-----------------|:------------| | `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`, but it can also be `none`. | +| `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/articles/api/authentication/_change-password.md b/articles/api/authentication/_change-password.md index 34d23d69e3..00e44b2854 100644 --- a/articles/api/authentication/_change-password.md +++ b/articles/api/authentication/_change-password.md @@ -1,13 +1,13 @@ # Change Password - + ```http POST https://${account.namespace}/dbconnections/change_password Content-Type: application/json { "client_id": "${account.clientId}", "email": "EMAIL", - "password": "", "connection": "CONNECTION", + "organization": "ORGANIZATION_ID" } ``` @@ -15,7 +15,7 @@ Content-Type: application/json curl --request POST \ --url https://${account.namespace}/dbconnections/change_password \ --header 'content-type: application/json' \ - --data '{"client_id": "${account.clientId}","email": "EMAIL", "password": "", "connection": "CONNECTION"}' + --data '{"client_id": "${account.clientId}","email": "EMAIL", "connection": "CONNECTION", "organization": "ORGANIZATION_ID"}' ``` ```javascript @@ -29,7 +29,8 @@ curl --request POST \ webAuth.changePassword({ connection: 'CONNECTION', - email: 'EMAIL' + email: 'EMAIL', + organization: 'ORGANIZATION_ID' }, function (err, resp) { if(err){ console.log(err.message); @@ -53,40 +54,34 @@ curl --request POST \ "We've just sent you an email to reset your password." ``` -Given a user's `email` address and a `connection`, Auth0 will send a change password email. +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. -This endpoint only works for database connections. +Note: This endpoint only works for database connections. ### Request Parameters | Parameter | Description | |:-----------------|:------------| -| `client_id`
    Required | The `client_id` of your client. | +| `client_id` | The `client_id` of your client. | | `email`
    Required | The user's email address. | -| `password ` | The new password. See the next paragraph for the case when a password can be set. | | `connection`
    Required | The name of the database connection configured to your client. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> +| `organization` | The `organization_id` of the Organization associated with the user. | ### Remarks -- If you are using Lock version 9 and above, **do not set the password field** or you will receive a *password is not allowed* error. You can only set the password if you are using Lock version 8. -- If a password is provided, when the user clicks on the confirm password change link, the new password specified in this POST will be set for this user. -- If a password is NOT provided, when the user clicks on the password change link they will be redirected to a page asking them for a new password. -- 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). +- 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). -### More Information +### 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](/policies/rate-limits) +- [Auth0 API Rate Limit Policy](/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) diff --git a/articles/api/authentication/_impersonation.md b/articles/api/authentication/_impersonation.md deleted file mode 100644 index 66659ae9d1..0000000000 --- a/articles/api/authentication/_impersonation.md +++ /dev/null @@ -1,86 +0,0 @@ -# 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. - - -### More Information - -- [Impersonation](/user-profile/user-impersonation) diff --git a/articles/api/authentication/_introduction.md b/articles/api/authentication/_introduction.md index fac162fb6c..0df041af98 100644 --- a/articles/api/authentication/_introduction.md +++ b/articles/api/authentication/_introduction.md @@ -2,7 +2,7 @@ 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), and [SAML](/protocols/saml). +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). @@ -14,24 +14,49 @@ The Authentication API is served over HTTPS. All URLs referenced in the document ## Authentication methods -There are three ways to authenticate with this API: -- with an OAuth2 Access Token in the `Authorization` request header field (which uses the `Bearer` authentication scheme to transmit the Access Token) -- with your Client ID and Client Secret credentials -- only with your Client ID +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) -Each endpoint supports only one option. +### OAuth2 Access Token -### OAuth2 token +Send a valid Access Token in the `Authorization` header, using the `Bearer` authentication scheme. -In this case, you have to send a valid [Access Token](/tokens/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. +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 -In this case, you have to send your Client ID and Client Secret information in the request JSON body. 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). +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 -For public applications (such as applications that cannot hold credentials securely, like SPAs or mobile apps) we offer some endpoints that can be accessed using only the Client ID. An example is the [Implicit Grant](#implicit-grant). +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 @@ -44,40 +69,58 @@ For POST requests, parameters not included in the URL should be encoded as 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 SSO Flow](#idp-initiated-sso-flow) that uses both a query string parameter and a `x-www-form-urlencoded` value. +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: +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 either the [Authentication API Debugger](/extensions/authentication-api-debugger) or our preconfigured [Postman collection](https://app.getpostman.com/run-collection/2a9bc47495ab00cda178). For some endpoints both options are available. +You can test the endpoints using the [Authentication API Debugger](/extensions/authentication-api-debugger). -### Test with the 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. -If it's the first time you use it, you have to install it using the [dashboard](https://${manage_url}/#/extensions). Once you do you are ready to configure your app's settings and run your tests. +<%= 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: -Note that its URL varies according to your tenant's region: -- US West -- Europe Central -- Australia +- 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**. -### Test with Postman +### Authentications flows -If you are working with APIs, you are probably already familiar with [Postman](https://www.getpostman.com/), a development tool that enables you to configure and run API requests. +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**. -We have preconfigured a collection that you can [download](https://app.getpostman.com/run-collection/2a9bc47495ab00cda178). You will have to configure some environment variables to customize the requests. For more information on this, refer to [Using the Auth0 API with our Postman Collections](/api/postman). ## Errors -When an error occurs, you will receive an error object. All error objects have an error code and an error description so that your applications can tell what the problem is. +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. @@ -93,10 +136,10 @@ If you exceed the provided rate limit for a given endpoint, you will receive the 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](/connections/database/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}). +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/articles/api/authentication/_login.md b/articles/api/authentication/_login.md index fa63346cbd..ede24026ba 100644 --- a/articles/api/authentication/_login.md +++ b/articles/api/authentication/_login.md @@ -1,5 +1,13 @@ + # Login +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#social" +}) %> + ## Social ```http @@ -21,7 +29,7 @@ GET https://${account.namespace}/authorize? domain: '${account.namespace}', clientID: '${account.clientId}' }); - + // Trigger login with google webAuth.authorize({ connection: 'google-oauth2' @@ -39,14 +47,9 @@ GET https://${account.namespace}/authorize? ``` -<%= include('../../_includes/_http-method', { - "http_badge": "badge-primary", - "http_method": "GET", - "path": "/authorize", - "link": "#social" -}) %> +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). -Use this endpoint to authenticate a user with a social provider. It will return a `302` redirect to the social provider specified in `connection`. +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. @@ -56,40 +59,26 @@ Social connections only support browser-based (passive) authentication because m | Parameter | Description | |:-----------------|:------------| -| `response_type`
    Required | Use `code` for server side flows and `token` for application side flows | +| `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. | +| `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). | - -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> - -1. At 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/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. +| `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 -- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). - -- 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. +- 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 -### More Information - -- [Supported Social Identity Providers](/identityproviders#social) +- [Supported Social Identity Providers](https://marketplace.auth0.com/features/social-connections) - [Custom Social Connections](/connections/social/oauth2) -- [Using the State Parameter](/protocols/oauth2/oauth-state) +- [State Parameter](/secure/attack-protection/state-parameters) - [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) - ## Database/AD/LDAP (Passive) ```http @@ -98,6 +87,7 @@ GET https://${account.namespace}/authorize? client_id=${account.clientId}& connection=CONNECTION& redirect_uri=${account.callback}& + scope=openid%20profile%20email& state=STATE ``` @@ -110,64 +100,46 @@ GET https://${account.namespace}/authorize? domain: '${account.namespace}', clientID: '${account.clientId}' }); - + // Calculate URL to redirect to var url = webAuth.client.buildAuthorizeUrl({ clientID: '${account.clientId}', // string responseType: 'token', // code or token redirectUri: '${account.callback}', + scope: 'openid profile email' state: 'YOUR_STATE' }); - + // Redirect to url // ... ``` -<%= include('../../_includes/_http-method', { - "http_badge": "badge-primary", - "http_method": "GET", - "path": "/authorize", - "link": "#database-ad-ldap-passive-" -}) %> - -Use this 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 login with email and password. +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 | Use `code` for server side flows and `token` for application side flows. | +| `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. | +| `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. | - -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> - -1. At 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/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. - - ### Remarks -- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). -- 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. +- 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). -### More Information +### Learn More - [Database Identity Providers](/connections/database) -- [Rate Limits on User/Password Authentication](/connections/database/rate-limits) +- [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits) - [Active Directory/LDAP Connector](/connector) -- [Using the State Parameter](/protocols/oauth2/oauth-state) +- [State Parameter](/protocols/oauth2/oauth-state) - [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) ## Enterprise (SAML and Others) @@ -190,69 +162,212 @@ GET https://${account.namespace}/authorize? domain: '${account.namespace}', clientID: '${account.clientId}' }); - - // Trigger login using redirect with credentials to enterprise connections - webAuth.redirect.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' - }); - // Trigger login using popup mode with credentials to enterprise connections - webAuth.popup.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' + // Calculate URL to redirect to + var url = webAuth.client.buildAuthorizeUrl({ + clientID: 'YOUR_CLIENT_ID', // string + responseType: 'token', // code or token + redirectUri: 'https://YOUR_APP/callback', + scope: 'openid profile email' + state: 'YOUR_STATE' }); + + // Redirect to url + // ... ``` -<%= include('../../_includes/_http-method', { - "http_badge": "badge-primary", - "http_method": "GET", - "path": "/authorize", - "link": "#enterprise-saml-and-others-" -}) %> - -Use this 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. +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 | Use `code` for server side flows, `token` for application side flows. | +| `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. | +| `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 -### Test with Authentication API Debugger +- [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-) -<%= include('../../_includes/_test-this-endpoint') %> +## Back-Channel Login -1. At 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). +:::note +This feature is currently in Early Access. To request access, contact your Technical Account Manager. +::: -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). +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). -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. +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 -- If no `connection` is specified, it will redirect to the [Login Page](https://${account.namespace}/login) and show the Login Widget. -- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). -- 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). -- In order to use `loginWithCredentials`, auth0.js needs to make cross-origin calls. Check the [Cross-Origin Authentication](/cross-origin-authentication) article to understand the limitations of this approach. +The following code sample is an example login hint: -### More Information + ```http + { + "format": "iss_sub", + "iss": "https://[TENANT_DOMAIN]/", + "sub": "auth0|[USER ID]" + } + ``` -- [SAML](/protocols/saml) -- [Obtain a Client Id and Client Secret for Microsoft Azure Active Directory](/connections/enterprise/azure-active-directory) -- [Using the State Parameter](/protocols/oauth2/oauth-state) -- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) +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/articles/api/authentication/_logout.md b/articles/api/authentication/_logout.md index e2c0661bd1..930bf1a337 100644 --- a/articles/api/authentication/_logout.md +++ b/articles/api/authentication/_logout.md @@ -1,4 +1,13 @@ + # 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? @@ -30,43 +39,158 @@ curl --request GET \ ``` +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": "/v2/logout", + "path": "/oidc/logout", "link": "#logout" }) %> -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 (see [Setting Allowed Logout URLs at the App Level](/logout#set-the-allowed-logout-urls-at-the-application-level)). -- If the `client_id` parameter is NOT included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the tenant level (see [Setting Allowed Logout URLs at the Tenant Level](/logout#set-the-allowed-logout-urls-at-the-tenant-level)). +```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 | -|:-----------------|:------------| -| `returnTo ` | URL to redirect the user after the logout. | -| `client_id` | The `client_id` of your application. | -| `federated` | 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`. | +| 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 -### Test with Authentication API Debugger +- 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). -<%= include('../../_includes/_test-this-endpoint') %> +### Learn More -1. At 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). +- [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) -1. Copy the **Callback URL** and set it as part of the **Allowed Logout URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). +## SAML Logout -1. At the *Other Flows* tab, click **Logout**, or **Logout (Federated)** to log the user out of the identity provider as well. +```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}' +``` -### Remarks +Use this endpoint to log out a user from an Auth0 tenant configured as a SAML identity provider (IdP). -- Logging the user out of their identity provider is not common practice, so think about the user experience before you use the `federated` querystring 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). +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). -### More Information +### 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) + +## Global Token Revocation +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/global-token-revocation/connection/YourConnectionName", + "link": "#logout" +}) %> + +Use this endpoint with the [Okta Workforce Identity Cloud Universal Logout](https://developer.okta.com/docs/guides/oin-universal-logout-overview/) to log users out of your applications. To learn more, read [Universal Logout](https://auth0.com/docs/authenticate/login/logout/universal-logout). + +### Request Parameters +| Parameter | Description | +| :-- | :-- | +| `subject` | `{ "format": "iss_sub", "iss": "https://issuer.example.com/", "sub": "145234573" }` | + +### Remarks +- A request to this endpoint revokes sessions cookies and refresh tokens, but not access tokens. +- You must authenticate at the endpoint before revoking user sessions. Review [Endpoint Authentication](https://developer.okta.com/docs/guides/oin-universal-logout-overview/#endpoint-authentication). diff --git a/articles/api/authentication/_multifactor-authentication.md b/articles/api/authentication/_multifactor-authentication.md index 83fc1cb202..32c6a59802 100644 --- a/articles/api/authentication/_multifactor-authentication.md +++ b/articles/api/authentication/_multifactor-authentication.md @@ -1,18 +1,18 @@ -# Multifactor Authentication +# Multi-factor Authentication -The Multifactor Authentication (MFA) API endpoints allow you to enforce MFA when users interact with [the Token endpoints](#get-token), as well enroll and manage user authenticators. +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 multifactor 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. +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. -For more information, check out: +To learn more, read: -- [Multifactor Authentication and Resource Owner Password](/api-auth/tutorials/multifactor-resource-owner-password) -- [Multifactor Authentication API](/multifactor-authentication/api) -- [Multifactor Authentication in Auth0](/multifactor-authentication) +- [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 +## Challenge Request ```http POST https://${account.namespace}/mfa/challenge @@ -62,6 +62,7 @@ Content-Type: application/json ``` > RESPONSE SAMPLE FOR OOB WITHOUT BINDING METHOD: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -72,6 +73,7 @@ Content-Type: application/json ``` > RESPONSE SAMPLE FOR OOB WITH BINDING METHOD: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -82,21 +84,14 @@ Content-Type: application/json } ``` -<%= include('../../_includes/_http-method', { - "http_badge": "badge-success", - "http_method": "POST", - "path": "/mfa/challenge", - "link": "#multifactor-authentication" -}) %> - -Request a challenge based on the challenge types supported by the application and user. +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 messages or out-of-band (OOB) +- `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 multifactor authentication with a one-time password](#verify-with-one-time-password-otp-). +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 @@ -104,10 +99,11 @@ If OTP is supported by the user and you don't want to request a different factor |:-----------------|:------------| | `mfa_token`
    Required | The token received from `mfa_required` error. | | `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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | +| `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. | -| `oob_channel` | **(early access users only)** The channel to use for OOB. Can only be provided when `challenge_type` is `oob`. Accepted channel types are `sms` or `auth0`. Excluding this parameter means that your client application will accept all supported OOB channels. | -| `authenticator_id` | **(early access users only)** 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. | +| `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 @@ -115,31 +111,27 @@ If OTP is supported by the user and you don't want to request a different factor - 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. -- **(early access only)** If the user is not enrolled, you will get a `association_required` error, indicating the user needs to enroll to use MFA. Check [Add an authenticator](#add-an-authenticator) below on how to proceed. +- 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. -### More information +### Learn More -- [Associate a New Authenticator for Use with Multifactor Authentication](/multifactor-authentication/api/challenges) +* [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) +## Verify with One-Time Password (OTP) ```http POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "client_id": "${account.clientId}", - "client_secret": "YOUR_CLIENT_SECRET", - "mfa_token": "MFA_TOKEN", - "grant_type": "http://auth0.com/oauth/grant-type/mfa-otp", - "otp": "OTP_CODE" -} +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/json' \ - --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"}' + --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 @@ -147,14 +139,14 @@ var request = require("request"); var options = { method: 'POST', url: 'https://${account.namespace}/oauth/token', - headers: { 'content-type': 'application/json' }, - body: + 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' }, - json: true }; + client_secret: 'YOUR_CLIENT_SECRET' } + }; request(options, function (error, response, body) { if (error) throw new Error(error); @@ -164,6 +156,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE FOR OTP: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -181,7 +174,7 @@ Content-Type: application/json "link": "#multifactor-authentication" }) %> -Verifies multifactor authentication (MFA) using a one-time password (OTP). +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`. @@ -192,35 +185,31 @@ The response is the same as responses for `password` or `http://auth0.com/oauth/ | 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`
    Required | Your application's Client ID. | -| `client_secret` | Your application's Client Secret. **Required** when the **Token Endpoint Authentication Method** field at your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | +| `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. | -### More informationm +### Learn More -- [Associate an OTP Authenticator](/multifactor-authentication/api/otp) +- [Associate OTP Authenticators](/mfa/guides/mfa-api/otp) -## Verify with out-of-band (OOB) +## Verify with Out-of-Band (OOB) ```http POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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" -} +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/json' \ - --data '{"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"}' + --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 @@ -228,15 +217,15 @@ var request = require("request"); var options = { method: 'POST', url: 'https://${account.namespace}/oauth/token', - headers: { 'content-type': 'application/json' }, - body: + 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' }, - json: true }; + client_secret: 'YOUR_CLIENT_SECRET' } + }; request(options, function (error, response, body) { if (error) throw new Error(error); @@ -246,6 +235,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE FOR PENDING CHALLENGE: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -256,6 +246,7 @@ Content-Type: application/json ``` > RESPONSE SAMPLE FOR VERIFIED CHALLENGE: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -267,6 +258,7 @@ Content-Type: application/json ``` > RESPONSE SAMPLE FOR REJECTED CHALLENGE: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -283,51 +275,48 @@ Content-Type: application/json "link": "#multifactor-authentication" }) %> -Verifies multifactor authentication (MFA) using an out-of-band (OOB) challenge (either Push notification or SMS). +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. +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 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. +- 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 a 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. +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`. | +| `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_secret` | Your application's Client Secret. **Required** when the **Token Endpoint Authentication Method** field at your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | +| `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. | -### More informationm +### Learn More -- [Associate an OTP Authenticator](/multifactor-authentication/api/oob) +- [Associate Out-of-Band Authenticators](/mfa/guides/mfa-api/oob) -## Verify with recovery code +## Verify with Recovery Code ```http POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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" -} +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/json' \ - --data '{"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"}' + --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 @@ -335,14 +324,14 @@ var request = require("request"); var options = { method: 'POST', url: 'https://${account.namespace}/oauth/token', - headers: { 'content-type': 'application/json' }, - body: + 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-recover-code', + grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code', client_id: '${account.clientId}', - client_secret: 'YOUR_CLIENT_SECRET' }, - json: true }; + client_secret: 'YOUR_CLIENT_SECRET' } + }; request(options, function (error, response, body) { if (error) throw new Error(error); @@ -352,6 +341,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE FOR OTP: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -370,23 +360,25 @@ Content-Type: application/json "link": "#multifactor-authentication" }) %> -Verifies multifactor authentication (MFA) using a recovery code. +Verifies multi-factor authentication (MFA) using a recovery code. -Some multifactor 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. +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. +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 OTP MFA use `http://auth0.com/oauth/grant-type/mfa-otp`. | +| `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_secret` | Your application's Client Secret. **Required** when the **Token Endpoint Authentication Method** field at your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | +| `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 +## Add an Authenticator ```http POST https://${account.namespace}/mfa/associate @@ -401,7 +393,6 @@ Authorization: Bearer ACCESS_TOKEN or MFA_TOKEN } ``` - ```shell curl --request POST \ --url 'https://${account.namespace}/mfa/associate' \ @@ -435,6 +426,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE FOR OOB (SMS channel): + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -442,12 +434,13 @@ Content-Type: application/json "oob_code": "Fe26.2**da6....", "binding_method":"prompt", "authenticator_type":"oob", - "oob_channel":"sms", + "oob_channels":"sms", "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"], } ``` > RESPONSE SAMPLE FOR OOB (Auth0 channel): + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -455,12 +448,13 @@ Content-Type: application/json "oob_code": "Fe26.2**da6....", "barcode_uri":"otpauth://...", "authenticator_type":"oob", - "oob_channel":"auth0", + "oob_channels":"auth0", "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"], } ``` > RESPONSE SAMPLE FOR OTP: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -478,39 +472,37 @@ Content-Type: application/json "link": "#multifactor-authentication" }) %> -::: warning -This endpoint is still under development. It is available to customers with early access. -::: +Associates or adds a new authenticator for multi-factor authentication (MFA). -Associates or adds a new authenticator for multifactor authentication. +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 active authenticators, an [Access Token](/tokens/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. -If the user has no active authenticators, you can use the `mfa_token` from the `mfa_required` error in place of an [Access Token](/tokens/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. -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. -A `recovery_codes` field is included in the response the first time an authenticator is added. You can use `recovery_codes` to pass multifactor authentication as shown on [Verify with recovery code](#verify-with-recovery-code) above. - -To access this endoint you must set an [Access Token](/tokens/access-token) at the Authorization header, with the following claims: +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` +- `audience`: `https://${account.namespace}/mfa/` ### Request parameters | Parameter | Description | |:-----------------|:------------| | `client_id`
    Required | Your application's Client ID. | -| `client_secret` | Your application's Client Secret. **Required** when the **Token Endpoint Authentication Method** field in your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | +| `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_channel` | The type of OOB channels supported by the client. An array with values `"auth0"` or `"sms"`. Required if `authenticator_types` include `oob`. | -| `phone_number` | The phone number to use for SMS. Required if `oob_channel` includes `sms`. | +| `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`. | -### More information +### Learn More -- [Associate a New Authenticator for Use with Multifactor Authentication](/multifactor-authentication/api) +- [Multi-factor Authentication API](/mfa/concepts/mfa-api) -## List authenticators +## List Authenticators ```http GET https://${account.namespace}/mfa/authenticators @@ -544,6 +536,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE: + ```JSON HTTP/1.1 200 OK Content-Type: application/json @@ -556,21 +549,21 @@ Content-Type: application/json { "id":"sms|dev_gB342kcL2K22S4yB", "authenticator_type":"oob", - "oob_channel":"sms", + "oob_channels":"sms", "name":"+X XXXX1234", "active":true }, { "id":"sms|dev_gB342kcL2K22S4yB", "authenticator_type":"oob", - "oob_channel":"sms", + "oob_channels":"sms", "name":"+X XXXX1234", "active":false }, { "id":"push|dev_433sJ7Mcwj9P794y", "authenticator_type":"oob", - "oob_channel":"auth0", + "oob_channels":"auth0", "name":"John's Device", "active":true }, @@ -581,6 +574,7 @@ Content-Type: application/json } ] ``` + <%= include('../../_includes/_http-method', { "http_badge": "badge-primary", "http_method": "GET", @@ -588,28 +582,24 @@ Content-Type: application/json "link": "#multifactor-authentication" }) %> -::: warning -This endpoint is still under development. It is available to customers with early access. -::: - Returns a list of authenticators associated with your application. -To access this endoint you must set an [Access Token](/tokens/access-token) at the Authorization header, with the following claims: +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` +- `audience`: `https://${account.namespace}/mfa/` ### Request Parameters | Parameter | Description | |:-----------------|:------------| -| `ACCESS_TOKEN`
    Required | The `access_token` obtained during login. | +| `ACCESS_TOKEN`
    Required | The Access Token obtained during login. | -#### More information +#### Learn More -- [Manage Authenticators: List Authenticators](/multifactor-authentication/api/manage#list-authenticators) +- [Manage Authenticators](/mfa/guides/mfa-api/manage) -## Delete an authenticator +## Delete an Authenticator ```http DELETE https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID @@ -641,6 +631,7 @@ request(options, function (error, response, body) { ``` > RESPONSE SAMPLE: + ```JSON HTTP/1.1 204 OK ``` @@ -651,26 +642,21 @@ HTTP/1.1 204 OK "link": "#multifactor-authentication" }) %> -::: warning -This endpoint is still under development. It is available to customers with early access. -::: - Deletes an associated authenticator using its ID. You can get authenticator IDs by [listing the authenticators](#list-authenticators). -To access this endoint you must set an [Access Token](/tokens/access-token) at the Authorization header, with the following claims: +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` - +- `audience`: `https://${account.namespace}/mfa/` ### Request Parameters | Parameter | Description | |:-----------------|:------------| -| `ACCESS_TOKEN`
    Required | The `access_token` obtained during login. | +| `ACCESS_TOKEN`
    Required | The Access Token obtained during login. | | `AUTHENTICATOR_ID`
    Required | The ID of the authenticator to delete. -### More information +### Learn More -- [Manage Authenticators: Delete Authenticators](/multifactor-authentication/api/manage#delete-authenticators) +- [Manage Authenticators](/mfa/guides/mfa-api/manage) diff --git a/articles/api/authentication/_passwordless.md b/articles/api/authentication/_passwordless.md index 76f89ac175..4cb6994684 100644 --- a/articles/api/authentication/_passwordless.md +++ b/articles/api/authentication/_passwordless.md @@ -2,7 +2,7 @@ # 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. +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 @@ -11,9 +11,10 @@ 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": "EMAIL", //set for connection=email - "phone_number": "PHONE_NUMBER", //set for connection=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", @@ -26,7 +27,7 @@ Content-Type: application/json curl --request POST \ --url 'https://${account.namespace}/passwordless/start' \ --header 'content-type: application/json' \ - --data '{"client_id":"${account.clientId}", "connection":"email|sms", "email":"EMAIL", "phone_number":"PHONE_NUMBER", "send":"link|code", "authParams":{"scope": "openid","state": "YOUR_STATE"}}' + --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 @@ -89,54 +90,54 @@ You have three options for [passwordless authentication](/connections/passwordle | 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. | -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> ### 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 [/oauth/ro 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 has a [rate limit](/policies/rate-limits#authentication-api) of 50 requests per hour per IP. +- 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). -### More Information +### Learn More - [Passwordless Authentication](/connections/passwordless) -- [Authenticate users with using Passwordless Authentication via Email](/connections/passwordless/email) -- [Authenticate users with a one-time code via SMS](/connections/passwordless/sms) -- [Authenticate users with Touch ID](/connections/passwordless/ios-touch-id-swift) -- [Passwordless FAQ](/connections/passwordless/faq) +- [Passwordless Best Practices](/connections/passwordless/best-practices) ## Authenticate User ```http -POST https://${account.namespace}/oauth/ro +POST https://${account.namespace}/oauth/token Content-Type: application/json { + "grant_type" : "http://auth0.com/oauth/grant-type/passwordless/otp", "client_id": "${account.clientId}", - "connection": "email|sms", - "grant_type": "password", - "username": "EMAIL|PHONE", //email or phone number - "password": "VERIFICATION_CODE", //the verification code - "scope": "SCOPE" + "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/ro' \ + --url 'https://${account.namespace}/oauth/token' \ --header 'content-type: application/json' \ - --data '{"client_id":"${account.clientId}", "connection":"email|sms", "grant_type":"password", "username":"EMAIL|PHONE", "password":"VERIFICATION_CODE", "scope":"SCOPE"}' + --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 @@ -184,55 +185,72 @@ curl --request POST \ <%= include('../../_includes/_http-method', { "http_badge": "badge-success", "http_method": "POST", - "path": "/oauth/ro", + "path": "/oauth/token", "link": "#authenticate-user" }) %> -::: warning -This feature is disabled by default for new tenants as of 8 June 2017. Please see [Application Grant Types](/applications/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. +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. | -| `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`. | +| `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 -### Test with Postman +For the complete error code reference for this endpoint refer to [Standard Error Responses](#standard-error-responses). -<%= include('../../_includes/_test-with-postman') %> +### Learn More -### Test with Authentication API Debugger +- [Passwordless Authentication](/connections/passwordless) + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/passwordless/verify", + "link": "#authenticate-user-legacy" +}) %> -<%= include('../../_includes/_test-this-endpoint') %> +::: 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. +::: -1. At the *Configuration* tab, set the fields **Application** (select the application you want to use for the test) and **Connection** (use `sms` or `email`). +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. -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). +### Request Parameters -1. At 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**. +| 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 `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 /oauth/ro](#post-oauth-ro). +For the complete error code reference for this endpoint refer to [Errors > POST /passwordless/verify](#post-passwordless-verify). -### More Information +### Learn More + +- [Passwordless Best Practices](/connections/passwordless/best-practices) -- [Passwordless Authentication](/connections/passwordless) -- [Authenticate users with using Passwordless Authentication via Email](/connections/passwordless/email) -- [Authenticate users with a one-time code via SMS](/connections/passwordless/sms) -- [Authenticate users with Touch ID](/connections/passwordless/ios-touch-id-swift) -- [Passwordless FAQ](/connections/passwordless/faq) diff --git a/articles/api/authentication/_saml-sso.md b/articles/api/authentication/_saml-sso.md index 7827d283a9..0769a51318 100644 --- a/articles/api/authentication/_saml-sso.md +++ b/articles/api/authentication/_saml-sso.md @@ -1,6 +1,6 @@ # SAML -The SAML protocol is used for 3rd party SaaS applications mostly, like Salesforce and Box. Auth0 supports SP and IDP Initiated Sign On. For more information refer to: [SAML](/protocols/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 @@ -25,30 +25,28 @@ include('../../_includes/_http-method', { "link": "#accept-request" }) %> -Use this endpoint to accept a SAML request to initiate a login. +Use this endpoint to accept a SAML request to initiate a login. -Optionally, it accepts a connection parameter to login with a specific provider. If no connection is specified, the [Auth0 Login Page](/login_page) will be shown. +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 | The `client_id` of your application. | -| `connection` | The connection to use. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> +| `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 the application's `callback_URL`. +- The SAML request `AssertionConsumerServiceURL` will be used to `POST` back the assertion. It must match one of the application's `callback_URLs`. -### More Information +### Learn More - [SAML](/protocols/saml) ## Get Metadata @@ -71,7 +69,7 @@ include('../../_includes/_http-method', { "link": "#get-metadata" }) %> -This endpoint returns the SAML 2.0 metadata. +This endpoint returns the SAML 2.0 metadata. ### Request Parameters @@ -80,16 +78,11 @@ This endpoint returns the SAML 2.0 metadata. | `client_id`
    Required | The `client_id` of your application. | -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - - -### More Information +### Learn More - [SAML](/protocols/saml) -## IdP-Initiated SSO Flow +## IdP-Initiated Single Sign-On (SSO) Flow ```http POST https://${account.namespace}/login/callback?connection=CONNECTION @@ -113,7 +106,7 @@ include('../../_includes/_http-method', { "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 querystring. The user will be redirected to the application that is specified in the SAML Provider IdP-Initiated Sign On section. +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 @@ -123,17 +116,5 @@ This endpoint accepts an IdP-Initiated Sign On SAMLResponse from a SAML Identity | `connection`
    Required | The name of an identity provider configured to your application. | | `SAMLResponse`
    Required | An IdP-Initiated Sign On SAML Response. | - -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the field **Application** (select the application you want to use for the test) and **Connection** (the name of the configured identity provider). - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *Other Flows* tab, click **SAML**. - - -### More Information +### Learn More - [SAML](/protocols/saml) diff --git a/articles/api/authentication/_sign-up.md b/articles/api/authentication/_sign-up.md index c00be0399f..46e637c7bd 100644 --- a/articles/api/authentication/_sign-up.md +++ b/articles/api/authentication/_sign-up.md @@ -1,4 +1,5 @@ # Signup + ```http POST https://${account.namespace}/dbconnections/signup @@ -8,6 +9,12 @@ Content-Type: application/json "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' } } ``` @@ -16,7 +23,7 @@ Content-Type: application/json 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", "user_metadata":{ "plan": "silver", "team_id": "a111" }}' + --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 @@ -33,6 +40,12 @@ curl --request POST \ connection: 'CONNECTION', email: 'EMAIL', password: 'PASSWORD', + 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' } }, function (err) { if (err) return alert('Something went wrong: ' + err.message); @@ -48,7 +61,12 @@ curl --request POST \ "_id": "58457fe6b27...", "email_verified": false, "email": "test.account@signup.com", - "user_metadata":{"plan":"silver","team_id":"a111"} + "username": "johndoe", + "given_name": "John", + "family_name": "Doe", + "name": "John Doe", + "nickname": "johnny", + "picture": "http://example.org/jdoe.png" } ``` @@ -59,7 +77,7 @@ curl --request POST \ "link": "#signup" }) %> -Given a user's credentials, and a `connection`, this endpoint will create a new user using active authentication. +Given a user's credentials and a `connection`, this endpoint creates a new user. This endpoint only works for database connections. @@ -68,24 +86,26 @@ This endpoint only works for database connections. | Parameter | Description | |:-----------------|:------------| -| `client_id`
    Required | The `client_id` of your client. | +| `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. | -| `user_metadata` | The [user metadata](/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. | - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> +| `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). -### More Information +### 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) -- [User Metadata](/metadata) +- [Metadata Overview](/users/concepts/overview-user-metadata) diff --git a/articles/api/authentication/_userinfo.md b/articles/api/authentication/_userinfo.md index f1c01d36ac..f21daa73ff 100644 --- a/articles/api/authentication/_userinfo.md +++ b/articles/api/authentication/_userinfo.md @@ -1,5 +1,4 @@ # User Profile - ## Get User Info ```http @@ -23,15 +22,15 @@ curl --request GET \ domain: '${account.namespace}', clientID: '${account.clientId}' }); - - // Parse the URL and extract the access_token + + // Parse the URL and extract the Access Token webAuth.parseHash(window.location.hash, function(err, authResult) { if (err) { return console.log(err); } webAuth.client.userInfo(authResult.accessToken, function(err, user) { - // This method will make a request to the /userinfo endpoint - // and return the user object, which contains the user's information, + // This method will make a request to the /userinfo endpoint + // and return the user object, which contains the user's information, // similar to the response below. }); }); @@ -42,15 +41,28 @@ curl --request GET \ ```json { - "email_verified": false, - "email": "test.account@userinfo.com", - "updated_at": "2016-12-05T15:15:40.545Z", - "name": "test.account@userinfo.com", - "picture": "https://s.gravatar.com/avatar/dummy.png", - "user_id": "auth0|58454...", - "nickname": "test.account", - "created_at": "2016-12-05T11:16:59.640Z", - "sub": "auth0|58454..." + "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" } ``` @@ -61,36 +73,33 @@ curl --request GET \ "link": "#get-user-info" }) %> -Given the Auth0 [Access Token](/tokens/access-token) obtained during login, this endpoint returns a user's profile. +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`. +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. | - -### Test with Postman +| `access_token`
    Required | The Auth0 Access Token obtained during login. | -<%= include('../../_includes/_test-with-postman') %> ### 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`. For more information about this, check the [Auth0.js v8 Migration Guide](/libraries/auth0js/migration-guide#the-parsehash-method). -- If you want this endpoint to return `user_metadata` or other custom information, you can use [rules](/rules#copy-user-metadata-to-id-token). For more information refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims). +- 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 return a snapshot of the value at the time of login +- 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. -### More Information +### Learn More - [Auth0.js v8 Reference: Extract the authResult and get user info](/libraries/auth0js#extract-the-authresult-and-get-user-info) diff --git a/articles/api/authentication/_wsfed-req.md b/articles/api/authentication/_wsfed-req.md index 3b22830e29..c8e94025b2 100644 --- a/articles/api/authentication/_wsfed-req.md +++ b/articles/api/authentication/_wsfed-req.md @@ -1,5 +1,4 @@ # WS-Federation - ## Accept Request ```http @@ -30,24 +29,7 @@ This endpoint accepts a WS-Federation request to initiate a login. | `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. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - - -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the field **Application** (select the application you want to use for the test) and **Connection** (the name of the configured identity provider). - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *Other Flows* tab, click **WS-Federation**. - +| `wreply` | The callback URL. | ### Remarks @@ -56,23 +38,21 @@ This endpoint accepts a WS-Federation request to initiate a login. - 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). - -### More Information +### Learn More - [WS-Federation](/protocols/ws-fed) - ## Get Metadata ```http -GET https://${account.namespace}/wsfed/${account.clientId}/FederationMetadata/2007-06/FederationMetadata.xml +GET https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml ``` ```shell curl --request GET \ - --url 'https://${account.namespace}/wsfed/${account.clientId}/FederationMetadata/2007-06/FederationMetadata.xml' + --url 'https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml' ``` -<% var getMetadataPath = '/wsfed/YOUR_CLIENT_ID/FederationMetadata/2007-06/FederationMetadata.xml'; %> +<% var getMetadataPath = '/wsfed/FederationMetadata/2007-06/FederationMetadata.xml'; %> <%= include('../../_includes/_http-method', { "http_badge": "badge-primary", @@ -83,12 +63,6 @@ include('../../_includes/_http-method', { This endpoint returns the WS-Federation metadata. - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - - -### More Information +### Learn More - [WS-Federation](/protocols/ws-fed) diff --git a/articles/api/authentication/api-authz/_auth-code-flow.md b/articles/api/authentication/api-authz/_auth-code-flow.md new file mode 100644 index 0000000000..2a3e3d4f27 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_auth-code-pkce.md b/articles/api/authentication/api-authz/_auth-code-pkce.md new file mode 100644 index 0000000000..23edc9a190 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_authz-client.md b/articles/api/authentication/api-authz/_authz-client.md index 6ea3ca39f9..4979eff892 100644 --- a/articles/api/authentication/api-authz/_authz-client.md +++ b/articles/api/authentication/api-authz/_authz-client.md @@ -2,227 +2,24 @@ To begin an OAuth 2.0 Authorization flow, your application should first send the user to the authorization URL. -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. +## 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 Grant](/api-auth/grant/authorization-code) -- [Authorization Code Grant using Proof Key for Code Exchange (PKCE)](/api-auth/grant/authorization-code-pkce) -- [Implicit Grant](/api-auth/grant/implicit) +- [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) -On the other hand, the [Resource Owner Password Grant](/api-auth/grant/password) and [Client Credentials](/api-auth/grant/client-credentials) flows do not use this endpoint since there is no user authorization involved. Instead they invoke directly the `POST /oauth/token` endpoint to retrieve an Access Token. +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). +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). -## Authorization Code Grant +## 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). -```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 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](/api-auth/tutorials/adoption/scope-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 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. | -| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (see Remarks for more info). | - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Client** field to the application you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the fields **Audience** (to the unique identifier of the API you want to access), **Response Type** (set to `code`) and enable the **Audience** switch. - -1. Click **OAuth / OIDC Login**. Following the redirect, the URL will contain the authorization code. Note, that the code will be set at the **Authorization Code** field so you can proceed with exchanging it for an Access 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 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`. -- Include `offline_access` to the `scope` request parameter to get a Refresh Token from [POST /oauth/token](#authorization-code). 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/${account.clientId}/settings). -- 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 SSO session has not expired. - -### More Information - -- [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code) -- [Executing an Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant) -- [Using the State Parameter](/protocols/oauth2/oauth-state) -- [Silent Authentication](/api-auth/tutorials/silent-authentication) - - -## Authorization Code Grant (PKCE) - -```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 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, 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 clients adds to the initial request that Auth0 includes when redirecting the 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`. | -| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (see Remarks for more info). | - - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Application** field to the app you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the fields **Audience** (to the unique identifier of the API you want to access), **Response Type** (set to `code`) and enable the **Audience** and **PKCE** switches. - -1. Click **OAuth / OIDC Login**. Following the redirect, the URL will contain the authorization code. Note, that the code will be set at the **Authorization Code** field, and the **Code Verifier** will be automatically set as well, so you can proceed with exchanging the code for an Access 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 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`. -- 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 [Client's Settings](${manage_url}/#/applications/${account.clientId}/settings). -- 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 SSO session has not expired. - - -### More Information - -- [Calling APIs from Mobile Apps](/api-auth/grant/authorization-code-pkce) -- [Executing an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) -- [Silent Authentication](/api-auth/tutorials/silent-authentication) - - -## Implicit Grant - -```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 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, 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 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. | -| `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 to your application. | -| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (see Remarks for more info). | - - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Application** field to the app you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the fields **Audience** (to the unique identifier of the API you want to access), **Response Type** (set to `token`) and enable the **Audience** switch. - -1. Click **OAuth / OIDC Login**. - - -### Remarks - -- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). -- 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. You can 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 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`. -- 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 SSO session has not expired. - -### More Information - -- [Calling APIs from Client-side Web Apps](/api-auth/grant/implicit) -- [Executing the Implicit Grant Flow](/api-auth/tutorials/implicit-grant) -- [Using the 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) +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/articles/api/authentication/api-authz/_client-credential.md b/articles/api/authentication/api-authz/_client-credential.md new file mode 100644 index 0000000000..3f532cd8bb --- /dev/null +++ b/articles/api/authentication/api-authz/_client-credential.md @@ -0,0 +1,74 @@ +# 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. | +| `organization`
    Optional| The organization or identifier with which you want the request to be associated. To learn more, read [Machine-to-Machine Access for Organizations](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications)| + +### 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/articles/api/authentication/api-authz/_device-code.md b/articles/api/authentication/api-authz/_device-code.md new file mode 100644 index 0000000000..11a26b9470 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_get-token.md b/articles/api/authentication/api-authz/_get-token.md deleted file mode 100644 index 874f3bdd6d..0000000000 --- a/articles/api/authentication/api-authz/_get-token.md +++ /dev/null @@ -1,495 +0,0 @@ -# Get Token - -Use this endpoint to: -- Get an `access_token` in order to call an API. You can, optionally, retrieve an `id_token` and a `refresh_token` as well. -- Refresh your Access Token, using a Refresh Token you got during authorization. - -Note that the only OAuth 2.0 flows that can retrieve a Refresh Token are: -- [Authorization Code](/api-auth/grant/authorization-code) -- [Authorization Code with PKCE](/api-auth/grant/authorization-code-pkce) -- [Resource Owner Password](/api-auth/grant/password) - -## Authorization Code - -```http -POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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/json' \ - --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/json' }, - body: - { grant_type: 'authorization_code', - client_id: '${account.clientId}', - client_secret: 'YOUR_CLIENT_SECRET', - code: 'AUTHORIZATION_CODE', - redirect_uri: '${account.callback}' }, - 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 -{ - "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 OAuth 2.0 grant that regular web apps utilize in order 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 must match. | - - -### Test with Postman - -<%= include('../../../_includes/_test-with-postman') %> - - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -If you have just executed the [Authorization Code Grant](#authorization-code-grant) you should already have a code set at the **Authorization Code** field of the *OAuth2 / OIDC* tab. If so, click **OAuth2 Code Exchange**, otherwise follow the instructions. - -1. At the *Configuration* tab, set the **Application** field to the application you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](#authorization-code-grant). Click **OAuth2 Code Exchange**. - - -### More Information - -- [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code) -- [Executing an Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant) - - -## Authorization Code (PKCE) - -```http -POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "grant_type": "authorization_code", - "client_id": "${account.clientId}", - "code_verifier": "CODE_VERIFIER", - "code": "AUTHORIZATION_CODE", - "redirect_uri": "com.myclientapp://myclientapp.com/callback" -} -``` - -```shell -curl --request POST \ - --url 'https://${account.namespace}/oauth/token' \ - --header 'content-type: application/json' \ - --data '{"grant_type":"authorization_code","client_id": "${account.clientId}","code_verifier": "CODE_VERIFIER","code": "AUTHORIZATION_CODE","redirect_uri": "com.myclientapp://myclientapp.com/callback"}' -``` - -```javascript -var request = require("request"); - -var options = { method: 'POST', - url: 'https://${account.namespace}/oauth/token', - headers: { 'content-type': 'application/json' }, - body: '{"grant_type":"authorization_code","client_id": "${account.clientId}","code_verifier": "CODE_VERIFIER","code": "AUTHORIZATION_CODE","redirect_uri": "com.myclientapp://myclientapp.com/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 OAuth 2.0 grant that mobile apps utilize in order 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 must match. | - - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -If you have just executed the [Authorization Code Grant (PKCE)](#authorization-code-grant-pkce-) you should already have the **Authorization Code** and **Code Verifier** fields, of the *OAuth2 / OIDC* tab, set. If so, click **OAuth2 Code Exchange**, otherwise follow the instructions. - -1. At the *Configuration* tab, set the **Client** field to the application you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](#authorization-code-grant-pkce-), and the **Code Verifier** to the key. Click **OAuth2 Code Exchange**. - - -### More Information - -- [Calling APIs from Mobile Apps](/api-auth/grant/authorization-code-pkce) -- [Executing an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) - - -## Client Credentials - -```http -POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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/json' \ - --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/json' }, - body: - { client_id: '${account.clientId}', - client_secret: 'YOUR_CLIENT_SECRET', - audience: 'API_IDENTIFIER', - grant_type: 'client_credentials' }, - 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 -{ - "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 utilize in order to access an API. Use this endpoint to directly request an `access_token` by using the Client 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. | - - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Client** field to the application you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, click **OAuth2 Client Credentials**. - - -### More Information - -- [Calling APIs from a Service](/api-auth/grant/client-credentials) -- [Setting up a Client Credentials 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) - - -## Resource Owner Password - -```http -POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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/json' \ - --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/json' }, - body: - { grant_type: 'password', - username: 'USERNAME', - password: 'PASSWORD', - audience: 'API_IDENTIFIER', - scope: 'SCOPE', - 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: - -```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 apps we recommend using the [Authorization Code Grant](#authorization-code-grant) instead. -::: - -This is the OAuth 2.0 grant that highly trusted apps use in order 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 [client side](/api-auth/grant/implicit) applications and [mobile apps](/api-auth/grant/authorization-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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | -| `audience` | The unique identifier of the target API you want to access. | -| `username`
    Required | Resource Owner's identifier. | -| `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). | - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Client** field to the application you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the **Username** and **Password**, and click **Password Grant**. - - -### 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). - -### More Information -- [Calling APIs from Highly Trusted Applications](/api-auth/grant/password) -- [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant) -- [Multifactor Authentication and Resource Owner Password](/api-auth/tutorials/multifactor-resource-owner-password) - -## Refresh Token - -```http -POST https://${account.namespace}/oauth/token -Content-Type: application/json -{ - "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/json' \ - --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/json' }, - body: - { grant_type: 'refresh_token', - client_id: '${account.clientId}', - client_secret: 'YOUR_CLIENT_SECRET', - refresh_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 -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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. | -| `refresh_token`
    Required | The Refresh Token to use. | - - -### Test this endpoint - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Client** field to the client you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the field **Refresh Token** to the Refresh Token you have. Click **OAuth2 Refresh Token Exchange**. - - -### More Information - -- [Refresh Token](/tokens/refresh-token) diff --git a/articles/api/authentication/api-authz/_highly-regulated.md b/articles/api/authentication/api-authz/_highly-regulated.md new file mode 100644 index 0000000000..0181295d99 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_implicit.md b/articles/api/authentication/api-authz/_implicit.md new file mode 100644 index 0000000000..a6bf10fdb7 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_refresh-token.md b/articles/api/authentication/api-authz/_refresh-token.md new file mode 100644 index 0000000000..ebd8bbdba7 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_resource-owner.md b/articles/api/authentication/api-authz/_resource-owner.md new file mode 100644 index 0000000000..c8ce53f4ab --- /dev/null +++ b/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/articles/api/authentication/api-authz/_revoke-refersh-token.md b/articles/api/authentication/api-authz/_revoke-refersh-token.md deleted file mode 100644 index 7cc710f5f7..0000000000 --- a/articles/api/authentication/api-authz/_revoke-refersh-token.md +++ /dev/null @@ -1,75 +0,0 @@ -# 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. - -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**. - -### Request Parameters - -| 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/application-types#confidential-applications). | -| `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/${account.clientId}/settings)) 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). - -### More Information - -- [Refresh Token](/tokens/refresh-token) diff --git a/articles/api/authentication/api-authz/_revoke-refresh-token.md b/articles/api/authentication/api-authz/_revoke-refresh-token.md new file mode 100644 index 0000000000..5f44c585e2 --- /dev/null +++ b/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/articles/api/authentication/api-authz/_token-exchange-native-social.md b/articles/api/authentication/api-authz/_token-exchange-native-social.md new file mode 100644 index 0000000000..e234380215 --- /dev/null +++ b/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/articles/api/authentication/errors/_errors.md b/articles/api/authentication/errors/_errors.md index 83eba927d5..3b9163d8ae 100644 --- a/articles/api/authentication/errors/_errors.md +++ b/articles/api/authentication/errors/_errors.md @@ -1,46 +1,21 @@ # Standard Error Responses The Authentication API may return the following HTTP Status Codes: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    StatusDescription
    400Bad Request
    401Unauthorized
    403Forbidden
    404Not Found
    405Method Not Allowed
    429Too Many Requests
    500Internal Server Error
    503Service Unavailable
    +| 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/articles/api/authentication/errors/_oauth-access_token.md b/articles/api/authentication/errors/_oauth-access_token.md index 6572e237b4..44b0f7541e 100644 --- a/articles/api/authentication/errors/_oauth-access_token.md +++ b/articles/api/authentication/errors/_oauth-access_token.md @@ -1,36 +1,10 @@ # POST /oauth/access_token - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    StatusResponse
    400{"error": "invalid_request", "error_description": "the connection was disabled"}
    The connection is not active or not enabled for your client_id
    400{"error": "invalid_request", "error_description": "the connection was not found"}
    400{"error": "invalid_request", "error_description": "missing client_id parameter"}
    400{"error": "invalid_request", "error_description": "missing access_token parameter"}
    401{"error": "invalid_request", "error_description": "invalid access_token: invalid_token"}
    The access_token is invalid or does not contain the scope you set
    403{"error": "unauthorized_client", "error_description": "invalid client"}
    +| 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/articles/api/authentication/errors/_oauth-revoke.md b/articles/api/authentication/errors/_oauth-revoke.md index 4f5ce06019..cbca1e2779 100644 --- a/articles/api/authentication/errors/_oauth-revoke.md +++ b/articles/api/authentication/errors/_oauth-revoke.md @@ -1,24 +1,7 @@ # POST /oauth/revoke - - - - - - - - - - - - - - - - - - - - - -
    StatusDescription
    200{"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{"error": "invalid_request", "error_description": "..."}
    The required parameters were not sent in the request.
    401<{"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.
    +| 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/articles/api/authentication/errors/_oauth-ro.md b/articles/api/authentication/errors/_oauth-ro.md index 2dbfd6f52f..e552af873a 100644 --- a/articles/api/authentication/errors/_oauth-ro.md +++ b/articles/api/authentication/errors/_oauth-ro.md @@ -2,123 +2,33 @@ ## Grant type: jwt-bearer - - - - - - - - - - - - - - - - - - - - - -
    StatusDescription
    400{"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{"error": "invalid_request", "error_description": "missing id_token parameter"}
    For this grant type you need to provide a JWT ID Token
    400{"error": "invalid_grant", "error_description": "..."}
    Errors related to an invalid id_token or user
    +| 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    StatusDescription
    400{"error": "invalid_request", "error_description": "missing username parameter"}
    400{"error": "invalid_request", "error_description": "missing password parameter"}
    400{"error": "invalid_request", "error_description": "missing connection parameter"}
    400{"error": "invalid_request", "error_description": "scope parameter must be a string"}
    Incorrect scope formatting; each scope must be separated by whitespace
    400{"error": "invalid_request", "error_description": "specified strategy does not support requested operation"}
    The connection/provider does not implement username/password authentication
    401{"error": "invalid_user_password", "error_description": "Wrong email or password."}
    401{"error": "unauthorized", "error_description": "user is blocked"}
    401{ "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."}
    429{"error": "too_many_attempts", "error_description": "..."}
    Some anomaly detections will return this error
    429{"error": "too_many_logins", "error_description": "..."}
    Some anomaly detections will return this error
    +| 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    StatusDescription
    400{"error": "invalid_request", "error_description": "missing client_id parameter"}
    400{"error": "invalid_request", "error_description": "the connection was not found"}
    400{"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{"error": "invalid_request", "error_description": "The connection is not yet configured..."}
    The connection is not properly configured with custom scripts
    400{"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{"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{"error": "unauthorized_client", "error_description": "invalid client"}
    The provided client_id is not valid
    403{"error": "access_denied", "error_description": "..."}
    Validation of specific points raised an access issue
    +| 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/articles/api/authentication/errors/_passwordless-start.md b/articles/api/authentication/errors/_passwordless-start.md index 15814aa9ac..348b707a16 100644 --- a/articles/api/authentication/errors/_passwordless-start.md +++ b/articles/api/authentication/errors/_passwordless-start.md @@ -1,56 +1,25 @@ + # POST /passwordless/start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    StatusResponse
    400{"error": "bad.tenant","error_description": "error in tenant - tenant validation failed: invalid_tenant"}
    400{"error": "bad.client_id", "error_description": "Missing required property: client_id"}
    400{"error": "bad.connection", "error_description": "Missing required property: connection"}
    400{"error": "bad.connection", "error_description": "Connection does not exist"}
    400{"error": "bad.connection", "error_description": "Connection is disabled"}
    400{"error": "bad.connection", "error_description": "Invalid connection strategy. It must either be a passwordless connection"}
    400{"error": "bad.authParams", "error_description": "error in authParams - invalid type: string (expected object)"}
    400{"error": "bad.request", "error_description": "the following properties are not allowed: "}
    400{"error": "bad.phone_number", "error_description": "Missing required property: phone_number"}
    400{"error": "bad.phone_number", "error_description": "String does not match pattern: ^\\+[0-9]{1,15}$"}
    400{"error": "sms_provider_error", "error_description": " (Code: )"}
    +| 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/articles/api/authentication/errors/_passwordless-verify.md b/articles/api/authentication/errors/_passwordless-verify.md new file mode 100644 index 0000000000..1ea71461b4 --- /dev/null +++ b/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/articles/api/authentication/index.md b/articles/api/authentication/index.md index 32a55606b3..3edd4a539a 100644 --- a/articles/api/authentication/index.md +++ b/articles/api/authentication/index.md @@ -1,6 +1,9 @@ --- title: Authentication API Explorer fullWidth: true +contentType: + - index + - reference ---
    @@ -43,10 +46,6 @@ fullWidth: true <%= include('./_wsfed-req') %>
    -
    - <%= include('./_impersonation') %> -
    -
    <%= include('./_application-reg') %>
    @@ -56,10 +55,34 @@ fullWidth: true <%= include('./api-authz/_authz-client') %>
    - <%= include('./api-authz/_get-token') %> + <%= 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/_revoke-refersh-token') %> + <%= include('./api-authz/_device-code') %> +
    +
    + <%= include('./api-authz/_refresh-token') %> +
    +
    +<%= include('./api-authz/_revoke-refresh-token') %> +
    +
    +<%= include('./api-authz/_token-exchange-native-social') %>
    Legacy @@ -69,12 +92,15 @@ fullWidth: true
    <%= include('./legacy/_userinfo') %>
    -
    +
    <%= include('./legacy/_linking') %>
    <%= include('./legacy/_delegation') %>
    +
    + <%= include('./legacy/_impersonation') %> +
    <%= include('./legacy/_resource-owner') %>
    @@ -90,8 +116,13 @@ fullWidth: true <%= include('./errors/_oauth-access_token') %>
    - <%= include('./errors/_oauth-ro') %> +<%= include('./errors/_oauth-ro') %>
    <%= include('./errors/_passwordless-start') %>
    +
    + <%= include('./errors/_passwordless-verify') %> +
    + + diff --git a/articles/api/authentication/legacy/_delegation.md b/articles/api/authentication/legacy/_delegation.md index bc32d1689a..a173755d24 100644 --- a/articles/api/authentication/legacy/_delegation.md +++ b/articles/api/authentication/legacy/_delegation.md @@ -1,5 +1,3 @@ - - # Delegation ```http @@ -35,7 +33,7 @@ curl --request POST \ }) %> ::: warning -This feature is disabled by default for new tenants as of 8 June 2017. See the [migration notice](/migrations#api-authorization-with-third-party-vendor-apis) for more information. +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. @@ -49,25 +47,10 @@ Given an existing token, this endpoint will generate a new token signed with the | `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` | +| `target` | The target `client_id` | +| `scope` | Use `openid` or `openid profile email` | | `api_type` | The API to be called. | -### Test with Postman - -<%= include('../../../_includes/_test-with-postman') %> - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Application** field to the app you want to use for the test. - -1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the fields **ID Token**, **Refresh Token** and **Target Client ID**. Click **Delegation**. - - ### 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`. @@ -84,8 +67,7 @@ Given an existing token, this endpoint will generate a new token signed with the - `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). -### More Information +### Learn More - [Delegation Tokens](/tokens/delegation) - -- [Auth0 API Rate Limit Policy](/policies/rate-limits) +- [Auth0 API Rate Limit Policy](/policies/rate-limits) \ No newline at end of file diff --git a/articles/api/authentication/legacy/_impersonation.md b/articles/api/authentication/legacy/_impersonation.md new file mode 100644 index 0000000000..6fd286a04f --- /dev/null +++ b/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/articles/api/authentication/legacy/_linking.md b/articles/api/authentication/legacy/_linking.md index 6e42378c78..0e4b6657ce 100644 --- a/articles/api/authentication/legacy/_linking.md +++ b/articles/api/authentication/legacy/_linking.md @@ -1,7 +1,10 @@ # 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& @@ -18,13 +21,9 @@ GET https://${account.namespace}/authorize? "link": "#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). -::: - 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. +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 @@ -40,14 +39,14 @@ This endpoint will trigger the login flow to link an existing account with a new ### Remarks -- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). +- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications). -### More Information +### Learn More -- [Linking Accounts](/link-accounts) -- [User Initiated Account Linking](/link-accounts/user-initiated-linking) -- [Account Linking from Server Side Code](/link-accounts/suggested-linking) +- [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 @@ -56,7 +55,7 @@ This endpoint will trigger the login flow to link an existing account with a new POST https://${account.namespace}/login/unlink Content-Type: application/json { - "access_token": "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity access_token + "access_token": "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity Access Token "user_id": "LINKED_USER_ID" // (provider|id) } ``` @@ -95,7 +94,7 @@ xhr.send(params); }) %> ::: warning -This endpoint is **deprecated**. The [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_provider_by_user_id) should be used instead. +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. @@ -105,15 +104,10 @@ Given a logged-in user's `access_token` and `user_id`, this endpoint will unlink | Parameter | Description | |:-----------------|:------------| -| `access_token`
    Required | The logged-in user's `Access Token` | +| `access_token`
    Required | The logged-in user's Access Token | | `user_id`
    Required | The logged-in user's `user_id` | -### Test with Postman - -<%= include('../../../_includes/_test-with-postman') %> - - -### More Information +### Learn More -- [Unlinking Accounts](/link-accounts#unlinking-accounts) +- [Unlink User Accounts](/users/guides/unlink-user-accounts) diff --git a/articles/api/authentication/legacy/_login.md b/articles/api/authentication/legacy/_login.md index b01992c62f..4c197080e9 100644 --- a/articles/api/authentication/legacy/_login.md +++ b/articles/api/authentication/legacy/_login.md @@ -1,7 +1,5 @@ - # Login - ## Social with Provider's Access Token ```http @@ -62,24 +60,21 @@ xhr.send(params); ::: 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/application-grant-types) for more information. +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. +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`. | +| `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. | +| `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. | -### Test with Postman - -<%= include('../../../_includes/_test-with-postman') %> ### Remarks @@ -91,13 +86,11 @@ Given the social provider's `access_token` and the `connection`, this endpoint w For the complete error code reference for this endpoint refer to [Errors > POST /oauth/access_token](#post-oauth-access_token). -### More Information +### Learn More - [Call an Identity Provider API](/tutorials/calling-an-external-idp-api) - -- [Identity Provider Access Tokens](/tokens/idp) - -- [Add scopes/permissions to call Identity Provider's APIs](/tutorials/adding-scopes-for-an-external-idp) +- [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) @@ -169,7 +162,7 @@ curl --request POST \ 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`. +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 @@ -179,29 +172,14 @@ Use this endpoint for API-based (active) authentication. Given the user credenti | `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` (used to [Authenticate users with Touch ID](/connections/passwordless/ios-touch-id-swift)) | +| `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` | -### Test with Postman - -<%= include('../../../_includes/_test-with-postman') %> - -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At 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/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set **Username** and **Password**. Click **Resource Owner Endpoint**. - - ### Remarks -- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS. +- 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). @@ -210,14 +188,10 @@ Use this endpoint for API-based (active) authentication. Given the user credenti ### Error Codes -For the complete error code reference for this endpoint refer to [Errors > POST /oauth/ro](#post-oauth-ro). +For the complete error code reference for this endpoint, refer to [Errors > POST /oauth/ro](#post-oauth-ro). -### More Information +### Learn More - [Database Identity Providers](/connections/database) - -- [Rate Limits on User/Password Authentication](/connections/database/rate-limits) - -- [Active Directory/LDAP Connector](/connector) - -- [Authenticate users with Touch ID](/connections/passwordless/ios-touch-id-swift) +- [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/articles/api/authentication/legacy/_resource-owner.md b/articles/api/authentication/legacy/_resource-owner.md index bd3cb61a42..d191536587 100644 --- a/articles/api/authentication/legacy/_resource-owner.md +++ b/articles/api/authentication/legacy/_resource-owner.md @@ -65,10 +65,10 @@ request(options, function (error, response, body) { }) %> ::: 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). +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`. +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 @@ -79,23 +79,13 @@ Given the user's credentials, this endpoint will authenticate the user with the | `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`. | +| `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`). | -### Test with Authentication API Debugger - -<%= include('../../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the **Application** field to the application you want to use for the test, and **Connection** to the name of the 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/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the **Username** and **Password**, and click **Resource Owner Endpoint**. - ### Remarks -- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS. +- 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`. @@ -105,6 +95,6 @@ Given the user's credentials, this endpoint will authenticate the user with the For the complete error code reference for this endpoint refer to [Errors > POST /oauth/ro](#post-oauth-ro). -### More Information +### Learn More - [Calling APIs from Highly Trusted Applications](/api-auth/grant/password) diff --git a/articles/api/authentication/legacy/_userinfo.md b/articles/api/authentication/legacy/_userinfo.md index 25e29fce75..d35e12a99e 100644 --- a/articles/api/authentication/legacy/_userinfo.md +++ b/articles/api/authentication/legacy/_userinfo.md @@ -1,5 +1,6 @@ -# User Profile + +# User Profile ## Get Token Info ```http @@ -73,17 +74,14 @@ webAuth.parseHash(window.location.hash, function(err, authResult) { 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 (signature and expiration) and returns the user information associated with the user id `sub` property of the token. +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. | - -### Test with Postman +| `id_token`
    Required | The ID Token to use. | -<%= include('../../../_includes/_test-with-postman') %> ### Remarks @@ -92,8 +90,8 @@ This endpoint validates a JSON Web Token (signature and expiration) and returns - `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). -### More Information +### Learn More -- [User Profile: In-Depth Details - API](/user-profile/user-profile-details#api) +- [User Profile Struture](/users/references/user-profile-structure) - [Auth0 API Rate Limit Policy](/policies/rate-limits) diff --git a/articles/api/authorization-extension/_groups.md b/articles/api/authorization-extension/_groups.md index 39262240d9..17bc41355c 100644 --- a/articles/api/authorization-extension/_groups.md +++ b/articles/api/authorization-extension/_groups.md @@ -69,7 +69,7 @@ Use this endpoint to retrieve all groups. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -107,11 +107,11 @@ include('../../_includes/_http-method', { "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. +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: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -161,7 +161,7 @@ Use this endpoint to create a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: create:groups @@ -209,7 +209,7 @@ Use this endpoint to delete a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: delete:groups @@ -264,7 +264,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -309,7 +309,7 @@ Use this endpoint to retrieve the mappings of a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -326,7 +326,7 @@ The [Access Token](#get-an-access-token) should have the following scopes:
    Examples
    ```http -PUT https://{extension_url}/groups/{group_id}/mappings +PATCH https://{extension_url}/groups/{group_id}/mappings Content-Type: 'application/json' Authorization: 'Bearer {access_token}' { @@ -336,10 +336,11 @@ Authorization: 'Bearer {access_token}' ``` ```shell -curl --request PUT \ - --url 'https://{extension_url}/groups/{group_id}/mappings' \ +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"}' + --data '[{"groupName": "Test", "connectionName": "google-oauth2"}]' ``` > RESPONSE SAMPLE: @@ -349,17 +350,17 @@ curl --request PUT \ ```
    - PUT + 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#group-mappings). +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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -414,7 +415,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -423,7 +424,7 @@ The [Access Token](#get-an-access-token) should have the following scopes: | 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 [Client Credentials implementation guide](/api-auth/tutorials/client-credentials) | +| `{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 @@ -488,7 +489,7 @@ Use this endpoint to get the members for a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -499,6 +500,9 @@ The [Access Token](#get-an-access-token) should have the following scopes: | `{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 @@ -537,7 +541,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -587,7 +591,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -643,7 +647,7 @@ Use this endpoint to get the nested members for a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -654,6 +658,8 @@ The [Access Token](#get-an-access-token) should have the following scopes: | `{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 @@ -691,7 +697,7 @@ Use this endpoint to get the nested groups for a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -741,7 +747,7 @@ Use this endpoint to add nested groups. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -791,7 +797,7 @@ Use this endpoint to remove one or more nested groups. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -842,7 +848,7 @@ Use this endpoint to get the roles for a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -891,7 +897,7 @@ Use this endpoint to add roles to a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -941,7 +947,7 @@ Use this endpoint to remove one or more groups roles. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -1019,7 +1025,7 @@ Use this endpoint to get the nested roles for a group. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups diff --git a/articles/api/authorization-extension/_introduction.md b/articles/api/authorization-extension/_introduction.md index 91da48ec9a..973481dac2 100644 --- a/articles/api/authorization-extension/_introduction.md +++ b/articles/api/authorization-extension/_introduction.md @@ -2,12 +2,12 @@ The Authorization Extension API enables you to: -- automate provisioning for your users, roles, groups, and permissions +- 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. +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 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: @@ -15,9 +15,11 @@ For each endpoint in this explorer, you will find sample snippets you can use, i - 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: +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'; @@ -35,15 +37,15 @@ All endpoints in this explorer, start with `https://{extension_url}`. This is th 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](/tokens/access-token). +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 setup your application (you will have to do this only once): +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#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). +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). -In order to get an `access_token` you need to `POST` to the `/oauth/token` endpoint. You can find detailed instructions [here](/api-auth/tutorials/client-credentials#ask-for-a-token). +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. \ No newline at end of file +Use this Access Token to access the Authorization Extension API. diff --git a/articles/api/authorization-extension/_permissions.md b/articles/api/authorization-extension/_permissions.md index d09449bd42..8c1c151fcf 100644 --- a/articles/api/authorization-extension/_permissions.md +++ b/articles/api/authorization-extension/_permissions.md @@ -1,6 +1,6 @@ # 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)): +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). @@ -41,7 +41,7 @@ Use this endpoint to retrieve all permissions. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:permissions @@ -83,7 +83,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: read:permissions @@ -134,7 +134,7 @@ Use this endpoint to create a permission. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: create:permissions @@ -193,7 +193,7 @@ Use this endpoint to update the details of a permission. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:permissions @@ -243,7 +243,7 @@ Use this endpoint to remove a permission. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: delete:permissions diff --git a/articles/api/authorization-extension/_roles.md b/articles/api/authorization-extension/_roles.md index 172a23447d..45ca6b2d8c 100644 --- a/articles/api/authorization-extension/_roles.md +++ b/articles/api/authorization-extension/_roles.md @@ -1,6 +1,6 @@ # 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. +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). @@ -54,7 +54,7 @@ Use this endpoint to retrieve all roles. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:roles @@ -96,7 +96,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: read:roles @@ -150,7 +150,7 @@ Use this endpoint to create a role. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: create:roles @@ -217,7 +217,7 @@ Use this endpoint to update the details of a role. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:roles @@ -268,7 +268,7 @@ Use this endpoint to remove a role. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: delete:roles diff --git a/articles/api/authorization-extension/_users.md b/articles/api/authorization-extension/_users.md index 7916708817..a2337dd9f2 100644 --- a/articles/api/authorization-extension/_users.md +++ b/articles/api/authorization-extension/_users.md @@ -1,6 +1,6 @@ # 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. +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). @@ -32,7 +32,7 @@ GET https://{extension_url}/users ], "user_id":"auth0|59091da1b3c34a15589c780d", "last_login":"2017-06-25T07:28:54.719Z", - "name":"dummy.user@example.com", + "name":"placeholder.user@example.com", "picture":"https://s.gravatar.com/avatar/your-gravatar.png", "email":"richard.dowinton@auth0.com" } @@ -53,7 +53,7 @@ Use this endpoint to retrieve all users. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:users @@ -63,6 +63,8 @@ The [Access Token](#get-an-access-token) should have the following scopes: |:-----------------|:------------| | `{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 @@ -76,11 +78,11 @@ GET https://{extension_url}/users/{user_id} ```text { - "email":"dummy.user@example.com", + "email":"placeholder.user@example.com", "email_verified":true, "user_id":"auth0|59091da1b3c34a15589c780d", "picture":"https://s.gravatar.com/avatar/your-gravatar.png", - "nickname":"dummy.user", + "nickname":"placeholder.user", "identities":[ { "user_id":"59091da1b3c34a15589c780d", @@ -91,7 +93,7 @@ GET https://{extension_url}/users/{user_id} ], "updated_at":"2017-06-25T07:28:54.719Z", "created_at":"2017-06-08T15:30:41.237Z", - "name":"dummy.user@example.com", + "name":"placeholder.user@example.com", "app_metadata":{ "authorization":{ "roles":[ @@ -121,7 +123,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: read:users @@ -171,7 +173,7 @@ Use this endpoint to get the groups of a single user, based on its unique identi ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:users @@ -217,11 +219,11 @@ include('../../_includes/_http-method', { "link": "#add-user-to-groups" }) %> -Use this endpoint to add one or more users in a group. +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: +The [Access Token](#get-an-access-token) should have the following scopes: update:groups @@ -272,7 +274,7 @@ Use this endpoint to calculate the group memberships for a user (including neste ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:groups @@ -324,7 +326,7 @@ Use this endpoint to get the roles of a single user, based on its unique identif ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:users @@ -374,7 +376,7 @@ Use this endpoint to assign a role to a user. ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: update:users @@ -412,7 +414,7 @@ curl --request DELETE \ (empty response body) ``` -<% var path = '/users/{role_id}/roles'; %> +<% var path = '/users/{user_id}/roles'; %> <%= include('../../_includes/_http-method', { "http_badge": "badge-danger", @@ -425,7 +427,7 @@ 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: +The [Access Token](#get-an-access-token) should have the following scopes: update:roles @@ -436,7 +438,7 @@ The [Access Token](#get-an-access-token) should have the following scopes: | `{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 | -| `{role_id}`
    Required | The id of the role(s) you want to remove users from | +| `body`
    Required | The id of the role(s) you want to remove users from (i.e. `[ "{role_id}" ]`) | ## Calculate Roles @@ -478,7 +480,7 @@ Use this endpoint to calculate the roles assigned to the user (including through ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:roles @@ -537,7 +539,7 @@ Use this endpoint to execute the authorization policy for a user in the context ### Scopes -The [Access Token](#get-an-access-token) should have the following scopes: +The [Access Token](#get-an-access-token) should have the following scopes: read:users @@ -546,8 +548,8 @@ The [Access Token](#get-an-access-token) should have the following scopes: | 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) | +| `{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` | The connection name the user logged in with | +| `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/articles/api/authorization-extension/index.md b/articles/api/authorization-extension/index.md index f538ea6210..cc27f2407b 100644 --- a/articles/api/authorization-extension/index.md +++ b/articles/api/authorization-extension/index.md @@ -1,6 +1,14 @@ --- title: Authorization Extension API Explorer fullWidth: true +topics: + - authorization + - apis + - api-authorization +contentType: + - reference + - index +useCase: invoke-api ---
    diff --git a/articles/api/info.md b/articles/api/info.md index 7e2b196133..44920523b6 100644 --- a/articles/api/info.md +++ b/articles/api/info.md @@ -1,24 +1,31 @@ --- -description: This page explains the basics of Auth0's Management and Authentication APIs. +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 two APIs for developers to consume in their applications: +Auth0 exposes the following APIs for developers to consume in their applications. + +## Authentication API -* **Authentication**: Handles identity-related tasks; -* **Management**: Handles management of your Auth0 account, including functions related to (but not limited to): +The Authentication API exposes identity functionality for Auth0 and supported identity protocols (including OpenID Connect, OAuth, and SAML). - * Applications; - * Connections; - * Emails; - * Users. +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. -## Authentication API +Some example tasks include: -The Authentication API exposes Auth0 identity functionality, as well as those of supported identity protocols (such as OpenID Connect, OAuth, and SAML). Typically, you would consume this API through one of the Auth0 SDKs, such as [Auth0.js](/libraries/auth0js), or a library, like [Lock](/libraries/lock). If you are building your authentication UI manually, you would need to interface directly with the Authentication API. +* 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)
    @@ -28,7 +35,7 @@ The Authentication API exposes Auth0 identity functionality, as well as those of

    API Explorer

    -

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

    +

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

    Open API Explorer

    @@ -37,7 +44,7 @@ The Authentication API exposes Auth0 identity functionality, as well as those of

    Postman

    Try the Auth0 Authentication API in Postman.

    -

    Run in Postman

    +

    Run in Postman

    How to use our Postman Collections

    @@ -46,9 +53,16 @@ The Authentication API exposes Auth0 identity functionality, as well as those of
    -## Management API v2 +## Management API -The Management API allows you to manage every aspect of your Auth0 account. For example, you can use the Management API to automate the configuration of your user environments or for runtime tasks such as user creation. +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)
    @@ -67,7 +81,7 @@ The Management API allows you to manage every aspect of your Auth0 account. For

    Postman

    Try the Auth0 Management API in Postman.

    -

    Run in Postman

    +

    Run in Postman

    How to use our Postman Collections

    @@ -76,6 +90,10 @@ The Management API allows you to manage every aspect of your Auth0 account. For -### Management API v1 - DEPRECATED +### 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. -The Management API v1 is deprecated and **should not** be used for new projects. If your existing application uses Management API v1, you can reference its API explorer [here](/api/v1). +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/articles/api/management/guides/apis/enable-rbac.md b/articles/api/management/guides/apis/enable-rbac.md new file mode 100644 index 0000000000..3c9258dbe9 --- /dev/null +++ b/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/articles/api/management/guides/apis/update-permissions-apis.md b/articles/api/management/guides/apis/update-permissions-apis.md new file mode 100644 index 0000000000..7d39e4ca0c --- /dev/null +++ b/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/articles/api/management/guides/applications/remove-app.md b/articles/api/management/guides/applications/remove-app.md new file mode 100644 index 0000000000..9e10014666 --- /dev/null +++ b/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/articles/api/management/guides/applications/rotate-client-secret.md b/articles/api/management/guides/applications/rotate-client-secret.md new file mode 100644 index 0000000000..464308df41 --- /dev/null +++ b/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/articles/api/management/guides/applications/update-grant-types.md b/articles/api/management/guides/applications/update-grant-types.md new file mode 100644 index 0000000000..febf502d5a --- /dev/null +++ b/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/articles/api/management/guides/applications/update-ownership.md b/articles/api/management/guides/applications/update-ownership.md new file mode 100644 index 0000000000..bbe9d019bf --- /dev/null +++ b/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/articles/api/management/guides/applications/view-ownership.md b/articles/api/management/guides/applications/view-ownership.md new file mode 100644 index 0000000000..58d736a93a --- /dev/null +++ b/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/articles/api/management/guides/connections/configure-connection-sync.md b/articles/api/management/guides/connections/configure-connection-sync.md new file mode 100644 index 0000000000..c3343c830c --- /dev/null +++ b/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/articles/api/management/guides/connections/promote-connection-domain-level.md b/articles/api/management/guides/connections/promote-connection-domain-level.md new file mode 100644 index 0000000000..50c1c6f4bc --- /dev/null +++ b/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/articles/api/management/guides/connections/retrieve-connection-options.md b/articles/api/management/guides/connections/retrieve-connection-options.md new file mode 100644 index 0000000000..1d62b08e31 --- /dev/null +++ b/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/articles/api/management/guides/roles/add-permissions-roles.md b/articles/api/management/guides/roles/add-permissions-roles.md new file mode 100644 index 0000000000..5c9ce675be --- /dev/null +++ b/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/articles/api/management/guides/roles/create-roles.md b/articles/api/management/guides/roles/create-roles.md new file mode 100644 index 0000000000..3208506c22 --- /dev/null +++ b/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/articles/api/management/guides/roles/delete-roles.md b/articles/api/management/guides/roles/delete-roles.md new file mode 100644 index 0000000000..28396f3025 --- /dev/null +++ b/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/articles/api/management/guides/roles/edit-role-definitions.md b/articles/api/management/guides/roles/edit-role-definitions.md new file mode 100644 index 0000000000..676490c389 --- /dev/null +++ b/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/articles/api/management/guides/roles/remove-role-permissions.md b/articles/api/management/guides/roles/remove-role-permissions.md new file mode 100644 index 0000000000..1bb761e434 --- /dev/null +++ b/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/articles/api/management/guides/roles/view-role-permissions.md b/articles/api/management/guides/roles/view-role-permissions.md new file mode 100644 index 0000000000..86a3aec456 --- /dev/null +++ b/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/articles/api/management/guides/roles/view-role-users.md b/articles/api/management/guides/roles/view-role-users.md new file mode 100644 index 0000000000..8c68a6c5e4 --- /dev/null +++ b/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/articles/api/management/guides/rules/create-rules.md b/articles/api/management/guides/rules/create-rules.md new file mode 100644 index 0000000000..0e102f32c0 --- /dev/null +++ b/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/articles/api/management/guides/tenants/configure-session-lifetime-settings.md b/articles/api/management/guides/tenants/configure-session-lifetime-settings.md new file mode 100644 index 0000000000..2e4421e585 --- /dev/null +++ b/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/articles/api/management/guides/users/assign-permissions-users.md b/articles/api/management/guides/users/assign-permissions-users.md new file mode 100644 index 0000000000..1bca553a35 --- /dev/null +++ b/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/articles/api/management/guides/users/assign-roles-users.md b/articles/api/management/guides/users/assign-roles-users.md new file mode 100644 index 0000000000..12b652a0d7 --- /dev/null +++ b/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/articles/api/management/guides/users/remove-user-permissions.md b/articles/api/management/guides/users/remove-user-permissions.md new file mode 100644 index 0000000000..1cdf1f4c6d --- /dev/null +++ b/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/articles/api/management/guides/users/remove-user-roles.md b/articles/api/management/guides/users/remove-user-roles.md new file mode 100644 index 0000000000..10e60f99fe --- /dev/null +++ b/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/articles/api/management/guides/users/set-root-attributes-user-import.md b/articles/api/management/guides/users/set-root-attributes-user-import.md new file mode 100644 index 0000000000..ac6df80bdd --- /dev/null +++ b/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/articles/api/management/guides/users/set-root-attributes-user-signup.md b/articles/api/management/guides/users/set-root-attributes-user-signup.md new file mode 100644 index 0000000000..7eebeb41e9 --- /dev/null +++ b/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/articles/api/management/guides/users/update-root-attributes-users.md b/articles/api/management/guides/users/update-root-attributes-users.md new file mode 100644 index 0000000000..97be3eabfd --- /dev/null +++ b/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/articles/api/management/guides/users/view-user-permissions.md b/articles/api/management/guides/users/view-user-permissions.md new file mode 100644 index 0000000000..f24b5c02d7 --- /dev/null +++ b/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/articles/api/management/guides/users/view-user-roles.md b/articles/api/management/guides/users/view-user-roles.md new file mode 100644 index 0000000000..af6fb61d60 --- /dev/null +++ b/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/articles/api/management/v1/index.md b/articles/api/management/v1/index.md index b6c9fb97ab..e0673851e7 100644 --- a/articles/api/management/v1/index.md +++ b/articles/api/management/v1/index.md @@ -1,13 +1,17 @@ --- 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) -::: warning -This version of the Management API has been deprecated. -Please use the [new version](/api/v2) instead. -::: +<%= include('../../../_includes/_version_warning_api') %> ## Authentication @@ -16,19 +20,16 @@ Please use the [new version](/api/v2) instead.
    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. +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/json -{ - "client_id": "", - "client_secret": "", - "grant_type": "client_credentials" -} +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 querystring ( `?access_token=...`) or in an HTTP header (`Authorization: Bearer ...access_token...`). +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 @@ -61,25 +62,13 @@ Authorization: Bearer {token}
    Gets an user by id
    -Gets an user who have logged in through any of your connections that has a given 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/users/{user_id}/devices
    -
    Gets all user's devices
    -
    - -Gets all devices/refresh_tokens being used by the user. - -```text -GET /api/users/{user_id}/devices -Authorization: Bearer {token} -``` -
    GET /api/connections/{connection}/users
    Gets all users from an enterprise directory
    @@ -98,9 +87,9 @@ Authorization: Bearer {token}
    **Search** remarks: Depending on the connection's type the search will be done in different fields: -* Active Directory/LDAP: by default uses Ambigous 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 e-mail addresses over all e-mail address spaces that the Exchange server knows about). +* 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. -* Google Apps: Email/username 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. @@ -117,9 +106,9 @@ Authorization: Bearer {token} 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 Ambigous 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 e-mail addresses over all e-mail address spaces that the Exchange server knows about). +* 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. -* Google Apps: Email/username 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. @@ -341,7 +330,7 @@ Authorization: Bearer {token}
    Revokes a Refresh Token
    -Revokes a user's Refresh Token +Revokes a user's Refresh Token ```text DELETE /api/users/{user_id}/refresh_tokens/{refresh_token} @@ -412,7 +401,7 @@ Authorization: Bearer {token} Content-Type: application/json { "name": "" - "strategy": "waad|google-apps|adfs|PingFederate|samlp|auth0", + "strategy": "waad|g-suite|adfs|PingFederate|samlp|auth0", "options": { "tenant_domain": "domain_aliases": @@ -439,7 +428,7 @@ Content-Type: application/json 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 google-apps adfs PingFederate samlp auth0 +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} @@ -481,7 +470,7 @@ Authorization: Bearer {token}
    Creates a new applications/APIs
    -Create an application. The body of the request can include the `name` and `callbacks` parameters. +Create an application. The body of the request can include the `name` and `callbacks` parameters. ```text POST /api/clients @@ -696,13 +685,13 @@ The following is a description of the values returned by the request: * `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 occured. + * `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 releated to the event. - * `user_name`: The user name releated to the event. + * `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. @@ -743,10 +732,10 @@ Retrieves data about log entries based on the specified parameters. Log entries * `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 occured. +* `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 releated 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} @@ -760,13 +749,13 @@ The following is a description of the values returned by the request: * `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 occured. + * `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 releated to the event. - * `user_name`: The user name releated to the event. + * `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. @@ -807,7 +796,7 @@ If no fields are provided a case insensitive 'starts with' search is performed o * `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 insensitve exact search is used. If multiple fields are used, the AND operator is used to join the clauses. +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. @@ -826,13 +815,13 @@ The following is a description of the values returned by the request: * `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 occured. + * `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 releated to the event. - * `user_name`: The user name releated to the event. + * `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. @@ -883,13 +872,13 @@ The following is a description of the values returned by the request: * `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 occured. + * `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 releated to the event. - * `user_name`: The user name releated to the event. + * `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. diff --git a/articles/api/management/v1/reference.md b/articles/api/management/v1/reference.md index e8ff38b2a7..3d0af562df 100644 --- a/articles/api/management/v1/reference.md +++ b/articles/api/management/v1/reference.md @@ -2,10 +2,17 @@ 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 @@ -13,7 +20,7 @@ https://${account.namespace}/api ``` ### Authentication -Each API request must include an Access Token, either inside the query string: +Each API request must include an Access Token, either inside the query string: ```text https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} @@ -50,7 +57,7 @@ curl https://${account.namespace}/oauth/token --data "client_id=${account.client ``` ### 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. +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} @@ -105,12 +112,12 @@ The body of the response is a `connection` object formatted as follows: | Strategy | For Customers Using | |:---------|:--------------------| | `adfs` | On Premises Active Directory or any WS-Federation server | -| `google-apps` | Google Apps | +| `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`, `google-apps` or `adfs` strategies, the following properties are added to the connection object: +When implementing the `office365`, `g-suite` or `adfs` strategies, the following properties are added to the connection object: ```text provisioning_ticket: TICKET @@ -162,7 +169,7 @@ The `options` object returned in the `connection` will be different for each str | `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`). | -###### Google Apps Strategy +###### G Suite Strategy ```text { @@ -181,7 +188,7 @@ The `options` object returned in the `connection` will be different for each str } ``` -To obtain the `client_id` and `client_secret` for Google Apps connections, see [Google connections](/connections/social/google). +To obtain the `client_id` and `client_secret` for G Suite connections, see [Google connections](/connections/social/google). ###### Google OAuth2 Strategy @@ -310,7 +317,7 @@ 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 Google Apps, initially inactive (`status=0`): +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 { @@ -323,7 +330,7 @@ The body of the request is formatted as a `connection` object. For example, the "tenant_domain": GOOG-APP-DOMAIN, "ext_groups":true //Optional }, - "strategy": "google-apps" + "strategy": "g-suite" }; ``` @@ -339,7 +346,7 @@ For updates, use the PUT method. A PUT works on a specific `connection`, therefo | 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 Google Apps domain.| +|`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 @@ -372,7 +379,7 @@ Most attributes in the `user` object are self-explanatory. Some comments are bel |`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: e-mail, and so on). | +|`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 diff --git a/articles/api/management/v1/use-cases.md b/articles/api/management/v1/use-cases.md deleted file mode 100644 index 89d3f1d663..0000000000 --- a/articles/api/management/v1/use-cases.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -description: This page lists the API features that are only available in Management API v1. -section: apis ---- - -# Management API v1 Use Cases - -Currently, there are API features and functionality that are only available in the [Management API v1](/api/v1). If your business process or configuration requires these features, please continue to use the API v1. - -The features only available in Management API v1 include: - -* [Active Directory Connector Monitoring](#active-directory-connector-monitoring) -* [Application Users](#application-users) -* [Email](#email) -* [Enterprise Users/Directory Searching](#enterprise-users/directory-searching) -* [Impersonation](#impersonation) -* [Rules Configuration](#rules-configuration) -* [Searching via the PSaaS Appliance](#searching-via-the-auth0-appliance) - -## Active Directory Connector Monitoring - -In Management API v1, there is a `GET` endpoint that allows you to monitor the status of your Active Directory Connector: - -GET `/api/connections/{AUTH0_CONNECTION}/socket` - -## Application Users - -With Management API v1, after authenticating with the `client_id` and `client_secret` of an application, you can make a `GET` call to the appropriate Users endpoint to return only those users that belong to any specified application connection that is enabled for that application. - -[`/api/clients/{client-id}/users`](/api/v1#!#get--api-clients--client-id--users) - -## Email - -With Management API v1, you can use the `PATCH` email endpoint to update email templates as part of your automation process. - -[`/api/emails/{email-template-name}`](/api/v1#put--api-emails--email-template-name-) - -## Enterprise Users/Directory Searching - -Management API v1 allows you to search directly for users authenticated using enterprise connections, such as Active Directory or Azure Active Directory. - -* All users from a specific directory: -[`/api/connections/{connection}/users`](/api/v1#get--api-connections--connection--users) - -* Specific users from a given directory: -[`/api/connections/{connection}/users?search={criteria}`](/api/v1#get--api-connections--connection--users-search--criteria-) - -* All users from all enterprise directories: -GET `/api/enterpriseconnections/users?search={criteria}` - -## Impersonation - -Management API v1 includes an impersonation endpoint that generates a link that can be used only once to log in as a specific user for troubleshooting purposes. - -[`/users/{user_id}/impersonate`](/auth-api#impersonation) - - -## Rules Configuration - -Management API v1 allows you to add values to a global `configuration` object that is accessible to **all** Rules. - -* To return all key/value pairs on the global `configuration` object: `GET /api/rules-configs` -* To create or update a global `configuration` object: `POST /api/rules-configs` - -## Searching via the PSaaS Appliance - -In Management API v1, you can perform a "starts with" search for users by name or email: - -[`/api/users?search={criteria}`](/api/v1#!#get--api-users-search--criteria-). - -This functionality works for both cloud instances and the PSaaS Appliance. - -In Management API v2, the search operates with reduced functionality and does not currently support the Lucene query syntax. diff --git a/articles/api/management/v2/changes.md b/articles/api/management/v2/changes.md index 67e81d297a..b81792b5c1 100644 --- a/articles/api/management/v2/changes.md +++ b/articles/api/management/v2/changes.md @@ -3,6 +3,11 @@ description: Describes the major differences between Auth0's Management API v1 a section: apis crews: crew-2 toc: true +topics: + - management-api + - apis +contentType: reference +useCase: invoke-api --- # Management API v1 vs v2 @@ -11,7 +16,6 @@ This document describes the major differences between Auth0's Management API v1 ## tl;dr * v2 uses JWTs instead of opaque tokens. -* v2 allows you to send an `id_token` to perform operations on the user to which the `id_token` refers. * 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. @@ -25,15 +29,14 @@ This document describes the major differences between Auth0's Management API v1 | 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. | Implemented using Elastic Search. See the [get_users](/api/v2#!/Users/get_users) documentation. | +| [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) | Not available. | TBD. | -| [GET /api/connections/{connection}/users?search={criteria}](/api/v1#!#get--api-connections--connection--users-search--criteria-) | Not available. | TBD. | -| [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=v2` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. | -| [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=v2` 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-) | Not available. | Not available. | +| [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}/send\_verification\_email](/api/v1#!#post--api-users--user_id--send_verification_email) | Not available. | TBD. | | [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) | @@ -55,7 +58,7 @@ This document describes the major differences between Auth0's Management API v1 | ----------- | ------ | ----------- | | [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-) | Not available. | [PUT /api/v2/clients/{id}](/api/v2#!/Clients/patch_clients_by_id) | +| [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) | @@ -64,15 +67,15 @@ This document describes the major differences between Auth0's Management API v1 | 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-) | Changed `connection-name` to `id`. | [GET /api/connections/{id}](/api/v2#!/Connections/get_connections_by_id) | +| [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-) | Not available. Changed `connection-name` to `id`. | [PATCH /api/v2/connections/{id}](/api/v2#!/Connections/patch_connections_by_id) | -| [DELETE /api/connections/{connection-name}](/api/v1#!#delete--api-connections--connection-name-) | Changed `connection-name` to `id`. | [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}/users?search={criteria}](/api/v1) | None. | [GET /api/v2/users](/api/v2#!/Users/get_users) (see note) | +| [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 PSaaS Appliance (search_engine:v1), use `connection` field; for cloud (search_engine:v2), use `q=identities.connection:"connection_name"` +For Private Cloud (search_engine:v2), use `q=identities.connection:"connection_name"` ::: ### Rules endpoints @@ -81,20 +84,35 @@ For PSaaS Appliance (search_engine:v1), use `connection` field; for cloud (searc | ----------- | ------ | ----------- | | [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-) | Uses `{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-) | Uses `{id}` instead of `rule-name`. | [DELETE /api/v2/rules/{id}](/api/v2#!/Rules/delete_rules_by_id) | +| [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 have not been implemented in Management API v2. Logs must first be indexed in Elastic Search. +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 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`. +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. +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: @@ -110,7 +128,7 @@ So, for example, if the Access Token contains the scope `update:current_user_met ## User metadata -In the Management API v1, [`user.metadata`](/api/v1#!#patch--api-users--user_id--metadata) provides additional information about a user which 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": +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 { @@ -120,7 +138,7 @@ In the Management API v1, [`user.metadata`](/api/v1#!#patch--api-users--user_id- } ``` -when working with rules or retrieving the user from the API you would get: +when working with rules or retrieving the user from the API, you would get: ```javascript console.log(user.email); // "jane.doe@gmail.com" @@ -199,7 +217,7 @@ In Management API v1, different endpoints are used to update the various user pr * [`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. +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 diff --git a/articles/api/management/v2/create-m2m-app.md b/articles/api/management/v2/create-m2m-app.md new file mode 100644 index 0000000000..ef3cf0d79c --- /dev/null +++ b/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/articles/api/management/v2/faq-management-api-access-tokens.md b/articles/api/management/v2/faq-management-api-access-tokens.md new file mode 100644 index 0000000000..28600870ec --- /dev/null +++ b/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/articles/api/management/v2/get-access-tokens-for-production.md b/articles/api/management/v2/get-access-tokens-for-production.md new file mode 100644 index 0000000000..fdb44e1706 --- /dev/null +++ b/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/articles/api/management/v2/get-access-tokens-for-spas.md b/articles/api/management/v2/get-access-tokens-for-spas.md new file mode 100644 index 0000000000..49f58e6168 --- /dev/null +++ b/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/articles/api/management/v2/get-access-tokens-for-test.md b/articles/api/management/v2/get-access-tokens-for-test.md new file mode 100644 index 0000000000..ad6a3e6b1b --- /dev/null +++ b/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/articles/api/management/v2/tokens-flows.md b/articles/api/management/v2/tokens-flows.md index 34a30b219b..18ddec7612 100644 --- a/articles/api/management/v2/tokens-flows.md +++ b/articles/api/management/v2/tokens-flows.md @@ -3,133 +3,47 @@ description: Describes what changed in the flow for generating Auth0 Management 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 to get a Management APIv2 Token. This article explains what changed, why this was done and how you can work around it (not recommended). +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. +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 [OAuth 2.0 Client Credentials grant](/api-auth/grant/client-credentials). - -You can get a new token either [using the dashboard](/api/management/v2/tokens#get-a-token-manually) (if you use the API sporadically) or [by configuring a server process](/api/management/v2/tokens#automate-the-process) (if you need a token frequently) that will get a new token every 24 hours. +The new way uses the [Client Credentials Flow](/flows/concepts/client-credentials). ::: note -For details on how to follow this new process refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens). +For details on how to follow this new process, see [Access Tokens for the Management API](/api/management/v2/tokens). ::: #### Why this changed -In order 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. +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 you could login and access the API explorer, you could generate a token with __any__ scope, even if you as the logged in user were not allowed to have that scope. +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__. You can [work around that](#can-i-still-get-a-non-expiring-token-), even though we do not recommend it. +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. -## Can I still get a non-expiring token? - -Yes you can. We added a text box (__Token Expiration (Seconds)__), at [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer), where you can set the new expiration time (in seconds) and click __Update & Regenerate Token__. A new token will be generated with your custom expiration time. Our recommendation however is not to use this and get a new token every 24 hours. You can easily automate this [following this process](/api/management/v2/tokens#1-get-a-token). - -Furthermore, you can generate a token using [JWT.io](https://jwt.io/): -- Use the [JWT.io Debugger](https://jwt.io/#debugger-io) to manually type the claims and generate a token. -- Use one of the [JWT.io libraries](https://jwt.io/#libraries-io). - -::: warning -Long-lived tokens compromise your security. Following this process is NOT recommended. -::: - -### Use the JWT.io Debugger - -You can use the [JWT.io Debugger](https://jwt.io/#debugger-io) to manually generate a token. - -The debugger allows you to edit the __Header__ and __Payload__ content on the right hand side of the screen. The token will automatically be updated on the left hand text area. Note that the debugger supports only `HS256` when editing header and payload. - -To generate a token follow the next steps: - -1. Go to [JWT.io Debugger](https://jwt.io/#debugger-io). Notice that there is a sample token on the left hand editor. The right hand editor contains the header, payload and verify signature parts. - -2. Delete the dummy `secret` value from the _Verify Signature_ panel. Set your __Global Client Secret__ (you can find this value at [Advanced Tenant Settings](${manage_url}/#/tenant/advanced)) and check the __secret base64 encoded__ flag. - -3. Make sure the _Header_ contains the `alg` and `typ` claims, as follows. - - ```json - { - "alg": "HS256", - "typ": "JWT" - } - ``` -4. Delete the dummy claims from the _Payload_ and add the following claims: `iss`, `aud`, `scope`, `iat`, `exp`. - - ```json - { - "iss": "https://${account.namespace}/", - "aud": "YOUR_GLOBAL_CLIENT_ID", - "scope": "SPACE-SEPARATED-LIST-OF-SCOPES", - "iat": CURRENT_TIMESTAMP, - "exp": EXPIRY_TIME - } - ``` - - Where: - - - __iss__: Who issued the token. Use your tenant's __Domain__. You can find this value at any [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). - - - __aud__: Who is the intended audience for this token. Use the __Global Client Id__ of your tenant. You can find this value at [Advanced Tenant Settings](${manage_url}/#/tenant/advanced). - - - __scope__: The (space separated) list of authorized scopes for the token. Each [Auth0 Management API v2](/api/management/v2) endpoint requires specific scopes. For example, the [Get all applications](/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`. So if you need to read _and_ create applications, then the token should include three scopes: `read:clients`, `read:client_keys` and `create:clients`. In this case you would set the scope at the editor to the value `read:clients read:client_keys create:clients`. - - - __iat__: The time at which the token was issued. It must be a number containing a `NumericDate` value, for example `1487260214` (which maps to `Thu, 16 Feb 2017 15:50:14 GMT`). You can use an [epoch converter](http://www.epochconverter.com/) to get this value. - - - __exp__: The time at which the token will expire. It must be a number containing a `NumericDate` value, for example `1518808520` (which maps to `Fri, 16 Feb 2018 19:15:20 GMT`). - -5. As you type the token on the left hand editor is automatically refreshed. When you are done copy this value. - -### Use a Library - -- Use one of the [JWT.io libraries](https://jwt.io/#libraries-io). For example, the following snippet generates a JWT using [node-jsonwebtoken](https://github.com/auth0/node-jsonwebtoken): - - ```javascript - const jwt = require('jsonwebtoken'); - const globalClientSecret = new Buffer('YOUR_GLOBAL_CLIENT_SECRET', 'base64'); - const currentTimestamp = Math.floor(new Date()); - - var token = jwt.sign({ - iss: 'https://${account.namespace}/', - aud: 'YOUR_GLOBAL_CLIENT_ID', - scope: 'read:clients read:client_keys'}, - globalClientSecret, - { //options - algorithm: 'HS256', - expiresIn: '1y' - } - ); - - console.log(token); - ``` - - Note the following: - - - The token is signed using `HS256` and the __Global Client Secret__ (you can find this value at [Advanced Tenant Settings](${manage_url}/#/tenant/advanced)). - - - The audience (claim `aud`) is the __Global Client Id__ (you can find this value at [Advanced Tenant Settings](${manage_url}/#/tenant/advanced)). - - - We want this token in order to call the [Get all applications](/api/management/v2#!/Clients/get_clients) so we only asked for the scopes required by this endpoint: `read:clients read:client_keys`. - - - The token expires in one year (`expiresIn: '1y'`). +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/articles/api/management/v2/tokens.md b/articles/api/management/v2/tokens.md index 4714b8e9e2..4d99886e40 100644 --- a/articles/api/management/v2/tokens.md +++ b/articles/api/management/v2/tokens.md @@ -1,241 +1,38 @@ --- -description: Details on how to generate and use a token for the Auth0 Management APIv2 +description: Overview of how Auth0 Management APIv2 Access Tokens work and how to use them. section: apis -crews: crew-2 -toc: true +topics: + - apis + - management-api + - tokens +contentType: + - concept +useCase: invoke-api --- -# The Auth0 Management APIv2 Token -In order to call the endpoints of [Auth0 Management API v2](/api/management/v2), you need a token, what we refer to as __Auth0 Management APIv2 Token__. This token is a [JWT](/jwt), it contains specific granted permissions (known as __scopes__), and it is signed with an application API key and secret for the entire tenant. +# Access Tokens for the Management API -There are two ways to get a Management APIv2 Token: -- [get one manually using the Dashboard](#get-a-token-manually), or -- [automate the process](#automate-the-process) (build a simple command line tool that generates tokens). +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__). -In this article we will see how you can do either. +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. -## Get a token manually +To call endpoints, you will need to do the following: -::: warning -Τhe Management APIv2 token, by default, has a validity of __24 hours__. After that the token will expire and you will have to get a new one. If this doesn't work for you, you can either [change the validity period of the token](#2-get-the-token), or [automate the process](#automate-the-process). Keep in mind that these tokens **cannot be revoked** so long expiration times are **not recommended**. -::: - -Let's see how you can get a token manually. Note, that the first step of the process need to be executed _only_ the first time. - -### 1. Create and Authorize an Application - -First, you need to create and authorize a Machine to Machine Application. We recommend creating one exclusively for authorizing access to the Management API, instead of reusing another one you might have. If you already have done that, you can skip this paragraph. - -::: panel What is a Machine to Machine Application? -A Machine to Machine Application represents a program that interacts with an API where there is no user involved. An example would be a server script that would be granted access to consume a Zip Codes API. It's a machine to machine interaction. This must be used instead of a Single Page or Native apps because those cannot meet the necessary security requirements for executing this type of flow. If you want to read more about calling APIs this way, refer to [Calling APIs from a Service](/api-auth/grant/client-credentials). -::: - -To create and authorize a Machine to Machine Application for the Management API, go to [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer). - -Click the button __Create & Authorize a Test Application__. - -![Create and Authorize Application](/media/articles/api/tokens/create-authorize-client.png) - -That's it! A new application has been created and it's authorized to access the Management API. - -Note, that each Machine to Machine Application that accesses an API, has to be granted a set of scopes. This application that we just created has been granted __all__ the APIv2 scopes. This means that it can access all the endpoints. - -::: panel What are the scopes? -The scopes are permissions that should be granted by the owner. Each [Auth0 Management API v2](/api/management/v2) endpoint requires specific scopes. For example, the [Get all applications](/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`. -::: +* [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 -If you have multiple apps 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. For example, if one app 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. +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. ::: -### 2. Get the Token - -A token is automatically generated and displayed at [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer). - -Note, that this token has by default an expiration time of 24 hours (86400 seconds). To change that, update the __Token Expiration (Seconds)__ field and click __Update & Regenerate Token__. - -![Test Application](/media/articles/api/tokens/copy-token.png) - -Click __Copy Token__. You can now make authorized calls to the [Management API v2](/api/management/v2) using this token. - -### 3. Use the Token - -You can use the [Management API v2 explorer page](/api/management/v2) to manually call an endpoint, using the token you got in the previous step. You will need: -- The Management API v2 token you just got. -- Your tenant's domain (`${account.namespace}`). You can find this on the _Settings_ of any of your [Applications](${manage_url}/#/applications/${account.clientId}/settings). - -Once you have this information you are ready to call the API. Follow these steps: -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 __Domain__ and __API Token__ fields, 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) - -## Automate the Process - -[The manual process](#get-a-token-manually) might work for you if you want to test an endpoint or invoke it sporadically. But if you need to make scheduled frequent calls then you have to build a simple CLI that will provide you with a token automatically (and thus simulate a non-expiring token). - -::: panel Prerequisites -Before you proceed with the implementation, you must have [created and authorized a Machine to Machine Application](#1-create-and-authorize-an-application). The Application should have all the required scopes for the endpoints you mean to access. -::: - -### 1. Get a Token - -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 at [this step](#1-create-and-authorize-an-application). - -The payload should be in the following format: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"audience\": \"https://${account.namespace}/api/v2/\"}" - } -} -``` - -The request parameters are: -- `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 at [this step](#1-create-an-application). You can find it at 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 at [this step](#1-create-an-application). 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 (JSON Web Token)](/jwt), 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. - -### 2. Use the Token - -To use this token, just 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. -::: - -That's it! You are done! - -### Sample Implementation: Python - -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 at [this step](#1-create-an-application). -- `CLIENT_ID`: The __Client ID__ of the Machine to Machine Application you created at [this step](#1-create-an-application). -- `CLIENT_SECRET`: The __Client Secret__ of the Machine to Machine Application you created at [this step](#1-create-an-application). - -```python -def main(): - import json, urllib, urllib2 - - # Configuration Values - AUDIENCE = "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 = "https://{domain}".format(domain=DOMAIN) - data = urllib.urlencode([('client_id', CLIENT_ID), - ('client_secret', CLIENT_SECRET), - ('audience', AUDIENCE), - ('grant_type', GRANT_TYPE)]) - req = urllib2.Request(base_url + "/oauth/token", data) - response = urllib2.urlopen(req) - oauth = json.loads(response.read()) - access_token = oauth['access_token'] - - # Get all Applications using the token - req = urllib2.Request(base_url + "/api/v2/clients") - req.add_header('Authorization', 'Bearer ' + access_token) - req.add_header('Content-Type', 'application/json') - - try: - response = urllib2.urlopen(req) - res = json.loads(response.read()) - print res - except urllib2.HTTPError, e: - print 'HTTPError = ' + str(e.code) + ' ' + str(e.reason) - except urllib2.URLError, e: - print 'URLError = ' + str(e.reason) - except urllib2.HTTPException, e: - print 'HTTPException' - except Exception: - print 'Generic Exception' - -# Standard boilerplate to call the main() function. -if __name__ == '__main__': - main() -``` - -## Frequently Asked Questions - -__How long is the token valid for?__
    -The Management APIv2 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 APIv2 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 APIv2 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 APIv2 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. - ## Keep reading -::: next-steps -* [Changes in Auth0 Management APIv2 Tokens](/api/management/v2/tokens-flows) -* [Calling APIs from a Service](/api-auth/grant/client-credentials) +* [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) -* [Information on the query string syntax](/api/management/v2/query-string-syntax) -* [Search for Users](/api/management/v2/user-search) -::: +* [User Search](/users/search) +* [User Search Query Syntax](/users/search/v3/query-syntax) + diff --git a/articles/api/postman.md b/articles/api/postman.md index 699205d5e7..7bdcb17983 100644 --- a/articles/api/postman.md +++ b/articles/api/postman.md @@ -1,57 +1,61 @@ --- -desription: This page explains how to use Postman Collections to access Auth0 APIs. +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 --- -# Using the Auth0 API with our Postman Collections +# Use Auth0 APIs with Postman Collections -## Installing the Collections +## Install Postman Collections -To install the Postman Collection you will need to have installed the Postman App for Windows, Mac or Chrome. You can download any of these from the [Postman Apps page](https://www.getpostman.com/apps). +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, head over to our new [API Landing Page](/api/info), and install the Collection you want to use by clicking on the relevant "Run in Postman" button. +Next, visit [Auth0 APIs](/api/info) and install the Collection you want to use by clicking on the relevant **Run in Postman** button. -![](/media/articles/api/postman/auth0-api-landing.png) +![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 have installed. +Postman will prompt whether you want to open the Collection in Postman for Chrome or Postman for Windows/Mac. Select the application you installed. -![](/media/articles/api/postman/postman-open-with-dialog.png) +Once you make a selection, the selected Postman application will open and the collection will be imported. -Once you have made a selection, the selected Postman application will be opened 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. -![](/media/articles/api/postman/collection-post-install.png) +## Configure Postman Environment -Our API Collections are organized into folders which categorizes the various API calls according to category, so for example, for the Management API you will find all the Users methods under the **Users** folder. +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/). -## Configuring the Postman Environment +You must create an environment and configure the following variables: -The Auth0 Postman collections make use of environment variables to customize the requests being sent. More information on managing Postman environments can be found at [Setting up an environment with variables](https://www.getpostman.com/docs/environments) +| 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). | -You will need to create an environment and configure the following variables: +In the screenshot below, you can see a Postman environment configured with both the `auth0_domain` and `auth0_token` variables defined: -* `auth0_domain`: Should contain the domain for your Auth0 tenant, such as **jerrie.auth0.com**. -* `auth0_token`: Should contain the token needed when making calls to the Management API, and is therefore only required when using the Management API collection. More information on how to generate a token can be found at [The Auth0 Management APIv2 Token](https://auth0.com/docs/api/management/v2/tokens) +![Environment Configured](/media/articles/api/postman/environment-configured.png) -In the screenshot below you can see a Postman environment configured with both the `auth0_domain` and `auth0_token` variables defined: - -![](/media/articles/api/postman/environment-configured.png) - -## Executing a request +## Execute requests Once the environment is configured, you can follow these steps to execute an Auth0 API method: -1. Select the environment you want to work with -2. Select the relevant API method in the collection folder -3. Click the send button - -![](/media/articles/api/postman/execute-api-method.png) +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. -You may also optionally have to configure query parameters or the JSON method body, depending on the API call. For more information please refer to the [Sending Requests](https://www.getpostman.com/docs/requests) document on the Postman website. +![Execute API Method](/media/articles/api/postman/execute-api-method.png) -## A word about storing tokens in Postman variables +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/). -We do need to point out that storing tokens in Postman as environment variables could pose a potential security risk. If you are signed in to the Postman application it will automatically try and [synchronize some 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 uploaded Postman's servers. +::: 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. -It also has to be said that Postman has taken measures to ensure that this information is encrypted, and indeed encourages users to store this sort of information in Environment Variables. You can [read more about this on their website](https://www.getpostman.com/docs/security). +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 for you, then you will need to sign out of Postman to ensure that environment variables are not synchronized. +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/articles/appliance/admin/backing-up-the-appliance-instances.md b/articles/appliance/admin/backing-up-the-appliance-instances.md index 4751b9ce8b..a8a8111de9 100644 --- a/articles/appliance/admin/backing-up-the-appliance-instances.md +++ b/articles/appliance/admin/backing-up-the-appliance-instances.md @@ -1,6 +1,13 @@ --- 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 diff --git a/articles/appliance/admin/creating-tenants.md b/articles/appliance/admin/creating-tenants.md deleted file mode 100644 index 5cccf6b44d..0000000000 --- a/articles/appliance/admin/creating-tenants.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -section: appliance -description: How to automatically create tenants in the PSaaS Appliance ---- - -# PSaaS Appliance Administration: Automatic Creation of Tenants - -If your business needs require you to create tenants regularly, you may automate this process in the PSaaS Appliance. For example, you might need to create one tenant for each customer or project that goes live. - -## Creating a Management API Application for the Root Tenant Authority - -1. Choose the Root Tenant Authority (RTA) tenant using the drop-down menu located in the top right-hand side of the Dashboard. -2. Go to the Applications page. -3. Create an application called 'Tenant Provisioning.' -4. Once you have created the 'Tenant Provisioning' application, go to the Connections tab and disable **all** Connections for this application. -5. Navigate to `${manage_url}/#/apis`. Click the link to open the Auth0 Management API. -6. Go to the Machine to Machine Applications tab, and enable Tenant Provisioning by moving the associated slide to the right. -7. Create the new application grant. - -### Creating the New Application Grant - -1. Navigate to the [Management API Explorer](/api/management/v2#!/Client_Grants/post_client_grants) to generate the required `POST` call. -2. Click the bubble that says **'create:client_grants'** to select that Scope. -3. Paste the following payload into the provided `body` box after you have supplied the client ID and the root tenant authority: - ```text - { - 'client_id': '${account.clientId}', - 'audience': 'https://ROOT_TENANT_AUTHORITY/api/v2/', - 'scope': ['create:tenants'] - } - ``` -4. Click 'Try' to test the provided information. If you receive a `201` response, you may proceed to click on the 'get curl command' link to generate the required `POST` call. It will contain the following information: - - ```har - { - "method": "POST", - "url": "https://ROOT_TENANT_AUTHORITY/api/v2/client-grants", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [], - "queryString" : [], - "postData": { - "mimeType": "application/json", - "text" : "{ \"client_id\": \"${account.clientId}\", \"audience\": \"https://ROOT_TENANT_AUTHORITY/api/v2/\", \"scope\": [\"create:tenants\"] }" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" - } - ``` - -## Using the New Application grant - -Once you have created your New Application Grant, you may use it to complete the following tasks. - -### Getting an Access Token - -```har -{ - "method": "POST", - "url": "https://ROOT_TENANT_AUTHORITY_DOMAIN/oauth/token", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "cache-control", "value": "no-cache" }, - { "name": "content-type", "value": "application/json" } - ], - "queryString" : [], - "postData" : { - "mimeType": "application/json", - "text": "{\"audience\": \"https://ROOT_TENANT_AUTHORITY/api/v2/\", \"grant_type\": \"client_credentials\",\"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\"}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` - -In return, you will receive the Access Token: - -```text -{ - 'access_token': 'eyJ0eXAiO...' -} -``` - -### Creating a Tenant - -You may use the following call create a tenant. Once the tenant is created, the API responds with a Client ID and Secret that grants access to the Management API for the newly-created tenant (which you can then use to get additional Access Tokens--see the following section for the sample call). - -```har -{ - "method": "POST", - "url": "https://ROOT_TENANT_AUTHORITY_DOMAIN/api/v2/tenants", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "cache-control", "value": "no-cache" }, - { "name": "content-type", "value": "application/json" }, - { "name": "authorization", "value": "Bearer ACCESS_TOKEN" } - ], - "queryString" : [], - "postData" : { - "mimeType": "application/json", - "text": "{\"name\": \"customer-1\",\"owners\": [\"me@email.com\"]}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` - -#### Getting an Access Token for the Newly-Created Tenant - -This snippet shows how you can get an Access Token for the newly-created tenant, which you can then use to call the Management API. - -```har -{ - "method": "POST", - "url": "https://NEW_TENANT_DOMAIN/oauth/token", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "cache-control", "value": "no-cache" }, - { "name": "content-type", "value": "application/json" } - ], - "queryString" : [], - "postData" : { - "mimeType": "application/json", - "text": "{\"audience\": \"https://NEW_TENANT_DOMAIN/api/v2/\", \"grant_type\": \"client_credentials\", \"client_id\": \"MANAGEMENT_CLIENT_ID\", \"client_secret\": \"MANAGEMENT_CLIENT_SECRET\"}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` diff --git a/articles/appliance/admin/disabling-sign-ups.md b/articles/appliance/admin/disabling-sign-ups.md index 65a3152e79..219fc4f573 100644 --- a/articles/appliance/admin/disabling-sign-ups.md +++ b/articles/appliance/admin/disabling-sign-ups.md @@ -1,6 +1,13 @@ --- 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 diff --git a/articles/appliance/admin/federated-access-to-manage.md b/articles/appliance/admin/federated-access-to-manage.md new file mode 100644 index 0000000000..a5633b68fd --- /dev/null +++ b/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/articles/appliance/admin/importance-of-updates.md b/articles/appliance/admin/importance-of-updates.md new file mode 100644 index 0000000000..c38ad249b4 --- /dev/null +++ b/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/articles/appliance/admin/index.md b/articles/appliance/admin/index.md index a0f776bbdf..cdde2ec3c8 100644 --- a/articles/appliance/admin/index.md +++ b/articles/appliance/admin/index.md @@ -3,17 +3,24 @@ 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); +* [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); -* [Limiting SSH Access](/appliance/admin/limiting-ssh-access); -* [Updating the PSaaS Appliance](/appliance/admin/updating-the-appliance); -* [Configuring Custom Error Pages](/hosted-pages/custom-error-pages). +* [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/articles/appliance/admin/inviting-coadmins.md b/articles/appliance/admin/inviting-coadmins.md index 59026f316a..a5f17a2222 100644 --- a/articles/appliance/admin/inviting-coadmins.md +++ b/articles/appliance/admin/inviting-coadmins.md @@ -1,6 +1,13 @@ --- 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 diff --git a/articles/appliance/admin/limiting-ssh-access.md b/articles/appliance/admin/limiting-ssh-access.md index e6645eb3bb..4d0b93b513 100644 --- a/articles/appliance/admin/limiting-ssh-access.md +++ b/articles/appliance/admin/limiting-ssh-access.md @@ -1,10 +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 to the virtual machines in your corporate firewall. +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/articles/appliance/admin/managing-the-dashboard.md b/articles/appliance/admin/managing-the-dashboard.md index 83ca580c8a..5ad7477bc3 100644 --- a/articles/appliance/admin/managing-the-dashboard.md +++ b/articles/appliance/admin/managing-the-dashboard.md @@ -1,6 +1,13 @@ --- 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 diff --git a/articles/appliance/admin/monitoring.md b/articles/appliance/admin/monitoring.md index 2cbc24e5c6..751be898b9 100644 --- a/articles/appliance/admin/monitoring.md +++ b/articles/appliance/admin/monitoring.md @@ -1,6 +1,13 @@ --- 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 diff --git a/articles/appliance/admin/rate-limiting.md b/articles/appliance/admin/rate-limiting.md index 1e0145f58e..5e276a2e64 100644 --- a/articles/appliance/admin/rate-limiting.md +++ b/articles/appliance/admin/rate-limiting.md @@ -1,10 +1,17 @@ --- 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 -Beginning with PSaaS Appliance build `6576`, 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). +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 @@ -64,4 +71,4 @@ 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"]}] -``` \ No newline at end of file +``` diff --git a/articles/appliance/admin/updating-the-appliance.md b/articles/appliance/admin/updating-the-appliance.md index 5c58bf8839..bfec4751aa 100644 --- a/articles/appliance/admin/updating-the-appliance.md +++ b/articles/appliance/admin/updating-the-appliance.md @@ -1,36 +1,82 @@ --- 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, 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. You should not exceed **90 days** without 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 -::: note For more information about PSaaS Appliance Releases, please see the [Change Log](https://auth0.com/changelog/appliance). -::: -## Best Practices +## 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 +#### 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 [trigged via the Management Dashboard](/appliance/dashboard/updates) and requires the downloading of the application itself, as well as any operating system updates. The update takes between 60 minutes (for a single Development node) to 90 minutes (for a three-node Production cluster). +* 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 +#### After the update ::: note For additional information on gathering testing information, please see [PSaaS Appliance Monitoring](/appliance/monitoring). @@ -39,20 +85,35 @@ For additional information on gathering testing information, please see [PSaaS A * 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. -Please remember that you are responsible for testing and ensuring that all of your applications work as expected. +* Run smoke tests to ensure that there are no issues with the update. -## Coordination with Auth0 + 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: -While most updates require manual installation of patches by an Auth0 Customer Success Engineering, some updates are self-service and can be performed using the [Updates page](/appliance/dashboard/updates). + 1. All application functionality that involves authentication flows or user identity changes + 2. Basic access to the Auth0 Management Dashboard -We recommend that you let Auth0 known when you plan on upgrading your Development node. + Some of the areas and processes that you might consider including in your smoke tests include: -Production upgrades should **always** be performed in conjunction with an Auth0 Customer Success Engineer. We will schedule these updates so that an Auth0 Customer Success Engineer is on the call with your operations team during the entire process. + * 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 3-5 minute window of downtime. This occurs when we restart services. Because of this, we are willing to schedule updates to Production clusters during non-business hours. Please contact your Customer Success Manager to select a time that would be best for you. +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/articles/appliance/appliance-overview.md b/articles/appliance/appliance-overview.md index f501e1a7f1..ed9bfb70b7 100644 --- a/articles/appliance/appliance-overview.md +++ b/articles/appliance/appliance-overview.md @@ -1,6 +1,12 @@ --- 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 @@ -8,12 +14,7 @@ description: The PSaaS Appliance is an option for your organization when complia 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** or **Microsoft Azure**. Other public cloud service providers will need to be reviewed. -* your own datacenter (as a managed service) using **VMWare** or **Microsoft Hyper-V**. - -::: note -Please contact us for additional information if you are interested in using cloud environments and/or virtualization environments not listed above. -::: +* your cloud environment using **Amazon AWS** ## Infrastructure @@ -74,7 +75,7 @@ If Auth0 is managing a dedicated environment for you, Auth0 will obtain your con ### Connectivity -During maintenance operations, the PSaaS Appliance instances contact external Auth0 endpoints for updating under your consent and supervision. After maintenance completes, you can block Internet access to the PSaaS Appliance. +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. diff --git a/articles/appliance/cli/adding-node-to-backup-role.md b/articles/appliance/cli/adding-node-to-backup-role.md index 14d254a6c0..fad2cdabe9 100644 --- a/articles/appliance/cli/adding-node-to-backup-role.md +++ b/articles/appliance/cli/adding-node-to-backup-role.md @@ -1,14 +1,19 @@ --- 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 -::: note - This document applies beginning with PSaaS Appliance update **build 7247**. -::: - ## 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. diff --git a/articles/appliance/cli/backing-up-the-appliance.md b/articles/appliance/cli/backing-up-the-appliance.md index 0f9530d7b8..f382361fb5 100644 --- a/articles/appliance/cli/backing-up-the-appliance.md +++ b/articles/appliance/cli/backing-up-the-appliance.md @@ -2,6 +2,14 @@ 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 @@ -24,7 +32,7 @@ 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` +* The replica set connection string: `a0/a0-1:27017,a0-2:27017,a0-3:27017`. ## Generate a New Backup @@ -58,10 +66,10 @@ To do this, you can use the `backup-sensitive` command, which works the same way 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` +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 diff --git a/articles/appliance/cli/configure-cli.md b/articles/appliance/cli/configure-cli.md index c4d4f91c64..90b57df34f 100644 --- a/articles/appliance/cli/configure-cli.md +++ b/articles/appliance/cli/configure-cli.md @@ -1,6 +1,13 @@ --- 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 @@ -9,7 +16,7 @@ The PSaaS Appliance Command Line Interface (CLI) allows you to perform operation ## Downloading the CLI Setup Files -To download the files required to set up the CLI, please contact your Auth0 Customer Success Manager for your custom download link. +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 @@ -26,7 +33,7 @@ Usage: a0cli [options] 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 availables commands from the specified node. + update-commands Retrieve available commands from the specified node. Options: @@ -47,7 +54,7 @@ Usage: a0cli [options] 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 availables commands from the specified node. + 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. diff --git a/articles/appliance/cli/index.md b/articles/appliance/cli/index.md index 16f63b5d72..8f2d5a346f 100644 --- a/articles/appliance/cli/index.md +++ b/articles/appliance/cli/index.md @@ -2,6 +2,14 @@ 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 diff --git a/articles/appliance/cli/reconfiguring-ip.md b/articles/appliance/cli/reconfiguring-ip.md index 70b05d8963..8ec85afb75 100644 --- a/articles/appliance/cli/reconfiguring-ip.md +++ b/articles/appliance/cli/reconfiguring-ip.md @@ -1,70 +1,18 @@ --- section: appliance -description: How to reconfigure AppliPSaaS Applianceance IP Addresses using the CLI +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, you may change the individual IP addresses using the console (TTY1) interface in the Virtual Machine Manager. However, there is no easy way to tell the cluster nodes the new IP addresses of the other members of the cluster. +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 **6576**, you may reconfigure the mapping of IP addresses to the names of nodes for each PSaaS Appliance node using the PSaaS Appliance's Command Line Interface (CLI). Once this is done, the nodes may resume communication with one another within that cluster. - -## Prerequisites - -Prior to beginning, please be sure to [configure the CLI](/appliance/cli/configure-cli) for use in performing operations on your PSaaS Appliance instances via authorized workstations. - -## Using the `re-ip` Task - -The `reip` task has the following signature: - -```text -$a0cli -t re-ip ":[,:...]" -``` - -Running the above will modify the ``'s `/etc/hosts` file to point each `` to its corresponding ``. - -### Use Example - -Suppose that you run the following command: - -```text -$a0cli -t 10.0.0.11 re-ip "a0-1:10.0.0.21,a0-2:10.0.0.22,a0-3:10.0.0.23" -``` - -Suppose that this node has the following `/etc/hosts` file: - -```text -# The following lines are desirable for IPv6 capable hosts -::1 ip6-localhost ip6-loopback -fe00::0 ip6-localnet -ff00::0 ip6-mcastprefix -ff02::1 ip6-allnodes -ff02::2 ip6-allrouters -ff02::3 ip6-allhosts -127.0.0.1 login.myauth0.com -127.0.0.1 login0.myauth0.com -127.0.0.1 login.appliancelab.net -127.0.0.1 auth.appliancelab.net -10.0.1.11 a0-1 -10.0.1.12 a0-2 -10.0.1.13 a0-3 -``` - -Running the command results in the CLI modifying the `/etc/hosts` file so that it becomes the following: - -```text -# The following lines are desirable for IPv6 capable hosts -::1 ip6-localhost ip6-loopback -fe00::0 ip6-localnet -ff00::0 ip6-mcastprefix -ff02::1 ip6-allnodes -ff02::2 ip6-allrouters -ff02::3 ip6-allhosts -127.0.0.1 login.myauth0.com -127.0.0.1 login0.myauth0.com -127.0.0.1 login.appliancelab.net -127.0.0.1 auth.appliancelab.net -10.0.1.21 a0-1 -10.0.1.22 a0-2 -10.0.1.23 a0-3 -``` +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/articles/appliance/clock.md b/articles/appliance/clock.md index d9fadd0b66..5674a7c5b0 100644 --- a/articles/appliance/clock.md +++ b/articles/appliance/clock.md @@ -1,12 +1,19 @@ --- 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 (Infrastracture 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 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. diff --git a/articles/appliance/critical-issue.md b/articles/appliance/critical-issue.md index faac684045..d7b7d47801 100644 --- a/articles/appliance/critical-issue.md +++ b/articles/appliance/critical-issue.md @@ -2,11 +2,20 @@ 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 shoud be read in conjunction with the general [Enterprise Support Guidance document](/onboarding/enterprise-support). +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. @@ -20,12 +29,16 @@ A Critical Issue is defined as an Auth0 issue severely impacting your live or in - 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 Customer Success Manager. +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.* @@ -33,16 +46,15 @@ As a secondary point of escalation, PSaaS Appliance customers can also send an e ### 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 [New Ticket](${env.DOMAIN_URL_SUPPORT}/tickets/new) button. -3. Select the affected service. **Note that even if you only see your cloud account, you will be getting support for your PSaaS Appliance installation.** -4. In **Environment** indicate the specific installation having the problem (such as Production, QA). -5. For **What can we help you with?** select `Auth0 Service Issue`. -6. For **Severity** select `Urgent` +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. + 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. ::: -7. Complete an appropriate **Subject** title. -8. 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.* +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 @@ -55,7 +67,7 @@ To speed resolution, please provide the following when logging an issue via emai 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. +* 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/articles/appliance/custom-domains/index.md b/articles/appliance/custom-domains/index.md index d2d6912613..cb3728aba9 100644 --- a/articles/appliance/custom-domains/index.md +++ b/articles/appliance/custom-domains/index.md @@ -2,13 +2,25 @@ 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 or more arbitrary DNS names 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. +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. diff --git a/articles/appliance/dashboard/activity.md b/articles/appliance/dashboard/activity.md index 15872885f7..d73389b069 100644 --- a/articles/appliance/dashboard/activity.md +++ b/articles/appliance/dashboard/activity.md @@ -1,12 +1,19 @@ --- 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#appliance-controls). +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. diff --git a/articles/appliance/dashboard/cli.md b/articles/appliance/dashboard/cli.md index b16a0d041b..f817659fb8 100644 --- a/articles/appliance/dashboard/cli.md +++ b/articles/appliance/dashboard/cli.md @@ -1,6 +1,14 @@ --- 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 @@ -13,7 +21,7 @@ If your PSaaS Appliance instances requires integration with the PSaaS Appliance ![](/media/articles/appliance/dashboard/cli-keys.png) -Please see your vender 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: +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. diff --git a/articles/appliance/dashboard/index.md b/articles/appliance/dashboard/index.md index a145e960bd..e77472478b 100644 --- a/articles/appliance/dashboard/index.md +++ b/articles/appliance/dashboard/index.md @@ -3,6 +3,15 @@ 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 @@ -31,8 +40,6 @@ For additional information about the pages contained in the PSaaS Appliance conf [Activity](/appliance/dashboard/activity) -[Instrumentation](/appliance/dashboard/instrumentation) - [Rate Limiting](/appliance/dashboard/rate-limiting) [CLI](/appliance/dashboard/cli) diff --git a/articles/appliance/dashboard/instrumentation.md b/articles/appliance/dashboard/instrumentation.md deleted file mode 100644 index bb9870725b..0000000000 --- a/articles/appliance/dashboard/instrumentation.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -section: appliance -description: Overview on instrumentation in the PSaaS Appliance ---- - -# PSaaS Appliance Dashboard: Instrumentation - -The PSaaS Appliance ships with a feature called [Instrumentation](/appliance/instrumentation), which makes it easy for your PSaaS Appliance administrators or Auth0 Customer Success Engineers to gather information about the current (or previous) state of the PSaaS Appliance. - -If you have chosen to enable Instrumentation, you can see specific Grafana dashboards in the [PSaaS Appliance Dashboard](${manage_url}/configuration#/instrumentation). - -## The Instrumentation Page - -If you've never used the PSaaS Appliance Dashboard to view your Grafana data, you'll be asked to sign in to your Grafana account. Without these permissions, Auth0 cannot return and display your data and dashboards. - -![](/media/articles/appliance/dashboard/instrumentation-login.png) - -Once you've logged in, you'll be able to see your data. You can set the following options to change the data displayed: - -* **Nodes**: The PSaaS Appliance node for which you want to view data. Each node ships with its own Grafana instance; -* **Dashboard**: The [Grafana dashboard](http://docs.grafana.org/guides/getting_started/#dashboards-panels-rows-the-building-blocks-of-grafana) you want to see for the node you've selected; -* **Range**: The time period for which you want data. Choose from one of the following: - - * Last minute; - * Last 5 minutes; - * Last 15 minutes; - * Last 30 minutes; - * Last hour. - -![](/media/articles/appliance/dashboard/instrumentation-page.png) diff --git a/articles/appliance/dashboard/nodes.md b/articles/appliance/dashboard/nodes.md index c92688df8d..f406e27741 100644 --- a/articles/appliance/dashboard/nodes.md +++ b/articles/appliance/dashboard/nodes.md @@ -1,6 +1,14 @@ --- 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 diff --git a/articles/appliance/dashboard/oss-components.md b/articles/appliance/dashboard/oss-components.md index 7d1041d859..76c680a20e 100644 --- a/articles/appliance/dashboard/oss-components.md +++ b/articles/appliance/dashboard/oss-components.md @@ -1,7 +1,14 @@ --- 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 diff --git a/articles/appliance/dashboard/rate-limiting.md b/articles/appliance/dashboard/rate-limiting.md index 28dda742f9..ac92f8c95c 100644 --- a/articles/appliance/dashboard/rate-limiting.md +++ b/articles/appliance/dashboard/rate-limiting.md @@ -1,6 +1,14 @@ --- 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 diff --git a/articles/appliance/dashboard/settings.md b/articles/appliance/dashboard/settings.md index 6fd0f9a013..842e959bdc 100644 --- a/articles/appliance/dashboard/settings.md +++ b/articles/appliance/dashboard/settings.md @@ -1,6 +1,14 @@ --- 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 @@ -70,13 +78,22 @@ The Settings page is broken down into the following sections: * **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. -## Update Settings +### Units of time -* **Update Proxy**: unless your specific configuration is set up for offline updates, please leave this field blank. +When providing time values to Auth0, please use the following abbreviations to ensure the correct units are used: -## Monitoring +| Abbreviation | Description | +| - | - | +| w | weeks | +| d | days | +| h | hours | +| m | minutes | +| s | seconds | +| ms | milliseconds | -* **New Relic License Key**: if you use New Relic for monitoring, enter your license key here to monitor your PSaaS Appliance instances. +## Update Settings + +* **Update Proxy**: unless your specific configuration is set up for offline updates, please leave this field blank. ## API Keys @@ -88,7 +105,7 @@ The Settings page is broken down into the following sections: ## 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). +* **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 diff --git a/articles/appliance/dashboard/tenants.md b/articles/appliance/dashboard/tenants.md index 11a33b57b3..120e7b9073 100644 --- a/articles/appliance/dashboard/tenants.md +++ b/articles/appliance/dashboard/tenants.md @@ -1,6 +1,14 @@ --- 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 @@ -27,7 +35,11 @@ For each associated tenant, you will see the following pieces of information: 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 +### 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: diff --git a/articles/appliance/dashboard/troubleshoot.md b/articles/appliance/dashboard/troubleshoot.md index 1664bd5e48..7af19b48fc 100644 --- a/articles/appliance/dashboard/troubleshoot.md +++ b/articles/appliance/dashboard/troubleshoot.md @@ -1,6 +1,14 @@ --- 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 diff --git a/articles/appliance/dashboard/updates.md b/articles/appliance/dashboard/updates.md index e11db153d3..a78879ad02 100644 --- a/articles/appliance/dashboard/updates.md +++ b/articles/appliance/dashboard/updates.md @@ -1,6 +1,14 @@ --- 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 @@ -11,9 +19,9 @@ description: Overview of the PSaaS Appliance Dashboard Updates page The Updates page of the PSaaS Appliance configuration area allows you to make the required/selected updates to your PSaaS Appliance instance. -::: note - Updates cannot be rolled back/undone, so take VM snapshots and make backups as needed. -::: +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) @@ -27,5 +35,5 @@ Once you have selected the appropriate build, any **release notes** applicable w 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 Customer Success 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). +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/articles/appliance/disaster-recovery-raci.md b/articles/appliance/disaster-recovery-raci.md index 70716392b1..4a9e440e7b 100644 --- a/articles/appliance/disaster-recovery-raci.md +++ b/articles/appliance/disaster-recovery-raci.md @@ -1,6 +1,14 @@ --- 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 --- @@ -47,7 +55,7 @@ The following table details the task division for configuring, creating, and mon Download PSaaS Appliance CLI tool C R, A - The subscriber will need to contact their Auth0 Customer Success Manager for the custom download link. + The subscriber will need to contact their Auth0 Technical Account Manager for the custom download link. Install PSaaS Appliance CLI Tool @@ -118,7 +126,7 @@ The following table details the task division for configuring, creating, and mon Restore the Data Backup R, C I - Please 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. + Please 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. @@ -149,12 +157,18 @@ The following table details the task division for configuring, creating, and mon R, A The subscriber is responsible for restoring a VM Snapshot.. + + Recover Auth0 Environment + R + I, A + Auth0 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 Customer Success 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 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/articles/appliance/disaster-recovery.md b/articles/appliance/disaster-recovery.md index eae11b6b8a..a2296865d2 100644 --- a/articles/appliance/disaster-recovery.md +++ b/articles/appliance/disaster-recovery.md @@ -1,11 +1,18 @@ --- 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 a discussion of the advantages and disadvantages associated with the various disaster recovery (DR) options available. +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. @@ -13,13 +20,15 @@ In cases where the data centers have very low latency, you can run individual PS ## Geographic High-Availability PSaaS Appliance Implementation -If your requirements demand very little to no downtime, we recommend a [Geographic High-Availability PSaaS Appliance](/appliance/geo-ha) implementation. This is the only implementation that has automatic failover with recovery on the order of 1 minute. +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 an PSaaS Appliance implementation that provides: +Geo-HA is a PSaaS Appliance implementation that provides: * Data center redundancy; -* Automatic failure handling; +* Rapid failure response; * The highest form of PSaaS Appliance availability offered by Auth0. **Disadvantages**: @@ -28,35 +37,33 @@ 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, since this is not a scenario that is covered by the typical setup. +* 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 you need to rebuild an 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. +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 faster than using database backups (though the process is slower than GEO-HA). -* You may not need manual intervention from an Auth0 Customer Success Engineer (CSE) to restore your cluster. +* Recovery via VM snapshots is quicker than using database backups (though the process is slower than GEO-HA). **Disadvantages**: -* VM snapshots can become very large in size (snapshots are not compressed, and you would need a snapshot of each VM/drive), which makes storage tricky. +* 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 your PSaaS Appliance instances using 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. -Use the [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli) to [reconfigure the IP addresses](/appliance/cli/reconfiguring-ip) of the VM(s). +3. Contact a Managed Services Engineer via support ticket to complete the recovery of your environment ::: panel VMWare's Site Recovery Manager -If you are hosting your PSaaS Appliance instances using VMware, you may also implement a similar backup/recovery scenario using VMWare's Site Recovery Manager (SRM). SRM provides an automated mechanism to move your snapshots to a secondary site, where they can be retrieved if you ever need your data restored. If you choose this option, Auth0 will help you set up and test your implementation. - -We have tested that it will change the IP for the box and you can [run re-ip](/appliance/cli/reconfiguring-ip) as long as you have prepared the [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli) ahead of time and uploaded the certificate. +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 @@ -71,7 +78,7 @@ If you choose to use database backups as your DR strategy, please note that this * Database backups are smaller and easier to move offsite than VM snapshots. **Disadvantage**: -* You will need manual intervention from an Auth0 CSE to restore your PSaaS Appliance. +* 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: @@ -79,12 +86,8 @@ For more information, please see: * [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) -::: note - This option is available to PSaaS Appliance on version **7247** or later. -::: - ## 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. +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/articles/appliance/extensions.md b/articles/appliance/extensions.md index b831ea59ee..b98480d9b1 100644 --- a/articles/appliance/extensions.md +++ b/articles/appliance/extensions.md @@ -2,23 +2,34 @@ 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. -## Configure Extensions +You may receive updates to Extensions at any time without prior notice. -Extensions make use of Webtasks. 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: +## Set up and enable Webtasks -`webtask.` +You must set up and enable Webtasks before you can use Extensions. -::: note -To enable Webtasks, go to the [Webtasks Settings page of the Management Dashboard](${manage_url}/#/account/webtasks). +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 -See [Enable Webtasks, Web Extensions, and User Search](/appliance/infrastructure/extensions) for additional information. -::: +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). @@ -32,4 +43,6 @@ The [Delegated Administration](/extensions/delegated-admin) extension is availab ## 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). \ No newline at end of file +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/articles/appliance/geo-ha/disaster-recovery.md b/articles/appliance/geo-ha/disaster-recovery.md index 7f23338be2..8750ac5517 100644 --- a/articles/appliance/geo-ha/disaster-recovery.md +++ b/articles/appliance/geo-ha/disaster-recovery.md @@ -1,6 +1,13 @@ --- 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 --- @@ -70,7 +77,7 @@ The following table details some of the ways in which the Geographic High-Availa Connection between the Global Load Balancer and the Primary Site Unavailable - All requests are routed to the secondary site, but the secondary nodes continue to use data on the primary site + All 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. @@ -95,7 +102,7 @@ The following table details some of the ways in which the Geographic High-Availa 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. +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. @@ -110,7 +117,7 @@ As a customer, it is your responsibility to perform regular backups on your Geog 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 Customer Success Manager to schedule a discussion about performance impact if backups are performed more frequently/during peak usage times. +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 diff --git a/articles/appliance/geo-ha/dr-overview.md b/articles/appliance/geo-ha/dr-overview.md index 073d13f585..32051a5492 100644 --- a/articles/appliance/geo-ha/dr-overview.md +++ b/articles/appliance/geo-ha/dr-overview.md @@ -1,6 +1,14 @@ --- 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 --- diff --git a/articles/appliance/geo-ha/index.md b/articles/appliance/geo-ha/index.md index c14393f61e..16329c8635 100644 --- a/articles/appliance/geo-ha/index.md +++ b/articles/appliance/geo-ha/index.md @@ -2,11 +2,21 @@ 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 data center redundancy and automatic failure handling. This is the highest form of PSaaS Appliance availability offered by Auth0. +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 @@ -37,6 +47,8 @@ The Arbiter does not store data or execute application logic, but acts as a witn 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. diff --git a/articles/appliance/index.html b/articles/appliance/index.html index 1335704513..56af4b1bc2 100644 --- a/articles/appliance/index.html +++ b/articles/appliance/index.html @@ -3,13 +3,18 @@ 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, your cloud, or your own data center. + An Auth0 deployment that exists in a dedicated area of Auth0's cloud or your AWS cloud.

    @@ -97,9 +102,9 @@

    PSaaS Appliance Administration

  • - Tools for Monitoring the PSaaS Appliance + Monitoring the PSaaS Appliance

    - In addition to providing tools for monitoring your PSaaS Appliance instances, Auth0 provides integration with select third-party utilities. + Learn how to monitor your PSaaS Appliance instances, so that you always know how it is performing.

    • @@ -113,12 +118,6 @@

      PSaaS Appliance Administration

      The PSaaS Appliance Command Line Interface (CLI) allows you to perform operations on your PSaaS Appliance via authorized workstations.

      • -
    • - Automatic Creation of Tenants -

      - If your business needs require you to create tenants regularly, you may automate this process in your PSaaS Appliance instances. For example, you might need to create one tenant for each customer or project that goes live. -

      -
    • Node.js Modules Available in Rules and Custom Database Connections for PSaaS Appliance

      diff --git a/articles/appliance/infrastructure/dns.md b/articles/appliance/infrastructure/dns.md index 24a8b7d1c9..2466fa2ca1 100644 --- a/articles/appliance/infrastructure/dns.md +++ b/articles/appliance/infrastructure/dns.md @@ -1,6 +1,14 @@ --- section: appliance description: PSaaS Appliance infrastructure information about DNS +topics: + - appliance + - infrastructure + - dns +contentType: reference +useCase: appliance +applianceId: appliance31 +sitemap: false --- @@ -25,11 +33,11 @@ Dedicated and non-dedicated host names must be unique. Management Dashboard - manage-project.yourdomain.com + manage.yourdomain.com Configuration - config-project.yourdomain.com + config.yourdomain.com Webtask @@ -37,30 +45,30 @@ Dedicated and non-dedicated host names must be unique. App Tenant(s) - app1-project.yourdomain.com;
      app2-project.yourdomain.com
      ...and so on + 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 append “-dev” to the hostname component in the domain name: +For a dev/test non-production PSaaS Appliance a common practice is to include "dev” in the domain name: - + - + - + - +
      Management Dashboard (Dev)manage-dev-project.yourdomain.commanage.dev.yourdomain.com
      Configuration (Dev)config-dev-project.yourdomain.comconfig.dev.yourdomain.com
      Webtask (Dev)webtask-dev.yourdomain.comwebtask.dev.yourdomain.com
      App Tenant(s) (Dev)app1-dev-project.yourdomain.com;
      app2-dev-project.yourdomain.com
      ...and so on      		identity.dev.yourdomain.com (for example);
      app-name.dev.yourdomain.com (if you want more than 1 App tenant)
      ...and so on
      @@ -69,7 +77,6 @@ For a dev/test non-production PSaaS Appliance a common practice is to append “ * **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; -* **Project**: the name of the overarching project or department; * **yourdomain.com**: your organization's domain name. ![](/media/articles/appliance/infrastructure/appliance-dns.png) @@ -181,4 +188,4 @@ Suppose these were your standard domains: -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). \ No newline at end of file +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/articles/appliance/infrastructure/extensions.md b/articles/appliance/infrastructure/extensions.md index 04a15fb0ea..f2a2e22e74 100644 --- a/articles/appliance/infrastructure/extensions.md +++ b/articles/appliance/infrastructure/extensions.md @@ -1,64 +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 -Beginning with version `8986`, the PSaaS Appliance supports extensions. This is in addition to support for [Webtasks](appliance/webtasks). +The PSaaS Appliance supports: -::: note -Some of the [Extensions](/extensions) available to users of the Auth0 public cloud are unavailable in the PSaaS Appliance. As such, these do not appear as options in the PSaaS Appliance's Dashboard. -::: +* Extensions +* [Webtasks](appliance/webtasks) +* User search using Elasticsearch -Beginning with version `10755`, the PSaaS Appliance supports User Search using Elasticsearch. This allows you to use extensions that require User Search, including the [Delegated Admininstration extension](/extensions/delegated-admin) +## Extensions -## Requirements for Enabling User Search +You can find a list of extensions available to you [in the Dashboard](${manage_url}/#/extensions). -To enable User Search, you must increase the amount of storage available in your Development and Production environments. +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. -* 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 additional **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. +## Webtasks Requirements -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; -* Update your PSaaS Appliance to version `10755` or above. Auth0 will work with you to upgrade your Development environment first, so that you can test the changes. Auth0 will coordinate the Production upgrade after you've concluded testing in Development. - -## Requirements for Enabling Webtasks - -Your Development and/or Production environments must meet the following requirements before you can enable Webtasks and update to version `8986` or above. +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`) - * Please note that version 8293 required outbound access to `docker.it.auth0.com` (or `52.9.124.234`) on Port **5000**. * `cdn.auth0.com` -* All nodes are able to communicate with other nodes in the same cluster using ports **8721** and **8701**. +* 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` -## Enabling Webtasks - -Once you have met the requirements for enabling Webtasks, submit a Support ticket to request that Auth0: +## Enable Webtasks -* Configure Webtasks (including switching your sandbox mode to `auth0-sandbox`) -* Update your PSaaS Appliance to version `8986`. Auth0 will work with you to upgrade your Development environment first, so that you can test the changes. Afterwards, Auth0 will coordinate the Production upgrade. +Once you have met the requirements for enabling Webtasks, submit a Support ticket to request that Auth0 configure Webtasks on your behalf. ## 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). +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 Admininstration extension](/extensions/delegated-admin) +* [Delegated Administration extension](/extensions/delegated-admin) * [Webtasks](/appliance/webtasks) * [Version Change Logs](https://auth0.com/changelog/appliance) ::: diff --git a/articles/appliance/infrastructure/faq.md b/articles/appliance/infrastructure/faq.md index 0286f7c2da..e9dc9fc33e 100644 --- a/articles/appliance/infrastructure/faq.md +++ b/articles/appliance/infrastructure/faq.md @@ -1,6 +1,13 @@ --- 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 @@ -23,7 +30,9 @@ No, the PSaaS Appliance is a managed service that runs within your network. You 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? -If Auth0 hosts the PSaaS Appliance, Auth0 will provide the required certificate(s). +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. @@ -74,7 +83,6 @@ Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS A 1. Jumphost + Firewall Whitelist 2. Two Jumphosts -3. VPN We do not support other methods, such as VDI or Screen Sharing mechanisms. @@ -90,4 +98,4 @@ You can read the PSaaS Appliance terms [here](https://auth0.com/legal/baseline/P #### 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. \ No newline at end of file +Please refer to [our documentation on the internet-related requirements](/appliance/infrastructure/internet-restricted-deployment) for the PSaaS Appliance. diff --git a/articles/appliance/infrastructure/index.md b/articles/appliance/infrastructure/index.md index 44b51cc621..6f2919f464 100644 --- a/articles/appliance/infrastructure/index.md +++ b/articles/appliance/infrastructure/index.md @@ -3,6 +3,15 @@ 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 diff --git a/articles/appliance/infrastructure/infrastructure-overview.md b/articles/appliance/infrastructure/infrastructure-overview.md index 2a949d7a43..b9e92e633a 100644 --- a/articles/appliance/infrastructure/infrastructure-overview.md +++ b/articles/appliance/infrastructure/infrastructure-overview.md @@ -1,6 +1,13 @@ --- section: appliance description: PSaaS Appliance infrastructure overview +topics: + - appliance + - infrastructure +contentType: concept +useCase: appliance +applianceId: appliance35 +sitemap: false --- # PSaaS Appliance Deployment Architecture diff --git a/articles/appliance/infrastructure/installation.md b/articles/appliance/infrastructure/installation.md index 36c641b829..4197c25fc8 100644 --- a/articles/appliance/infrastructure/installation.md +++ b/articles/appliance/infrastructure/installation.md @@ -1,6 +1,16 @@ --- section: appliance description: PSaaS Appliance infrastructure information about installation +topics: + - appliance + - infrastructure + - installation +contentType: + - concept + - how-to +useCase: appliance +applianceId: appliance36 +sitemap: false --- @@ -42,11 +52,10 @@ Auth0 provides a project plan methodology to help customers get up and running w 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. Complete and submit the [Pre-PSaaS Appliance Installation Checklist](https://docs.google.com/forms/d/e/1FAIpQLSckWRi2MWpzhBkUXoqjaEzMPGUsyL4ICbOetcGvSnn64dSM-A/viewform?c=0&w=1) to ensure that you have everything you need ready and on hand for the PSaaS Appliance deployment; -3. Access and install the PSaaS Appliance; -4. Complete and submit the Post-PSaaS Appliance Install Checklist to notify Auth0 that you have everything in place and that Auth0 can commence configuring the PSaaS Appliance; -5. Complete the steps detailed in the PSaaS Appliance Setup Guide. +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 diff --git a/articles/appliance/infrastructure/internet-restricted-deployment.md b/articles/appliance/infrastructure/internet-restricted-deployment.md index 0823f734c7..352e6b0e36 100644 --- a/articles/appliance/infrastructure/internet-restricted-deployment.md +++ b/articles/appliance/infrastructure/internet-restricted-deployment.md @@ -1,8 +1,12 @@ --- 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 Appliace Deployments with Limited Internet Connectivity +# PSaaS Appliance Deployments with Limited Internet Connectivity The Auth0 PSaaS Appliance is delivered as a managed service that can run in: @@ -14,7 +18,7 @@ The PSaaS Appliance is designed to mirror the solutions offered via the Auth0 Pu ## 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). +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). @@ -22,29 +26,41 @@ The PSaaS Appliance **must** have access to the internet during [update periods] Operating the PSaaS Appliance in an internet-restricted environment results in the loss of the following features/functionality: -* Management Dashboard +* Analytics (including usage statistics) +* Authentication API Explorer +* [Extensions](/extensions) +* [Hooks](/hooks) * Lock * Management API Explorer -* Authentication API Explorer +* Management Dashboard * Quickstarts * Social Connections -* Analytics (including usage statistics) ### 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**). +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 +* **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. \ No newline at end of file +Currently, there are no plans to reduce the reliance of the PSaaS Appliance on the Auth0 CDN. diff --git a/articles/appliance/infrastructure/ip-domain-port-list.md b/articles/appliance/infrastructure/ip-domain-port-list.md index 2499ee38f2..d81d3d2a2f 100644 --- a/articles/appliance/infrastructure/ip-domain-port-list.md +++ b/articles/appliance/infrastructure/ip-domain-port-list.md @@ -1,11 +1,21 @@ --- 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: IP/Domain and Port List +# 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. @@ -124,7 +134,7 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro Updates Outbound apt-mirror.it.auth0.com (52.8.153.197) - 80/443 + 443 Provides update packages for PSaaS Appliance instances Yes @@ -137,11 +147,11 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro Yes - Web extensions and Management Dashboard + Web extensions, Hooks, and Management Dashboard Outbound cdn.auth0.com 443 - Required to run web extensions; also required for admins to browse to the Management Dashboard + Required to run web extensions and Hooks; also required for admins to browse to the Management Dashboard Yes @@ -184,6 +194,14 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro Required by the PSaaS Appliance to resolve host names internal and external to your environment Yes + + SMTP + Outbound + SMTP Server(s) + 25/587 + Allows sending of emails from the Appliance + No + diff --git a/articles/appliance/infrastructure/network.md b/articles/appliance/infrastructure/network.md index 6185221b20..d197ad2191 100644 --- a/articles/appliance/infrastructure/network.md +++ b/articles/appliance/infrastructure/network.md @@ -1,6 +1,14 @@ --- 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 diff --git a/articles/appliance/infrastructure/security.md b/articles/appliance/infrastructure/security.md index 88691636f4..adc6c39577 100644 --- a/articles/appliance/infrastructure/security.md +++ b/articles/appliance/infrastructure/security.md @@ -1,6 +1,14 @@ --- 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 @@ -9,7 +17,12 @@ description: PSaaS Appliance infrastructure information about security ## SSL Certificates -You need to create and install a unique SSL certificate for each PSaaS Appliance (such as your production cluster, your development node, or your QA environment). You need additional certificates if your environments require [extensions](/extensions) or you use [custom domains](/appliance/custom-domains). If you are using extensions, please see [Webtask with Dedicated Domains](/appliance/webtasks/dedicated-domains). +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. @@ -17,8 +30,8 @@ You need to create and install a unique SSL certificate for each PSaaS Appliance The SSL Certificate: -* must be created by a public certificate authority. They cannot be self-signed. -* may be a wildcard *or* a multi-domain (SAN) 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; @@ -44,6 +57,14 @@ 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: @@ -53,11 +74,11 @@ If you are behind a transparent proxy, you will need to: ## 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 at the PSaaS Appliance. In both cases your SSL/TLS certificate must be locally installed on the PSaaS Appliance. +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 in order for the PSaaS Appliance to send emails. The PSaaS Appliance requires an authentication SMTP server that has been configured with SMTP PLAIN authentication. +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. @@ -71,8 +92,8 @@ Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS A ### Initial Configuration -Auth0's remote access method for initial configuration requires SSH access via Jumphost (the preferred method) or via VPN. After the initial configuration, please feel free to disable this connection. +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. In the event that 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 (the preferred method) or over VPN. This connection may be enabled for and disabled after the agreed-upon time frames for work. +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/articles/appliance/infrastructure/virtual-machines.md b/articles/appliance/infrastructure/virtual-machines.md index 5095b5367e..45851327f6 100644 --- a/articles/appliance/infrastructure/virtual-machines.md +++ b/articles/appliance/infrastructure/virtual-machines.md @@ -1,15 +1,19 @@ --- 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 the following PSaaS Appliance usage on the following virtualization environments: - -* Amazon Web Services (AWS); -* Microsoft Azure; -* VMware. +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 @@ -19,8 +23,8 @@ Auth0 provides the PSaaS Appliance via a Virtual Machine Template for you to pro 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 (16 GB RAM minimum); -* **CPU**: 8 vCPU (4 vCPU minimum); +* **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*: @@ -37,7 +41,7 @@ For multi-node clusters, Auth0 recommends deploying the PSaaS Appliance virtual ## For AWS Users -* The *recommended* [instance type](https://aws.amazon.com/ec2/instance-types/) is **M4.2xlarge** (M4.xlarge minimum). +* 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. diff --git a/articles/appliance/instrumentation.md b/articles/appliance/instrumentation.md new file mode 100644 index 0000000000..1aea21eb0a --- /dev/null +++ b/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/articles/appliance/instrumentation/add-grafana-users.md b/articles/appliance/instrumentation/add-grafana-users.md deleted file mode 100644 index 036bb40a0d..0000000000 --- a/articles/appliance/instrumentation/add-grafana-users.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -section: appliance -description: This document covers how to add new users to Grafana. ---- - -# PSaaS Appliance: Adding Users to Grafana - - -By default, each Grafana instance (every PSaaS Appliance node comes with its own instance of Grafana) includes the following users: - -* `admin` -* `root@auth0.com` - -To visualize the instrumentation page with an PSaaS Appliance administrative user *other* than `root@auth0.com`, you will need to add that user to the Grafana instances for **each** PSaaS Appliance node. - -1. Navigate to the PSaaS Appliance node's instance of Grafana (`https://.com/grafana/`), and log in using a set of valid credentials. -2. Click the **Grafana icon** located in the top left corner. Select **Admin** and then **Global Users**. - - ![Grafana Admin Menu](/media/articles/appliance/instrumentation/grafana-users-1.png) - -3. To add the user, click **+ Add new user**. - - ![Grafana Add New User Button](/media/articles/appliance/instrumentation/grafana-users-2.png) - -3. Add the user's *email address* to the **Name**, **Email**, and **Username** fields, and set the user's password. This can be any complex password of the user's choosing. Note that the user will have to enter their password only if they try to access Grafana using Basic Authentication. If the user logs in using OAuth, Grafana will select the user based on the provided email address. - - ![Grafana Add New User Screen](/media/articles/appliance/instrumentation/grafana-users-3.png) - - You can use one of two authentication methods with Grafana: - - ::: panel Grafana Authentication - * **Basic Authentication**: used by configuration scripts launched by Puppet - * **OAuth Authentication**: used by when pages when users either: - * Visualize the instrumentation page; - * Navigate to Grafana's website. - ::: - -4. Click **Create**. You will now see the user reflected in the *Users* list. - - ![Grafana Users List](/media/articles/appliance/instrumentation/grafana-users-4.png) diff --git a/articles/appliance/instrumentation/available-metrics.md b/articles/appliance/instrumentation/available-metrics.md deleted file mode 100644 index 3315b0d908..0000000000 --- a/articles/appliance/instrumentation/available-metrics.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -section: appliance -description: This document covers the metrics available when using Instrumentation. ---- - -# PSaaS Appliance: Metrics Available via Instrumentation - -The following metrics are available to you when Instrumentation is enabled on your PSaaS Appliance: - -## Metrics Regarding PSaaS Appliance Infrastructure - -* [CPU](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/CPU_README.md) -* [Disk](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/DISK_README.md) -* [Disk I/O](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/DISK_README.md) -* [Memory](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/MEM_README.md) -* [Processes](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/PROCESSES_README.md) -* [Swap](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/MEM_README.md) -* [System](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/SYSTEM_README.md) -* [MongoDB](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/mongodb/README.md) -* [Net](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/system/net.go) -* [NGINX](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/nginx/README.md) -* [RabbitMQ](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/rabbitmq) -* [Procstat](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/procstat/README.md) - -## Metrics Regarding PSaaS Appliance Processes - -* auth0-api2_http_requests_authenticated -* auth0-api2_http_requests_received -* auth0-api2_http_requests_replied -* auth0-api2_http_response_time -* auth0-import-users-worker_event-loop_blocked -* auth0-import-users-worker_resources_cpu_usage -* auth0-import-users-worker_resources_memory_heapTotal -* auth0-import-users-worker_resources_memory_heapUsed -* auth0-import-users-worker_resources_memory_usage -* auth0-notifications_event-loop_blocked -* auth0-notifications_resources_cpu_usage -* auth0-notifications_resources_memory_heapTotal -* auth0-notifications_resources_memory_heapUsed -* auth0-notifications_resources_memory_usage -* auth0-server_auth_step_time -* auth0-server_clients_findByTenantAndClientId -* auth0-server_connections_getByName -* auth0-server_http_requests_received -* auth0-server_http_requests_replied -* auth0-server_http_response_time -* auth0-server_tenants_get -* auth0-users_bootup_time -* auth0-users_http_requests_received -* auth0-users_http_requests_replied -* auth0-users_http_requests_size -* auth0-users_http_response_time diff --git a/articles/appliance/instrumentation/components.md b/articles/appliance/instrumentation/components.md deleted file mode 100644 index 4762ae3b9f..0000000000 --- a/articles/appliance/instrumentation/components.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -section: appliance -description: This document covers the software used for Instrumentation. ---- - -# PSaaS Appliance: Instrumentation Components - -The following applications are used to implement Instrumentation within the PSaaS Appliance: - -* [Grafana](http://grafana.org/): tools for time series and metrics visualization -* [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/): time series database used to store/query collected data -* [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/): tools for gathering data from the PSaaS Appliance diff --git a/articles/appliance/instrumentation/index.md b/articles/appliance/instrumentation/index.md deleted file mode 100644 index 822d009713..0000000000 --- a/articles/appliance/instrumentation/index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -url: /appliance/instrumentation -section: appliance -description: This document covers why and how to enable instrumentation in the PSaaS Appliance. ---- - -# Private SaaS (PSaaS) Appliance: Instrumentation - -The PSaaS Appliance ships with a feature called Instrumentation, which makes it easy for your PSaaS Appliance administrators or Auth0 Customer Success Engineers to gather information about the current (or previous) state of the PSaaS Appliance. With Instrumentation, you are collecting time series data about the overall PSaaS Appliance, as well as individual processes. You can then query or visualize this data to draw conclusions about the state of your PSaaS Appliance. - -::: note -Please contact your Auth0 Customer Success Manager if you would like to enable Instrumentation for your PSaaS Appliance (please note that this feature is not available for PSaaS Appliances hosted by Auth0). -::: - -* [Software Components Utilized](/appliance/instrumentation/components) -* [Available Metrics](/appliance/instrumentation/available-metrics) -* [Access Your Data](/appliance/instrumentation/access-data) -* [Visualize Your Data](/appliance/instrumentation/visualize-data) -* [Add Users in Grafana](/appliance/instrumentation/add-grafana-users) diff --git a/articles/appliance/instrumentation/visualize-data.md b/articles/appliance/instrumentation/visualize-data.md deleted file mode 100644 index d4ed8da02a..0000000000 --- a/articles/appliance/instrumentation/visualize-data.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: appliance -description: This document covers how to visualize data gathered via Instrumentation. ---- - -# PSaaS Appliance: How to Visualize Your Data - -Once you have enabled Instrumentation, you can access your data in one of two places: - -* PSaaS Appliance Dashboard -* Grafana - -## View Your Data in the PSaaS Appliance Dashboard - -If you would like to see your data in the Appliance Dashboard, navigate to `https:///configuration#/instrumentation` to access the graphs created from the data collected from your PSaaS Appliance instances. - -![PSaaS Appliance Instrumentation Dashboard](/media/articles/appliance/instrumentation/general-data.png) - -## Access Your Data Directly from Grafana - -Each PSaaS Appliance node has its own instances of Grafana, InfluxDB, and Telegraph. To access a given node's Grafana instance: - -1. Obtain the node's private IP address -2. Using the private IP address, navigate to `https://.com/grafana/` - -### Add Grafana Dashboards to the Instrumentation Page in the PSaaS Appliance Dashboard - -If you need to view relationships between datasets that have yet to be graphed, you can create new (or update existing) Grafana Dashboards displayed on the PSaaS Appliance Dashboard's Instrumentation page. To create new Grafana dashboards, please view [this video](https://www.youtube.com/watch?v=sKNZMtoSHN4&index=7&list=PLDGkOdUX1Ujo3wHw9-z5Vo12YLqXRjzg2). - -Once you have created your Grafana dashboards, tag them as `instrumentation` so that they appear on the Instrumentation page. To do this: - -1. Navigate to the Grafana dashboard's *Settings > General* page. -2. Add a tag to the appropriate Grafana dashboard called `instrumentation`. - -![Grafana Dashboard Settings Screen](/media/articles/appliance/instrumentation/tag-dashboard.png) diff --git a/articles/appliance/modules.md b/articles/appliance/modules.md index 7c3b86f186..494289c92f 100644 --- a/articles/appliance/modules.md +++ b/articles/appliance/modules.md @@ -1,48 +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, 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. - -The latest version of the PSaaS Appliance supports the use of three different modes: -* Webtask - This model has the same functionality as the Auth0 cloud version. It provides a balance between performance and isolation, supports a greater number of node modules, and is the recommended model for most customers; -* In process - This model executes within the Node.js process of the Auth0 service. This provides the best raw performance. The model provides no isolation between custom code and the Auth0 service, and supports only the limited set of modules listed below. The recommended approach for high scale is to allocate additional resources and use the Webtask model. In some very demanding conditions where isolation is not a concern, this model may be considered; -* Out-of-process - This is the original model that provides high isolation. It has significantly higher performance overhead compared to the other two models and supports the limited set of modules listed below. +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: -* [async](https://github.com/caolan/async) _(~0.9.0)_ -* [auth0](https://github.com/auth0/node-auth0) _(2.0.0-alpha.5)_ -* [azure_storage](https://github.com/Azure/azure-storage-node) _(~0.4.1)_ -* [bcrypt](https://github.com/ncb000gt/node.bcrypt.js) _(~0.8.3)_ -* [Buffer](http://nodejs.org/docs/v0.10.24/api/buffer.html) -* [couchbase](https://github.com/couchbase/couchnode) _(~1.2.1)_ -* [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.0.1)_ -* [jwt](https://github.com/auth0/node-jsonwebtoken) _(~0.4.1)_ -* [knex](http://knexjs.org) _(~0.6.3)_ - * The function returned by `require('knex')` is available as `Knex`. -* [lodash](https://github.com/lodash/lodash) _(~2.4.1)_ -* [mongo](https://github.com/mongodb/node-mongodb-native) _(~1.3.15)_ - * [BSON](http://mongodb.github.io/node-mongodb-native/api-bson-generated/bson.html) - * [Double](http://mongodb.github.io/node-mongodb-native/api-bson-generated/double.html) - * [Long](http://mongodb.github.io/node-mongodb-native/api-bson-generated/long.html) - * [ObjectID](http://mongodb.github.io/node-mongodb-native/api-bson-generated/objectid.html) - * [Timestamp](http://mongodb.github.io/node-mongodb-native/api-bson-generated/timestamp.html) -* [mysql](https://github.com/felixge/node-mysql) _(~2.0.0-alpha8)_ -* [pbkdf2](https://github.com/davidmurdoch/easy-pbkdf2) _(0.0.2)_ -* [pg](https://github.com/brianc/node-postgres) _(4.1.1)_ -* [pubnub](https://github.com/pubnub/javascript/tree/master/node.js) _(3.7.0)_ -* [q](https://github.com/kriskowal/q) _(~1.0.1)_ -* [querystring](http://nodejs.org/api/querystring.html) _(0.10.28)_ -* [request](https://github.com/mikeal/request) _(~2.27.0)_ -* [sqlserver](https://github.com/pekim/tedious) _(~0.1.4)_ -* [uuid](https://github.com/broofa/node-uuid) _(~2.0.1)_ -* [xml2js](https://github.com/Leonidas-from-XIV/node-xml2js) _(~0.2.8)_ -* [xmldom](https://github.com/jindw/xmldom) _(~0.1.13)_ -* [xpath](https://github.com/goto100/xpath) _(0.0.5)_ -* [xtend](https://github.com/Raynos/xtend) _(~1.0.3)_ +| 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/articles/appliance/monitoring/authenticated-endpoints.md b/articles/appliance/monitoring/authenticated-endpoints.md index 5a956f236a..50fa8bc069 100644 --- a/articles/appliance/monitoring/authenticated-endpoints.md +++ b/articles/appliance/monitoring/authenticated-endpoints.md @@ -1,69 +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: Using Authenticated Testing Endpoints +# PSaaS Appliance: Authenticated Testing Endpoints -For calls to the testing endpoints that return detailed information, Auth0 requires these requests to be authenticated using a key generated using the PSaaS Appliance Dashboard. This key is used in the request header of the call sent to the endpoint. +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. -## Generating the API Key +The authenticated endpoints are similar to the Test All endpoints in that both return positive or negative status information about system resources. -To generate an API Key for use the authenticated testing endpoints, navigate to the [Settings](/appliance/dashboard/settings) page of your PSaaS Appliance Dashboard. There, you will find an [API Keys section](/appliance/dashboard/settings#api-keys) that allows you to generate new keys. +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. -During the first use, you will see a that there is no key. To generate your first key, click on the "Generate" button at the far right of the row. +## 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. If confirmed, you will see that the key now populates the previously-blank field. +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 key at a time. If you generate a new key, all applications and services using the old key will fail. +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. ::: -## Available Endpoints +## Authenticated API Endpoints + +The API exposes a number of endpoints that you can use to test the status of the service. -The following authenticated endpoints are available for you to use: +**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. -* GET /status/cpu -* GET /status/memory -* GET /status/disk -* GET /status/services -* GET /status/network -* GET /status/internet -* GET /status/email -* GET /status/db -* GET /status/replicaset +There are two ways you can call a specific API endpoint: -Your call might look something like the following: +* 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 http://127.0.0.1:9110/status/cpu ---user api_keys_health:YOUR_API_KEY +curl -v https://{node-ip}/health/status/cpu --user api_keys_health:YOUR_API_KEY ``` -You may also make the call via https, though you will have to make the following modifications to your call: - * Add "health" to the URL path; - * Remove the port number from the IP address used. +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 -For example, `http://10.1.0.248:9110/status/cpu` becomes `https://10.1.0.248/health/status/cpu`. +This endpoint checks to see if any of the node's core Auth0 services are down. -## Access from Outside the PSaaS Appliance +| 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. | -If you'd like to access these endpoints from outside the PSaaS Appliance, you can do so using your `manage` domain. +#### GET /status/internet -| Internal Access | External Access | -| --------------- | --------------- | -| http://10.1.0.248:9110/status/cpu **or** https://10.1.0.248/health/status/cpu | ${manage_url}/health/status/cpu | +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. | -## Endpoint Responses +#### GET /status/replicaset -Calls to authenticated endpoints will return in one of the following status codes: +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 | There are no issues with the resource. | -| 429 | Too many requests have been made to the resource. | -| 520 | There is an issue with the resource. | +| 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/articles/appliance/monitoring/index.md b/articles/appliance/monitoring/index.md index 3d3fc5937f..a7f8f588d9 100644 --- a/articles/appliance/monitoring/index.md +++ b/articles/appliance/monitoring/index.md @@ -2,17 +2,76 @@ 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 -In addition to providing tools for monitoring your PSaaS Appliance, Auth0 provides integration with select third-party utilities. +The PSaaS Appliance is a managed service, which means that Auth0 is responsible for: -Your options include: +* Installation +* Updates +* General maintenance tasks -* **Instrumentation**: If [Instrumentation](/appliance/instrumentation) has been enabled for your PSaaS Appliance instances, you can gather and visualize data about your infrastructure and processes - * If you've enabled Instrumentation, you can send your data to DataDog. You'll need to supply your DataDog API key in the configuration page to do this. When viewing your metrics in DataDog, it will *not* appear in the standard DataDog UI under Infrastructure. You'll need to add your own dashboard and search for the PSaaS Appliance data you want displayed. -* **Health Checks**: [Health Checks](/appliance/dashboard/troubleshoot#health-check) provide minute-by-minute summaries of your PSaaS Appliance infrastructure at a given point in time. These logs are available for the the previous twenty-nine days and can be found in the [Troubleshoot](/appliance/dashboard/troubleshoot) page of your PSaaS Appliance Configuration Area; -* **[Auth0's `testall` Endpoint](/appliance/monitoring/testall)**: The `testall` endpoint is an unauthenticated endpoint that is particularly useful for monitoring by load balancers; -* **[Auth0's Authenticated Testing Endpoints](/appliance/monitoring/authenticated-endpoints)**: Auth0 provides endpoints that you may, once authenticated, call to receive status codes such as *204*, *520*, or *429*; -* **Integration with Third-Party Utilities to Monitor Synthetic Transactions**: Auth0 supports integration with system monitoring tools like *Microsoft System Center* so that you can [run and monitor synthetic transactions](/monitoring#configuring-scom). \ No newline at end of file +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/articles/appliance/monitoring/testall.md b/articles/appliance/monitoring/testall.md index e3e3b76298..442f42ee39 100644 --- a/articles/appliance/monitoring/testall.md +++ b/articles/appliance/monitoring/testall.md @@ -1,6 +1,14 @@ --- 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 @@ -25,9 +33,11 @@ Alternatively, if there are any issues, `/testall` returns a `5xx` response code 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: -* `https://{IP Address Node 1}/testall` -* `https://{IP Address Node 2}/testall` -* `https://{IP Address Node 3}/testall` +* `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 diff --git a/articles/appliance/private-cloud-requirements.md b/articles/appliance/private-cloud-requirements.md index 3814ccf858..58a4f080df 100644 --- a/articles/appliance/private-cloud-requirements.md +++ b/articles/appliance/private-cloud-requirements.md @@ -2,6 +2,14 @@ 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 @@ -70,7 +78,7 @@ The Management Dashboard, Webtask, and App Tenant(s) **must** be a part of the s 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. +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. diff --git a/articles/appliance/raci.md b/articles/appliance/raci.md index e283148842..4d86c2fe93 100644 --- a/articles/appliance/raci.md +++ b/articles/appliance/raci.md @@ -1,6 +1,13 @@ --- 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 @@ -36,14 +43,14 @@ The following RACI Matrix provides a more in-depth summary of the roles and resp |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 Customer Success Engineer|I|The Auth0 Customer Success Engineer will SSH into the VMs and deploy the Appliance.| -|Configuration of Development and Production environments|C|R|The Auth0 CSE 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 Customer Success Engineers will provide a 90-minute Operations Handover meeting to review information regarding PSaaS Appliance monitoring, backup, and updates, as well as answer questions.| +|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 Customer Success 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.| +|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.| diff --git a/articles/appliance/remote-access-options.md b/articles/appliance/remote-access-options.md index 6b0e8b96c5..586fd59a1f 100644 --- a/articles/appliance/remote-access-options.md +++ b/articles/appliance/remote-access-options.md @@ -1,6 +1,13 @@ --- 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 @@ -43,25 +50,7 @@ Similar to option 1, this configuration permits an external Auth0 Jumphost to co * Additional virtual Jumphost required in customer infrastructure -### Option 3: VPN - -This configuration provides VPN access to the customer’s network either to Auth0 engineers individually or a dedicated, Jumphost-like Auth0 server. - -![](/media/articles/appliance/remote-access/vpn.png) - -*Pros*: - -* Customers usually have VPN infrastructure in place -* No additional servers are required -* Auth0 access can be enabled and disabled using existing VPN account procedures - -*Cons*: - -* Inability to audit management activity on the command line -* Customer responsible for provisioning VPN accounts for Auth0 engineers and Identity Management -* Customer responsible for securing VPN traffic only to PSaaS appliance -* Customer is responsible for VPN availability (critical to allow access during support events) ### 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. \ No newline at end of file +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/articles/appliance/webtasks/dedicated-domains.md b/articles/appliance/webtasks/dedicated-domains.md index 60008d3540..11bbe60ff3 100644 --- a/articles/appliance/webtasks/dedicated-domains.md +++ b/articles/appliance/webtasks/dedicated-domains.md @@ -3,15 +3,24 @@ 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 -Some extensions, such as the [Authorization Extension](/extensions/authorization-extension/v2), required us to enable full trust in your PSaaS environment to run correctly. - -Beginning with PSaaS Appliance version `13451`, you may now configure Webtask on a dedicated domain. This enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service). +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 do not use Webtask or [Extensions](/appliance/extensions), you do not need to implement Webtask dedicated domains. +If you are planning on using [Extensions](/appliance/extensions), you must implement Webtask dedicated domains. ::: ## Background @@ -81,7 +90,7 @@ No. Because the tenant name is used in the first part of the domains for the Aut **Do I have to enable Webtask Dedicated Domains?** -Yes, if you are planning to use extensions. If you are not planning on using extensions, you do not have to enable 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?** diff --git a/articles/appliance/webtasks/index.md b/articles/appliance/webtasks/index.md index 7260e6488c..c390c9c027 100644 --- a/articles/appliance/webtasks/index.md +++ b/articles/appliance/webtasks/index.md @@ -1,6 +1,15 @@ --- 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 @@ -14,23 +23,7 @@ Prior to working with Webtasks, please ensure that you have configured the: * [Webtask Command Line Interface (`wt-cli`)](https://webtask.io/docs/101) ::: -## Sandboxes - -Auth0 provides different stages (which are known as sandboxes) on which you may run your rules and custom database logic: - -* `node_sandbox` (default): while more secure than `eval`, `node_sandbox` is more resource intensive; -* `eval`: provides the best performance, but is the least secure of the three available modes; -* `auth0-sandbox`: provides better performance that `node_sandbox`, improved isolation over `eval`, and offers a greater number of Node.js modules for use with your custom code. - -::: note -Only one sandbox mode may be selected at any given time (for example, you may not run selected rules in one sandbox and other rules in another sandbox). If you would like to change the sandbox mode, please discuss this with your Auth0 Customer Success Engineer. -::: - -## Code Compatibility - -Code that you have written for use with `node-sandbox` or `eval` will work in `auth0-sandbox`. However, code that is written for `auth0-sandbox` may not be compatible with `node-sandbox` or `eval`, especially if your code uses modules. - -The `auth0-sandbox` is the recommended method for running your custom code. +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 @@ -38,11 +31,13 @@ You may use Webtasks by calling its endpoints directly. This can be done using t ### Node.js Modules -Currently, not all of the [Node.js modules available for the Auth0 Cloud Environment](https://tehsis.github.io/webtaskio-canirequire/) are available for the PSaaS Appliance. +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/tehsis/webtaskio-canirequire/blob/gh-pages/tasks/list_modules.js) using the appropriate sandbox on your PSaaS Appliance instance. +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. -First, copy locally the [`List Modules` Webtask](https://github.com/tehsis/webtaskio-canirequire/blob/gh-pages/tasks/list_modules.js), either by downloading the file or by copying this code: +#### 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'; @@ -88,13 +83,13 @@ module.exports = cb => { }; ``` -Afterwards, create a webtask profile using `wt-cli`, if you don't already have one. +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" ``` -Now you are ready to register your webtask, using the `wt create` command. This command receives as input a path or URL of the webtasks's code and provides as output the URL where the webtask is available. +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: @@ -102,8 +97,7 @@ If you saved the file under a `my-webtasks` directory as `list_modules.js` you w 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. - +You should get a message that the Webtask was created, alongside with the URL to access it. The response is a JSON object. ```json { diff --git a/articles/application-auth/current/client-side-web.md b/articles/application-auth/current/client-side-web.md index 94be5c6b0e..8d504faa5c 100644 --- a/articles/application-auth/current/client-side-web.md +++ b/articles/application-auth/current/client-side-web.md @@ -2,15 +2,25 @@ 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 -The Auth0 OAuth 2.0 authentication endpoints support Client-side Web Applications. These applications are also referred to as JavaScript or Single Page Applications. +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 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 an [ID Token](/tokens/id-token) and [Access Token](/tokens/access-token) in the hash fragment of the request. +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 @@ -18,12 +28,12 @@ The OAuth 2.0 Authorization Framework allows for different kinds of authorizatio 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/id-token) as parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier). The [ID Token](/tokens/id-token) is a [JSON Web Token (JWT)](/jwt) and contains various attributes (referred to as Claims) regarding the user, such as the user's name, email address, profile picture and so on. +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/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. +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. +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) ::: @@ -32,22 +42,22 @@ For more information on calling APIs from Client-side Web Apps, please see [Call 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 +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 applications in Auth0. An Auth0 applications maps to your application and allows it to use Auth0 for authentication. +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 [Applicationss](${manage_url}/#/applicationss) menu option on the left. Create a new Application by clicking on the **Create Applications** button. +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. +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 applications 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`. +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. +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) @@ -59,17 +69,17 @@ 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 SSO session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. +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`.) | +| 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/id-token). To obtain an [ID Token](/tokens/id-token) 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). | +| 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. | +| 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.** | @@ -79,19 +89,19 @@ This endpoint supports the following query string parameters: ## 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/id-token) in the hash fragment of the URL, such as +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/id-token) will be a [JSON Web Token (JWT)](/jwt) 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`. +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/id-token) in order to read the claims (or attributes) of the user. The [JWT section of our website](/jwt) contains more information about the structure of a JWT. +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/id-token). This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. +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: +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 @@ -128,7 +138,7 @@ The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you if (authResult && authResult.idTokenPayload) { window.location.hash = ''; alert('your user_id is: ' + authResult.idTokenPayload.sub); - } + } }); } @@ -141,7 +151,7 @@ The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you ### The ID Token payload -An example payload for an [ID Token](/tokens/id-token) may look something like this: +An example payload for an [ID Token](/tokens/concepts/id-tokens) may look something like this: ```json { @@ -165,13 +175,13 @@ The payload above contains the following claims: | 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/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](/tokens/id-token), 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** | +| 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/id-token) will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an [ID Token](/tokens/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. +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. @@ -179,7 +189,7 @@ The [JWT.io website](https://jwt.io) has a handy debugger which will allow you t ### 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/id-token). +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. @@ -204,7 +214,7 @@ ${account.callback} #id_token=eyJ0... ``` -And this is an example of the decoded payload of the [ID Token](/tokens/id-token) which will be returned: +And this is an example of the decoded payload of the [ID Token](/tokens/concepts/id-tokens) which will be returned: ```json { @@ -237,7 +247,7 @@ ${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/id-token): +The name and profile picture will be available in the `name` and `picture` claims of the returned [ID Token](/tokens/concepts/id-tokens): ```json { @@ -279,7 +289,7 @@ ${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/id-token). You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: +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 { diff --git a/articles/application-auth/current/index.md b/articles/application-auth/current/index.md index b332be79b6..685c9b3586 100644 --- a/articles/application-auth/current/index.md +++ b/articles/application-auth/current/index.md @@ -1,17 +1,35 @@ --- classes: topic-page title: Application Authentication -description: Introduction to the various application authentication flows. +description: Introduction to authentication and the various application authentication flows. +topics: + - authentication + - oauth2 +contentType: index +useCase: + - add-login --- -# Application Authentication +# 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. +Authentication refers to the process of confirming identity. While often used interchangeably with [authorization](/authorization), authentication represents a fundamentally different function. -You can get more details on implementing these flows by following one of the following links: +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: [ - 'application-auth/current/mobile-desktop', - 'application-auth/current/server-side-web', - 'application-auth/current/client-side-web' + '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/articles/application-auth/current/mobile-desktop.md b/articles/application-auth/current/mobile-desktop.md index 57847be51b..183b936bb5 100644 --- a/articles/application-auth/current/mobile-desktop.md +++ b/articles/application-auth/current/mobile-desktop.md @@ -2,6 +2,16 @@ 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 @@ -11,7 +21,7 @@ You can authenticate users of your mobile/desktop applications by: * 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 process. +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: @@ -26,15 +36,17 @@ If you would like to implement this functionality using either Lock or one of th ## Overview -Auth0 exposes OAuth 2.0 endpoints that you can use to authenticate users. You can call these endpoints through an embedded browser in your **native** application. After authentication completes, you can return an [ID Token](/tokens/id-token) that contains the user's profile information. +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. These 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. +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 +## 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. +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**. @@ -71,7 +83,7 @@ Once you've created the `code_verifier` and the `code_challenge`, you'll need to * Authenticating the user; * Redirecting the user to an Identity Provider to handle authentication; -* Checking for active SSO sessions. +* 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: @@ -121,11 +133,32 @@ Using the authorization code obtained in step 2, you can obtain the ID Token by "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"code_verifier\": \"YOUR_GENERATED_CODE_VERIFIER\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"https://${account.namespace}/mobile\" }" + "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" + } + ] } } ``` @@ -145,7 +178,7 @@ If all goes well, you'll receive an HTTP 200 response with the following payload ``` ::: note -You can use the `access_token` to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info). +You can use the Access Token to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info). ::: ## The ID Token @@ -165,7 +198,7 @@ Once you've decoded the ID Token, you can extract user information from it. The } ``` -For additional details, please see our docs [on the ID Token and its claims](/tokens/id-token#id-token-payload). +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). @@ -202,11 +235,32 @@ Using the authorization code, you can obtain the ID Token by making a `POST` cal "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"code_verifier\": \"YOUR_GENERATED_CODE_VERIFIER\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${account.namespace}/mobile\" }" + "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" + } + ] } } ``` @@ -223,7 +277,7 @@ If all goes well, you'll receive an HTTP 200 response with the following payload } ``` -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: +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 { @@ -272,11 +326,32 @@ Using the authorization code, you can obtain the ID Token by making a `POST` cal "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"code_verifier\": \"YOUR_GENERATED_CODE_VERIFIER\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${account.namespace}/mobile\" }" + "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" + } + ] } } ``` @@ -293,7 +368,7 @@ If all goes well, you'll receive an `HTTP 200` response with the following paylo } ``` -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: +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 { diff --git a/articles/application-auth/current/server-side-web.md b/articles/application-auth/current/server-side-web.md index ca2980a9a2..026aa3dab9 100644 --- a/articles/application-auth/current/server-side-web.md +++ b/articles/application-auth/current/server-side-web.md @@ -2,15 +2,26 @@ 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 authorization to authenticate users. +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 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 `code` can then be exchanged for an [ID Token](/tokens/id-token) which contains the identity of the user. +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 @@ -18,12 +29,12 @@ The OAuth 2.0 Authorization Framework allows for different kinds of authorizatio 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/id-token) by making a request to the `/oauth/token` endpoint. +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)](/jwt) 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). +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/access-token) 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) +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) @@ -58,7 +69,7 @@ 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 SSO session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. +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: @@ -89,11 +100,32 @@ You application will need to handle the request to this callback URL, extract th "method": "POST", "url": "https://${account.namespace}/oauth/token", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${account.callback}\"}" + "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}" + } + ] } } ``` @@ -109,7 +141,7 @@ The response from `/oauth/token` contains `access_token`, `expires_in`, `id_toke } ``` -The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/jwt) 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](/jwt) contains more information about the structure of a JWT. +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. @@ -178,7 +210,7 @@ After the user has authenticated, they will be redirected back to the `redirect_ ${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: +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 { @@ -208,7 +240,7 @@ After the user has authenticated, they will be redirected back to the `redirect_ ${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`: +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 { diff --git a/articles/application-auth/legacy/client-side-web.md b/articles/application-auth/legacy/client-side-web.md index 31611ec17b..da677b5d3a 100644 --- a/articles/application-auth/legacy/client-side-web.md +++ b/articles/application-auth/legacy/client-side-web.md @@ -1,6 +1,16 @@ --- 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 @@ -8,11 +18,11 @@ toc: true 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. +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. +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 @@ -20,15 +30,15 @@ The OAuth 2.0 Authorization Framework allows for different kinds of authorizatio 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)](/jwt) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on. +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. +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 +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 @@ -37,19 +47,19 @@ The first thing you need to do is to create a new application in Auth0. An Auth0 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. +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. +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 SSO session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. +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: @@ -57,7 +67,7 @@ This endpoint supports the following query string parameters: |:------------------|:---------| | 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). | +| 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) | @@ -69,19 +79,19 @@ This endpoint supports the following query string parameters: ## 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 +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)](/jwt) 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`. +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](/jwt) contains more information about the structure of a JWT. +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. +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: +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: ``` @@ -108,9 +118,9 @@ The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you ``` -### The `id_token` Payload +### The ID Token Payload -An example payload for an `id_token` may look something like this: +An example payload for an ID Token may look something like this: ```json { @@ -133,12 +143,12 @@ The payload above contains the following claims: | 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** | +| 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. +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. @@ -146,7 +156,7 @@ The [JWT.io website](https://jwt.io) has a handy debugger which will allow you t ### 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`. +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. @@ -163,7 +173,7 @@ https://${account.namespace}/authorize &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: +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} @@ -171,7 +181,7 @@ ${account.callback} &token_type=Bearer ``` -And this is an example of the decoded payload of the `id_token` which will be returned: +And this is an example of the decoded payload of the ID Token which will be returned: ```json { @@ -195,7 +205,7 @@ https://${account.namespace}/authorize &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: +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} @@ -203,7 +213,7 @@ ${account.callback} &token_type=Bearer ``` -The name and profile picture will be available in the `name` and `picture` claims of the returned `id_token`: +The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: ```json { @@ -236,7 +246,7 @@ You can just as easily request a user log in with other social providers, like G - [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 ID Token and `token_type` passed as parameters in the hash fragment: ```text ${account.callback} @@ -244,7 +254,7 @@ ${account.callback} &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: +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 { diff --git a/articles/application-auth/legacy/index.md b/articles/application-auth/legacy/index.md index b36f669b6d..56a74c0a5b 100644 --- a/articles/application-auth/legacy/index.md +++ b/articles/application-auth/legacy/index.md @@ -2,6 +2,12 @@ classes: topic-page title: Application Authentication description: Introduction to the various application authentication flows. +topics: + - authentication + - oauth2 +contentType: index +useCase: + - add-login --- # Application Authentication diff --git a/articles/application-auth/legacy/mobile-desktop.md b/articles/application-auth/legacy/mobile-desktop.md index bb9bb772bb..04b9497aee 100644 --- a/articles/application-auth/legacy/mobile-desktop.md +++ b/articles/application-auth/legacy/mobile-desktop.md @@ -1,6 +1,16 @@ --- -description: Explains how to authenticate users in a mobile or desktop application. +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 @@ -8,11 +18,11 @@ toc: true 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. +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. +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. @@ -22,15 +32,15 @@ The OAuth 2.0 Authorization Framework allows for different kinds of authorizatio 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)](/jwt) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on. +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. +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 +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 @@ -41,7 +51,7 @@ Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications] 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) +![](/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. @@ -49,7 +59,7 @@ Once the application has been created you can navigate to the **Settings** tab o ## 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 SSO session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. +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: @@ -57,7 +67,7 @@ This endpoint supports the following query string parameters: |:------------------|:---------| | 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). | +| 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) | @@ -74,17 +84,17 @@ After the user has authenticated, Auth0 will call back to the URL specified in t 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)](/jwt) 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. +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](/jwt) contains more information about the structure of a JWT. +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`. +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. +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 +### The ID Token Payload -An example payload for an `id_token` may look something like this: +An example payload for an ID Token may look something like this: ```json { @@ -107,12 +117,12 @@ The payload above contains the following claims: | 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** | +| 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. +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. @@ -128,7 +138,7 @@ You can also use this object to store information about the user (such as name, ### 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. +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 @@ -145,7 +155,7 @@ https://${account.namespace}/mobile &token_type=Bearer ``` -And this is an example of the decoded payload of the `id_token` which will be returned: +And this is an example of the decoded payload of the ID Token which will be returned: ```json { @@ -159,7 +169,7 @@ And this is an example of the decoded payload of the `id_token` which will be re ### Request the Name and Profile Picture -You can request a user's name and profile picture by requesting the `name` and `picture` scopes. +You can request a user's name and profile picture by requesting the `name` and `picture` scopes. ```text https://${account.namespace}/authorize @@ -177,7 +187,7 @@ https://${account.namespace}/mobile &token_type=Bearer ``` -The name and profile picture will be available in the `name` and `picture` claims of the returned `id_token`: +The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: ```json { @@ -218,7 +228,7 @@ https://${account.namespace}/mobile &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: +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 { diff --git a/articles/application-auth/legacy/server-side-web.md b/articles/application-auth/legacy/server-side-web.md index 01c57db94b..5cb0b0ac58 100644 --- a/articles/application-auth/legacy/server-side-web.md +++ b/articles/application-auth/legacy/server-side-web.md @@ -2,6 +2,15 @@ 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 @@ -13,7 +22,7 @@ You can use the Auth0 Authentication API to create server-side web applications ## 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. +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 @@ -21,9 +30,9 @@ The OAuth 2.0 Authorization Framework allows for different kinds of authorizatio 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. +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)](/jwt) 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. +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) @@ -31,7 +40,7 @@ The `id_token` is a [JSON Web Token (JWT)](/jwt) and contains various attributes 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`. +5. The Authorization Server validates this information and returns an ID Token. ## Register your Application @@ -45,13 +54,13 @@ The **Create Application** window will open, allowing you to enter the name of y 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`. +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 SSO session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. +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: @@ -59,7 +68,7 @@ This endpoint supports the following query string parameters: |:------------------|:---------| | 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). | +| 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) | @@ -68,7 +77,7 @@ This endpoint supports the following query string parameters: 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}). ::: -## Exhange the `access_code` for an `id_token` +## 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 @@ -76,18 +85,39 @@ After the user has authenticated, Auth0 will call back to the URL specified in t ${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`: +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/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${account.callback}\"}" + "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}" + } + ] } } ``` @@ -102,15 +132,15 @@ The response from `/oauth/token` contains an `access_token`, `id_token` and `tok } ``` -The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/jwt) 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](/jwt) contains more information about the structure of a JWT. +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`. +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. +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 +### The ID Token Payload -An example payload for an `id_token` may look something like this: +An example payload for an ID Token may look something like this: ```json { @@ -133,12 +163,12 @@ The payload above contains the following claims: | 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** | +| 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. +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. @@ -146,7 +176,7 @@ The [JWT.io website](https://jwt.io) has a handy debugger which will allow you t ### 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`. +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. @@ -169,7 +199,7 @@ After the user has authenticated, they will be redirected back to the `redirect_ ${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: +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 { @@ -199,7 +229,7 @@ After the user has authenticated, they will be redirected back to the `redirect_ ${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`: +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 { @@ -232,7 +262,7 @@ You can just as easily request a user log in with other social providers, like G - [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 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: @@ -240,7 +270,7 @@ After the user has authenticated, they will be redirected back to the `redirect_ ${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: +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 { diff --git a/articles/applications/addons.md b/articles/applications/addons.md deleted file mode 100644 index e9a5612132..0000000000 --- a/articles/applications/addons.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: Explains what Add-ons are and how they are associated with Auth0 Applications. ---- - -# Application Add-ons - -Add-ons are plugins associated with an application in Auth0. Usually, they are third-party APIs used by the application(s) that Auth0 generates Access Tokens for (for example, Salesforce, Azure Service Bus, Azure Mobile Services, SAP and more). - -To view all the available add-ons for an application navigate to [Dashboard > Applications > Addons](${manage_url}/#/applications/${account.clientId}/addons). - -![Application Addons List](/media/articles/applications/addons-dashboard-list.png) - -Some typical scenarios for using add-ons include: - -* **Accessing External APIs**: Using the Delegation endpoint, you can exchange an application's Access Token for a third-party service's (such as Salesforce or Amazon) Access Token. - -* **Integrating with Applications Using SAML2/WS-Federation**: Add-ons allow you to integrate with any custom or SSO integration that does not currently enjoy built-in Auth0 support, since they allow you to configure every aspect of the SAML2/WS-Federation integration. - -![Addons Example Diagram](/media/articles/applications/applications-addon-types.png) diff --git a/articles/applications/application-grant-types.md b/articles/applications/application-grant-types.md deleted file mode 100644 index eda69f9382..0000000000 --- a/articles/applications/application-grant-types.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -description: Using the Grant Types property on Applications -toc: true ---- -# Application Grant Types - -Auth0 provides many different authentication and authorization flows to suit your needs. For example, if you are securing a mobile app, you'd use the [Authorization Code using Proof Key for Code Exchange (PKCE) OAuth 2.0 Grant](/api-auth/grant/authorization-code-pkce), or if you're securing a client-side app (such as a mobile app that's *not* native), you'd use the [Implicit Grant](api-auth/grant/implicit). - -However, you might want to limit the use of certain flows (which we'll refer to as "grant types" in this doc) depending on the type of app you're securing. You can set and manage these limitations using the `grant_types` property that each Client has. - -In this doc, we'll talk about: - -* What grant types are -* The grant types available -* How to set the Client's `grant_type` property -* What grant types are available based on the Client's `grant_type` property value - -## What Grant Types Are - -OAuth 2.0 is a protocol that allows you to grant limited access to your resources to another entity without exposing credentials. By using Auth0, you can support different OAuth 2.0 flows without worrying about the technical aspects/implementation. - -OAuth 2.0 supports several types of grants, which are methods by which you can gain Access Tokens (string values that represent the permissions granted). Different grant types allow different types of access, and based on the needs of your app, some grant types are more appropriate than others. Auth0 allows you to indicate which sets of permissions are appropriate based on the `grant_type` property. - -::: note -Not sure which non-legacy 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. -::: - -## Grant Types Available - -The following is a list of grant types valid for Auth0 Applications. The grant types can be divided into three different categories: - -* Grants that conform with specifications (such as [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)) -* [Auth0 extension grants](https://tools.ietf.org/html/rfc6749#section-4.5) -* Auth0 legacy grants - -The following `grant_types`, are either: - -* OIDC-conformant (that is, their implementation conforms to the [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html)) -* Auth0 extension grants - -| `grant_type` | More info | -|:-----|:----| -| `implicit` | [Implicit Grant](/api-auth/grant/implicit) | -| `authorization_code` | [Authorization Code Grant](/api-auth/grant/authorization-code) | -| `client_credentials` | [Client Credentials Grant](/api-auth/grant/client-credentials) | -| `password` | [Resource Owner Password Grant](/api-auth/grant/password) | -| `refresh_token` | [Use a Refresh Token](/tokens/refresh-token/current#use-a-refresh-token) | -| `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` | [Multifactor Authentication OOB Grant Request](/api-auth/tutorials/multifactor-resource-owner-password#mfa-oob-grant-request) | -| `http://auth0.com/oauth/grant-type/mfa-otp` | [Multifactor Authentication OTP Grant Request](/api-auth/tutorials/multifactor-resource-owner-password#mfa-otp-grant-request) | -| `http://auth0.com/oauth/grant-type/mfa-recovery-code` | [Multifactor Authentication Recovery Grant Request](/api-auth/tutorials/multifactor-resource-owner-password#mfa-recovery-grant-request) | - -The following are legacy grant types: - -* `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` - -## How to Edit the Client `grant_types` Property - -You can set the the `grant_types` property for your Auth0 Client using the Management Dashboard. - -::: warning -As of 8 June 2017, new Auth0 customers **cannot** add *any* of the legacy grant types to their Applications. Only customers as of 8 June 2017 can add legacy grant types to their existing Applications. -::: - -Begin by navigating to the [Applications page](${manage_url}/#/applications) of the Management Dashboard. - -![Auth0 Applications](/media/articles/clients/client-grant-types/clients.png) - -Click on the cog icon next to the Client you're interested in to launch its settings page. - -![Auth0 Client Settings](/media/articles/clients/client-grant-types/client-settings.png) - -Scroll down to the bottom of the settings page, and click **Advanced Settings**. - -![Auth0 Client Advanced Settings](/media/articles/clients/client-grant-types/client-advanced-settings.png) - -Switch to the **Grant Types** tab and enable or disable the respective grants for this client. Click **Save Changes**. - -![Auth0 Client Grant Types](/media/articles/clients/client-grant-types/grant-types.png) - -### Use the Management API - -In addition to setting the `grant_types` value using the Dasbhoard, you can make a [`PATCH` call to the Update a Client endpoint](/api/management/v2#!/Clients/patch_applications_by_id) of the Management API to update the `grant_types` field. - -### Errors - -Attempting to use any flow with a client 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. -``` - -## Information for Existing and New Auth0 Customers - -As of 8 June 2017, all Auth0 applications have a `grant_types` property that **must** be populated. Here's how Auth0 will handle this change based on whether you're a current customer with an existing Client or a new customer. - -### Existing Applications - -To avoid changes in functionality for current Auth0 customers, we will populate the `grant_types` property for all existing Applications as of 8 June 2017 with **all** Auth0 legacy, Auth0 extension, and specification-conformant grant types. - -### New Applications - -Depending on whether a newly-created Client is [public](/applications/client-types#public-applications) or [confidential](/applications/client-types#confidential-applications), the Client will have varying access to grant types. Trusted first-party applications have access to additional grant types. - -#### Public Applications - -Public Applications, indicated by the `token_endpoint_auth_method` flag set to `none`, are those created in the Dashboard for Native and Single Page Applications. - -::: panel Token Endpoint Authentication Method -The `Token Endpoint Authentication Method` defines how a client authenticates against the [token endpoint](/api/authentication#authorization-code). Its valid values are: - -* `None`, for a public client without a client secret -* `Post`, for a client using HTTP POST parameters -* `Basic`, for a client using HTTP Basic parameters - -You can find this field at the [Client Settings page](${manage_url}/#/applications/${account.clientId}/settings) of the [Auth0 Dashboard](${manage_url}). -::: - -By default, Public Applications are created with the following `grant_types`: - -* `implicit` -* `authorization_code` -* `refresh_token` - -::: note -Public applications **cannot** utilize the `client_credentials` grant type. To add this grant type to a Client using the [Management API](/api/management/v2#!/Clients/patch_clients_by_id), set the **token_endpoint_auth_method** to `client_secret_post` or `client_secret_basic`. Either of these will indicate the Client is confidential, not public. -::: - -#### Confidential Applications - -Confidential Applications, indicated by the `token_endpoint_auth_method` flag set to anything *except* `none`, are those created in the Dashboard for Regular Web Applications or Non-Interactive Applications. Additionally, any Client where `token_endpoint_auth_method` is unspecified is confidential. By default, Confidential Applications are created with the following `grant_types`: - -* `implicit`; -* `authorization_code`; -* `refresh_token`; -* `client_credentials`. - -#### Trusted First-Party Applications - -Trusted first-party applications can additionally use the following `grant_types`: - -* `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, note that all the Password and MFA grant types are enabled when you add the `Password` or `MFA` grant type on your client. You cannot select these individually. -::: - -## Secure Alternatives to the Legacy Grant Types - -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](/hosted-pages/login) instead of the `oauth/ro` endpoint. -::: - -## Enable a Legacy Grant Type - -::: warning -As of 8 June 2017, new Auth0 customers cannot add any of the 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. To find the secure alternative for your case refer to [Secure Alternatives to the Legacy Grant Types](#secure-alternatives-to-the-legacy-grant-types). -::: - -To enable a legacy grant type, you will need to update the `grant_types` property for you client appropriately. For details on how to do so, refer to [Edit the grant_types Property](#edit-available-grant_types). diff --git a/articles/applications/application-settings/_adv-settings-mobile.md b/articles/applications/application-settings/_adv-settings-mobile.md new file mode 100644 index 0000000000..fb14954545 --- /dev/null +++ b/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/articles/applications/application-settings/_adv-settings.md b/articles/applications/application-settings/_adv-settings.md index d2af38f64d..f86aa43c4a 100644 --- a/articles/applications/application-settings/_adv-settings.md +++ b/articles/applications/application-settings/_adv-settings.md @@ -14,19 +14,11 @@ Application metadata are custom string keys and values (each of which has a char You can create up to 10 sets of metadata. -#### Mobile 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**. - #### 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**. +* 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. diff --git a/articles/applications/application-settings/_settings-pt2.md b/articles/applications/application-settings/_settings-pt2.md index 1fcc3b475d..cbd497d7b3 100644 --- a/articles/applications/application-settings/_settings-pt2.md +++ b/articles/applications/application-settings/_settings-pt2.md @@ -1,15 +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). 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 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. +- **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. 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 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. 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). +- **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). -- **JWT Expiration (seconds)**: The amount of time (in seconds) before the Auth0 id_token expires. The default value is `36000`, which maps to 10 hours. +- **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 to the identity provider (such as Facebook, ADFS, and so on). +- **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/articles/applications/application-settings/_settings.md b/articles/applications/application-settings/_settings.md index 596a1350fb..7a276d13d1 100644 --- a/articles/applications/application-settings/_settings.md +++ b/articles/applications/application-settings/_settings.md @@ -6,7 +6,7 @@ - **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. +- **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. diff --git a/articles/applications/application-settings/index.yml b/articles/applications/application-settings/index.yml deleted file mode 100644 index 12753dbc99..0000000000 --- a/articles/applications/application-settings/index.yml +++ /dev/null @@ -1,13 +0,0 @@ -versioning: - baseUrl: applications/application-settings - current: native - versions: - - native - - single-page-app - - regular-web-app - - non-interactive - defaultArticles: - native: index - single-page-app: index - regular-web-app: index - non-interactive: index diff --git a/articles/applications/application-settings/native/index.md b/articles/applications/application-settings/native/index.md deleted file mode 100644 index 0803ec041d..0000000000 --- a/articles/applications/application-settings/native/index.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -description: Application settings for Native -url: /applications/application-settings/native -toc: true ---- - -# Application Settings: Native - -::: version-warning -This document lists the settings for a Native Application; if you're using a different Application type, please use the drop-down to select the appropriate doc. -::: - -When creating an Auth0 Application, you'll be asked to indicate the *type* of Application you want to create. - -![Window for selecting application type](/media/articles/clients/create-clients.png) - -For desktop or mobile apps running natively on the device, you'll want to create a Native Application. - -## Settings - -<%= include('../_settings') %> - -- **Application Type**: The type of application you are implementing. For desktop or mobile apps running natively on the device, you'll want to create a Native Application. - -<%= include('../_settings-pt2') %> - -### Advanced Settings - -<%= include('../_adv-settings') %> - -<%= include('../_adv-settings-pt2') %> diff --git a/articles/applications/application-settings/non-interactive/index.md b/articles/applications/application-settings/non-interactive/index.md deleted file mode 100644 index 85f4277e9a..0000000000 --- a/articles/applications/application-settings/non-interactive/index.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -description: Application settings for Machine to Machine Applications -url: /applications/application-settings/non-interactive -toc: true ---- - -# Application Settings: Machine to Machine Application - -::: version-warning -This document lists the settings for a Machine to Machine Application; if you're using a different Application type, please use the drop-down to select the appropriate doc. -::: - -When creating an Auth0 Application, you'll be asked to indicate the *type* of Application you want to create. - -![Window for selecting application type](/media/articles/clients/create-clients.png) - -If your app is a CLI, daemon, or a service running on the backend, you'll want to create a **Machine to Machine Application**. - -## Settings - -<%= include('../_settings') %> - -- **Application Type**: The type of application you are implementing. If your app is a CLI, daemon, or a service running on the backend, use a **Machine to Machine Application**. - -<%= include('../_token-endpoint-auth-method') %> - -<%= include('../_settings-pt2') %> - -### Advanced Settings - -<%= include('../_adv-settings') %> - -<%= include('../_trust-token-endpoint-ip-header') %> - -<%= include('../_adv-settings-pt2') %> diff --git a/articles/applications/application-settings/regular-web-app/index.md b/articles/applications/application-settings/regular-web-app/index.md deleted file mode 100644 index aaf78fbb2c..0000000000 --- a/articles/applications/application-settings/regular-web-app/index.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -description: Application settings for Web Apps -url: /applications/application-settings/regular-web-app -toc: true ---- -# Application Settings: Regular Web Applications - -::: version-warning -This document lists the settings for a Regular Web App; if you're using a different Application type, please use the drop-down to select the appropriate doc. -::: - -When creating an Auth0 Application, you'll be asked to indicate the *type* of Application you want to create. - -![Window for selecting application type](/media/articles/clients/create-clients.png) - -If you're working with a traditional web app that has the ability to refresh its pages, you'll want to create a Regular Web Application. - -## Settings - -<%= include('../_settings') %> - -- **Application Type**: The type of application you are implementing. If you're working with a traditional web app that has the ability to refresh its pages, use a Regular Web Applications. - -<%= include('../_token-endpoint-auth-method') %> - -<%= include('../_settings-pt2') %> - -### Advanced Settings - -<%= include('../_adv-settings') %> - -<%= include('../_trust-token-endpoint-ip-header') %> - -<%= include('../_adv-settings-pt2') %> diff --git a/articles/applications/application-settings/single-page-app/index.md b/articles/applications/application-settings/single-page-app/index.md deleted file mode 100644 index 2d75ebb05f..0000000000 --- a/articles/applications/application-settings/single-page-app/index.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -description: Application settings for Single Page Apps -url: /applications/application-settings/single-page-app -toc: true ---- - -# Application Settings: Single Page Applications - -::: version-warning -This document lists the settings for an SPA Application; if you're using a different Application type, please use the drop-down to select the appropriate doc. -::: - -When creating an Auth0 Application, you'll be asked to indicate the *type* of Application you want to create. - -![Window for selecting application type](/media/articles/clients/create-clients.png) - -If your app is similar to one with a JavaScript front-end that utilizes an API, you'll want to create a SPA Application. - -## Settings - -<%= include('../_settings') %> - -- **Application Type**: The type of application you are implementing. For apps with a JavaScript front-end that utilizes an API, create an SPA. - -<%= include('../_settings-pt2') %> - -### Advanced Settings - -<%= include('../_adv-settings') %> - -<%= include('../_adv-settings-pt2') %> diff --git a/articles/applications/application-types.md b/articles/applications/application-types.md deleted file mode 100644 index 187bd858cf..0000000000 --- a/articles/applications/application-types.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Application Types -description: Read about the the different applications types: public vs confidential, and first vs third-party -toc: true ---- -# Application Types - -<%= include('../_includes/_pipeline2') %> - -When working with Auth0 applications, which are used to represent your applications, there are several terms you should know in terms of how applications are classified: - -* [Confidential vs public](#confidential-vs-public-applications) -* [First vs third-party](#first-vs-third-party-applications) - -## Confidential vs public applications - -The OAuth 2.0 specification [defines two types of applications](https://tools.ietf.org/html/rfc6749#section-2.1): public and confidential. - -When creating an application through the [Dashboard](${manage_url}/#/applications), Auth0 will ask you what type of application you want the application to represent and use that information to determine the application type. - -### Check your application type - -You can use the Management API's [Get a Client endpoint](/api/management/v2#!/Clients/get_clients_by_id) to check your existing Application's type. If the application is first party, the `is_first_party` equals `true`, else `false`. Be sure to replace `CLIENT_ID` with the ID of your application. - -```har -{ - "method": "GET", - "url": "https://${account.namespace}/api/v2/clients/CLIENT_ID?fields=is_first_party&include_fields=true", - "headers": [{ - "name": "Authorization", - "value": "Bearer MGMT_API_ACCESS_TOKEN" - }] -} -``` - -::: note -See [The Auth0 Management APIv2 Token](/api/management/v2/tokens) for instructions on obtaining the Access Token required to call the Management API. -::: - -### Confidential applications - -Confidential applications are able to hold credentials (such as a client ID and secret) in a secure way without exposing them to unauthorized parties. This means that you will need a trusted backend server to store the secret(s). - -The following application types use confidential applications: - -* A web application with a secure backend using the [Authorization Code grant](/api-auth/grant/authorization-code), [Password](/api-auth/grant/password) or [Password Realm](/api-auth/tutorials/password-grant#realm-support) grants -* A machine to machine application using the [Client Credentials grant](/api-auth/grant/client-credentials) - -All of these grants require applications to authenticate by specifying their client ID and secret when calling the token endpoint. - -Since confidential applications are capable of holding secrets, you can choose to 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. The following application types use public applications: - -* Native desktop or mobile applications using the [Authorization Code grant with PKCE](/api-auth/grant/authorization-code-pkce) -* JavaScript-based client-side web applications (such as single-page apps) using the [Implicit](/api-auth/grant/implicit) grant - -Since public applications are unable to hold secrets, [ID Tokens](/tokens/id-token) 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 - -## First vs third-party applications - -First-party and third-party refer to the ownership of the application. This has implications in terms of 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, if you wanted to access the Contoso API, you'd use a first-party applications to log into `contoso.com`. - -All applications created via the [Dashboard](${manage_url}/#/applications) are first-party by default. - -### 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 access protected resources behind your API securely. For example, if you were to create a developer center that allows users to obtain credentials to integrate their apps with your API (this functionality is similar to those provided by well-known APIs such as Facebook, Twitter, and GitHub), you would use a third-party applications. - -Third-party applications must be created through the [Management API](/api/management/v2#!/Clients/post_clients) by setting `is_first_party` to `false`. - -Third party applications have the following characteristics: - -- They cannot skip user consent when consuming APIs. This is for security purposes, as anyone can create an applications, but each applications relies on the final user to provide consent. -- The [ID Tokens](/tokens/id-token) generated for these applications, hold minimum user profile information. -- They can use only tenant level connections (domain connections). These are sources of users, configured in the tenant's [dashboard](${manage_url}) as connections. These connections are enabled for every third party applications and can be also enabled for selected first party (standard) applications. -- To authenticate users using [Lock](/libraries/lock), you will have to use a version greater than `10.7`. - - [PSaaS Appliance](/appliance) users must use `https://{config.auth0Domain}/` as the value for [the `configurationBaseUrl` option](https://github.com/auth0/lock#other-options). -- They cannot use [ID Tokens](/tokens/id-token) to invoke [Management APIv2](/api/management/v2) endpoints. Instead, they should get a Management APIv2 Token (see the *How to get a Management APIv2 Token* panel for details). Note that the applications should be granted the `current_user_*` scopes, as required by each 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 Guardian 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 multifactor 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_provider_by_user_id) - -::: panel How to get a Management APIv2 Token -In order to access the [Management APIv2](/api/management/v2) endpoints from a third party applications, you need a Management APIv2 Token. To get one you can use any of the [API Authorization Flows](/api-auth), with the following request parameters: -- `audience=https://${account.namespace}/api/v2/` -- `scope=read:current_user update:current_user_metadata` -::: diff --git a/articles/applications/concepts/app-types-confidential-public.md b/articles/applications/concepts/app-types-confidential-public.md new file mode 100644 index 0000000000..8a5e97d787 --- /dev/null +++ b/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/articles/applications/concepts/app-types-first-third-party.md b/articles/applications/concepts/app-types-first-third-party.md new file mode 100644 index 0000000000..1412c22625 --- /dev/null +++ b/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/articles/applications/concepts/application-grant-types.md b/articles/applications/concepts/application-grant-types.md new file mode 100644 index 0000000000..76ced1103e --- /dev/null +++ b/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/articles/applications/concepts/client-secret.md b/articles/applications/concepts/client-secret.md new file mode 100644 index 0000000000..3c97f7efa3 --- /dev/null +++ b/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/articles/applications/concepts/grant-types-legacy.md b/articles/applications/concepts/grant-types-legacy.md new file mode 100644 index 0000000000..795ad11152 --- /dev/null +++ b/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/articles/applications/connections.md b/articles/applications/connections.md deleted file mode 100644 index abf585d450..0000000000 --- a/articles/applications/connections.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: Explains what Connections are and how they are associated with Auth0 Applications. -crews: crew-2 ---- -# Application Connections - -Connections are sources of users. They are categorized into Database, Social, Enterprise and Passwordless and can be shared among different applications. - -You can configure any number of connections for your applications to use in your Dashboard. To view all the connections that you have configured or create new ones navigate to [Dashboard](${manage_url}/#/) and select the connection type you want: -- [Database](${manage_url}/#/connections/database) -- [Social](${manage_url}/#/connections/social) -- [Enterprise](${manage_url}/#/connections/enterprise) -- [Passwordless](${manage_url}/#/connections/passwordless) - -For more details on the connections you can configure refer to: [Identity Providers Supported by Auth0](/identityproviders). - -## Example multi-tenant configuration - -If you have two separate domains (for example, public facing and internal), or two groups of connections you'd like to allow users, the best solution is to create a second Auth0 tenant via the settings menu in the top right on the [Dashboard](${manage_url}). This will allow you to have separate sets of users, applications, and connections for the two groups of users and applications you need to support. - -Let's suppose that you have two applications: an internal timesheets application and a customer portal. Users should login to the timesheets application either using their Active Directory credentials or their Google apps social connection. The customer portal on the other hand should be accessible via Facebook, Google, or LinkedIn authentication. - -You can configure this in Auth0 as follows: - -- Create a tenant `Fabrikam-Internal` for your internal domain, and an application within it `Fabrikam Employee Timesheets` for timesheets. -- Create a second tenant `Fabrikam-Public` for your public-facing domain, and an application within it `Fabrikam Customer Portal` for the customer portal. -- Configure the following [Enterprise connections](${manage_url}/#/connections/enterprise) for the `Fabrikam-Internal` tenant: Active Directory / LDAP, and Google Apps; once each is set up, check the **Applications** tab to enable them. -- Configure the following [Enterprise connection](${manage_url}/#/connections/enterprise) for the `Fabrikam-Public` tenant: Google Apps; once it is set up, check the **Applications** tab to enable it. -- Configure the following [Social connections](${manage_url}/#/connections/social) for the `Fabrikam-Public` tenant: Facebook, LinkedIn; once each is set up, check the **Applications** tab to enable it. diff --git a/articles/applications/enable-android-app-links.md b/articles/applications/enable-android-app-links.md deleted file mode 100644 index a809581a30..0000000000 --- a/articles/applications/enable-android-app-links.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -description: How to enable Android App Links support for your Auth0 application ---- - -# Enable Android App Links Support for your Auth0 Application - -The following document outlines how to configure [Android App Links](https://developer.android.com/training/app-links/index.html) for your Auth0 application. - -Android App Links allow an application to designate itself as the default handler of a given type of link. For example, clicking a URL in an email would open the link in the designated application. - -## Provide Your App's Package Name and Certificate Fingerprint - -You can establish the app link with Auth0 using [Applications](${manage_url}/#/applications) page of the [Auth0 Dashboard](${manage_url}). - -Select the Application you want to link with your Android application. You will see the **Settings** page for the Application. - -![](/media/articles/applications/settings.png) - -Scroll to the bottom of the **Settings** page and click **Show Advanced Settings.** - -![](/media/articles/applications/advanced-settings.png) - -Select the **Mobile Settings** tab, then provide the [App Package Name](https://developer.android.com/studio/build/application-id.html) and the SHA256 fingerprints of your app’s signing certificate for your Android application. - -You can generate the fingerprint using the Java keytool in your terminal: - -```bash -keytool -list -v -keystore my-release-key.keystore -``` - -::: note -For more information on signing certificates, check out the [Sign Your App](https://developer.android.com/studio/publish/app-signing.html) page of the Android developer documentation. -::: - -![](/media/articles/applications/mobile-settings.png) - -Click **Save Changes** when done. - -## Test Your App Link - -You can test your app link by navigating to the following URL using your browser: - -`https://${account.namespace}/.well-known/assetlinks.json` - -If the link is successful, you will return the following JSON (formatted for readability): - -```json -[{ - "relation": ["delegate_permission/common.handle_all_urls"], - "target": { - "namespace": "android_app", - "package_name": "com.mycompany.app1", - "sha256_cert_fingerprints": - ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"] - } -}] -``` - -::: note -See [Verify Android App Links](https://developer.android.com/training/app-links/verify-site-associations.html#testing) for further information on testing your app link. -::: diff --git a/articles/applications/enable-universal-links.md b/articles/applications/enable-universal-links.md deleted file mode 100644 index 7e80253de4..0000000000 --- a/articles/applications/enable-universal-links.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -description: How to enable Universal Links support for your Auth0 app in Xcode ---- - -# Enable Universal Links Support for your Auth0 Application in Xcode - -Because universal links establish a *verified relationship between domains and applications*, both your Auth0 Application settings and your iOS application need to be in sync. To do this, you need to provide Auth0 with the following information: - -* `Team ID`; -* `Bundle identifier`. - -## Find Your Apple `Team ID` and `Bundle Identifier` - -To find your Apple `Team ID`, go to your [Apple developer account summary page](https://developer.apple.com/membercenter/index.action#accountSummary). - -To find your iOS application's `Bundle identifier`, go to its [Xcode project settings](https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html) page: - -![](/media/articles/applications/bundle-id.png) - -## Provide Your Apple `Team ID` and `Bundle Identifier` to Auth0 - -You can establish the universal link from the Auth0 side using [Applications](${manage_url}/#/clients) page of the [Management Dashboard](${manage_url}). - -Select the Application you want to link with your iOS application. You will see the *Settings* page for the Application. - -![](/media/articles/applications/settings.png) - -Scroll to the bottom of the *Settings* page and click *Show Advanced Settings.* - -![](/media/articles/applications/advanced-settings.png) - -Select the *Mobile Settings* tab and provide the **Team ID** and the **App bundler identifier** values for your iOS application. - -![](/media/articles/applications/mobile-settings.png) - -Click **Save Changes** when done. - -## Test Your Universal Link - -To test this, check whether the universal links apple app site association file is available for your application. Go to your browser and open: https://YOURACCOUNT.auth0.com/apple-app-site-association (replace YOURACCOUNT with your Auth0 account name). - -You can test your universal link by navigating to the following URL using your browser: - -`${account.namespace}/apple-app-site-association` - -If the link is successful, you will return the following JSON (formatted for readability): - -```json -{ - "applinks": { - "apps": [], - "details": [{ - "appID": "86WQXF56BC.com.auth0.Passwordless-Email", - "paths": ["/ios/com.auth0.Passwordless-Email/*"] - }] - } -} -``` diff --git a/articles/applications/guides/enable-third-party-apps.md b/articles/applications/guides/enable-third-party-apps.md new file mode 100644 index 0000000000..bcd3c1712c --- /dev/null +++ b/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/articles/applications/how-to-rotate-client-secret.md b/articles/applications/how-to-rotate-client-secret.md deleted file mode 100644 index 608a3ba224..0000000000 --- a/articles/applications/how-to-rotate-client-secret.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -description: This page lists different ways of how to update your application's secret. -crews: crew-2 ---- - -# Rotate the Client Secret - -The client secret protects your resources by only granting tokens to requestors if they're authorized. Protect your client secrets; if any are ever compromised, you should rotate to a new one. Please remember that all authorized apps will therefore need to be updated with the new client secret. - -## Rotate the Client Secret in the Dashboard - -You can rotate your client secret under [Applications in the Dashboard](${manage_url}/#/applications). Choose the application you wish to edit by clicking on its name *or* the **Settings** gear icon associated with the application. - -![](/media/articles/clients/change-client-secret/clients.png) - -On the **Settings** page, the **Client Secret** will be the fourth parameter listed. To the right, click on the **rotation** icon to rotate your secret. You can view you your new secret by checking the box next to **Reveal client secret**. - -Scroll to the bottom of the Settings page, and click **Save Changes**. - -![](/media/articles/clients/change-client-secret/client-settings.png) - -## Rotate the Client Secret Using the Management API - -You can rotate your application's secret by making a `POST` call to the [Rotate a Client Secret endpoint](/api/management/v2#!/Clients/post_rotate_secret) of the Management API. - -Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Access Token, respectively. - -::: note -To make calls to the Management API, you must [get and use a valid Access Token](/api/management/v2/tokens). -::: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID/rotate-secret", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [{ - "name": "Authorization", - "value": "Bearer MGMT_API_ACCESS_TOKEN" - }], - "queryString": [], - "postData": {}, - "headersSize": -1, - "bodySize": -1, - "comment": "" -} -``` - -## Update Authorized Applications - -Once you've rotated your client secret, you must update any authorized applications with the new value. - -To make sure that you see as little downtime as possible when connecting your apps to your Auth0 application, we suggest you store the new client secret as a fallback to the previous secret. Then, 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) to track keys until they're no longer needed. Once you're sure that an old secret is obsolete, you can remove its value from your app. diff --git a/articles/applications/index.md b/articles/applications/index.md index 91e1e36547..2f3bf9a89a 100644 --- a/articles/applications/index.md +++ b/articles/applications/index.md @@ -1,91 +1,52 @@ --- -description: Explains the basics of creating and using Auth0 Applications. -toc: true +description: Understand the basics of creating and using Auth0 Applications. +topics: + - applications +contentType: + - concept +useCase: + - build-an-app --- -# Applications +# Applications in Auth0 -An Auth0 **application** represents your application and allows use of Auth0 for authentication. The term application does not imply any particular implementation characteristics. Your application can 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. +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. -## Application Types +Auth0 categorizes apps based on these characteristics: -::: note -Auth0 differentiates between [public and private applications](/applications/application-types#confidential-vs-public-applications), as well as [first- vs. third-party applications](/applications/application-types#first-vs-third-party-applications). -::: - -There are four application types in Auth0. Depending on which type you choose, you'll see [different settings you can configure](/applications/application-settings). - -- **Native**: Used for mobile, desktop or hybrid apps, than run natively in a device, like Android, Ionic or iOS. For a complete listing of the SDKs Auth0 offers for mobile apps refer to: [Native SDKs](/quickstart/native). - -- **Single Page Web Applications**: Used for JavaScript front-end apps that run on a browser, like Angular, jQuery or React. For a complete listing of the SDKs Auth0 offers for SPAs refer to: [Single Page App SDKs](/quickstart/spa). - -- **Regular Web Applications**: Used for traditional web applications that run on a server, like ASP .NET, Java or Node.js. For a complete listing of the SDKs Auth0 offers for Web Apps refer to: [Web App SDKs](/quickstart/webapp). - -- **Machine to Machine Applications**: Used for server to server applications like CLIs, daemons or services running on your backend. Typically you would use this option if you have a service that requires access to an API. - -## How to configure an Application - -Navigate to the [dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. By default, you should have one application named *Default App*. You can either configure this one or create a new one by clicking the **+ Create Application** button. - -The *Create Application* windows pops open. Set a descriptive name for your application and select the application type. The application type should match your application. - -![Create Application window](/media/articles/applications/create-client-popup.png) - -After you set the name and application type, click **Create**. +* **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. -A new application will be created and you will be redirected to this application's view that has four tabs: +* **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. -- [Quick Start](${manage_url}/#/applications/${account.clientId}/quickstart): Lists all available Quick Starts, filtered by your application's type. +* **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. -- [Settings](${manage_url}/#/applications/${account.clientId}/settings): Lists all the available settings for your application. +## Manage app settings - ::: note - Please see [Application Settings](/applications/application-settings) for detailed information. - ::: +You register apps on the [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings) page. See [Application Settings](/dashboard/reference/settings-application) for details. -- [Addons](${manage_url}/#/applications/${account.clientId}/addons): Add-ons are extensions associated with applications. They are typically third-party APIs used by the application(s) for which Auth0 generates Access Tokens. For more details refer to: [Addons](/applications/addons). +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. -- [Connections](${manage_url}/#/applications/${account.clientId}/connections): Connections are sources of users. They are categorized into Database, Social and Enterprise and can be shared among different applications. For more details refer to: [Connections](/applications/connections). For a detailed list on the supported Identity Providers refer to: [Identity Providers Supported by Auth0](/identityproviders). - -::: note -After creating your first application, set the environment for your tenant to: development, staging, or production. For more information refer to [Set Up Multiple Environments](/dev-lifecycle/setting-up-env#set-the-environment). -::: - -## How to Delete an Application - -Navigate to the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) and scroll to the end of the page. Under the *Danger Zone* section you can find the **Delete Application** button. This operation cannot be undone. - -Once you click on the button a pop-up window will ask you to confirm the action. Click **Yes, delete application** to permanently remove the application. - -::: note -You can also delete an application using the [DELETE /api/v2/clients/{id} endpoint](/api/management/v2#!/Clients/delete_clients_by_id) of the Management API. +::: 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). ::: -## Application Auditing - -Auth0 stores log data of both actions taken in the dashboard by the administrators, as well as authentications made by your users. The logs include many of the actions performed by the user like failing to login to an application or requesting a password change. For more details refer to: [Logs](/logs). - -If you use a third-party application for log management, like Sumo Logic, Splunk or Loggly, you can use Auth0 Extensions to export your logs there. For details on the available extensions and how to configure them refer to: [Extensions](/extensions). - -## Dynamic Client Registration - -You can use the Auth0 to programmatically create applications, as described in the [OIDC Dynamic Client Registration 1.0 specification](https://openid.net/specs/openid-connect-registration-1_0.html). For more details please refer to [Dynamic Client Registration](/api-auth/dynamic-client-registration). - -## Next Steps +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. -Once you have configured your Application, some common next steps to take are: +## Monitor apps -- **Configure a Connection** and enable it for your Application. For details refer to [Application Connections](/applications/connections). For a list of the supported Identity Providers refer to [Identity Providers Supported by Auth0](/identityproviders). +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. -- **Configure your app** to use your Auth0 Application. For detailed instructions and samples for a variety of technologies, refer to our [quickstarts](/quickstarts). There you can find information on how to implement login and logout (using [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js)), handle your user sessions, retrieve and display user profile information, add [Rules](/rules) to customize your flow, and more. +## Remove apps - ::: note - For background theory on application authentication flows, refer to [Application Authentication](/application-auth). - ::: +You can [remove an application using the Auth0 Dashboard](/dashboard/guides/applications/remove-app) or the [Management API](/api/management/guides/applications/remove-app). -- Use our latest [API Authorization](/api-auth) features to **call an API**. +## Manage client secrets -- **Use [our APIs](/api/info)**. +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). - - The [Authentication API](/api/authentication) handles all the primary identity related functions (login, logout, get user profile, and so forth). Most users consume this API through our [Quickstarts](/quickstarts), the [Auth0.js library](/libraries/auth0js) or the [Lock widget](/libraries/lock). However, if you are building all of your authentication UI manually you will have to interact with this API directly. +## Grant types - - The [Management API](/api/management/v2) can be used to automate various tasks in Auth0 such as creating users. +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/articles/applications/reference/grant-types-auth0-mapping.md b/articles/applications/reference/grant-types-auth0-mapping.md new file mode 100644 index 0000000000..d0808c59d3 --- /dev/null +++ b/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/articles/applications/reference/grant-types-available.md b/articles/applications/reference/grant-types-available.md new file mode 100644 index 0000000000..f4f2946b74 --- /dev/null +++ b/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/articles/applications/reference/wildcard-subdomains.md b/articles/applications/reference/wildcard-subdomains.md new file mode 100644 index 0000000000..74f968b6d1 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md b/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md index ae0e6718bb..7c95f9b91b 100644 --- a/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md +++ b/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md @@ -9,9 +9,9 @@ An Access Token is obtained by authenticating the user with an Authorization Ser ::: 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](/jwt). +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/access-token). +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. @@ -30,7 +30,7 @@ When a client asks the API to create a new timesheet entry, then the Access Toke 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 specification, or the many other technical aspects of API authorization. +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: @@ -40,5 +40,5 @@ In any OAuth 2.0 flow we can identify the following roles: - __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. +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/articles/architecture-scenarios/_includes/_api-configure-scopes.md b/articles/architecture-scenarios/_includes/_api-configure-scopes.md index 571c464d01..148a374c9a 100644 --- a/articles/architecture-scenarios/_includes/_api-configure-scopes.md +++ b/articles/architecture-scenarios/_includes/_api-configure-scopes.md @@ -1,7 +1,7 @@ -### Configure the Scopes +### Configure the Permissions -Once the application has been created you will need to configure the Scopes which applications can request during authorization. +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 **Scopes** 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`. +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-scopes.png) \ No newline at end of file +![Add Scopes](/media/articles/architecture-scenarios/mobile-api/add-permissions.png) \ No newline at end of file diff --git a/articles/architecture-scenarios/_includes/_api-implement.md b/articles/architecture-scenarios/_includes/_api-implement.md index 70206c28f4..3a217a0af4 100644 --- a/articles/architecture-scenarios/_includes/_api-implement.md +++ b/articles/architecture-scenarios/_includes/_api-implement.md @@ -36,7 +36,7 @@ The validations that the API should perform are: 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, refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). +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) @@ -60,8 +60,8 @@ For retrieving the list of timesheets this is to ensure that we only return the 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. +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) -::: \ No newline at end of file +::: diff --git a/articles/architecture-scenarios/_includes/_api-signing-algorithms.md b/articles/architecture-scenarios/_includes/_api-signing-algorithms.md index 9860ac274f..26c06a5eaf 100644 --- a/articles/architecture-scenarios/_includes/_api-signing-algorithms.md +++ b/articles/architecture-scenarios/_includes/_api-signing-algorithms.md @@ -3,7 +3,7 @@ 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 Tokens (JWTs) in Auth0](/jwt#what-is-the-json-web-token-structure-). +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`. @@ -17,6 +17,3 @@ The most secure practice, and our recommendation, is to use __RS256__. Some of t - 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. -::: note -For a more detailed overview of the JWT signing algorithms refer to: [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/). -::: \ No newline at end of file diff --git a/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md b/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md new file mode 100644 index 0000000000..0f2d1ea2a4 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_architecture/_introduction.md b/articles/architecture-scenarios/_includes/_architecture/_introduction.md new file mode 100644 index 0000000000..ab22539da6 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md b/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md new file mode 100644 index 0000000000..bddb0fea0d --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md b/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md new file mode 100644 index 0000000000..dc2739a4cf --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md b/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md new file mode 100644 index 0000000000..f502ca08a7 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_application-integration.md b/articles/architecture-scenarios/_includes/_authentication/_application-integration.md new file mode 100644 index 0000000000..8580bb8809 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md b/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md new file mode 100644 index 0000000000..42aeb1a83b --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_introduction.md b/articles/architecture-scenarios/_includes/_authentication/_introduction.md new file mode 100644 index 0000000000..1921e46883 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_mfa.md b/articles/architecture-scenarios/_includes/_authentication/_mfa.md new file mode 100644 index 0000000000..ec67e73549 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md b/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md new file mode 100644 index 0000000000..262ba3477c --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md b/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md new file mode 100644 index 0000000000..58df288183 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_universal-login.md b/articles/architecture-scenarios/_includes/_authentication/_universal-login.md new file mode 100644 index 0000000000..57dc6a92d7 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md b/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md new file mode 100644 index 0000000000..6668a0c76d --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authorization/_api-integration.md b/articles/architecture-scenarios/_includes/_authorization/_api-integration.md new file mode 100644 index 0000000000..879f473836 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authorization/_application-integration.md b/articles/architecture-scenarios/_includes/_authorization/_application-integration.md new file mode 100644 index 0000000000..bf785f09e1 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authorization/_introduction.md b/articles/architecture-scenarios/_includes/_authorization/_introduction.md new file mode 100644 index 0000000000..b1720ae98f --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authorization/_m2m.md b/articles/architecture-scenarios/_includes/_authorization/_m2m.md new file mode 100644 index 0000000000..f22d07cc27 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_authorization/_rbac.md b/articles/architecture-scenarios/_includes/_authorization/_rbac.md new file mode 100644 index 0000000000..68df646d59 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_base-intro.md b/articles/architecture-scenarios/_includes/_base-intro.md new file mode 100644 index 0000000000..2dfc169d6e --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md b/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md new file mode 100644 index 0000000000..7089399c48 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md b/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md new file mode 100644 index 0000000000..ae02a82b67 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_email-templates.md b/articles/architecture-scenarios/_includes/_branding/_email-templates.md new file mode 100644 index 0000000000..3b3dccdf63 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_error-page.md b/articles/architecture-scenarios/_includes/_branding/_error-page.md new file mode 100644 index 0000000000..4f74e4757a --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_guardian.md b/articles/architecture-scenarios/_includes/_branding/_guardian.md new file mode 100644 index 0000000000..99b6009f56 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_introduction.md b/articles/architecture-scenarios/_includes/_branding/_introduction.md new file mode 100644 index 0000000000..387c2dc354 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_password-reset.md b/articles/architecture-scenarios/_includes/_branding/_password-reset.md new file mode 100644 index 0000000000..c3b0785c61 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_branding/_universal-login.md b/articles/architecture-scenarios/_includes/_branding/_universal-login.md new file mode 100644 index 0000000000..69e2691da7 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_deployment/_introduction.md b/articles/architecture-scenarios/_includes/_deployment/_introduction.md new file mode 100644 index 0000000000..c301f040e3 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_implementation-checklists.md b/articles/architecture-scenarios/_includes/_implementation-checklists.md new file mode 100644 index 0000000000..c4624b459c --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_keep-reading.md b/articles/architecture-scenarios/_includes/_keep-reading.md new file mode 100644 index 0000000000..9697768911 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_compliance.md b/articles/architecture-scenarios/_includes/_launch/_compliance.md new file mode 100644 index 0000000000..8538d072c5 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_introduction.md b/articles/architecture-scenarios/_includes/_launch/_introduction.md new file mode 100644 index 0000000000..4909da3507 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_launch.md b/articles/architecture-scenarios/_includes/_launch/_launch.md new file mode 100644 index 0000000000..c0c5526d56 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_operations.md b/articles/architecture-scenarios/_includes/_launch/_operations.md new file mode 100644 index 0000000000..22a43ad85d --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_support.md b/articles/architecture-scenarios/_includes/_launch/_support.md new file mode 100644 index 0000000000..3eea47b43a --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_tenant-check.md b/articles/architecture-scenarios/_includes/_launch/_tenant-check.md new file mode 100644 index 0000000000..2f9f2ce0d5 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_launch/_testing.md b/articles/architecture-scenarios/_includes/_launch/_testing.md new file mode 100644 index 0000000000..7ceb804ac1 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_logout/_introduction.md b/articles/architecture-scenarios/_includes/_logout/_introduction.md new file mode 100644 index 0000000000..08510e5ea8 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_multitenancy.md b/articles/architecture-scenarios/_includes/_multitenancy.md new file mode 100644 index 0000000000..50c06de00b --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_email-provider.md b/articles/architecture-scenarios/_includes/_operations/_email-provider.md new file mode 100644 index 0000000000..8f83e0bece --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_infrastructure.md b/articles/architecture-scenarios/_includes/_operations/_infrastructure.md new file mode 100644 index 0000000000..540e16cd72 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_introduction.md b/articles/architecture-scenarios/_includes/_operations/_introduction.md new file mode 100644 index 0000000000..33fb73bae3 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_logging.md b/articles/architecture-scenarios/_includes/_operations/_logging.md new file mode 100644 index 0000000000..41ce91d599 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_monitoring.md b/articles/architecture-scenarios/_includes/_operations/_monitoring.md new file mode 100644 index 0000000000..d64277752e --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_notifications.md b/articles/architecture-scenarios/_includes/_operations/_notifications.md new file mode 100644 index 0000000000..57dd93c1f9 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_operations/_service-status.md b/articles/architecture-scenarios/_includes/_operations/_service-status.md new file mode 100644 index 0000000000..a42bdbd948 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_planning.md b/articles/architecture-scenarios/_includes/_planning.md new file mode 100644 index 0000000000..8ad9191355 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md new file mode 100644 index 0000000000..0306b71049 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md new file mode 100644 index 0000000000..d66954e4a6 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md new file mode 100644 index 0000000000..cfbccfab6c --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md new file mode 100644 index 0000000000..d0098b386d --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md new file mode 100644 index 0000000000..572f16a38e --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md new file mode 100644 index 0000000000..8fe125d585 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md b/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md new file mode 100644 index 0000000000..0407264659 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md b/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md new file mode 100644 index 0000000000..5571357acc --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_introduction.md b/articles/architecture-scenarios/_includes/_provisioning/_introduction.md new file mode 100644 index 0000000000..4a6ec7c089 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_organizations.md b/articles/architecture-scenarios/_includes/_provisioning/_organizations.md new file mode 100644 index 0000000000..7dd959ad2c --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md b/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md new file mode 100644 index 0000000000..6799c34345 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md b/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md new file mode 100644 index 0000000000..c581a3e097 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md b/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md new file mode 100644 index 0000000000..fea6aca40e --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_qa/_integration-testing.md b/articles/architecture-scenarios/_includes/_qa/_integration-testing.md new file mode 100644 index 0000000000..629c1f9d99 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_qa/_introduction.md b/articles/architecture-scenarios/_includes/_qa/_introduction.md new file mode 100644 index 0000000000..9f423218bc --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_qa/_load-testing.md b/articles/architecture-scenarios/_includes/_qa/_load-testing.md new file mode 100644 index 0000000000..1761e56882 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_qa/_mock-testing.md b/articles/architecture-scenarios/_includes/_qa/_mock-testing.md new file mode 100644 index 0000000000..786ee3b346 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_qa/_unit-testing.md b/articles/architecture-scenarios/_includes/_qa/_unit-testing.md new file mode 100644 index 0000000000..a8ebd23233 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_rate-limit-policy.md b/articles/architecture-scenarios/_includes/_rate-limit-policy.md new file mode 100644 index 0000000000..ce743cf61d --- /dev/null +++ b/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/articles/architecture-scenarios/application/mobile-api/index.md b/articles/architecture-scenarios/application/mobile-api/index.md deleted file mode 100644 index db5281bdf1..0000000000 --- a/articles/architecture-scenarios/application/mobile-api/index.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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 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 ---- - -# 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/application/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 Grant Flow with PKCE (see [Proof Key for Code Exchange](/architecture-scenarios/application/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/application/mobile-api/part-2)) -* User Permissions can be enforced using the Authorization Extension (see [Configure the Authorization Extension](/architecture-scenarios/application/mobile-api/part-2#configure-the-authorization-extension)) -* The API is secured by ensuring that a valid [Access Token](/tokens/access-token) is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/architecture-scenarios/application/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/application/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/application/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/application/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/application/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/application/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/application/mobile-api/part-1"] -}) %> diff --git a/articles/architecture-scenarios/application/mobile-api/part-1.md b/articles/architecture-scenarios/application/mobile-api/part-1.md deleted file mode 100644 index ffc292f62b..0000000000 --- a/articles/architecture-scenarios/application/mobile-api/part-1.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -description: Solutions Overview for the Mobile + API architecture scenario -toc: true ---- - -# Mobile + API: Solutions Overview - -<%= include('../../_includes/_api-overview-of-solution.md') %> - -<%= include('../../_includes/_api-authentication-and-authorization.md') %> - -## Proof Key for Code Exchange (PKCE) - -OAuth 2 provides several grant types for different use cases. In this particular use case, we want to access the API from a mobile application, which will use the OAuth 2.0 [Proof Key for Code Exchange](/api-auth/grant/authorization-code-pkce) to do so. - -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](/tokens/access-token) (and possibly a [Refresh Token](/tokens/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. - -![PKCE](/media/articles/architecture-scenarios/mobile-api/authorization-code-grant-pkce.png) - -1. The native app 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 app with an `authorization_code` in the querystring. -3. The native app 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 app can use the `access_token` to call the API on behalf of the user. - -## Authorization Extension - -The [Auth0 Authorization Extension](/extensions/authorization-extension) allows you to provide authorization support in your application, by assigning Roles, Groups and Permissions to Users. - -The Authorization Extension creates a [Rule](/rules) which will augment the [User profile](/rules/current#rule-syntax) during the authentication flow with the Roles, Groups and Permissions assigned to the user. You can then use this information to ensure that the `access_token` issued to a user only contains scopes which are allowed according to the permissions defined in the Authorization Extension. - -<%= include('./_stepnav', { - prev: ["Introduction", "/architecture-scenarios/application/mobile-api"], next: ["2. Auth0 Configuration", "/architecture-scenarios/application/mobile-api/part-2"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/mobile-api/part-2.md b/articles/architecture-scenarios/application/mobile-api/part-2.md deleted file mode 100644 index f1b1993815..0000000000 --- a/articles/architecture-scenarios/application/mobile-api/part-2.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -description: Auth0 Configuration for the Mobile + API architecture scenario -toc: true ---- - -# Mobile + API: Auth0 Configuration - -In this section we will review all the configurations we need to apply at the [Auth0 Dashboard](${manage_url}). - - -## Create the API - -Click on the [APIs menu option](${manage_url}/#/apis) on the left, and click the Create API button. - -You will be required to supply the following details for your API: - -- __Name__: a friendly name for the API. Does not affect any functionality. -- __Identifier__: a unique identifier for the API. 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. 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. For more details on the signing algorithms see the Signing Algorithms paragraph below. - -![Create API](/media/articles/architecture-scenarios/mobile-api/create-api.png) - -Fill in the required information and click the __Create__ button. - -<%= include('../../_includes/_api-signing-algorithms.md') %> - -<%= include('../../_includes/_api-configure-scopes.md') %> - -## Create the Application - -There are four application types in Auth0: __Native__ (used by mobile or desktop apps), __Single Page Web Applications__, __Regular Web Applications__ and __Machine to Machine Application__ (used by CLIs, Daemons, or services running on your backend). For this scenario we want to create a new Application for our mobile application, hence we will use Native as the application type. - -To create a new Application, navigate to the [dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications}) menu option on the left. Click the __+ Create Application__ button. - -Set a name for your Application (we will use `Timesheets Mobile`) and select `Native` as the type. - -Click __Create__. - -![Create Application](/media/articles/architecture-scenarios/mobile-api/create-application.png) - -## Configure the Authorization Extension - -You will need to ensure that the Authorization Extension is installed for your tenant. You can refer to the [Authorization Extension documentation](/extensions/authorization-extension#how-to-install) for details on how to do this. - -### Define Permissions - -You will need to define Permissions which correlates with the scopes you have already defined. In the Authorization Extension, click the _Permissions_ tab, and then click on the **Create Permission** button. In the dialog, capture the details for each permission. Ensure that the name of the permission is exactly the same as the corresponding scope: - -![Create Permission](/media/articles/architecture-scenarios/mobile-api/create-permission.png) - -Proceed to create the permissions for all the remaining scopes: - -![Permissions](/media/articles/architecture-scenarios/mobile-api/permissions.png) - -### Define Roles - -Head over to the _Roles_ tab and create 2 Roles. Click the **Create Role** button and select the **Timesheets SPA** application. Give the Role a name and description of Employee, and select the `delete:timesheets`, `create:timesheets` and `read:timesheets` permissons. Click on **Save**. - -![Create Employee Role](/media/articles/architecture-scenarios/mobile-api/create-employee-role.png) - -Next, follow the same process to create a **Manager** role, and ensure that you have selected all the permissions: - -![Create Manager Role](/media/articles/architecture-scenarios/mobile-api/create-manager-role.png) - -### Assign Users to Roles - -You will need to assign all users to either the Manager or the User role. You can do this by going to the _Users_ tab in the Authorization Extension and selecting a user. On the user information screen, go to the _Roles_ tab. You can add a role to the user by clicking the **Add Role to User** button, and selecting the approproate role for the user. - -![Add User to Role](/media/articles/architecture-scenarios/mobile-api/add-user-role.png) - -### Configuring the Authorization Extension - -You will also need to ensure that the Rule for the Authorization Extension is published. You can do this by clicking on your user avatar in to top right of the Authorization Extension, and selecting the **Configuration** option: - -![Navigate to COnfiguration](/media/articles/architecture-scenarios/mobile-api/select-configuration.png) - -Ensure that you have enabled **Permissions** and then click the **Publish Rule** button: - -![Pulish Rule](/media/articles/architecture-scenarios/mobile-api/publish-rule.png) - -### Create a Rule to validate token scopes - -The final step in this process is to create a Rule which will validate that the scopes contained in an `access_token` is valid based on the permissions assigned to the user. Any scopes which are not valid for a user should be removed from the `access_token`. - -In your Auth0 Dashboard, go to the _Rules_ tab. You should see the Rule created by the Authorization Extension: - -![Rules](/media/articles/architecture-scenarios/mobile-api/rules-1.png) - -Click on the **Create Rule** button and select the **Empty Rule** template. You can give the Rule a name, such as **Access Token Scopes**, and then specify the following code for the Rule: - -```js -function (user, context, callback) { - if (context.clientName !== 'Timesheets SPA') { - return callback(null, user, context); - } - - var permissions = user.permissions || []; - var requestedScopes = context.request.body.scope || context.request.query.scope; - var filteredScopes = requestedScopes.split(' ').filter( function(x) { - return x.indexOf(':') < 0; - }); - Array.prototype.push.apply(filteredScopes, permissions); - context.accessToken.scope = filteredScopes.join(' '); - - callback(null, user, context); -} -``` - -The code above will ensure that all Access Tokens will only contain the scopes which are valid according to a user's permissions. Once you are done you can click on the **Save** button. - -Rules execute in the order they are displayed on the Rules page, so ensure that the new rule you created is positioned below the rule for the Authorization Extension, so it executes after the Authorization Extension rule: - -![Rules](/media/articles/architecture-scenarios/mobile-api/rules-2.png) - -<%= include('./_stepnav', { - prev: ["1. Solution Overview", "/architecture-scenarios/application/mobile-api/part-1"], next: ["3. API + Mobile Implementation", "/architecture-scenarios/application/mobile-api/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/mobile-api/part-3.md b/articles/architecture-scenarios/application/mobile-api/part-3.md deleted file mode 100644 index 427b2950b2..0000000000 --- a/articles/architecture-scenarios/application/mobile-api/part-3.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -description: API and Mobile Configuration for the Mobile + API architecture scenario -toc: true ---- - -# Mobile + API: API and Mobile Configuration - -<%= include('../../_includes/_api-implement.md') %> - -## Implement the Mobile App - -In this section we will see how we can implement a mobile application for our scenario. - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#1-set-up-the-application) -::: - -### Authorize the User - -To authorize the user we will implement an [Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce). The mobile application should first send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-) along with 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=YOUR_CLIENT_ID& - code_challenge=CODE_CHALLENGE& - code_challenge_method=S256& - redirect_uri=https://YOUR_APP/callback -``` - -The `GET` request to the authorization URL should include the following values: - -Parameter | Description -----------|------------ -__client_id__ | The value of your Auth0 Client Id. You can retrieve it from the Settings of your Application at the [Auth0 Dashboard](${manage_url}/#/applications). -__audience__ | The value of your API Identifier. You can retrieve it from the Settings of your API at the [Auth0 Dashboard](${manage_url}/#/apis). -__scope__ | The [scopes](/scopes) which determine the claims to be returned in the `id_token` and `access_token`. For example, a scope of `openid` will return an `id_token` in the response. In our example mobile app, we use the following scopes: `create:timesheets read:timesheets openid profile email offline_access`. These scopes allow the mobile app to call the API, obtain a `refresh_token`, and return the user's `name`, `picture`, and `email` claims in the `id_token`. -__response_type__ | Indicates the Authentication Flow to use. For a mobile application using PKCE, this should be set to `code`. -__code_challenge__ | The generated code challenge from the code verifier. You can find instructions on generating a code challenge [here](/api-auth/tutorials/authorization-code-grant-pkce#1-create-a-code-verifier). -__code_challenge_method__ | Method used to generate the challenge. Auth0 supports only `S256`. -__redirect_uri__ | The URL which Auth0 will redirect the browser to 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). - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#2-authorize-the-user) -::: - -### Get the Credentials - -After a successful request to the authorization URL, you should receive the following response: - -```text -HTTP/1.1 302 Found -Location: https://${account.namespace}/callback?code=AUTHORIZATION_CODE -``` - -Next you can exchange the `authorization_code` from the response for an Access Token that can be used to call your API. Perform a `POST` request to the [Token URL](/api/authentication#authorization-code-pkce-) including the following data: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"code_verifier\": \"YOUR_GENERATED_CODE_VERIFIER\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"com.myclientapp://myclientapp.com/callback\", }" - } -} -``` - -Parameter | Description -----------|------------ -__grant_type__ | This must be set to `authorization_code`. -__client_id__ | The value of your Auth0 Client Id. You can retrieve it from the Settings of your Application at the [Auth0 Dashboard](${manage_url}/#/applications). -__code_verifier__ | Cryptographically random key that was used to generate the `code_challenge` passed to [authorization URL](/api/authentication#authorization-code-grant-pkce-) (`/authorize`). -__code__ | The `authorization_code` received from the previous authorize call. -__redirect_uri__ | The URL must match the `redirect_uri` passed in the previous section to `/authorize`. - -The response from the Token URL will contain: - -```json -{ - "access_token": "eyJz93a...k4laUWw", - "refresh_token": "GEbRxBN...edjnXbL", - "id_token": "eyJ0XAi...4faeEoQ", - "token_type": "Bearer", - "expires_in":86400 -} -``` - -- __access_token__: An `access_token` for the API, specified by the `audience`. -- __refresh_token__: A [Refresh Token](/tokens/refresh-token/current) will only be present if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. -- __id_token__: An `id_token` JWT containing user profile information. -- __token_type__: A string containing the type of token, this will always be a Bearer token. -- __expires_in__: The amount of seconds until the `access_token` expires. - -You will need to store the above credentials in local storage for use in calling your API and retrieving the user profile. - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#store-credentials) -::: - -### Get the User Profile - -To retrieve the [User Profile](/api/authentication?http#user-profile), your mobile application can decode the [ID Token](/tokens/id-token) using one of the [JWT libraries](https://jwt.io/#libraries-io). This is done by [verifying the signature](/tokens/id-token#verify-the-signature) and [validating the claims](/tokens/id-token#validate-the-claims) of the token. After validating the ID Token, you can access its payload containing the user information: - -```json -{ - "email_verified": false, - "email": "test.account@userinfo.com", - "clientID": "q2hnj2iu...", - "updated_at": "2016-12-05T15:15:40.545Z", - "name": "test.account@userinfo.com", - "picture": "https://s.gravatar.com/avatar/dummy.png", - "user_id": "auth0|58454...", - "nickname": "test.account", - "created_at": "2016-12-05T11:16:59.640Z", - "sub": "auth0|58454..." -} -``` - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#3-get-the-user-profile) -::: - -### Display UI Elements Conditionally Based on Scope - -Based on the `scope` of the user, you may want to show or hide certain UI elements. To determine the scope issued to a user, you will need to inspect the the `scope` which was granted when the user was authenticated. This will be a string containing all the scopes, so you therefore need to inspect this string to see whether it contains the required `scope` and based on that make a decision whether to display a particular UI element. - -::: note -[See the implementation in Android](/architecture-scenarios/application/mobile-api/mobile-implementation-android#4-display-ui-elements-conditionally-based-on-scope) -::: - -### Call the API - -To access secured resources from your API, the authenticated user's `access_token` needs to be included in requests that are sent to it. This is accomplished by sending the `access_token` in an `Authorization` header using the `Bearer` scheme. - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#5-call-the-api) -::: - -### Renew the Token - -::: warning -Refresh Tokens must be stored securely by an application since they do not expire and allow a user to remain authenticated essentially forever. If Refresh Tokens are compromised or you no longer need them, you can revoke the Refresh Tokens using the [Authentication API](/api/authentication#revoke-refresh-token). -::: - -To refresh your `access_token`, perform a `POST` request to the `/oauth/token` endpoint using the `refresh_token` from your authorization result. - -A [Refresh Token](/tokens/refresh-token/current) will only be present if you included the `offline_access` scope in the previous authorization request and enabled __Allow Offline Access__ for your API in the Dashboard. - -Your request should include: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "queryString" : [], - "postData" : { - "mimeType": "application/json", - "text" : "{ \"grant_type\": \"refresh_token\", \"client_id\": \"${account.clientId}\", \"refresh_token\": \"YOUR_REFRESH_TOKEN\" }" - }, - "headersSize" : 150, - "bodySize" : 0, - "comment" : "" -} -``` - -Parameter | Description -----------|------------ -__grant_type__ | This must be set to `refresh_token`. -__client_id__ | The value of your Auth0 Client Id. You can retrieve it from the Settings of your Application at the [Auth0 Dashboard](${manage_url}/#/applications). -__refresh_token__ | the `refresh_token` to use, from the previous authentication result. - -The response will include the new `access_token`: - -```json -{ - "access_token": "eyJz93a...k4laUWw", - "refresh_token": "GEbRxBN...edjnXbL", - "id_token": "eyJ0XAi...4faeEoQ", - "token_type": "Bearer", - "expires_in":86400 -} -``` - -::: note -[See the implementation in Android.](/architecture-scenarios/application/mobile-api/mobile-implementation-android#store-the-credentials) -::: - -<%= include('./_stepnav', { - prev: ["2. Auth0 Configuration", "/architecture-scenarios/application/mobile-api/part-2"], next: ["Conclusion", "/architecture-scenarios/application/mobile-api/part-4"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/mobile-api/part-4.md b/articles/architecture-scenarios/application/mobile-api/part-4.md deleted file mode 100644 index 7dd6a93185..0000000000 --- a/articles/architecture-scenarios/application/mobile-api/part-4.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: Conclusion for the Mobile + API architecture scenario ---- - -# Mobile + API: Conclusion - -In this document we covered a simple scenario: an API, used by a mobile application to allow employees to capture their timesheets. - -We learned about the Authorization Code Grant with PKCE, what an Access Token is, how to configure an API in Auth0, how to configure a mobile application to communicate securely with this API, how to define and secure our API endpoints, how to use the provided libraries to validate the Access Token and how to retrieve a new one from Auth0. - -We started by describing the business case and the requirements and went on explaining how each requirement can be met and the thought process behind each choice that was made. - -We used Node.js for the API implementation and Android for the mobile application. Hopefully though after going through this document you are able to build this using the technologies you prefer. - -Don't forget to check back for new business cases and more complex architecture scenarios! - -<%= include('./_stepnav', { - prev: ["3. API + Mobile Implementation", "/architecture-scenarios/application/mobile-api/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/server-api/index.md b/articles/architecture-scenarios/application/server-api/index.md deleted file mode 100644 index a07f61ce7b..0000000000 --- a/articles/architecture-scenarios/application/server-api/index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -order: 02 -title: Server Application + API -image: /media/articles/architecture-scenarios/server-api.png -extract: Server to server communication where a server “Application” needs to make secure calls to an API (“Resource Server”), but on behalf of the application vs. a user. -description: Explains the architecture scenario with server to server communication with secure calls to an API (“Resource Server”), but on behalf of the application vs. a user. -toc: true ---- - -# Server + API - -In this scenario we will build a Timesheet API for a fictitious company named ExampleCo. The API will allow to add timesheet entries for an employee or a contractor. - -We will also be building a cron job which will process timesheet entries from an external system to 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/application/server-api/part-1#api-authentication-and-authorization)) -* For authorizing a Machine to Machine Application (a CLI, service or daemon where no user interaction is involved) Auth0 supports the Client Credentials grant (see [Client Credentials Grant](/architecture-scenarios/application/server-api/part-1#client-credentials-grant)) -* Both the Machine to Machine Application and the API must be configured in the Auth0 Dashboard (see [Auth0 Configuration](/architecture-scenarios/application/server-api/part-2)) -* The API will be secured by ensuring that a valid Access Token (which is implemented as a JSON Web Token) is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/architecture-scenarios/application/server-api/part-3)) -* Upon successful authorization an Access Token is issued to the Machine to Machine Application (see [Get an Access Token](/architecture-scenarios/application/server-api/part-3#get-an-access-token)) -* The Machine to Machine Application can in turn use this Access Token to pass along as an HTTP Authorization header to authenticate calls to API endpoints (see [Invoke the API](/architecture-scenarios/application/server-api/part-3#invoke-the-api)) -::: - -## 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. For this purpose, they 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 some of the external contractors already use another tool to track their timesheets. Hence a solution to avoid the double work is required. It was decided to build a cron job which will read the timesheet entries from this external system, and automatically upload those to ExampleCo's backend using an API. - -### Goals & Requirements - -ExampleCo wants to build a flexible solution. At the moment only an automated process needs to push timesheet entries but in the future the company plans on launching more applications, like a mobile app to accommodate their sales teams. Hence the company has decided to develop a single Timesheets API which will be used to log time not only by this server process, but by all future applications 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/application/server-api/part-1"] -}) %> diff --git a/articles/architecture-scenarios/application/server-api/part-1.md b/articles/architecture-scenarios/application/server-api/part-1.md deleted file mode 100644 index 7638816527..0000000000 --- a/articles/architecture-scenarios/application/server-api/part-1.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -description: Solutions Overview for the Server + API architecture scenario -toc: true ---- - -# Server + API: Solution Overview - -<%= include('../../_includes/_api-overview-of-solution.md') %> - -<%= include('../../_includes/_api-authentication-and-authorization.md') %> - -## Client Credentials Grant - -OAuth 2 provides several *grant types* for different use cases. In this particular use case where a cron job will be uploading timesheets via an API, there is no interactive user (or resource owner) who grants permission to the cron job to access the API. - -The cron job is also not making the API calls on behalf of any user. Instead there is a machine-to-machine authorization and the application (the cron job) makes calls to the Resource Server (the API) on its own behalf. - -For situations like this where there is no user interaction involved, the Client Credentials Grant is ideal. With Client Credentials Grant (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) an Application can directly request an `access_token` from the Authorization Server by using its Client Credentials (a Client Id and a Client Secret). Instead of identifying a Resource Owner, this token will represent the Application itself. - -![Client Credentials Grant Flow](/media/articles/architecture-scenarios/server-api/client-credentials-grant.png) - -1. The Application authenticates with the Authorization Server using its Client ID and Client Secret. -1. The Authorization Server validates this information and returns an `access_token`. -1. The Application can use the `access_token` to call the Resource Server on behalf of itself. - -<%= include('./_stepnav', { - prev: ["Introduction", "/architecture-scenarios/application/server-api"], next: ["2. Auth0 Configuration", "/architecture-scenarios/application/server-api/part-2"] -}) %> diff --git a/articles/architecture-scenarios/application/server-api/part-2.md b/articles/architecture-scenarios/application/server-api/part-2.md deleted file mode 100644 index c85bab6ade..0000000000 --- a/articles/architecture-scenarios/application/server-api/part-2.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -description: Auth0 Configuration for the Server + API architecture scenario -toc: true ---- - -# Server + API: Auth0 Configuration - -In this section we will review all the configurations we need to apply using the [Auth0 Dashboard](${manage_url}). - -## Configure the API - -Click on the [APIs menu option](${manage_url}/#/apis) on the left, and click the **Create API** button. - -You will be required to supply the following details for your API: - -- **Name**: a friendly name for the API. Does not affect any functionality. -- **Identifier**: a unique identifier for the API. 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. 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. For more details on the signing algorithms see the [Signing Algorithms paragraph](#signing-algorithms) below. - -![Create API](/media/articles/architecture-scenarios/server-api/create-api.png) - -Fill in the required information and click the **Create** button. - -### 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 Tokens (JWTs) in Auth0](/jwt#what-is-the-json-web-token-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. - -For a more detailed overview of the JWT signing algorithms refer to: [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/). - -## Configure the Scopes - -Once the application has been created you will need to configure the Scopes which applications can request during authorization. - -In the settings for your API, go to the *Scopes* tab. In this section you can add all four of the scopes which was discussed before, namely `batch:upload`, `read:timesheets`, `create:timesheets`, `delete:timesheets`, `approve:timesheets`. - -::: note - For the purposes of this document we will only be ever concerned with the `batch:upload` scope, as that is all that is required by the Cron job. For completeness sake we are however adding the necessary scopes which will be required by future applications as well. -::: - -![Add Scopes](/media/articles/architecture-scenarios/server-api/add-scopes.png) - -## Create the Application - -When creating an API in the Auth0 Dashboard, a test application for the API will automatically be generated. In the Auth0 Dashboard, navigate to the [Application Section](${manage_url}/#/applications) and you will see the test application for the Timesheets API. - -![Machine to Machine Application](/media/articles/architecture-scenarios/server-api/non-interactive-client.png) - -Go to the settings for the application by clicking on the gear icon, and rename the application to `Timesheets import Job`. - -For the cron job you will need a Machine to Machine Application. This test application which was generated when the API was created was automatically configured as a Machine to Machine Application as can be seen in the screenshot below. - -![Machine to Machine Application Settings](/media/articles/architecture-scenarios/server-api/non-interactive-client-settings.png) - -## Configure Application's access to the API - -The final part of the Auth0 configuration is to allow the application access to the Timesheets API. Go back to the configuration of the API, and select the *Machine to Machine Application* tab. - -You will see the **Timesheets Import Job** application listed, and it should have access to API as can be seen from the switch to the right of the application name which indicates a value of `Authorized`. If it does not indicate that the application is authorized, simply toggle the value of the switch from `Unauthorized` to `Authorized`. - -![Authorize Application](/media/articles/architecture-scenarios/server-api/authorize-client.png) - -You will also need to specify which scopes will be included in Access Tokens which are issued to the application when the application authorizes with Auth0. - -Expand the settings for the application by clicking on the down arrow to the far right, and you will see the list of available scopes. The cron job will only require the `batch:upload` scope as it will simply create new timesheets based on the timesheet entries in the external system. - -Once you have selected the `batch:upload` scope you can save the settings by clicking the **Update** button. - -![Assign Scopes](/media/articles/architecture-scenarios/server-api/assign-scopes.png) - -Now that we have designed our solution and discussed the configurations needed on Auth0 side, we can proceed with the implementation part. That's what the next paragraph is all about, so keep reading! - - -<%= include('./_stepnav', { - prev: ["1. Solution Overview ", "/architecture-scenarios/application/server-api/part-1"], next: ["3. Application Implementation", "/architecture-scenarios/application/server-api/part-3"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/server-api/part-3.md b/articles/architecture-scenarios/application/server-api/part-3.md deleted file mode 100644 index 5549f66eee..0000000000 --- a/articles/architecture-scenarios/application/server-api/part-3.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -description: Application Implementation for the Server + API architecture scenario -toc: true ---- - -# Server + API: Application Implementation - -In this section of the tutorial, we will take an in-depth look into our API and its associated Machine to Machine Application. - -::: 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 application 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. -::: - -We will configure one single endpoint that will be used for creating timesheet entries. The endpoint will be `/timesheets/upload` and the HTTP method `POST`. - -The API will expect a JSON object as input, containing the timesheet information. We will use the following JSON: - -```json -{ - 'user_id': '007', - 'date': '2017-05-10T17:40:20.095Z', - 'project': 'StoreZero', - 'hours': 5 -} -``` - -The API will print the JSON, so we can verify the contents and echo back a message like the following: `Created timesheet 14 for employee 007`. - -::: note - See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#1-define-the-api-endpoint) -::: - -### Secure the API endpoints - -::: panel-warning Configure the API -In order to secure your endpoints you need to have your API configured in the Auth0 Dashboard. For information on how to do that refer to the [Configure the API](#configure-the-api) paragraph of this document. -::: - -The first step towards securing our API endpoint is to get an Access Token as part of the Header and validate it. If it's not valid then we should return an HTTP Status 401 (Unauthorized) to the calling process. - -::: note - See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#2-secure-the-api-endpoint) -::: - -#### Get an Access Token - -To get an Access Token without using our application sample implementation, perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint with a payload in the following format: - -```json -{ - audience: "YOUR_API_IDENTIFIER", - grant_type: "client_credentials", - client_id: "${account.client_id}", - client_secret: "${account.client_secret}" -} -``` - -::: note - For more information on this refer to: [API Authorization: Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens). -::: - -## Check the application permissions - -Now we have secured our API's endpoint with an Access Token but we still haven't ensured that the process calling the API has indeed the rights to post a new timesheet entry. - -As discussed earlier in this doc, each Access Token may include a list of the permissions that have been granted to the client. These permissions are defined using the scope request parameter. For more information on how to configure this refer to the [Configure the Scopes](#configure-the-scopes) paragraph. - -For our endpoint we will require the scope `batch:upload`. - -::: note - See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#3-check-the-client-permissions) -::: - -### Implement the Machine to Machine Application - -In this section we will see how we can implement a Machine to Machine Application for our scenario. - -::: note - For simplicity reasons we will keep our implementations solely focused on the authentication and authorization part and configure our application to send a single hard-coded timesheet entry to the API. Also, we will print in the console, something we wouldn't do with a server running process. -::: - -### Get an Access Token - -We will start by invoking the Auth0 `/oauth/token` API endpoint in order to get an Access Token. - -In order to do so we will need the following configuration values: - -- **Domain**: The value of your Auth0 Domain. You can retrieve it from the *Settings* of your application at the [Auth0 Dashboard](${manage_url}/#/applications). This value will be a part of the API URL: `https://${account.namespace}/oauth/token`. - -- **Audience**: The value of your API Identifier. You can retrieve it from the *Settings* of your API at the [Auth0 Dashboard](${manage_url}/#/apis). - -- **Client ID**: The value of your Auth0 application's Id. You can retrieve it from the *Settings* of your application at the [Auth0 Dashboard](${manage_url}/#/applications). - -- **Client Secret**: The value of your Auth0 application's Secret. You can retrieve it from the *Settings* of your application at the [Auth0 Dashboard](${manage_url}/#/applications). - -Our implementation should perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint with a payload in the following format: - -```json -{ - "audience": "YOUR_API_IDENTIFIER", - "grant_type": "client_credentials", - "client_id": "${account.client_id}", - "client_secret": "${account.client_secret}" -} -``` - -For more information on this refer to: [API Authorization: Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens). - -::: note - See the implementation in [Python](/architecture-scenarios/application/server-api/cron-implementation-python#get-an-access-token). -::: - -## Invoke the API - -Now that we have an Access Token, which includes the valid scopes, we can invoke our API. - -In order to do so we will: -- Build a hard-coded timesheet entry in JSON format. -- Add the Access Token as an `Authorization` header to our request. -- Make the HTTP POST request. -- Parse the response and print it in the terminal (optional). - -::: note - See the implementation in [Python](/architecture-scenarios/application/server-api/cron-implementation-python#invoke-the-api). -::: - -<%= include('./_stepnav', { - prev: ["2. Auth0 Configuration", "/architecture-scenarios/application/server-api/part-2"], next: ["Conclusion", "/architecture-scenarios/application/server-api/part-4"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/server-api/part-4.md b/articles/architecture-scenarios/application/server-api/part-4.md deleted file mode 100644 index 35ba5464ba..0000000000 --- a/articles/architecture-scenarios/application/server-api/part-4.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -description: Conclusion for the Server + API architecture scenario -toc: true ---- - -# Server + API: Conclusion - -In this document we covered a simple scenario: an API, used to import timesheet entries in ExampleCo's systems, and a cron job, used by external contractors to send in their timesheets using this API. - -We learned about the Client Credentials Grant, what an Access Token is, how to configure an API in Auth0, how to configure a Machine to Machine Application to communicate securely with this API, how to define and secure our API endpoints, how to use the provided libraries to validate the Access Token and how to retrieve a new one from Auth0. - -We started by describing the business case and the requirements and went on explaining how each requirement can be met and the thought process behind each choice that was made. - -We used Node.js for the API implementation and Python for the non interactive server process, hopefully though after going through this document you are able to build this using the technologies you prefer. - -<%= include('./_stepnav', { - prev: ["3. Application Implementation", "/architecture-scenarios/application/server-api/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/spa-api/index.md b/articles/architecture-scenarios/application/spa-api/index.md deleted file mode 100644 index 92e1b4dbca..0000000000 --- a/articles/architecture-scenarios/application/spa-api/index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -order: 03 -title: SPA + API -image: /media/articles/architecture-scenarios/spa-api.png -extract: 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. -description: Explains the architecture scenario where a Single Page Web Application (SPA) talks to an API using OpenID Connect, and the OAuth 2.0 Implicit Grant Flow, to authenticate users with Auth0. -toc: true ---- - -# SPA + API - -In this scenario, we will build a Timesheet API for a fictitious company named ExampleCo. The API will allow adding timesheet entries for an employee or a contractor. - -We will also be building a Single Page Application (SPA) which will be used to log timesheet entries and send them to 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/application/spa-api/part-1#api-authentication-and-authorization)) -* For authorizing a user of a SPA, Auth0 supports the Implicit Grant (see [Implicit Grant](/architecture-scenarios/application/spa-api/part-1#implicit-grant)) -* Both the SPA and the API must be configured in the Auth0 Dashboard (see [Auth0 Configuration](/architecture-scenarios/application/spa-api/part-2#auth0-configuration)) -* User Permissions can be enforced using the Authorization Extension (see [Configure the Authorization Extension](/architecture-scenarios/application/spa-api/part-2#configure-the-authorization-extension)) -* The API will be secured by ensuring that a valid Access Token is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/architecture-scenarios/application/spa-api/part-3#implement-the-api)) -* The Auth0.js library can be used to authorize the user of the SPA and obtain a valid Access Token which can be used to call the API (see [Authorize the User](/architecture-scenarios/application/spa-api/part-3#authorize-the-user)) -* The SPA can pass the Access Token in the HTTP Authorization header when making calls to the API (see [Call the API](/architecture-scenarios/application/spa-api/part-3#call-the-api)) -* The SPA can display UI elements conditionally based on scopes granted to user (see [Display UI Elements Conditionally Based on Scope](/architecture-scenarios/application/spa-api/part-3#display-ui-elements-conditionally-based-on-scope)) - -::: - -## 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 to replace it with a SPA. 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. At the moment only a SPA is required to capture timesheet entries but in the future, the company plans on launching more applications, like a mobile app to accommodate their sales teams. Hence the company has decided to develop a single Timesheets API which will be used to log time not only by this server process but by all future applications 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. - -Two kinds of users will use this SPA: employees and managers. The employees should be able to read, create and delete their own timesheet entries, while the managers should be able to approve timesheets as well. - -<%= include('./_stepnav', { - next: ["1. Solution Overview", "/architecture-scenarios/application/spa-api/part-1"] -}) %> diff --git a/articles/architecture-scenarios/application/spa-api/part-1.md b/articles/architecture-scenarios/application/spa-api/part-1.md deleted file mode 100644 index fbda32a8d4..0000000000 --- a/articles/architecture-scenarios/application/spa-api/part-1.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -description: Solution Overview for the SPA + API architecture scenario -toc: true ---- - -# SPA + API: Solution Overview - -<%= include('../../_includes/_api-overview-of-solution.md') %> - -<%= include('../../_includes/_api-authentication-and-authorization.md') %> - -## Implicit Grant - -OAuth 2.0 provides several __grant types__ for different use cases. In this particular use case, we want to access the API from a [client-side app](/quickstart/spa). - -The SPA will use the OAuth 2.0 [Implicit Grant](/api-auth/grant/implicit) to do so. - -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` 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). - -Once the user authenticates, the application receives the `id_token` and `access_token` in the hash fragment of the URI. The application can now use the `id_token` to obtain information about the user, and `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, and if the application is a third party application, a consent page will be shown where the permissions, that will be given to the Client, are listed (for example, post messages, list contacts, and so forth). - -1. Auth0 redirects the user to the app with an `access_token` (and optionally an `id_token`) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment. - -1. The app can use the `access_token` to call the API on behalf of the user. - -## Authorization Extension - -The [Auth0 Authorization Extension](/extensions/authorization-extension) allows you to configure Roles, Groups, and Permissions, and assign them to Users. - -- The Permissions are actions that someone can do. For ExampleCo's business needs, we will configure four Permissions: read, create, delete and approve timesheets. -- The Roles are collections of Permissions. ExampleCo's timesheets app will be used by two kinds of users (employees and managers), with different permissions each, so we will configure two Roles: employee and manager. - -Since this covers our business case we will not create any Groups. - -The Authorization Extension will create a [Rule](/rules) which will read the Roles, Groups, and Permissions assigned to a user and add this information to the [User profile](/rules/current#rule-syntax) during the authentication flow. We can use this information to ensure that the `access_token` issued to a user only contains scopes which are allowed. We can later on proceed to customize our app, like disabling the Approve Timesheets functionality if the user does not have the required permission to do so. - -<%= include('./_stepnav', { - prev: ["Introduction", "/architecture-scenarios/application/spa-api"], next: ["2. Auth0 Configuration", "/architecture-scenarios/application/spa-api/part-2"] -}) %> diff --git a/articles/architecture-scenarios/application/spa-api/part-2.md b/articles/architecture-scenarios/application/spa-api/part-2.md deleted file mode 100644 index 27e262ac0b..0000000000 --- a/articles/architecture-scenarios/application/spa-api/part-2.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -description: Auth0 Configuration for the SPA + API architecture scenario -toc: true ---- - -# SPA + API: Auth0 Configuration - -In this section we will review all the configurations we need to apply at the [Auth0 Dashboard](${manage_url}). - -## Create the API - -Navigate to the [APIs section](${manage_url}/#/apis) of the dashboard, and click the **Create API** button. - -You will be asked to supply the following details for your API: - -- __Name__: a friendly name for the API. Does not affect any functionality. -- __Identifier__: a unique identifier for the API. 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. 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. For more details on the signing algorithms see the [Signing Algorithms paragraph](#signing-algorithms) below. - -![Create API](/media/articles/architecture-scenarios/spa-api/create-api.png) - -Fill in the required information and click the **Create** button. - -## 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 Tokens (JWTs) in Auth0](/jwt#what-is-the-json-web-token-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. - -::: note -For a more detailed overview of the JWT signing algorithms refer to [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/). -::: - -## Configure the Scopes - -Once the application has been created you will need to configure the Scopes which applications can request during authorization. - -In the settings for your API, go to the **Scopes** tab. In this section you can add the scopes for our business case: `read:timesheets`, `create:timesheets`, `delete:timesheets`, and `approve:timesheets`. - -![Add Scopes](/media/articles/architecture-scenarios/spa-api/add-scopes.png) - -## Create the Application - -There are four application types in Auth0: -- __Native__ (used by mobile or desktop apps), -- __Single Page Web Applications__, -- __Regular Web Applications__ and -- __Machine to Machine Applications__ (used by CLIs, Daemons, or services running on your backend). - -For this scenario we want to create a new Application for our SPA, hence we will use Single Page Application as the application type. - -To create a new Application, navigate to the [dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications}) menu option on the left. Click the __+ Create Application__ button. - -Set a name for your Application (we will use `Timesheets SPA`) and select `Single Page Web Applications` as the type. - -Click __Create__. - -![Create Application](/media/articles/architecture-scenarios/spa-api/create-client.png) - -That's it for now. When we are done with the SPA implementation we will revisit the dashboard and this Application's settings to make some changes in its configuration. - -## Configure the Authorization Extension - -You will need to ensure that the Authorization Extension is installed for your tenant. You can refer to the [Authorization Extension documentation](/extensions/authorization-extension#how-to-install) for details on how to do this. - -### Define Permissions - -You will now define the required Permissions, according to the scopes you have already defined: `read:timesheets`, `create:timesheets`, `delete:timesheets`, and `approve:timesheets`. - -In the Authorization Extension, click the **Permissions** tab, and then click on the **Create Permission** button. - -In the dialog, capture the details for each permission. - -Ensure that the name of the permission is exactly the same as the corresponding scope: - -![Create Permission](/media/articles/architecture-scenarios/spa-api/create-permission.png) - -Proceed to create the permissions for all the remaining scopes: - -![Permissions](/media/articles/architecture-scenarios/spa-api/permissions.png) - -### Define Roles - -Next let's configure the two Roles: employee and manager. - -Head over to the **Roles** tab, click the **Create Role** button, and select the **Timesheets SPA** application. - -Set the **Name** and **Description** to `Employee`, and select the `delete:timesheets`, `create:timesheets` and `read:timesheets` permissons. Click on **Save**. - -![Create Employee Role](/media/articles/architecture-scenarios/spa-api/create-employee-role.png) - -Next, follow the same process to create a `Manager` role, and ensure that you have selected all the permissions. - -![Create Manager Role](/media/articles/architecture-scenarios/spa-api/create-manager-role.png) - -### Assign Users to Roles - -You need to assign all users to either the `Manager` or the `Employee` role. - -You can do this by going to the **Users** tab in the Authorization Extension and selecting a user. - -On the user information screen, go to the **Roles** tab. Click **Add Role to User**, and select the appropriate role. - -![Add User to Role](/media/articles/architecture-scenarios/spa-api/add-user-role.png) - -### Configuring the Authorization Extension - -You will also need to ensure that the Rule for the Authorization Extension is published. - -To do so, click on your user avatar in the top right of the Authorization Extension, and select **Configuration**. - -![Navigate to Configuration](/media/articles/architecture-scenarios/spa-api/select-configuration.png) - -Make sure that **Permissions** are enabled and then click **Publish Rule**. - -![Pulish Rule](/media/articles/architecture-scenarios/spa-api/publish-rule.png) - -### Create a Rule to validate token scopes - -The final step in this process is to create a Rule which will validate that the scopes contained in an `access_token` is valid based on the permissions assigned to the user. Any scopes which are not valid for a user should be removed from the `access_token`. - -In your Auth0 Dashboard, go to the **Rules** tab. You should see the Rule created by the Authorization Extension: - -![Rules](/media/articles/architecture-scenarios/spa-api/rules-1.png) - -Click on the **Create Rule** button and select the **Empty Rule** template. You can give the Rule a name, such as **Access Token Scopes**, and then specify the following code for the Rule: - -```js -function (user, context, callback) { - if (context.clientName !== 'Timesheets SPA') { - return callback(null, user, context); - } - - var permissions = user.permissions || []; - var requestedScopes = context.request.body.scope || context.request.query.scope; - var filteredScopes = requestedScopes.split(' ').filter( function(x) { - return x.indexOf(':') < 0; - }); - Array.prototype.push.apply(filteredScopes, permissions); - context.accessToken.scope = filteredScopes.join(' '); - - callback(null, user, context); -} -``` - -The code above will ensure that all Access Tokens will only contain the scopes which are valid according to a user's permissions. Once you are done you can click on the **Save** button. - -Rules execute in the order they are displayed on the Rules page, so ensure that the new rule you created is positioned below the rule for the Authorization Extension, so it executes after the Authorization Extension rule: - -![Rules](/media/articles/architecture-scenarios/spa-api/rules-2.png) - -<%= include('./_stepnav', { - prev: ["1. Solution Overview", "/architecture-scenarios/application/spa-api/part-1"], next: ["3. API + SPA Implementation", "/architecture-scenarios/application/spa-api/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/spa-api/part-3.md b/articles/architecture-scenarios/application/spa-api/part-3.md deleted file mode 100644 index 2a6e8ea77c..0000000000 --- a/articles/architecture-scenarios/application/spa-api/part-3.md +++ /dev/null @@ -1,212 +0,0 @@ ---- -description: API and SPA Configuration for the SPA + API architecture scenario -toc: true ---- - -# SPA + API: API and SPA Configuration - -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 application 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 2 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/spa-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 Application permissions (scopes), but we will address this separately in the next paragraph of this document. - -For more information on validating Access Tokens, refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token). - -::: note -See the implementation in [Node.js](/architecture-scenarios/application/spa-api/api-implementation-nodejs#2-secure-the-api-endpoints) -::: - -### Check the Application's Permissions - -By now we have verified that the JWT is valid. The last step is to verify that the application 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/spa-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/spa-api/api-implementation-nodejs#4-determine-the-user-identity) -::: - -## Implement the SPA - -In this section we will see how we can implement a SPA for our scenario. - -### Authorize the user - -To authorize the user we will be using the [auth0.js library](/libraries/auth0js). You can initialize a new instance of the Auth0 application as follows: - -```js -var auth0 = new auth0.WebAuth({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - responseType: 'token id_token', - audience: 'YOUR_API_IDENTIFIER', - redirectUri: '${account.callback}', - scope: 'openid profile read:timesheets create:timesheets' -}); -``` - -You need to pass the following configuration values: - -- __clientID__:The value of your Auth0 Client Id. You can retrieve it from the Settings of your Application at the [Dashboard](${manage_url}/#/applications}). -- __domain__: The value of your Auth0 Domain. You can retrieve it from the Settings of your Application at the [Dashboard](${manage_url}/#/applications}). -- __responseType__: Indicates the Authentication Flow to use. For a SPA which uses the __Implicit Flow__, this should be set to `token id_token`. The `token` part, triggers the flow to return an `access_token` in the URL fragment, while the `id_token` part, triggers the flow to return an `id_token` as well. -- __audience__: The value of your API Identifier. You can retrieve it from the [Settings of your API](${manage_url}/#/apis}) at the Dashboard. -- __redirectUri__: The URL to which Auth0 should redirect to after the user has authenticated. -- __scope__: The [scopes](/scopes) which determine the information to be returned in the `id_token` and `access_token`. A scope of `openid profile` will return all the user profile information in the `id_token`. You also need to request the scopes required to call the API, in this case the `read:timesheets create:timesheets` scopes. This will ensure that the `access_token` has these scopes. - -To initiate the authentication flow you can call the `authorize()` method: - -```js -auth0.authorize(); -``` - -After the authentication, Auth0 will redirect back to the __redirectUri__ you specified when configuring the new instance of the Auth0 application. At this point you will need to call the `parseHash()` method which parses a URL hash fragment to extract the result of an Auth0 authentication response. - -The contents of the authResult object returned by parseHash depend upon which authentication parameters were used. It may include the following: - -- __idToken__: An `id_token` JWT containing user profile information -- __accessToken__: An `access_token` for the API, specified by the __audience__. -- __expiresIn__: A string containing the expiration time (in seconds) of the `access_token`. - -You also need to store the tokens returned by the authentication result in local storage to keep track of the fact that the user is logged in. You can also subsequently retrieve the `access_token` from local storage when calling your API. - -```js -this.auth0.parseHash((err, authResult) => { - if (authResult && authResult.accessToken && authResult.idToken) { - window.location.hash = ''; - // Store the authResult in local storage and redirect the user elsewhere - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - } else if (err) { - // Handle authentication error, for example by displaying a notification to the user - } -}); -``` - -::: note -See the implementation in [Angular 2](/architecture-scenarios/application/spa-api/spa-implementation-angular2#2-authorize-the-user) -::: - -### Get the User Profile - -::: panel Extract info from the token -This section shows how to retrieve the user info using the `access_token` and the [/userinfo endpoint](/api/authentication#get-user-info). To avoid this API call, you can just decode the `id_token` [using a library](https://jwt.io/#libraries-io) (make sure you validate it first). If you need additional user information consider using [our Management API](/api/management/v2#!/Users/get_users_by_id) from your backend. -::: - -The `client.userInfo` method can be called passing the returned `authResult.accessToken` in order to retrieve the user's profile information. It will make a request to the [/userinfo endpoint](/api/authentication#get-user-info) and return the `user` object, which contains the user's information, similar to the example below: - -```json -{ - "email_verified": "false", - "email": "test@example.com", - "clientID": "AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH", - "updated_at": "2017-02-07T20:50:33.563Z", - "name": "tester9@example.com", - "picture": "https://gravatar.com/avatar/example.png", - "user_id": "auth0|123456789012345678901234", - "nickname": "tester9", - "created_at": "2017-01-20T20:06:05.008Z", - "sub": "auth0|123456789012345678901234" -} -``` - -You can access any of these properties in the callback function passed when calling the `userInfo` function: - -```js -const accessToken = localStorage.getItem('access_token'); - -auth0.client.userInfo(accessToken, (err, profile) => { - if (profile) { - // Get the user’s nickname and profile image - var nickname = profile.nickname; - var picture = profile.picture; - } -}); -``` - -::: note -See the implementation in [Angular 2](/architecture-scenarios/application/spa-api/spa-implementation-angular2#3-get-the-user-profile) -::: - -### Display UI Elements Conditionally Based on Scope - -Based on the `scope` of the user, you may want to show or hide certain UI elements. To determine the scope issued to a user, you will need to store the scope which was initially requested during the authorization process. When a user is authorized, the `scope` will also be returned in the `authResult`. - -If the `scope` in the `authResult` is empty, then all the scopes which was requested was granted. If the `scope` in the `authResult` is not empty, it means a different set of scopes were granted, and you should use the ones in `authResult.scope`. - -::: note -See the implementation in [Angular 2](/architecture-scenarios/application/spa-api/spa-implementation-angular2#4-display-ui-elements-conditionally-based-on-scope) -::: - -### Call the API - -To access secured resources from your API, the authenticated user's `access_token` needs to be included in requests that are sent to it. This is accomplished by sending the `access_token` in an `Authorization` header using the `Bearer` scheme. - -::: note -See the implementation in [Angular 2](/architecture-scenarios/application/spa-api/spa-implementation-angular2#5-call-the-api) -::: - -### Renew the Access Token - -As a security measure, it is recommended that the lifetime of a user's `access_token` be kept short. When you create an API in the Auth0 dashboard, the default lifetime is `7200` seconds (2 hours), but this can be controlled on a per-API basis. - -Once expired, an `access_token` can no longer be used to access an API. In order to obtain access again, a new `access_token` needs to be obtained. - -Obtaining a new `access_token` can be done by repeating the authentication flow, used to obtain the initial `access_token`. In a SPA this is not ideal, as you may not want to redirect the user away from their current task to complete the authentication flow again. - -In cases like this you can make use of [Silent Authentication](/api-auth/tutorials/silent-authentication). Silent authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. This does however require that the user was already logged in via [SSO (Single Sign-On)](/sso). - -::: note -See the implementation in [Angular 2](/architecture-scenarios/application/spa-api/spa-implementation-angular2#6-renew-the-access-token) -::: - -<%= include('./_stepnav', { - prev: ["2. Auth0 Configuration", "/architecture-scenarios/application/spa-api/part-2"], next: ["Conclusion", "/architecture-scenarios/application/spa-api/part-4"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/spa-api/part-4.md b/articles/architecture-scenarios/application/spa-api/part-4.md deleted file mode 100644 index 1bd0228d29..0000000000 --- a/articles/architecture-scenarios/application/spa-api/part-4.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -description: Conclusion for the SPA + API architecture scenario -toc: true ---- - -# SPA + API: Conclusion - -In this document we covered a simple scenario involving an API used by a Single Page Application (SPA) to allow employees to capture their timesheets. - -We learned about the Implicit Grant, what an Access Token is, how to configure an API in Auth0, how to configure a SPA application to communicate securely with this API, how to define and secure our API endpoints, how to use the provided libraries to validate the Access Token and how to retrieve a new one from Auth0. - -We started by describing the business case and the requirements and went on explaining how each requirement can be met and the thought process behind each choice that was made. - -We used Node.js for the API implementation and Angular for the SPA. Hopefully though after going through this document you are able to build this using the technologies you prefer. - -<%= include('./_stepnav', { - prev: ["3. API + SPA Implementation", "/architecture-scenarios/application/spa-api/part-3"] -}) %> \ No newline at end of file diff --git a/articles/architecture-scenarios/application/web-app-sso/index.md b/articles/architecture-scenarios/application/web-app-sso/index.md deleted file mode 100644 index 4bca57ee11..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso/index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -order: 01 -title: Single Sign-On for Regular Web Apps -image: /media/articles/architecture-scenarios/web-oidc.png -extract: Traditional web application which needs to authenticate users using OpenID Connect. -description: Regular web app scenario which needs to authenticate users using OpenID Connect. -toc: true ---- - -# Single Sign-On for Regular Web Apps - -In this scenario, we will build a web application for a fictitious company named ExampleCo. The app is meant to be used by ExampleCo's employees and contractors. Employees will use their existing corporate directory (Active Directory), while contractors will be managed in a separate user store. - -::: panel TL;DR -* Auth0 supports open standards such as OAuth 2.0 and OpenID Connect (OIDC) for authentication and authorization (see [Which protocol to use](/architecture-scenarios/application/web-app-sso/part-1#which-protocol-to-use)) -* OIDC supports several different authorization flows - the most appropriate one for Web Applications being the Authorization Code Flow (see [Authentication Flow](/architecture-scenarios/application/web-app-sso/part-1#authentication-flow)) -* Your application will be configured in Auth0 as an application (see [Application](/architecture-scenarios/application/web-app-sso/part-2#application)) -* Identity Providers will be configured in Auth0 as a Connection (see [Connections](/architecture-scenarios/application/web-app-sso/part-2#connections)) -* Auth0 provides a Lock widget, which allow users to log in to the application (see [User Login](/architecture-scenarios/application/web-app-sso/part-3#user-login)) -* The web application needs to manage session state to keep track of the fact that the user is logged in. Along with this, Auth0 and the Identity Provider is also managing session information. (see [Session Management](/architecture-scenarios/application/web-app-sso/part-3#session-management)) -* Conversely, logging a user out also involves three layers of session management (see [User Logout](/architecture-scenarios/application/web-app-sso/part-3#user-logout)) -* Access Control can be managed with the Auth0 Authorization Extension (see [Access Control](/architecture-scenarios/application/web-app-sso/part-3#access-control)) -::: - -::: note -By _Regular Web App_, we mean an app that uses primarily server side, page `GET`, `POST`, and cookies for maintaining state. This is contrast with a Web _SPA_ (Single Page App), that heavily relies on client side JavaScript code calling an API. -::: - -## The Premise - -ExampleCo is a consulting startup company. Currently they have approximately 100 employees and they also outsource several activities to external contractors. Most of the employees work from the company's main office, but there are some teams that work remotely. Additionally, some employees frequently travel to customer locations and work from mobile devices. - -All employees and external contractors are required to fill in their timesheets every week using spreadsheets. The current system is inefficient and the company decided that they need to move to a better and more automated solution. - -The company evaluated several of the available timesheets application and concluded that it would be more cost-effective to build their own in-house solution, since they are looking for a very simple application at the moment. The app will be built using ASP.NET Core, since their developers are already using this technology and they can have the app ready in a week or so. - -### Goals & Requirements - -ExampleCo wants to launch the new solution quickly so they chose to start simple and build into it as they gather feedback from their employees. - -The application should be available to logged in users only. Each user will have a role, and based on this role, they should be able to perform certain actions and view specific data. - -::: panel Authentication vs Authorization -ExampleCo wants to __authenticate__ and __authorize__ each user. Authentication has to do with identity: verifying that the user is indeed who they claim to be. Authorization is about deciding which resources a user should have access to, and what they should be allowed to do with those resources. -::: - -ExampleCo's timesheets app needs to support two roles: _User_ and _Admin_: -- Someone with the User role can add timesheet entries, by specifying the date, the application and the hours worked. The Admin role also has this same right. -- Those with the User role should have access only to their own timesheets entries. -- Someone with the Admin role can additionally: - - Approve or reject timesheet entries of other users. - - Edit the application drop-down list of values (add, edit, delete). - -Each user will be required to fill in their timesheets by the end of the week. They can either choose to register daily their timesheets or add the entries for the whole week together. The timesheets will have to be reviewed and approved by an Admin. The rejected entries will have to be updated by each employee and re-submitted for approval. - -The company uses Active Directory for all employees and employees will sign into the Timesheet application using their Active Directory credentials. The external contractors can sign in with a username and password. Contractors are not on ExampleCo's corporate directory. - -ExampleCo wants to minimize user login burden, but wants to maintain a level of security depending on the operation: submitting timesheet entries is lower risk than approving them. However the approved timesheets are used for customer charging so security is definitely a requirement. The authentication strategy should be flexible so it can adapt as the company grows. For example, they should easily be able to add additional authentication requirements, like multifactor authentication, for Admins. - -The solution should be available both to the employees with a physical presence in the company office, as well as to those working remotely, without the overhead of a VPN connection, hence the app should be deployed on a cloud provider like Heroku or Microsoft Azure. - -![Diagram of the solution](/media/articles/architecture-scenarios/web-app-sso/solution-diagram.png) - -<%= include('./_stepnav', { - next: ["1. Solution Overview", "/architecture-scenarios/application/web-app-sso/part-1"] -}) %> diff --git a/articles/architecture-scenarios/application/web-app-sso/part-1.md b/articles/architecture-scenarios/application/web-app-sso/part-1.md deleted file mode 100644 index 7671d8390c..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso/part-1.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -description: Regular web app scenario solution overview -toc: true ---- - -# SSO for Regular Web Apps: Solution Overview - -In this section, we'll cover the solution we're implementing, including details on identity management, protocols to use, and the authentication flow required. - -## Identity Management - -ExampleCo decided to use Auth0 as their Identity as a Service (IDaaS) provider. The reasoning behind this decision was that the company did not want to commit resources on training, implementation and maintenance of identity and access management. Furthermore, the company plans on building into this solution in the future, possibly adding a mobile native app and an API to push approved timesheets to their internal systems. Auth0 provides the flexibility to incorporate such changes in their architecture with minimum effort. - -::: note -Identity-as-Service ("IDaaS") is a cloud-based service for identity and access management. The offered services often include SSO, federated identity, password management, and more. -::: - -## Which protocol to use - -The next decision has to do with which protocol to use, OAuth 2.0 with OpenID Connect (OIDC) or SAML. - -::: note -Auth0 implements proven, common and popular identity protocols, both for consumer oriented web products (OAuth 2.0, OAuth 1.0, OpenID) and for enterprise deployments (SAML, WS-Federation, LDAP). You have complete freedom to use the one that best meets your business needs. -::: - -__OpenID Connect__ is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON identity tokens (JWT) delivered via the OAuth 2.0 protocol. - -::: panel OAuth vs OpenID Connect (OIDC) -OAuth 2.0 and OpenID Connect (OIDC) are often mistaken for the same thing, but this is not exact. -__OAuth 2.0__ is a protocol that lets you authorize one website (the consumer or application) to access your data from another website (the resource server or provider). For example, you want to authorize a website to access some files from your Dropbox account. The website will redirect you to Dropbox which will ask you whether it should provide access to your files. If you agree the website will be authorized to access your files from Dropbox. At the core, OAuth 2.0 is about resource access and sharing. -__OpenID Connect__, on the other hand, is a simple identity layer built on top of the OAuth 2.0 protocol. It gives 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. At the core, OIDC is concerned with user authentication. -::: - -__SAML__ is an XML-based protocol, that provides both authentication and authorization between trusted parties. - -Compared to SAML, OpenID Connect is lighter weight and simpler to deal with. SAML is proven, powerful and flexible, but for the requirements of this app, that flexibility and power is not required. Identity federation (one of the most compelling reasons for adopting SAML) is not required here either, And if it ever became a requirement, it can be easily handled by Auth0, in the same way it deals with AD (that uses LDAP). - -For these reasons, ExampleCo will use OpenID Connect for their implementation. - -## Authentication Flow - -OpenID Connect supports more than one flow for authentication. Since our scenario involves a regular web app we will use the __Authorization Code Flow__. - -The flow goes as follows: -1. The web app (called the __Client__ in OIDC terms) initiates the authentication request by redirecting the __user-agent__ (browser) to Auth0 (the __Authorization Server__ in OIDC terms). -1. Auth0 authenticates the user (via the user-agent). 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). The user logs in to the service (unless they are already logged in) and authorizes the application access. -1. Assuming the user grants access, Auth0 redirects the __user-agent__ back to the __Application__, along with an _authorization code_ in the querystring. -1. The Application sends the _authorization code_ to Auth0, along with the application credentials (`client_id` and `client_secret`), and asks for a token. -1. Auth0 authenticates the __Application__ (using the `client_id` and `client_secret`) and validates the _authorization code_. If valid, Auth0 responds back with an __ID Token__. - -![Diagram of the Authorization Code Flow](/media/articles/architecture-scenarios/web-app-sso/authz-code-flow.png) - -::: panel Form Post Response Mode -Another option is to use the __OAuth 2.0 Form Post Response Mode__ with `response_type=id_token&response_mode=form_post`. Due to the `response_type=id_token` request parameter, the response contains the `id_token` directly, instead of the authorization code, while the `response_mode=form_post` encodes the `id_token` with the rest of the Authorization Response parameters as HTML form values that are auto-submitted in the User Agent. This way you can have an optimized authentication flow (no need to exchange the code for an `id_token`), however you have to make sure that it is supported by the technology you are using to implement your app (ASP .NET Core middleware does support it). For more details refer to the [OAuth 2.0 Form Post Response Mode specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). -::: - -The __ID Token__ (usually referred to as `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. - -::: panel More on tokens -Tokens are alphanumeric strings used in token-based authentication. They allow users to authenticate with a username and password once and get a token in return which they can use from that point on. They have a limited lifetime duration. - -__JSON Web Tokens (JWTs)__ are tokens that conform to the [JSON Web Token Standard](https://tools.ietf.org/html/rfc7519) and contain information about an identity 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. JWTs can be signed using a secret (with the __HMAC__ algorithm) or a public/private key pair using __RSA__. You can find more information on JWT [here](/jwt). - -The ID Token, which is a JWT, conforms to an industry standard (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) and contains three parts: A header, a body and a signature. -- The header contains the type of token and the hash algorithm used on the contents of the token. -- The body, also called the payload, contains identity claims about a user. There are some claims with registered names, for things like the issuer of the token, the subject of the token (who the claims are about), and the time of issuance. Any number of additional claims with other names can be added, though care must be taken to keep the JWT within the browser size limitations for URLs. -- The signature is used by the recipient of a JWT to validate the integrity of the information conveyed in the JWT. -::: - -### How to validate an ID Token - -The validation of an ID Token requires several steps: -1. If the ID Token is encrypted, decrypt it using the keys and algorithms that the Application specified. -1. The Issuer Identifier for the OpenID Provider must match the value of the `iss` (issuer) claim. -1. The `aud` (audience) claim should contain the Application's `client_id` value. The ID Token must be rejected if the ID Token does not list the Application as a valid audience, or if it contains additional audiences not trusted by the Application. -1. If the ID Token contains multiple audiences, the Application should verify that an `azp` claim is present. -1. If an `azp` (authorized party) claim is present, the Application should verify that its `client_id` is the claim value. -1. The Application must validate the signature of ID Tokens according to JWS using the algorithm specified in the JWT `alg` header parameter. The Application must use the keys provided by the Issuer. -1. The `alg` value should be the default of `RS256` or the algorithm sent by the Application in the `id_token_signed_response_alg` parameter during registration. -1. If the JWT `alg` header parameter uses a MAC based algorithm such as `HS256`, `HS384`, or `HS512`, the octets of the UTF-8 representation of the client_secret corresponding to the `client_id` contained in the `aud` (audience) claim are used as the key to validate the signature. For MAC based algorithms, the behavior is unspecified if the `aud` is multi-valued or if an `azp` value is present that is different than the `aud` value. -1. The current time must be before the time represented by the `exp` claim. -1. The `iat` claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Application specific. -1. If a `nonce` value was sent in the Authentication Request, a `nonce` claim must be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Application should check the `nonce` value for replay attacks. The precise method for detecting replay attacks is Application specific. -1. If the `acr` claim was requested, the Application should check that the asserted claim value is appropriate. -1. If the `auth_time` claim was requested, either through a specific request for this claim or by using the `max_age` parameter, the Application should check the `auth_time` claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication. - -::: note -If you store ID Tokens on your server, you must do so securely. -::: - -<%= include('./_stepnav', { - prev: ["Introduction", "/architecture-scenarios/application/web-app-sso"], - next: ["2. Auth0 Configuration", "/architecture-scenarios/application/web-app-sso/part-2"] -}) %> diff --git a/articles/architecture-scenarios/application/web-app-sso/part-2.md b/articles/architecture-scenarios/application/web-app-sso/part-2.md deleted file mode 100644 index dc3f22ffe8..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso/part-2.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -description: Regular web app scenario configuration for Auth0 -toc: true ---- -# SSO for Regular Web Apps: Auth0 Configuration - -In this section we will review all the configurations we need to apply using the [Auth0 Dashboard](${manage_url}). - -## Application - -The Auth0 configuration part starts with registering the timesheets app at the Auth0 dashboard as an __application__. An application is making protected resource requests on behalf of the resource owner (end-user). - -::: note -The term "application" does not imply any particular implementation characteristics. An application can be a web app, a mobile app or an SPA. In the case of ExampleCo it is a ASP.NET Core web app. -::: - -The main characteristics of an application in Auth0 are: -- __Name__: The canonical name of the application. This is used to identify the application at the portal, emails, logs, and more. -- __Client ID__ (read-only): The unique identifier for the application. This is the ID used in the application when setting up authentication with Auth0. It is an auto-generated alphanumeric string. -- __Client secret__ (read-only): A string used to sign and validate tokens which will be used in the different authentication flows. It is auto-generated and it must be kept confidential. -- __Domain__: The domain name assigned to the Auth0 account. The format of the domain is `{account-name}.auth0.com` or `{account-name}.{location}.auth0.com`, for example `ExampleCo.auth0.com`. -- __Callback URL__: The URL where the user is redirected after they authenticate. - -### Create an Application - -ExampleCo's scenario involves only one application: the timesheets web app. Hence we have to configure one Application at Auth0 side. - -To register a database connection, go to the [dashboard](${manage_url}) and in the side navigation select [Applications](${manage_url}/#/applications). - -Click on the button __+ Create Application__. You will be prompted for the name and the type of the application. We will name our application `Timesheet-App` and select `Regular Web Applications` as the application type. - -![Create Application Dialog Box](/media/articles/architecture-scenarios/web-app-sso/new-client.png) - -When you click __Create__ you will be navigated to the [Quick Start view](${manage_url}/#/applications/${account.clientId}/quickstart). Here you can pick the technology you plan on using to build your app and the relevant how-to quickstart will be displayed. - -The other available views are: -- [Settings](${manage_url}/#/applications/${account.clientId}/settings): Here you can view and update the settings of your application. This is the page you will use to retrieve information like _Domain_, _Client ID_, and _Client Secret_. In this page you will also have to [set the __Callback URL__ for your application](#configure-callback-urls). -- [Addons](${manage_url}/#/applications/${account.clientId}/addons): Addons are plugins associated with an application in Auth0. Usually, they are third party APIs used by the application that Auth0 generates Access Tokens for (for example Salesforce, Azure Service Bus, Azure Mobile Services, SAP, and so forth). We will not use any Addons in this scenario. -- [Connections](${manage_url}/#/applications/${account.clientId}/connections): Connections are sources of users. We will use this view shortly to enable specific connections for our application. - -### Configure Callback URLs - -The __Allowed Callback URLs__ field contains the URL(s) where Auth0 will redirect to after the user has authenticated in order for the OpenID Connect to complete the authentication process. You can specify multiple valid URLs by comma-separating them. You can use the star symbol as a wildcard for subdomains, for example `*.google.com`. Make sure to specify the protocol, `http://` or `https://`, otherwise the callback may fail in some cases. - -The Callback URL for our sample project is `http://localhost:5000/signin-auth0`. Go ahead and set this value to the __Allowed Callback URLs__ field if you plan on using our sample, otherwise add the URL you chose to deploy your application to. - -## Connections - -The next step is to configure the identity providers that will be used for authentication at the web app. Each identity provides maps to a __connection__ in Auth0. Each application needs at least one connection, and each connection can be used for more than one application. - -ExampleCo needs to configure two connections: one Active Directory connection for the internal employees, and one Database connection for external parties. - -::: panel Supported identity providers -Auth0 supports a vast variety of protocols and identity providers: -- Social: Allow your users to log in using Google, Facebook, LinkedIn, Github, and many more. -- Enterprise: Allow your users to log in using Active Directory, ADFS, LDAP, SAML-P, and many more. -- Database connections: Create your own user store by configuring a new database connection, and authenticate your users using email/username and password. The credentials can be securely stored either in the Auth0 user store, or in your own database. -- Passwordless authentication: Allow your users to login without the need to remember a password and use an authentication channel like SMS or e-mail. -::: - -### Create a database connection - -To register a database connection, go to the [dashboard](${manage_url}) and in the side navigation select [Connections > Database](${manage_url}/#/connections/database). - -Click on the button __+ Create DB Connection__. You will be prompted for the name of the connection. We will name our connection `Timesheet-Users`. - -![Create DB Connection Dialog Box](/media/articles/architecture-scenarios/web-app-sso/new-db-conn.png) - -When you click __Save__ you will be navigated to the _Settings_ page for the new connection. Ensure that you enable your application to use this connection at the _Applications Using This Connection_ section. - -![Enable the application to use this DB connection](/media/articles/architecture-scenarios/web-app-sso/enable-client-db.png) - -For more information on database connections refer to [Database Identity Providers](/connections/database). - -### Create an Active Directory / LDAP Connection - -Next you need to configure your Active Directory / LDAP connection. Go to the [Auth0 dashboard](${manage_url}) and in the side navigation select the [Connections > Enterprise](${manage_url}/#/connections/enterprise)). - -There you need to create the AD / LDAP connection and install the AD Connector. You can find details in these documents: -- [How to connect your Active Directory with Auth0](/connections/enterprise/active-directory) -- [How to install the Active Directory/LDAP Connector](/connector) - -::: note -The AD/LDAP Connector, is a bridge between your Active Directory and the Auth0 Service. This bridge is necessary because AD is typically locked down to your internal network, and Auth0 is a cloud service running on a completely different context. -[More information](/connector/overview) -::: - -Once you have configured the connection and the connector, be sure to enable your application to use this AD / LDAP connection: - -![Enable the application to use this AD connection](/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png) - -::: panel Kerberos support -The AD/LDAP connector supports Kerberos to make it easer for your users to authenticate when they are on a domain-joined machine within the corporate network. To activate Kerberos on an Active Directory you have to simply enable the option in the dashboard. After enabling Kerberos you'll also be able to configure the __IP Ranges__. When users originate from these IP address ranges this information will be exposed in the SSO endpoint which means client-side SDKs like auth0.js and the Lock will be able to detect Kerberos support and allow Integrated Windows Authentication. -[More information](/connector/kerberos) - -::: note -If you enable Kerberos then you need to make some changes to the AD/LDAP's configuration file. For details refer to: [Modify the AD/LDAP Connector Settings](/connector/modify). -::: - -Now that we have designed our solution and discussed the configurations needed on Auth0 side, we can proceed with integrating Auth0 with our timesheets web app. That's what the next paragraph is all about, so keep reading! - -<%= include('./_stepnav', { - prev: ["1. Solution Overview", "/architecture-scenarios/application/web-app-sso/part-1"], - next: ["3. Application Implementation", "/architecture-scenarios/application/web-app-sso/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/web-app-sso/part-3.md b/articles/architecture-scenarios/application/web-app-sso/part-3.md deleted file mode 100644 index 52afc1b4f7..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso/part-3.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -description: Regular web app scenario application implementation -toc: true ---- -# SSO for Regular Web Apps: Application Implementation - -Let's walk through the implementation of our regular web application. We used ASP .NET Core for the implementation, you can find the code in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-webapp-oidc). - -The sample contains an application which uses Active Directory integration to authenticate company employees and an Auth0 database connection for external contractors. Authorization is implemented using rules and claims as we will see in detail in this paragraph. - -## User Login - -Auth0 provides a Lock widget which serves as a login component for your application, meaning that you do not have to implement your own login screen. The Lock widget seamlessly integrates with all of the connections you configure inside your Auth0 dashboard, whether they be database, social or enterprise connections. - -There are a number of different ways in which you can implement a Login screen using a web application and Auth0: -- __Hosted Lock__: Use an instance of the Lock widget which is hosted on the Auth0 infrastructure. -- __Embedded Lock__: Embed the Lock widget inside a web page of your application. You have some customization options for the actual Lock widget, and full control over the rest of the HTML on the page. -- __Custom UI__: Develop a completely custom web page for the login screen. The custom HTML form will post back to your server which will in turn authenticate the user using the Authentication API. For more information on when to use a Custom UI refer to [Lock vs. a Custom UI](/libraries/when-to-use-lock). - -The recommended best practice is to use Hosted Lock because it is the most secure option and the easiest way to enable users to log in to your application. - -### Automate Home Realm Discovery (HRD) - -By default, Lock will display all the connections available for login. Selecting the appropriate Identity Providers from multiple options is called _Home Realm Discovery (HRD)_. In our case the options are either authenticating with Active Directory (for company employees) or using email/password for our database connection (external contractors). - -You may however want to avoid that first step, where the user needs to choose the Identity Provider (IdP), and have the system identify it instead of asking every time. Lock offers you the following options: - -- __Identify the IdP programatically__: When you initiate an authentication transaction with Auth0 you can optionally send a `connection` parameter. This value maps directly with any connection defined in your dashboard. When using the Hosted version of Lock by calling the [`/authorize`](/api/authentication/reference#database-ad-ldap-passive-) endpoint, you can pass along a `connection` query string parameter containing the name of the connection. Alternatively, if you are using Embedded Lock, this is as simple as writing `auth0.show({connections: ['YOUR_CONNECTION']});`. - - There are multiple practical ways of getting the `connection` value. One of them is to use __vanity URLs__: for example, company employees will use `https://internal.yoursite.com`, while external contractors will use `https://external.yoursite.com`. - -- __Use email domains__: Lock can use email domains as a way of routing authentication requests. Enterprise connections in Auth0 can be mapped to `domains`. If a connection has this setup, then the password textbox gets disabled automatically when typing an e-mail with a mapped domain. Note that you can associate multiple domains to a single connection. - -For additional information on this topic refer to: [Selecting the connection in Auth0 for multiple login options](/libraries/lock/v10/selecting-the-connection-for-multiple-logins). - -## Session Management - -When talking about managing sessions, there are typically three layers of sessions we need to consider: - -- __Application Session__: The first is the session inside the application. Even though your application uses Auth0 to authenticate users, you will still need to keep track of the fact that the user has logged in to your application. In a normal web application this is achieved by storing information inside a cookie. -- __Auth0 session__: Next, Auth0 will also keep a session and store the user's information inside a cookie. Next time when a user is redirected to the Auth0 Lock screen, the user's information will be remembered. -- __Identity Provider session__: The last layer is the Identity Provider, for example Facebook or Google. When you allow users to sign in with any of these providers, and they are already signed into the provider, they will not be prompted to sign in. They may simply be required to give permissions to share their information with Auth0 and in turn your application. - -When developing a web application, you will therefore need to keep track of the fact that the user has logged in to your Web application. You can do this by making use of a cookie-based session to keep track of the fact that the user has signed in, and also store any of the user related information or tokens. - -::: panel How do I control the duration of the user's local application session? Can I drive that from Auth0? -The web app has full control over the user's local application session. How this is done usually depends on the web stack being used (for example, ASP.NET). Regardless, all approaches ultimately use one or more cookies to control the session. The developer can choose to use the expiration of the JWT `id_token` returned by Auth0 to control their session duration or ignore it completely. Some developers store the `id_token` itself in session state and end the user's session when it has expired. - -The reason why you would use the expiration of the token to determine the expiration of the local session is because it gives you centralized control of the duration of a user session from the Auth0 Dashboard. -::: - -The login flow is as follows: - -![Login Flow Diagram](/media/articles/architecture-scenarios/web-app-sso/login-flow.png) - -1. __Initiate OIDC Authentication Flow__: The user's browser will send a request to Auth0 to initiate the OIDC flow. -1. __Set SSO Cookie__: Auth0 will set a cookie to store the user's information. -1. __Code exchange and return ID Token__: Auth0 will make a request back to the web server and return the code. The web server will exchange the code for an ID Token. -1. __Set auth cookie and send response__: The web server will send a response back to the browser and set the application authentication cookie to store the user's session information. -1. __Auth cookie sent with every subsequent request__: The application authentication cookie will be sent on every subsequent request as proof that the user is authenticated. - -::: panel How does Auth0's SSO session impact the application's session? -Auth0 manages its own single-sign-on session. Applications can choose to honor or ignore that SSO session when it comes to maintaining their own local session. The Lock widget even has a special feature where it can detect if an Auth0 SSO session exists and ask the user if they wish to log in again as that same user. - -![Lock Widget SSO](/media/articles/architecture-scenarios/web-app-sso/sso-login.png) - -If they do so, they are signed in without having to re-enter their credentials with the actual IDP. Even though the user didn't authenticate, the application still performs an authentication flow with Auth0 and obtains a new `id_token`, which can be used to then manage the new local application session. -::: - -**See the implementation in [ASP.NET Core](/architecture-scenarios/application/web-app-sso/implementation-aspnetcore#configure-the-cookie-and-oidc-middleware)**. - -## User Logout - -When logging the user out, you will once again need to think about the three layers of sessions which we spoke about before: -- __Application Session__: You need to log out the user from your Web Application, by clearing their session. -- __Auth0 session__: You need to log out the user from Auth0. To do this you redirect the user to `https://${account.namespace}/v2/logout`. Redirecting the user to this URL clears all single sign-on cookies set by Auth0 for the user. -- __Identity Provider session__: Although this is not common practice, you can force the user to log out from the Identity Provider used, for example Facebook or Google. To do this add a `federated` querystring parameter to the logout URL: `https://${account.namespace}/v2/logout?federated`. - -To redirect a user after logout, add a `returnTo` querystring parameter with the target URL as the value: `https://${account.namespace}/v2/logout?returnTo=http://www.example.com`. Note, that you will need to add the `returnTo` URL as an __Allowed Logout URLs__. For more information on how to implement this refer to: [Logout](/logout). - -The logout flow (not including federated logout) is as follows: - -![Logout Flow Diagram](/media/articles/architecture-scenarios/web-app-sso/logout-flow.png) - -1. __Initiate Logout Flow__: The logout flow will be initiated from the browser, for example by the user clicking a _Logout_ link. A request will be made to the web server. -1. __Clear user’s local session__: The user's Application Session / Cookie will be cleared. -1. __Redirect browser to Auth0 Logout__: The user's browser will be redirected to the Auth0 Logout URL. -1. __Clear SSO Cookie__: Auth0 will clear the user's SSO Cookie. -1. __Redirect to post-logout URL__: Auth0 will return a redirect response and redirect the user's browser to the `returnTo` querystring parameter. - -**See the implementation in [ASP.NET Core](/architecture-scenarios/application/web-app-sso/implementation-aspnetcore#implement-the-logout)**. - -## Access Control - -Authorization refers to the process of determining what actions a user can perform inside your application. - -You can either implement authorization directly inside your application, independently of Auth0, or use one of the available ways to retrieve the user authorization levels, put them as authorization claims inside the `id_token` and validate these claims inside your application, once you retrieve the token, to control access. - -There are various ways in which you can retrieve and set the user authorization claims when using Auth0: -- By configuring and using the [Auth0 Authorization Extension](/extensions/authorization-extension). -- By using Active Directory groups. These can be used in combination with the Authorization Extension by mapping Active Directory Groups to Groups you define using the Authorization extension. -- Add metadata to the user's profile by making use of [rules](/rules#add-roles-to-a-user). -- By calling an external services from inside a [rule](/rules). - -Since in our case the company has already Active Directory set up, we will enforce access control using the Authorization Extension in combination with Active Directory groups. - -::: panel Authorization Extension -At this point in time the authorization extension is primarily designed to enforce coarse-grained authorization, for example to control access to an application based on a user's group membership. It is not necessarily designed to control fine-grained access (such as whether a user can perform a specific action inside the application), even though this is how we are utilizing it in this instance. -::: - -All users will implicitly be regular users, but timesheet administrators will be assigned to an `Admin` group which will allow them to approve timesheets. The Authorization Extension allows for mapping groups to existing group membership. - -All timesheet administrators will be assigned to the `Timesheet Administrators` group on Active Directory, which will be automatically mapped to the `Admin` group inside the Timesheet Application. - -When you install the Authorization Extension, it creates a rule in the background, which does the following: -1. Determine the user's group membership. -1. Store the user's group membership info as part of the `app_metadata`. -1. Add the user's group membership to the outgoing token. -1. Verify that the user has been granted access to the current application. - - -### Install the Authorization Extension - -To install the Authorization extension navigate to the [Extensions](${manage_url}/#/extensions) view of your Auth0 Dashboard, and select and install the Auth0 Authorization extension. - -![Install the Authorization Extension](/media/articles/architecture-scenarios/web-app-sso/install-authz-ext.png) - -Once installed, you will see the app listed under _Installed Extensions_. - -When you click on the link to open the extension for the first time, you will be prompted to provide permission for the extension to access your Auth0 account. If you do so, you will be redirected to the Authorization Dashboard. - -Once on the Authorization Dashboard, navigate to Groups in the navigation menu, and create a new group called `Admin`. - -![Create Admin Group](/media/articles/architecture-scenarios/web-app-sso/create-admin-group.png) - -After the group has been added you can click on the new group to go to the group management section. Go to the _Group Mappings_ tab and add a new group mapping which will map all Active Directory users in the `Timesheet Admins` groups to the `Admin` group you just created. - -![Add Admin Group Mapping](/media/articles/architecture-scenarios/web-app-sso/add-group-mapping.png) - -Once you click __Save__ you can see the new mapping listed. - -![View Admin Group Mapping](/media/articles/architecture-scenarios/web-app-sso/view-group-mapping.png) - -With the mapping configured you only need to maintain membership to the `Timesheet Admins` group in Active Directory, and those users will be automatically mapped to the `Admin` group inside our application. - -For more information refer to the [Authorization Extension documentation](/extensions/authorization-extension). - -### Enforce permissions in your application - -When you installed the Authorization Extension, it also created an Auth0 rule which will add an `authorization` claim with all the authorization related settings for a particular user. The groups for a user will be added as a sub-claim of the `authorization` claim called `groups` and all the groups a user belongs to will be added as an array to this claim. This is an example of what JSON payload of a ID Token may look like with the groups listed: - -```json -{ - "sub": "1234567890", - "name": "John Doe", - "authorization": { - "groups": ["Admin"] - } -} -``` - -In your application you will therefore need to decode the ID Token returned when a user is authenticated, and extract the groups which a user belongs to from the `authorization` claim. You can then store these groups, along with other user information inside the user's session, and subsequently query these to determine whether a user has permissions to perform a certain action based on their group membership. - -::: note -See the implementation in [ASP.NET Core](/architecture-scenarios/application/web-app-sso/implementation-aspnetcore#implement-admin-permissions). -::: - -<%= include('./_stepnav', { - prev: ["2. Auth0 Configuration", "/architecture-scenarios/application/web-app-sso/part-2"], - next: ["4. Conclusion", "/architecture-scenarios/application/web-app-sso/part-4"] -}) %> diff --git a/articles/architecture-scenarios/application/web-app-sso/part-4.md b/articles/architecture-scenarios/application/web-app-sso/part-4.md deleted file mode 100644 index b3c4be4d57..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso/part-4.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -description: Regular web app scenario conclusion -toc: true ---- -# SSO for Regular Web Apps: Conclusion - -In this tutorial we covered a simple scenario: a regular web app, hosted in the cloud, using Auth0 for authentication, while utilizing the existing Active Directory user store. We learned what OpenID Connect offers and why it was preferable for this business case, how the Authentication Flow works, what an ID Token is and how to validate and manipulate it, how to configure applications and connections on Auth0 dashboard, how to implement user login and logout using Lock, and how session management and access control works. - -We started by describing the business case and the requirements and went on explaining how each requirement can be met and the thought process behind each choice that was made. - -We used ASP .NET Core for the sample web app implementation, hopefully though after going through this document you are able to build such a web app using the framework you prefer. - -<%= include('./_stepnav', { - prev: ["3. Application Implementation", "/architecture-scenarios/application/web-app-sso/part-3"] -}) %> diff --git a/articles/architecture-scenarios/application/web-saml.md b/articles/architecture-scenarios/application/web-saml.md deleted file mode 100644 index bfab970284..0000000000 --- a/articles/architecture-scenarios/application/web-saml.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -order: 05 -title: Regular Web App (using SAML) -image: /media/articles/architecture-scenarios/web-saml.png -extract: Traditional web application which needs to authenticate users using SAML2 -description: Explains the architecture scenario of using a traditional web application to authenticate users using SAML2. -beta: true ---- - -# Regular Web App (using SAML) - -::: note -This architecture scenario is under construction and will be updated soon. -::: - -![](/media/articles/architecture-scenarios/web-saml.png) - -In this scenario you have a traditional web application which needs to authenticate users using SAML2. The end result of the SAML flow after a user has successfully authenticated is a POST of the SAML Response (which contains SAML Assertions about the user) to a server-side endpoint (aka callback) in the Application. The Application therefore needs some SAML library that can process that response, validate the user, and create a local login session, which usually stored using one or more cookies. - -::: note -In this scenario an Access Token is also returned but it is rarely used since their is no API involved against which the user needs to be authenticated. -::: - -## Read More - -The following is a list of articles on this website which will help you to implement this scenario: - -* [Lock](/libraries/lock) -* [SAML](/saml-configuration) diff --git a/articles/architecture-scenarios/b2b-b2e.md b/articles/architecture-scenarios/b2b-b2e.md new file mode 100644 index 0000000000..590a1cea72 --- /dev/null +++ b/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/articles/architecture-scenarios/b2b.md b/articles/architecture-scenarios/b2b.md new file mode 100644 index 0000000000..ec33e404f6 --- /dev/null +++ b/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/articles/architecture-scenarios/b2c.md b/articles/architecture-scenarios/b2c.md new file mode 100644 index 0000000000..f9e43afa16 --- /dev/null +++ b/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/articles/architecture-scenarios/b2e.md b/articles/architecture-scenarios/b2e.md new file mode 100644 index 0000000000..a35f10a932 --- /dev/null +++ b/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/articles/architecture-scenarios/business/b2b-b2e.md b/articles/architecture-scenarios/business/b2b-b2e.md deleted file mode 100644 index 7465dc745b..0000000000 --- a/articles/architecture-scenarios/business/b2b-b2e.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -order: 07 -title: Business to Business + Enterprise 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 ---- - -# Business to Business + Enterprise 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) -* [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/articles/architecture-scenarios/business/b2b.md b/articles/architecture-scenarios/business/b2b.md deleted file mode 100644 index 11bf1641ee..0000000000 --- a/articles/architecture-scenarios/business/b2b.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -order: 05 -title: Business to Business Identity Scenarios -image: /media/articles/architecture-scenarios/b2b.png -extract: In this scenario you usually have a larger SAAS application, like Zendesk for example, where their customers are typically other companies which are registered as tenants. -description: Explains the architecture scenario of B2B with large SAAS application. -beta: true ---- - -# Business to Business Identity Scenarios - -::: note -This architecture scenario is under construction and will be updated soon. -::: - -![](/media/articles/architecture-scenarios/b2b.png) - -In this scenario you usually have a larger SAAS application, like Zendesk for example, where their customers are typically other companies which are registered as tenants. Each of these companies (also referred to as tenants) will have their own set of users who can access the information of that tenant on the SAAS application. - -When a tenant is smaller, these users can be stored and authenticated with a Database connection (username/password). Some of the tenants may also be large enterprise companies who wants federate their enterprise directory so they can manage their own users and the users can log in with their existing enterprise credentials. - -## 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) -* [Using Auth0 in SaaS, multi-tenant Apps](/saas-apps) -* [Identity Providers supported by Auth0](/identityproviders) -* [Connect Active Directory with Auth0](/connections/enterprise/active-directory) -* [Social Login](https://auth0.com/learn/social-login/) diff --git a/articles/architecture-scenarios/business/b2c.md b/articles/architecture-scenarios/business/b2c.md deleted file mode 100644 index 17f31735d7..0000000000 --- a/articles/architecture-scenarios/business/b2c.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -order: 04 -title: Business to Consumer Identity Scenarios -image: /media/articles/architecture-scenarios/b2c.png -extract: Usually eCommerce or SAAS applications which have end users (consumers) as customers and the application typically used OpenID Connect as a protocol to communicate with Auth0. -description: Explains the architecture scenario B2C with an eCommerce or SAAS application. -beta: true ---- - -# Business to Consumer Identity Scenarios - -::: note -This architecture scenario is under construction and will be updated soon. -::: - -![](/media/articles/architecture-scenarios/b2c.png) - -Usually eCommerce or SAAS applications which have end users (consumers) as customers and the application typically used OpenID Connect as a protocol to communicate with Auth0. - -Users are created and stored with a Database connection (username/password) which they can then later use to log in, or alternatively users can use a social connection such as Facebook, Twitter, Google, and so on to log in. Passwordless connections are also common with B2C. - -## 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) -* [Database Identity Providers](/connections/database) -* [Import users to Auth0](/connections/database/migrating) -* [Social Login](https://auth0.com/learn/social-login/) -* [Passwordless](/connections/passwordless) diff --git a/articles/architecture-scenarios/business/b2e.md b/articles/architecture-scenarios/business/b2e.md deleted file mode 100644 index b66f66c4c7..0000000000 --- a/articles/architecture-scenarios/business/b2e.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -order: 06 -title: Business to Enterprise 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. -beta: true ---- - -# Business to Enterprise Identity Scenarios - -::: note -This architecture scenario is under construction and will be updated soon. -::: - -![](/media/articles/architecture-scenarios/b2e.png) - -In this scenario you have a large organization who wants to federate their existing enterprise directory service to allow employees to log in to the various internal, as well as 3rd party applications, using their existing enterprise credentials. - -The 3rd party applications will typically be configured to use SAML as a protocol to communicate with Auth0, whereas the internal applications will more typically use OpenID Connect to communicate with Auth0. - -Since there are usually multiple configured applications, SSO (single sign-on) is important. Often times some sort of dashboard UI is used to host shortcuts to all the applications that a given user has access to. In that case, users typically first log into the dashboard and then jump to the various applications they wish to use, and each jump uses SSO to facilitate automatic login. - -## 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) -* [SAML](/saml-configuration) -* [What is SSO (Single Sign On)?](/sso) -* [Auth0 SSO Dashboard (sample)](https://github.com/auth0-samples/auth0-sso-dashboard) diff --git a/articles/architecture-scenarios/checklists.md b/articles/architecture-scenarios/checklists.md new file mode 100644 index 0000000000..16712907ca --- /dev/null +++ b/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/articles/architecture-scenarios/implementation-resources.md b/articles/architecture-scenarios/implementation-resources.md new file mode 100644 index 0000000000..b4c4f6a955 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md b/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md new file mode 100644 index 0000000000..b38753d752 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md b/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md new file mode 100644 index 0000000000..4414be9c8f --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md b/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md new file mode 100644 index 0000000000..5d0ca8d405 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-branding.md b/articles/architecture-scenarios/implementation/b2b/b2b-branding.md new file mode 100644 index 0000000000..b2da74226e --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md b/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md new file mode 100644 index 0000000000..8f0c437182 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch.md new file mode 100644 index 0000000000..358e53464e --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md new file mode 100644 index 0000000000..01a2a4ce91 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md new file mode 100644 index 0000000000..835be1391e --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md new file mode 100644 index 0000000000..e4742e5f13 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md new file mode 100644 index 0000000000..818c04db04 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md new file mode 100644 index 0000000000..bbe597465c --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md b/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md new file mode 100644 index 0000000000..e3c2314ffe --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-logout.md b/articles/architecture-scenarios/implementation/b2b/b2b-logout.md new file mode 100644 index 0000000000..f818eb1ceb --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-operations.md b/articles/architecture-scenarios/implementation/b2b/b2b-operations.md new file mode 100644 index 0000000000..7efd77e295 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md b/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md new file mode 100644 index 0000000000..bdc3ed3749 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md b/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md new file mode 100644 index 0000000000..8f2fe1e387 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2b/b2b-qa.md b/articles/architecture-scenarios/implementation/b2b/b2b-qa.md new file mode 100644 index 0000000000..2aa5556410 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md b/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md new file mode 100644 index 0000000000..9d01f715a0 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md b/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md new file mode 100644 index 0000000000..daffa7e833 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md b/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md new file mode 100644 index 0000000000..4394f0b496 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-branding.md b/articles/architecture-scenarios/implementation/b2c/b2c-branding.md new file mode 100644 index 0000000000..cba76c1648 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md b/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md new file mode 100644 index 0000000000..896280664b --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch.md new file mode 100644 index 0000000000..8eed687f5e --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md new file mode 100644 index 0000000000..1712d77cc6 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md new file mode 100644 index 0000000000..3459fb54f8 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md new file mode 100644 index 0000000000..eb2a8942e8 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md new file mode 100644 index 0000000000..188827213e --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md new file mode 100644 index 0000000000..dc54e51cb3 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md b/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md new file mode 100644 index 0000000000..6e313784cb --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-logout.md b/articles/architecture-scenarios/implementation/b2c/b2c-logout.md new file mode 100644 index 0000000000..79659c64c7 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-operations.md b/articles/architecture-scenarios/implementation/b2c/b2c-operations.md new file mode 100644 index 0000000000..b10ab32dcc --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md b/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md new file mode 100644 index 0000000000..5065318caf --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md b/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md new file mode 100644 index 0000000000..df2c065de1 --- /dev/null +++ b/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/articles/architecture-scenarios/implementation/b2c/b2c-qa.md b/articles/architecture-scenarios/implementation/b2c/b2c-qa.md new file mode 100644 index 0000000000..e27135e1cf --- /dev/null +++ b/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/articles/architecture-scenarios/implementations/mobile-api/api-implementation-nodejs.md b/articles/architecture-scenarios/implementations/mobile-api/api-implementation-nodejs.md deleted file mode 100644 index f23828c963..0000000000 --- a/articles/architecture-scenarios/implementations/mobile-api/api-implementation-nodejs.md +++ /dev/null @@ -1,248 +0,0 @@ ---- -description: The Node.js implementation of the API for the Mobile + API architecture scenario -url: /architecture-scenarios/application/mobile-api/api-implementation-nodejs -toc: true ---- - -# 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 singing 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](/jwt) and ensures it bears the correct permissions to call the desired endoint. 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. You can typically use the URL of your application or API as the namespace. - -::: note -For more information on namespaced claims, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-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); -}); -``` \ No newline at end of file diff --git a/articles/architecture-scenarios/implementations/mobile-api/mobile-implementation-android.md b/articles/architecture-scenarios/implementations/mobile-api/mobile-implementation-android.md deleted file mode 100644 index 19ac56e82f..0000000000 --- a/articles/architecture-scenarios/implementations/mobile-api/mobile-implementation-android.md +++ /dev/null @@ -1,1406 +0,0 @@ ---- -description: The Android implementation of the API for the Mobile + API architecture scenario -url: /architecture-scenarios/application/mobile-api/mobile-implementation-android -toc: true ---- - -# 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 - - - - - -
    • - Invite-Only Applications + User Invitation Applications

      - Using Auth0 with invite-only applications, which are those where access is limited to a select group of previously-identified users. + Using Auth0 with applications where an administrator creates the user account and then invites the user to complete the signup process by setting a password.

    • diff --git a/articles/design/using-auth0-with-multi-tenant-apps.md b/articles/design/using-auth0-with-multi-tenant-apps.md index 2e7057a9b3..3aa8e483a1 100644 --- a/articles/design/using-auth0-with-multi-tenant-apps.md +++ b/articles/design/using-auth0-with-multi-tenant-apps.md @@ -1,44 +1,72 @@ --- -description: This articles discusses how you can use Auth0 with multi-tenant applications. +description: This article discusses how you can use Auth0 to secure multi-tenant applications. crews: crew-2 toc: true +topics: + - design + - multi-tenancy +contentType: concept +useCase: strategize --- -# Using Auth0 with Multi-Tenant Applications -In this article, we will discuss (at a high-level) how Auth0 can help you manage users for your multi-tenant applications. +# Using Auth0 to Secure Your Multi-Tenant Applications -Multi-tenancy refers to the software architecture principle where a single instance of software runs on a server that is accessible to multiple groups of users. +This article provides a high-level overview of how Auth0 can help you manage your multi-tenant applications. -When working with multi-tenant software, you can serve multiple customers from a single application instance running on one server (or pool of servers). This contrasts with single-tenant software, where you serve each customer with a dedicated software instance running on dedicated servers. In summation: +## What is multi-tenancy -| Tenancy Type | Definition | -| - | - | -| Multi-Tenant | One instance, multiple customers | -| Single-Tenant | One instance, one customer | +[Multi-tenancy](https://en.wikipedia.org/wiki/Multitenancy) is when a single instance of software runs on a server that is accessible to multiple groups of users. -We define **tenant** as a group of users who share access to one particular application instance. One example of this includes a company with multiple employees, all of whom have access to your SaaS offering. +Auth0's Public Cloud is an example of a multi-tenant application. Your applications, settings, and connections are a single tenant, which shares resources with other tenants in the Public Cloud. -When you use a multi-tenant setup, one single instance of your SaaS offering would be shared across multiple tenants (or multiple companies), each of whom has its own group of employees. However, each tenant has a dedicated share of that instance, and you can then customize each share to meet the needs of the tenant that's using it. Such customization includes (but isn't limited to) branding, functionality, and access control. +Please note that this article is **not about using multiple Auth0 tenant(s)**. It is about using Auth0 to secure your own multi-tenant application. -## Auth0 and Multi-Tenancy +## Auth0 and multi-tenancy -By using a single Auth0 tenant for all of *your* customers, you maintain simplicity in your architecture and are able to manage all of your authentication flows in one place. The primary method by which you can handle multi-tenancy is to use multiple [connections](identityproviders). +There are several ways you can secure multi-tenant applications with Auth0. You can handle your multi-tenancy needs with one of the following approaches: -::: note -We recommend that you [create multiple Auth0 tenants](https://github.com/auth0/auth0-multitenant-spa-api-sample) only if you need to share access to the Auth0 Dashboard with individual customers. -::: +* [Use multiple connections](#use-multiple-connections) +* [Identify different tenants by application](#identify-tenants-by-application) +* [Store tenant details in app_metadata](#store-tenant-details-in-app_metadata) +* [Use separate Auth0 tenants](#create-separate-auth0-tenants-for-each-customer) -## Use Multiple Connections +### Use multiple connections + +You can use multiple connections to handle your tenants. Each connection would represent and contain a different pool of users. ::: warning -Auth0 enforces a limit of 50 Database Connections for each [application](/applications). Users with Enterprise agreements do not have any Database Connections limits. +If you use [Lock](/libraries/lock) in your applications, Lock supports a maximum of **50 Database Connections** per [application](/applications). Enterprise Connections are not affected by this limit. If you use the New Universal Login Experience, Lock is not involved and this limitation therefore does not affect you. ::: -While using multiple [Connections](/identityproviders) introduces additional layers of complexity, there are several scenarios where this option might make sense: +Using multiple [Connections](/identityproviders) introduces additional layers of complexity, but there are several scenarios where the upsides of this option outweigh the downsides: * You have different Connection-level requirements, such as varying password policies, for each of your Applications. -* You have users from different Connections. For example, one app may have users providing username/password credentials, while another app handles Enterprise logins. +* You have user pools from different Connections. For example, one app may have users providing username/password credentials, while another app handles Enterprise logins. + +To implement this, you can call `/authorize` with a connection specified for the user, using the `connection` option in the [Auth0 SPA SDK](/libraries/auth0-spa-js), or by passing a `connection` parameter to the `authorize()` method in [Auth0.js](/libraries/auth0js/v9). ::: note -For additional assistance on how you can customize Auth0, please contact [Sales](https://auth0.com/?contact=true) to discuss possible architecture scenarios. +There are entity limits which may apply when using Auth0 libraries. See [Entity Limit Policy](/policies/entity-limits) for details. ::: + +### Identify tenants by application + +You can represent each of your tenants with a separate application in Auth0. + +Representing each of your tenants with an application allows you to configure each one differently. You can also enable/disable [connections](/connections) for individual applications if your tenants have varying requirements. Doing so, however, requires you to track the tenants to which your users belong within your application. Then, when they log in, you will need to specify the application they are to use. + +### Store tenant details in app_metadata + +Storing tenant details in the user [metadata](/users/concepts/overview-user-metadata#metadata-usage) is the simplest of the implementation scenarios we cover in this article. + +Using the identifier of your choice (e.g., `"tenant": "customer_12345"`), you can store tenant related details in the `app_metadata`. Doing so allows all of your users, regardless of which tenant to which they belong, to log in using one uniform method. + +You can check for this value in your application after users log in and are redirected. This will help you sort users. + +### Create separate Auth0 tenants for each customer + +You can create a new Auth0 tenant for each of your application's tenants. + +We recommend that you follow this approach only if you need to share access to the Auth0 Dashboard with individual customers. Otherwise, one of the above solutions is a more practical and easy to manage one than attempting to manage many Auth0 tenant dashboards, which is also not a scalable solution as your customer base grows. + +This method requires you to use a different set of Auth0 credentials when calling Auth0 APIs to authenticate users belonging to each customer, because you would be using different applications on different Auth0 tenants (with different Client IDs) for each of your customers. diff --git a/articles/design/web-apps-vs-web-apis-cookies-vs-tokens.md b/articles/design/web-apps-vs-web-apis-cookies-vs-tokens.md index d59ca69e09..534c8d6a6f 100644 --- a/articles/design/web-apps-vs-web-apis-cookies-vs-tokens.md +++ b/articles/design/web-apps-vs-web-apis-cookies-vs-tokens.md @@ -1,15 +1,19 @@ --- description: This page compares web applications to web APIs and cookies vs. Tokens. +topics: + - design + - web-apps + - cookies + - tokens + - apis +contentType: concept +useCase: strategize --- # Web Apps vs Web APIs / Cookies vs Tokens * For us **Web Apps** are the traditional server-side applications that use **cookie-based authentication**. -* **Web APIs**, on the other hand, represent for us a new breed of applications, typically single page apps (like Angular, Ember, Backbone, and so on) or native mobile apps (like iOS, Android, and so on) which consume APIs (written in Node, Ruby, ASP.NET or even a mix of those) and will benefit from **token based authentication**. - -::: note -Before moving forward, you might want to read these articles for more context: [Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/) and [10 Things You Should Know about Tokens](https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/). -::: +* **Web APIs**, on the other hand, represent for us a new breed of applications, typically single-page apps (like Angular, Ember, Backbone, and so on) or native mobile apps (like iOS, Android, and so on) which consume APIs (written in Node, Ruby, ASP.NET or even a mix of those) and will benefit from **token based authentication**. * **Cookie-based authentication** is implemented by each web platform differently, but at the end of the day, they all end up setting some cookie (tied to a session on the server) which represents the "authenticated user". On each request, that cookie is sent and the session is deserialized from some store (in memory if it's a single server or some persistent storage if it's a server farm). We provide SDKs for most of the platforms that will tie into the corresponding authentication subsystem (such as passport on node, IPrincipal on .NET or Java, and so on). @@ -17,6 +21,8 @@ Before moving forward, you might want to read these articles for more context: [ * For both approaches you can get the **same amount of information from the user**. That's controlled by the `scope` parameter sent in the login request (either using the [Auth0Lock](/lock), our [JavaScript library](https://github.com/auth0/auth0.js) or a plain link). The `scope` is a parameter of the `.signin({scope: 'openid name email'})` method which ends up being part of the querystring in the login request. You can get more details about this in the [Scopes Documentation](/scopes). -* By default we use `scope=openid` in **token-based authentication** to avoid having a huge token. You can control any [standard OpenID Connect claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) that you want to get in the token by adding them as scope values. For example, `scope=openid name email family_name address phone_number`. +* By default we use `scope=openid` in **token-based authentication** to avoid having a huge token. You can control any [standard OpenID Connect (OIDC) claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) that you want to get in the token by adding them as scope values. For example, `scope=openid name email family_name address phone_number`. + +* Finally, you can **mix token-based authentication** with **cookie-based authentication**. Take into account that cookies will work just fine if the web app and the API are served from the same domain, so you might not need token based authentication. Now, if you need to, we also return a JWT on the web app flow. Each of our SDKs will do it differently. If you want to call your APIs from JavaScript (instead of using the existing cookie), then somehow you have to set the ID Token in your webpage. One way of doing it is by setting it on your layout/master page--something like `window.token = ${"<%= id_token %>;"}`--and then getting it from anywhere in your JavaScript code. -* Finally, you can **mix token-based authentication** with **cookie-based authentication**. Take into account that cookies will work just fine if the web app and the API are served from the same domain, so you might not need token based authentication. Now, if you need to, we also return a JWT on the web app flow. Each of our SDK will do it differently. If you want to call your APIs from JavaScript (instead of using the existing cookie) then somehow you have to set the `id_token` in your webpage. One way of doing it is by setting it on your layout/master page something like `window.token = ${"<%= id_token %>;"}` and then you get it from anywhere in your JavaScript code. +<%= include('../_includes/_samesite_none') %> \ No newline at end of file diff --git a/articles/dev-centers/java.md b/articles/dev-centers/java.md index e385db98ab..7d3e89fcb1 100644 --- a/articles/dev-centers/java.md +++ b/articles/dev-centers/java.md @@ -2,6 +2,10 @@ title: Java Developer Center description: Resources and documentation for Java developers logo: java +topics: + - java +contentType: reference +useCase: strategize --- # Java SDK Developer Center @@ -10,7 +14,7 @@ Here at Auth0 we try to offer as many libraries as needed to ensure we make your ## Java Servlet -A simple servlet based solution, suitable if you are using a legacy application or alternate Web MVC Framework without Spring support. If your application only needs secured endpoints and the ability to programmatically work with a Principal object for GrantedAuthority checks this library is a good fit. +A simple servlet based solution, suitable if you are using a legacy application or alternate Web MVC Framework without Spring support. If your application only needs secured endpoints and the ability to programmatically work with a Principal object for GrantedAuthority checks, this library is a good fit. - [Documentation](/server-platforms/java) - [Library](https://github.com/auth0/auth0-servlet) @@ -22,9 +26,8 @@ A modern Java Spring library that allows you to use Auth0 with Java Spring for s - [Documentation](/server-platforms/java-spring-mvc) - [Library](https://github.com/auth0/auth0-spring-mvc) -- [Sample Project](https://github.com/auth0-samples/auth0-spring-mvc-sample): Simple sample project that demonstrates using Auth0 with Java Spring to create a Secured MVC Web Application. -- [Sample Project demonstrating Lock, auth0.js, Social Connection Login, Database Connection and Account Linking](https://github.com/auth0-samples/auth0-spring-boot-social-dbconnection-link): Extends the simpler [Auth0 Spring MVC Sample Project](https://github.com/auth0-samples/auth0-spring-mvc-sample) and demonstrates Social Login, Database Connection Login and [account linking](/link-accounts). In this app, you can choose to login either with a Social Login or a Database Connection. If you login using Social Login and have not already linked you DB Connection then you are requested to do so. You can find details on how to setup and use this sample application in the _README_ of the [GitHub repository](https://github.com/auth0-samples/auth0-spring-boot-social-dbconnection-link). -- [Sample Project demonstrating Passwordless Authentication, Multifactor Authentication opt-in & account linking](https://github.com/auth0-samples/auth0-spring-mvc-passwordless-mfa-sample): Extends the simpler [Auth0 Spring MVC Sample Project](https://github.com/auth0-samples/auth0-spring-mvc-sample) and demonstrates using Auth0 (including Lock Passwordless and Auth0.js) with Java Spring to create a Secured MVC Web Application using [Passwordless Authentication](/connections/passwordless), [Multifactor Authentication](/multifactor-authentication) Opt-in & [account linking](/link-accounts). You can find details on how to setup and use this sample application in the _README_ of the [GitHub repository](https://github.com/auth0-samples/auth0-spring-mvc-passwordless-mfa-sample. +- [Sample Project](https://github.com/auth0-samples/auth0-spring-mvc-sample): A simple sample project that demonstrates usage of Auth0 with Java Spring to create a Secured MVC Web Application. +- [Sample Project demonstrating Lock, auth0.js, Social Connection Login, Database Connection and Account Linking](https://github.com/auth0-samples/auth0-spring-boot-social-dbconnection-link): Extends the simpler [Auth0 Spring MVC Sample Project](https://github.com/auth0-samples/auth0-spring-mvc-sample) and demonstrates Social Login, Database Connection Login and [account linking](/users/concepts/overview-user-account-linking). In this app, you can choose to login either with a Social Login or a Database Connection. If you login using Social Login and have not already linked your DB Connection, then you are requested to do so. You can find details on how to setup and use this sample application in the _README_ of the [GitHub repository](https://github.com/auth0-samples/auth0-spring-boot-social-dbconnection-link). ## Java Spring Security MVC @@ -35,32 +38,32 @@ A modern Java Spring library that allows you to use Auth0 with Spring Security f - [Sample Project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample) ::: panel Authorization Code Grant -All three technologies displayed above, adopt the `Oauth2 / OIDC Authorization Code Grant` flow in which authentication results in a callback to the server-side application with a `code`. This is then exchanged for [id_token](/tokens/id_token) and [access_token](/tokens/access_token) on the server-side (as part of the callback), and once the tokens have been received by the application, then `UserProfile` information can also be retrieved via request with a valid Token. +All three technologies displayed above, adopt the `Oauth2 / OIDC Authorization Code Grant` flow in which authentication results in a callback to the server-side application with a `code`. This is then exchanged for [ID Token](/tokens/id_token) and [Access Token](/tokens/access_token) on the server-side (as part of the callback) and once the tokens have been received by the application, then `UserProfile` information can also be retrieved via request with a valid Token. ::: ## Java Spring Security API -A modern Java Spring library that allows you to use Auth0 with Spring Security. Leverages Spring Boot dependencies. Validates the JWT from Auth0 in every API call to assert authentication according to configuration. This library would be suitable for headless APIs and SPA (single page application) backend end server scenarios. +A modern Java Spring library that allows you to use Auth0 with Spring Security. Leverages Spring Boot dependencies. Validates the JWT from Auth0 in every API call to assert authentication according to configuration. This library would be suitable for headless APIs and SPA (single-page application) backend end server scenarios. - [Documentation](/server-apis/java-spring-security) - [Library](https://github.com/auth0/auth0-spring-security-api) - [Sample Project](https://github.com/auth0-samples/auth0-spring-security-api-sample) -- [Companion SPA Applications](https://github.com/auth0-samples/auth0-spring-security-api-client-samples): Sample application that works as a companion for the [Auth0 Spring Security API Sample](https://github.com/auth0-samples/auth0-spring-security-api-sample) and [Auth0 Spring Security API Resource Server Sample](#auth0-resource-server-sample-using-spring-boot-and-spring-security). This sample provides an easy to understand seed project for users wishing to combine Java Spring Security API Server with a single page application front-end. The sample can run in two different modes: - - The SPA and API Server trust one another, and share the same Auth0 application information. In other words, they both have the same ClientId and therefore share the same Audience in their JWT Tokens. Hence the JWT Token received upon successful authentication in the SPA application is also passed in the Authorization Bearer header of the AJAX requests to the API Server. The API Server accepts the audience as it is the same as its own. - - The SPA application and API Server each have their own Auth0 Application on a shared Tenant (Account / Domain). In this situation, each has a different ClientId, and the Audience of the JWT Token generated for each application is different. The SPA application logs in and receives a JWT Token for authentication / authorization checks local to the SPA application. When making AJAX requests to the API Server, a delegation token is used instead - in effect, the SPA application swaps its own JWT Token for a JWT Token that is valid for requests to the API Server. +- [Companion SPA Applications](https://github.com/auth0-samples/auth0-spring-security-api-client-samples): A sample application that works as a companion for the [Auth0 Spring Security API Sample](https://github.com/auth0-samples/auth0-spring-security-api-sample) and [Auth0 Spring Security API Resource Server Sample](#auth0-resource-server-sample-using-spring-boot-and-spring-security). This sample provides an easy to understand seed project for users wishing to combine Java Spring Security API Server with a single-page application front-end. The sample can run in two different modes: + - The SPA and API Server trust one another and share the same Auth0 application information. In other words, they both have the same ClientId and therefore share the same Audience in their JWT Tokens. Hence the JWT Token received upon successful authentication in the SPA application is also passed in the Authorization Bearer header of the AJAX requests to the API Server. The API Server accepts the audience as it is the same as its own. + - The SPA application and API Server each have their own Auth0 Application on a shared Tenant (Account / Domain). In this situation, each has a different ClientId, and the Audience of the JWT Token generated for each application is different. The SPA application logs in and receives a JWT Token for authentication / authorization checks, local to the SPA application. When making AJAX requests to the API Server, a delegation token is used instead - in effect, the SPA application swaps its own JWT Token for a JWT Token that is valid for requests to the API Server. You can find details on how to setup and use this sample application at the _README_ of the [GitHub repository](https://github.com/auth0-samples/auth0-spring-security-api-client-samples/tree/master/auth0-spring-security-api-angular-client). -## Using Auth0 with Spring Boot and Spring Security for Single Sign On (SSO) +## Using Auth0 with Spring Boot and Spring Security for Single Sign-on (SSO) -We have created a [sample application](https://github.com/auth0-samples/auth0-spring-security-mvc-sso-sample) that demonstrates using Auth0 with Spring Boot and Spring Security to create two traditional server-side MVC web apps that are configured for Single Sign On with one another. `app1.com` is the main _portal_ website and `app2.com` is a _partner_ website that depends on `app1.com` for SSO authentication. The sample offers also one more _portal_ website, `app3.com`, which is a Single Page Application written in Angular 1.x. This is optional and provided for those wishing to do SSO with a mix of Server side and Single Page Apps. +We have created a [sample application](https://github.com/auth0-samples/auth0-spring-security-mvc-sso-sample) that demonstrates using Auth0 with Spring Boot and Spring Security to create two traditional server-side MVC web apps that are configured for SSO with one another. `app1.com` is the main _portal_ website and `app2.com` is a _partner_ website that depends on `app1.com` for Single Sign-on (SSO) authentication. The sample also offers one more _portal_ website, `app3.com`, which is a Single-Page Application written in Angular 1.x. This is optional and provided for those wishing to do SSO with a mix of Server side and Single-Page Apps. -The aim of this solution is to provide a simple, no-frills sample, developers can follow to understand the orchestration required to achieve SSO using Auth0 using Java, without having to also cope with understanding additional libraries or frameworks. +The aim of this solution is to provide a simple, no-frills sample that developers can follow to understand the orchestration required to achieve SSO using Auth0 using Java, without having to also cope with understanding additional libraries or frameworks. You can find more details on how to setup and use this sample application [here](https://github.com/auth0-samples/auth0-spring-security-mvc-sso-sample). ## Auth0 Resource Server Sample using Spring Boot and Spring Security -We have created a [sample application](https://github.com/auth0-samples/auth0-spring-security-api-resource-server-sample) that demonstrates using Auth0 with Spring Boot and Spring Security to create a secure Resource Server. This sample would be suitable for headless APIs and SPA (single page application) backend end server scenarios. It is specifically intended to demonstrate how to setup and read `scope` information from an Auth0 IDP JWT [Access Token](/tokens/access_token), and use this information to control authentication and authorization to secured endpoints. +We have created a [sample application](https://github.com/auth0-samples/auth0-spring-security-api-resource-server-sample) that demonstrates using Auth0 with Spring Boot and Spring Security to create a secure Resource Server. This sample would be suitable for headless APIs and SPA (single-page application) backend end server scenarios. It is specifically intended to demonstrate how to setup and read `scope` information from an Auth0 IDP JWT [Access Token](/tokens/access_token) as well as how to use this information to control authentication and authorization to secured endpoints. This sample application shows you how to: - Configure and run Java based Spring API server with Auth0 and Spring Security. diff --git a/articles/dev-lifecycle/child-tenants.md b/articles/dev-lifecycle/child-tenants.md index 2ca30101f0..3c2bdba948 100644 --- a/articles/dev-lifecycle/child-tenants.md +++ b/articles/dev-lifecycle/child-tenants.md @@ -1,13 +1,22 @@ --- description: How to request child tenants for your Auth0 tenant +topics: + - child-tenants + - dev-tools +contentType: how-to +useCase: + - support + - development --- # Child Tenant Request Process -This request process is for self-service customers requesting a development, test, or staging tenant that's linked to their paid production tenant. This tenant is called a **child tenant**. +This request process is for Developer or Developer Pro customers requesting a development, test, or staging tenant that's linked to their paid production tenant. This tenant is called a **child tenant**. -::: note Free tenants do not include a child tenant. + +::: warning +This policy does not apply if you have an Enterprise subscription. If you need to add child tenants to your subscription, contact your designated Technical Account Manager or our [Support](${env.DOMAIN_URL_SUPPORT}). ::: ## Child Tenant Policy diff --git a/articles/dev-lifecycle/index.md b/articles/dev-lifecycle/index.md index 6328251492..69cd2850f7 100644 --- a/articles/dev-lifecycle/index.md +++ b/articles/dev-lifecycle/index.md @@ -2,6 +2,12 @@ classes: topic-page title: Development Lifecycle description: Introduction to development lifecycle in Auth0. +topics: + - dev-tools +contentType: + - index + - how-to +useCase: development ---
      diff --git a/articles/dev-lifecycle/local-testing-and-development.md b/articles/dev-lifecycle/local-testing-and-development.md index 9b8b37a1bc..128c09eb32 100644 --- a/articles/dev-lifecycle/local-testing-and-development.md +++ b/articles/dev-lifecycle/local-testing-and-development.md @@ -1,32 +1,45 @@ --- description: How to develop and test Auth0 applications. +topics: + - dev-tools + - local-env +contentType: how-to +useCase: development --- # Work with Auth0 Locally In most cases, authenticating users through Auth0 requires an Internet connection. However, you can still develop and test apps that use Auth0 locally. In some cases, you might not need access to an Internet connection. ::: note -Please see [Setting Up Multiple Environments](/dev-lifecycle/setting-up-env) for information on structuring your development, test, and production environments when using Auth0. +See [Setting Up Multiple Environments](/dev-lifecycle/setting-up-env) for information on structuring your development, test, and production environments when using Auth0. ::: -## Use JSON Web Tokens (JWT) with Client-Side Applications +## Use JSON Web Tokens (JWT) with client-side applications -Because [JSON Web Tokens (JWT)](/jwt) are stateless (that is, the app that consumes them cares only about its contents, not any of its previous states), this is one of the easiest scenarios to test locally. +Because [JSON Web Tokens (JWT)](/tokens/concepts/jwts) are stateless (that is, the app that consumes them cares only about its contents, not any of its previous states), this is one of the easiest scenarios to test locally. You can obtain JWTs for testing using any of the following methods: -1. Create a test user for a database [connection](/identityproviders), and programatically log this user in. Essentially, you are using the recommended process for [calling an API using a highly-trusted application](/api-auth/grant/password). For detailed implementation instructions, see [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant). +1. Create a test user for a database [connection](/identityproviders), and programmatically log this user in. Essentially, you are using the recommended process for [calling an API using a highly-trusted application](/api-auth/grant/password). For detailed implementation instructions, see [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant). -2. Use a browser bot (such as Selenium) to play the role of a user, log in and retrieve a JWT. While this approach may take some effort to develop and maintain, it will allow you to test any [redirection rules](/rules/redirect) or [MFA prompts](/multifactor-authentication) that you have configured. +2. Use a browser bot (such as Selenium) to play the role of a user, log in and retrieve a JWT. While this approach may take some effort to develop and maintain, it will allow you to test any [redirection rules](/rules/redirect) or [MFA prompts](/mfa) that you have configured. -## Use Sessions with Server-Side Applications +## Use sessions with server-side applications Unless your server-side application allows the generation of artificial sessions for testing, you'll need a way to perform a login through Auth0 manually. -For a high-level overview of how to do this, see [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code). For detailed implementation instructions, see [Execute an Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant). +For a high-level overview of how to do this, see [Authorization Code Flow](/flows/concepts/auth-code). For detailed implementation instructions, see our tutorial, [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code). -## Use Local Domains with Auth0 +## Use local domains with Auth0 -If you're developing your application locally, you can use `localhost` and other domains inaccessible by Auth0 (such as those on an intranet) as callback URLs. +If you're developing your application locally, you can use `localhost` and other domains inaccessible by Auth0 (such as those on an intranet) as [callback URLs](/users/guides/redirect-users-after-login). For example, during development you could use `http://localhost:3000/callback` as the callback URL. -Because Auth0's main identity protocol is [OpenID Connect](/protocols), Auth0 never needs to directly call your application's server. Instead, Auth0 redirects users to your application's endpoint(s) with required information contained in a query string or hash fragment. +To set a callback URL, go to [Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings) and add the URL to the **Allowed Callback URLs** list. + +Because Auth0's main identity protocol is OpenID Connect (OIDC), Auth0 never needs to directly call your application's server. Instead, Auth0 redirects users to your application's endpoint(s) with required information contained in a query string or hash fragment. + +## Divert emails for testing + +If you want to test your local application and do not want the emails (creation, validation, etc.) to be delivered to the actual email address of the users your application creates or validates, Auth0 recommends using a custom email provider. For example, a service like [Mailtrap](https://mailtrap.io/signin) or your own custom SMTP server implementation can apply whatever logic you require to trap the emails. This ensures that users do not receive emails but you can access them for validation and troubleshooting. + +<%= include('../_includes/_email-domain-blacklist') %> diff --git a/articles/dev-lifecycle/setting-up-env.md b/articles/dev-lifecycle/setting-up-env.md index 5a5e4bf92d..f3ec26e81b 100644 --- a/articles/dev-lifecycle/setting-up-env.md +++ b/articles/dev-lifecycle/setting-up-env.md @@ -1,41 +1,50 @@ --- description: Use multiple Auth0 tenants to manage various environments. +topics: + - dev-tools + - local-env +contentType: how-to +useCase: development --- # Set Up Multiple Environments -__Development__, __Test__, __Q&A__ environments are easy to setup in Auth0. Simply create a new tenant for each to guarantee the maximum isolation between these environments. You can easily switch between tenants using the tenant chooser from the top right menu on the dashboard. You can also configure different administrators for each. +__Development__, __staging__, and __production__ environments are easy to set up in Auth0. Create a new tenant for each environment to guarantee isolation between them. You can easily switch between tenants using the tenant chooser from the top right menu on the Dashboard. You can also configure different administrators for each. ::: warning -Moving your tenant to a Development environment will impact [rate limits](https://auth0.com/docs/policies/rate-limits) for calls to the Authentication and Management API. +Production [rate limits](/policies/rate-limits) only apply to tenants tagged as `Production`. Ensure your tenant's environment tag is set to `Production` before going live. ::: -![](/media/articles/lifecycle/environments.png) - -The example above uses a simple naming convention to distinguish each environment, you can name your multiple environments anyway you prefer. No need to use this naming convention, though it is the one recommended. +You can name your multiple environments any way you prefer. For production environments, we strongly recommend using [custom domains](/custom-domains). ::: note -If you have a subscription plan costing at least **$167 (USD) per month**, you can request a [child account](/dev-lifecycle/child-tenants) that is identical to your Production account for use in a development/staging/testing environment. This includes paid/upgraded features, as well as individual configuration options, such as Rules. Free accounts do *not* include a child account. +If you have a subscription plan costing at least **$167 (USD) per month**, you can request a [child account](/dev-lifecycle/child-tenants) that is identical to your Production account in terms of paid/upgraded features for use in a development/staging/testing environment. Free accounts do *not* include a child account. ::: ## Set the Environment For each new tenant created, you should specify its environment. You can assign environment tags to your tenants to differentiate between development, staging, and production environments. -To assign an environment tag to a tenant, go to the [Auth0 Support Center > Tenants](${env.DOMAIN_URL_SUPPORT}/tenants/public). Locate your tenant and click the gear icon to bring up the **Settings** section. +::: note +If your tenant is mixed use, choose the higher environment. For example, a tenant used for both development and production should be set to `Production`. +::: + +1. To assign an environment tag to a tenant, go to the [Auth0 Support Center > Tenants](${env.DOMAIN_URL_SUPPORT}/tenants/public). Locate your tenant, and click the gear icon to bring up the **Settings** section. ![Support Center Tenants](/media/articles/clients/support-tenants.png) Next, select the **Assign Environment Tag** option. Use the form to identify your tenant's environment as either `Development`, `Staging`, or `Production`. -If your tenant is mixed use, choose the higher environment. For example, a tenant used for both development and production should be set to `Production`. - After selecting the environment, click on **Save Changes**. ![Support Center Tenants Settings](/media/articles/clients/support-tenants-settings.png) +::: note +Environment Tags are not available in [Private Cloud deployments ](/private-cloud). All tenants in the same environment will have the same limits. +::: + ## Migration -Through the [Management API v2](/api/management/v2), you can automate the migration of assets (rules, database connections, and so forth) between tenants. +Through the [Management API v2](/api/management/v2), you can automate the migration of assets ([rules](/rules/current), database [connections](/connections), and so forth) between tenants. For easier configuration management, save your configuration values in the [Dashboard](${manage_url}/#/rules), instead of hardcoding them into your __rules__ or __db connections__ scripts. @@ -48,13 +57,27 @@ function(user, context, callback){ } ``` -This code however is not portable since this URL will likely change from development to production. +This code, however, is not portable since this URL will likely change from development to production. + +The recommended way of working with code that you need to use/move from development to product is via [Rules](${manage_url}/#/rules) section. If you have not yet created a rule, you'll need to do so. (Otherwise, jump to step 4.) + +1. Click __Create Your First Rule__. + +![Create Your First Rule](/media/articles/lifecycle/rules-create-first.png) + +2. Choose the __empty rule__ template. -The recommended way is to navigate to the [Dashboard > Rules](${manage_url}/#/rules), scroll at the bottom of the page, set your configuration value (we will use `log_url` for the key name, and `https://someurl/log` for value), and click __Create__. +![Rules Templates](/media/articles/lifecycle/rules-template-empty.png) + +3. Enter a name for your new rule, and click __Save__. + +![Enter Rule Name](/media/articles/lifecycle/rules-enter-name.png) + +4. Navigate back to [Auth0 Dashboard Rules](${manage_url}/#/rules), and scroll to the bottom of the page to set your configuration values (we will use `log_url` for the key name, and `https://someurl/log` for value), then click __Create__. ![Rules Configuration Values](/media/articles/lifecycle/rules-conf-values.png) -Now you can write your rule as follows: +5. Now, you can write your rule. Edit the rule you created, enter the following code in the code area, and click __Save__. ```js function(user, context, callback){ @@ -63,12 +86,14 @@ function(user, context, callback){ } ``` -This code is portable and when you migrate to production you only need to change this setting, instead of searching your scripts. +![Write Rule Code](/media/articles/lifecycle/rules-rule-code.png) + +This code is portable, and when you migrate to production, you only need to change this setting instead of searching your scripts. ## AD/LDAP Connectors -Since an AD/LDAP Connector is tied to a specific Connection within an Auth0 tenant, if you setup multiple Auth0 tenants, you will need to create an AD/LDAP Connection and setup an AD/LDAP Connector for each tenant that requires this form of authentication. +If you use multiple Auth0 tenants with AD/LDAP, you will need to create an AD/LDAP Connection and set up an AD/LDAP Connector for each tenant. This is because each AD/LDAP Connector is tied to a specific Connection within an Auth0 tenant. -Multiple AD/LDAP Connectors can point to the same AD or LDAP directory, but each AD/LDAP connector can only be used by one Connection within one Auth0 tenant. +Multiple AD/LDAP Connectors can point to the same AD or LDAP directory, but each AD/LDAP Connector can only be used by one Connection within one Auth0 tenant. -If you have multiple AD/LDAP directories against which users will authenticate (for example, to support different departments or customers, each with their own directory) you can setup multiple AD/LDAP Connectors within each Auth0 tenant. +If you have multiple AD/LDAP directories against which users will authenticate (for example, to support different departments or customers, each with their own directory), you can set up multiple AD/LDAP Connectors within each Auth0 tenant. diff --git a/articles/email/custom.md b/articles/email/custom.md index 3c09eb4d1c..904c232284 100644 --- a/articles/email/custom.md +++ b/articles/email/custom.md @@ -1,29 +1,34 @@ --- description: The Auth0 APIs provide endpoints that allow you to completely manage email flow, and control when and how emails are sent. toc: true +topics: + - email +contentType: concept +useCase: customize-emails --- # Custom Email Handling The default email flow in Auth0 can address the requirements of most applications, but there may be instances where more flexibility is required. For example: - * Localization - * Custom **Redirect To** URLs based on the user or tenant - * Different email templates per application or tenant +* Localization +* Custom **Redirect To** URLs based on the user or tenant +* Different email templates per application or tenant The Auth0 Management API provides endpoints that allow you to completely manage email flow, and control when and how emails are sent. To begin, you will need to disable automatic emails by deselecting **Status** under the **Verification Email** and **Welcome Email** tabs on the [Email Templates](${manage_url}/#/emails) page of the Auth0 dashboard. -![Disable Verification Email](/media/articles/email/custom/email-custom.png) - ## Verification Email A verification email should be sent to every user for which the `email_verified` property is `false`. Typically, these are users in database connections or users authenticating with Social Providers that do not validate email addresses upon new user registration. -Using a [Rule](/rules), you can call your API when a user logs in for the first time with an email address that has not been verified. After calling your API, [add a flag](/rules/metadata-in-rules) to the user's profile metadata that indicates that the verification email has been sent: +Using a [Rule](/rules), you can call your API when a user logs in for the first time with an email address that has not been verified. After calling your API, [add a flag](/users/concepts/overview-user-metadata) to the user's profile metadata that indicates that the verification email has been sent: ```js function (user, context, callback) { + + const request = require('request'); + user.user_metadata = user.user_metadata || {}; if (user.email_verified || user.user_metadata.verification_email_sent) { return callback(null, user, context); @@ -34,7 +39,7 @@ function (user, context, callback) { json: { user: user, context: context, - secretToken: ";ojhsajk;h;Kh:Jh", + secretToken: configuration.MY_SECRET_TOKEN, }, timeout: 5000 }, function(err, response, body){ @@ -61,12 +66,17 @@ A custom redirect is useful when you want to direct users to certain URLs based The Auth0 Management API provides a [post_verification_email](/api/v2#!/Tickets/post_email_verification) endpoint that generates the verification link for each user. This endpoint allows you to specify the `resultUrl` to which users will be redirected after they have validated their email address by clicking the link in the verification email. +We recommend whitelisting the url through the dashboard. + ## Welcome Email A welcome email is sent to users once they have verified their email address. This can be implemented using a rule which sends the email only if the user's email address has been verified and the email has not been sent previously. ```js function (user, context, callback) { + + const request = require('request'); + if (!user.email_verified || user.welcome_email_sent) { return callback(null, user, context); } @@ -84,7 +94,7 @@ function (user, context, callback) { return callback(new Error(err)); // Email sent flag persisted in the user's profile. - user.persistent.welcome_email_sent = true; + user.app_metadata.welcome_email_sent = true; return callback(null, user, context); }); } diff --git a/articles/email/index.md b/articles/email/index.md index bb18e59700..2f3fec2e0d 100644 --- a/articles/email/index.md +++ b/articles/email/index.md @@ -1,15 +1,24 @@ --- url: /email description: Auth0 built-in email services. +topics: + - email +contentType: + - index + - reference + - how-to +useCase: customize-emails --- # Emails in Auth0 +An Auth0 [Database Connection](/connections/database) provides several emails as a part of its authentication flow, including verification emails, welcome emails, change password emails, breached password, and blocked account emails. The **Multi-factor Authentication Enrollment Email** can be sent to users in any connection. + ::: warning -Auth0's built-in email provider is not supported for use in a production environment and should be used for testing only. +Auth0's built-in email provider is not supported for use in a production environment, should be used for testing only, and has several restrictions. ::: -When you first create your application Auth0 provides a built-in email provider to send emails. This includes verification emails, welcome emails, change password emails, and blocked account emails. This is meant to be used for testing purposes only, and has several restrictions: +Auth0's built-in email provider has these restrictions: * You will not be able to use any of the email customization features. The content of the emails sent for testing will be restricted to format of the existing templates. @@ -29,7 +38,7 @@ To remove these restrictions in your testing or to setup your production level e After you have configured your own email service provider, the [Emails](${manage_url}/#/emails) dashboard will allow you to customize your emails beyond the existing templates. ::: note -For users with the **Free Subscription** plan, email workflows and using the custom email provider features are available. However a paid subscription plan is required for email customizations. See the [subscription pricing page](https://auth0.com/pricing) for more details. +For users with the **Free Subscription** plan, email workflows and using the custom email provider features are available. However, a paid subscription plan is required for email customizations. See the [subscription pricing page](https://auth0.com/pricing) for more details. ::: For more information see [Customizing Your Emails](/email/templates). diff --git a/articles/email/liquid-syntax.md b/articles/email/liquid-syntax.md index 06ae3b12eb..205cd9025e 100644 --- a/articles/email/liquid-syntax.md +++ b/articles/email/liquid-syntax.md @@ -1,5 +1,12 @@ --- description: How to use Liquid syntax in your email templates. +topics: + - email + - liquid +contentType: + - how-to + - concept +useCase: customize-emails --- # Liquid Syntax in Email Templates diff --git a/articles/email/providers.md b/articles/email/providers.md index 3d25685ac1..659f40862b 100644 --- a/articles/email/providers.md +++ b/articles/email/providers.md @@ -1,185 +1,220 @@ --- -description: How to configure your own SMTP email provider. +title: Use Your Own SMTP Email Provider +description: Learn how to configure your own SMTP email provider, so you can more completely manage, monitor, and troubleshoot your email communications. toc: true +topics: + - email + - smtp + - email-providers +contentType: how-to +useCase: customize-emails --- -# Use your own SMTP Email Provider +# Use Your Own SMTP Email Provider -Auth0 allows you to configure your own SMTP email provider. Auth0's built-in email infrastructure should be used for testing level emails only. By using your own provider you can more completely manage, monitor and troubleshoot your email communications. +Auth0 allows you to configure your own SMTP email provider so you can more completely manage, monitor, and troubleshoot your email communications. + +::: note +Auth0's built-in email infrastructure should be used for testing-level emails only. +::: Auth0 currently supports the following providers: -* [Amazon SES](#configure-amazon-ses-for-sending-email) -* [Mandrill](#configure-mandrill-for-sending-email) -* [SendGrid](#configure-sendgrid-for-sending-email) -* [SparkPost](#configure-sparkpost-for-sending-email) -* [Custom SMTP](#configure-a-custom-smtp-server-for-sending-email) +* [Amazon SES](#configure-amazon-ses) +* [Mandrill](#configure-mandrill) +* [SendGrid](#configure-sendgrid) +* [SparkPost](#configure-sparkpost) +* [Mailgun](#configure-mailgun) +* [Other SMTP](#configure-a-custom-smtp-server) (e.g., Gmail, Yahoo) -::: note -You can only configure one email provider (Amazon SES, Sendgrid, and so on.) which will be used for all emails. -::: +You can only configure one email provider, which will be used for all emails. + +## Whitelist IP addresses -## Configure Amazon SES for Sending Email +To ensure that emails can be sent from Auth0 to your SMTP, you must open the right ports and allow inbound connections from specific IP addresses. To get the list of IPs, navigate to [Dashboard > Emails > Provider](${manage_url}/#/templates/provider). -There are several steps to follow to configure Amazon SES for sending email. If you want to use the SES API, please follow this guide. +## Configure Amazon SES -You can use two types of credentials +To use the Amazon SES API to send emails, you must complete several configuration steps. First, though, you need to decide which credentials you want to use: -1. API Credentials -2. SMTP Credentials (the secret is usually 44 characters long) +* API Credentials +* SMTP Credentials (the secret is usually 44 characters long) -For more information about SES credentials, visit [Using Credentials With Amazon SES](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/using-credentials.html). +For more info about SES credentials, see Amazon's [Using Credentials With Amazon SES](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/using-credentials.html). -### Using API Credentials +### Use API credentials + +1. Sign up for an [Amazon AWS](http://aws.amazon.com/ses/) account, or log in. -1. Sign up for an [Amazon AWS](http://aws.amazon.com/ses/) account, or login. 2. [Verify your domain](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-domains.html). - ![](/media/articles/email/providers/ses-verify.png) 3. [Verify email addresses](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-email-addresses.html) 4. [Request production access](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html?icmpid=docs_ses_console). -5. [Get Your AWS Access Keys](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/get-aws-keys.html). Copy these keys. You will need to enter these values into Auth0 (see below). - ![](/media/articles/email/providers/aws-keys.png) +5. [Get your AWS access keys](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/get-aws-keys.html). Copy these keys; you will need to enter these values into Auth0. -6. [Attach a policy with the right permissions](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html). Attach a policy with the `ses:SendRawEmail` and `ses:SendEmail` permissions, as in this example: +6. [Attach a policy with the proper permissions](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html). Attach a policy with the `ses:SendRawEmail` and `ses:SendEmail` permissions, as in this example: - ![](/media/articles/email/providers/aws-policy.png) +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "ses:SendRawEmail", + "ses:SendEmail" + ], + "Resource": "*" + } + ] +} +``` -7. Go to the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Click **Use my own Email Provider** and click the **Amazon Web Services** logo. +7. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **Amazon Web Services** logo. -8. Enter your AWS `Access Key Id`, `Secret Access Key` and `Region` in the appropriate fields: + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) - ![](/media/articles/email/providers/enter-keys.png) +8. Provide a **From** email address, enter your AWS **Access Key Id** and **Secret Access Key**, select your **Region**, and click **Save**: -9. Click **Save**. + ![Enter AWS API Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-aws.png) -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. -The [Amazon SES console](https://console.aws.amazon.com/ses) will now display all emails which have been sent to your users. +The [Amazon SES console](https://console.aws.amazon.com/ses) will now display delivery insights for all emails that have been sent to your users. -### Using SMTP Credentials +### Use SMTP credentials -1. Sign up for an [Amazon AWS](http://aws.amazon.com/ses/) account, or login. -2. [Verify your domain](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-domains.html). +1. Sign up for an [Amazon AWS](http://aws.amazon.com/ses/) account, or log in. - ![](/media/articles/email/providers/ses-verify.png) +2. [Verify your domain](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-domains.html). 3. [Request production access](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html?icmpid=docs_ses_console). -4. [Get Your SMTP Credentials](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html). Copy the security credentials. You will need to enter these values into Auth0. +4. [Get your SMTP credentials](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html). Copy the security credentials; you will need to enter these values into Auth0. + +5. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SMTP** logo. + + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) + +6. Provide a **From** email address, then enter your SMTP server **Host**, **Port**, **Username**, and **Password**, and click **Save**. You can use `email-smtp.us-east-1.amazonaws.com` (using the appropriate region rather than `us-east-1`) for **Host** and `587` for **Port**. - ![](/media/articles/email/providers/ses-smtp.png) + ![Enter AWS SMTP Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.png) -5. Go to the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Click **Use my own Email Provider** and click the **SMTP** logo. +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. -6. Enter your SMTP server `Host`, `Port`, `Username` and `Password` in the appropriate fields. You can use `email-smtp.us-east-1.amazonaws.com` (using the appropriate region instead of `us-east-1`) for `Host` and `587` for `Port`. +The [Amazon SES console](https://console.aws.amazon.com/ses) will now display delivery insights for all emails that have been sent to your users. - ![](/media/articles/email/providers/enter-smtp-data.png) +## Configure Mandrill -7. Click **Save**. +1. Sign up for a [Mandrill](https://www.mandrill.com/signup/) account, or log in. -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +2. Navigate to Mandrill [Settings](https://mandrillapp.com/settings), and click **Add API key**. Copy this key value. -The [Amazon SES console](https://console.aws.amazon.com/ses) will now display all emails which have been sent to your users. +3. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **Mandrill** logo. -## Configure Mandrill for Sending Email + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -1. Sign up for a [Mandrill](https://www.mandrill.com/signup/) account, or login. Go to the [Settings page](https://mandrillapp.com/settings) and click **Add API key**. Save this key value. +4. Provide a *From** email address, enter the Mandrill **API Key** you previously copied, and click **Save**: - ![](/media/articles/email/providers/mandrill-keygen.png) + ![Enter Mandrill Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-mandrill.png) -2. Go to the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Click **Use my own Email Provider** and click the **Mandrill** logo. +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. -3. Enter your previously obtained Mandrill `API Key`: +The Mandrill [Outbound Activity](https://mandrillapp.com/activity) page will now display delivery insights for all emails that have been sent to your users. - ![](/media/articles/email/providers/mandrill-key.png) +## Configure SendGrid -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +1. Sign up for a [SendGrid](https://sendgrid.com) account, or log in. (If you have a Microsoft Azure subscription, you can get a free account in the Azure Marketplace.) -The [Outbound Activity](https://mandrillapp.com/activity) page in Mandrill will now display all emails which have been sent to your users, including the subject and the delivery status of each message. +2. Navigate to SendGrid **Settings > API Keys**, and click **Create API Key**. Provide a name for your key, enable **Full Access** for **Mail Send** permissions, and click **Save**. Copy this key value. -![](/media/articles/email/providers/email-mandrill-monitoring.png) +3. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SendGrid** logo. -## Configure SendGrid for Sending Email + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -1. Sign up for a [SendGrid](https://sendgrid.com) account, or login. (If you have a Microsoft Azure subscription you can get a free account in the Azure Marketplace). +4. Provide a **From** email address, enter the SendGrid **API Key** you previously copied, and click **Save**: -2. Go to **Settings > API Keys** and click **Create API Key**. -3. Provide a name for your key and enable **Full Access** for **Mail Send** permissions. Click **Save**. + ![Enter SendGrid Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-sendgrid.png) - ![](/media/articles/email/providers/sendgrid-permissions.png) +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. -4. Copy the API key provided. +The SendGrid [Email Activity](https://sendgrid.com/logs/index) page will now display delivery insights for all emails that have been sent to your users. - ![](/media/articles/email/providers/sendgrid-key.png) +## Configure SparkPost -5. Go to the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Click **Use my own Email Provider** and click the **SendGrid** logo. +1. Sign up for a [SparkPost](https://www.sparkpost.com/) account, or log in. -6. Provide a **From** email and enter your previously obtained **SendGrid API Key**: +2. Navigate to SparkPost [Sending Domains](https://app.sparkpost.com/account/sending-domains), and add your custom domain. SparkPost allows sending emails from only verified domains. - ![](/media/articles/email/providers/sendgrid-dashboard.png) +3. Navigate to SparkPost [Account API Keys](https://app.sparkpost.com/account/credentials), and click **New API key**. Save this key value and ensure it has `Transmissions: Read/Write` access. Copy this key value. +4. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SparkPost** logo. -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. If you have configured everything correctly, you will receive a confirmation email: + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) + +5. Provide a **From** email address, enter the SparkPost **API Key** you previously copied, select your **Region**, and click **Save**: + + ![Enter SparkPost Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-sparkpost.png) + +::: warning +If you are changing to the EU region in an account that was already configured for the US region, you must replace the **API Key** in Auth0 with a Sparkpost EU API Key. +::: -![](/media/articles/email/providers/sendgrid-test.png) +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. ::: note -If you do not receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +If you haven't registered a custom domain with SparkPost, you can send a maximum of five test emails from the `sparkpostbox.com` domain. For more info, see SparkPost's [Transmissions: The Sandox Domain](https://developers.sparkpost.com/api/transmissions.html#header-the-sandbox-domain). ::: -The [Email Activity](https://sendgrid.com/logs/index) page in SendGrid will now display all emails which have been sent to your users and the delivery status of each message. +The SparkPost [Message Events](https://app.sparkpost.com/reports/message-events) page will now display delivery insights for all emails that have been sent to your users. -![](/media/articles/email/providers/email-sendgrid-monitoring.png) +## Configure Mailgun -## Configure SparkPost for Sending Email +1. Sign up for a [Mailgun](https://mailgun.com) account, or log in. -1. Sign up for a [SparkPost](https://www.sparkpost.com/) account, or login. Go to the [Account API Keys page](https://app.sparkpost.com/account/credentials) and click **New API key**. Save this key value. The key must have `Transmissions: Read/Write` access. +2. Navigate to Mailgun **Sending > Domains**, and add your custom domain. Mailgun allows sending emails from only verified domains. - ![](/media/articles/email/providers/sparkpost-api-key-creation.png) +3. Navigate to Mailgun **Settings > API Keys**. Your API key was created when you signed up for your account; copy it from **Private API Key**. -2. Go to the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Click **Use my own Email Provider** and click the **SparkPost** logo. +4. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **Mailgun** logo. -3. Enter your previously obtained SparkPost `API Key`: + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) - ![](/media/articles/email/providers/sparkpost-set-key.png) +5. Provide a **From** email address, enter the **Domain** you previously added to Mailgun, enter the Mailgun **API Key** you previously copied, select your **Region**, and click **Save**: -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. Note that SparkPost only allows sending emails from verified domains. To verify a custom domain go to the [Sending Domains page](https://app.sparkpost.com/account/sending-domains) and add your custom domain. Alternatively, you can send test emails from the `sparpostbox.com` domain, but this is limited to only five test emails. See the [relevant SparkPost docs](https://developers.sparkpost.com/api/transmissions.html#header-the-sandbox-domain) for details. + ![Enter Mailgun Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-mailgun.png) -If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. -The [Message Events](https://app.sparkpost.com/reports/message-events) page in SparkPost will now display all emails which have been sent to your users, including the delivery status of each message. +The [Mailgun Dashboard](https://app.mailgun.com/app/dashboard) will now display delivery insights for all emails that have been sent to your users. -![](/media/articles/email/providers/sparkpost-message-events.png) +## Configure a custom SMTP server -## Configure a Custom SMTP Server for Sending Email +When using your own SMTP server to send email, the server must: -You can use your own SMTP server to send email. There are three requirements for the SMTP server: +* support LOGIN [authentication](https://en.wikipedia.org/wiki/SMTP_Authentication). +* support [TLS](https://en.wikipedia.org/wiki/STARTTLS) 1.0 or higher. +* use a certificate signed by a public certificate authority (CA). -* It must support LOGIN [authentication](https://en.wikipedia.org/wiki/SMTP_Authentication). -* It must support [TLS](https://en.wikipedia.org/wiki/STARTTLS) 1.0 or higher. -* It must use a certificate signed by a public certificate authority (CA). +If your SMTP server meets these criteria, then: -To be able to use your own SMTP server: +1. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SMTP** logo. -1. Open the [Custom Email Provider](${manage_url}/#/emails/provider) page of 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: + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) - ![](/media/articles/email/providers/enter-smtp-data.png) +2. Provide a **From** email address, then enter your SMTP server **Host**, **Port**, **Username**, and **Password**, and click **Save**: -5. Click **Save**. + ![Enter Custom SMTP Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.png) ::: note -Common ports include 25 and 587. Please avoid using port 25 if you can, since many providers have limitations on this port. +Common ports include 25 and 587. Please avoid using port 25 if you can because many providers have limitations on this port. ::: -Now you can send a test email using the **SEND TEST EMAIL** button on the [Custom Email Provider](${manage_url}/#/emails/provider) page of the Auth0 dashboard. If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +You can now send a test email using the **Send Test Email** button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your [Auth0 logs](${manage_url}/#/logs) for any failures. ::: panel Test services -SMTP makes it easy to setup test services that allow you to test that your setup is working without spamming your users. For more information, see: [Set up a Test SMTP Provider](/email/testing) . +SMTP makes it easy to set up test services that allow you to test that your setup is working without spamming your users. For more info, see [Set Up a Test SMTP Provider](/email/testing). ::: ## Keep reading diff --git a/articles/email/spa-redirect.md b/articles/email/spa-redirect.md index 3795331b9c..ff000c99f5 100644 --- a/articles/email/spa-redirect.md +++ b/articles/email/spa-redirect.md @@ -1,5 +1,10 @@ --- description: How to work around the limitation of single-page application email redirects. +topics: + - email + - spa +contentType: how-to +useCase: customize-emails --- # Single-Page App Email Redirect Issue @@ -29,7 +34,7 @@ For example, with the above URL, the app will be routed to `/` instead of `/#/re ## Using a Query String Parameter -To work around this limitation of SPA frameworks, it is recommended to use a server-side callback URL as the **redirect To** URL with a `route` parameter that preserves the SPA app route for the redirect. Once in this server-side URL, simply redirect to the SPA route saved in the `route` parameter along with rest of the query string. +To work around this limitation of SPA frameworks, it is recommended to use a server-side callback URL as the **redirect To** URL with a `route` parameter that preserves the SPA app route for the redirect. Once in this server-side URL, simply redirect to the SPA route saved in the `route` parameter along with rest of the query string. 1. Add a server-side URL as the **redirect To** URL with a `route` parameter that records the SPA route for the redirect. diff --git a/articles/email/templates.md b/articles/email/templates.md index 93b41b4047..cc7a76a95c 100644 --- a/articles/email/templates.md +++ b/articles/email/templates.md @@ -1,40 +1,90 @@ --- description: The Emails section of the Auth0 dashboard allows you to customize your emails with Liquid templating syntax. +topics: + - email +contentType: how-to +useCase: customize-emails +toc: true --- # Customizing Your Emails ::: warning -You must setup your own email provider using a [third-party service](/email/providers) ([Amazon SES](https://aws.amazon.com/ses/), [Mandrill](https://www.mandrill.com/signup/) or [SendGrid](https://sendgrid.com/pricing)) or a [custom provider](/email/custom) to be able to customize your emails. +You must set up your own email provider using a [third-party service](/email/providers) (such as Amazon SES, Mandrill, SendGrid, SparkPost, Mailgun, or a custom SMTP provider) to be able to customize your emails. ::: -The [Emails](${manage_url}/#/emails) dashboard allows you to customize your emails, including templating with some user attributes [using Liquid syntax](#email-templates). This can include references to the context of the current application or user. +Auth0 provides an [Emails](${manage_url}/#/emails) dashboard that allows you to customize your HTML-based emails, including templating with some contextual attributes [using Liquid syntax](/email/liquid-syntax). This can include references to the context of the current application or user. ![](/media/articles/email/index/emails-fields.png) ::: note -Only one template can be used for each template type (for example, only one template for change password emails). +Only one template can be used for each template type (for example, only one template for verify emails). ::: -## Configuring *From*, *Subject*, *Redirect To*, and *URL Lifetime* +At this time, Auth0 does not support plaintext/text-based emails. -For each type of email, you can customize the **From Address**, the **Subject**, the **Redirect To** and the **URL Lifetime**. +## Configuring email templates -### From Address +You can customize the **From Address**, the **Subject**, and the **Message** body for each email template. You can use [Liquid Syntax](/email/liquid-syntax) to dynamically generate content, with access to a number of contextual variables that will be replaced with the relevant values when rendering the email messages. + +### Common variables + +You can access the following common variables when using Liquid Syntax in the **From Address**, **Subject** and **Message** fields: + +* The `application` object, with access to the standard client properties like + * `application.name` + * `application.clientID` +* `connection.name` (except in the **Multi-factor Enrollment Email**) +* The `user` object, with access to the following properties: + * `user.email` + * `user.email_verified` + * `user.picture` + * `user.nickname` + * `user.given_name` + * `user.family_name` + * `user.name` + * `user.app_metadata` - stores information (such as a user's support plan, 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. + * `user.user_metadata` - stores user attributes (such as user preferences) that do not impact a user's core functionality. +* Tenant-related information (defined in the [Tenant Settings](${manage_url}/#/tenant)): + * `tenant` - the raw tenant name + * `friendly_name` + * `support_email` + * `support_url` + +Variables are referenced using the `{{ variable_name }}` syntax in Liquid. E.g.: + +```text +Hello {{ user.name }}. Welcome to {{ application.name }} from {{ friendly_name }}. +``` +Note that the attributes available for the `user` object will depend on the type of connection being used. + +::: note +Individual email templates define additional variables that are appropriate for the specific template. Be sure to check out the [individual templates descriptions](#individual-templates-descriptions) below. +::: + +For those emails where the user needs to follow a link to take action, you can also configure the **URL Lifetime** and **Redirect To** URL destination after the action is completed. Liquid Syntax is also supported in the **Redirect To** URL field, but only three variables are supported: + +* `application.name` +* `application.clientID` +* `application.callback_domain` + +See [Configuring the Redirect To URL](#configuring-the-redirect-to-url) for more details. + +### Configuring the From Address Users will see the sender's address in the **From Address** field when receiving an email from Auth0. If you do not configure a **From Address** for your emails your emails will be sent from the email address of the first owner of your Auth0 account. ::: note -For security purposes, you may not send customized emails from any `@auth0.com` address. If you are a PSaaS Appliance user, you may configure a similar domain blacklist. +For security purposes, you may not send customized emails from any `@auth0.com` address. If you are a Private Cloud user, you may configure a similar domain blacklist. ::: -The **From Address** field supports the following macros: +The **From Address** field supports all the [common variables](#common-variables) for templates, but these are the most commonly used: -* `{application.name}` -* `{connection.name}` +* `application.name` +* `friendly_name` (for the tenant's defined friendly name) -You can use these macros to set the display name of the **From Address** to something that relates to the application for which the user signed up. For example, the field could display `{application.name} `, as opposed to simply ``. +You can use these variables to set the display name of the **From Address** to something that relates to the application for which the user signed up. For example, the field could display `{{ application.name }} `, as opposed to simply ``. You must add the [Sender Policy Framework (SPF)](http://en.wikipedia.org/wiki/Sender_Policy_Framework) and [DomainKeys Identified Mail (DKIM)](http://en.wikipedia.org/wiki/DKIM) DNS records to your domain's zone file to allow Auth0 to send digitally-signed emails on your behalf. Without these records, the emails may end up in your users' junkmail folders. Additionally, your users may see the following as the **From Address**: @@ -44,7 +94,13 @@ MyApp support@mail128-21.atl41.mandrillapp.com on behalf of MyApp support@fabrik #### SPF Configuration -You can configure the SPF by adding a TXT record to your domain's zone file. You should set the host name to `@`, or leave it empty, depending on the provider. +You can configure the SPF by adding a TXT record to your domain's zone file. You should set the host name to `@`, or leave it empty, depending on the provider. The value of the record should look something like the following. + +```text +"v=spf1 include:spf.mandrillapp.com -all" +``` + +If you already have an SPF record you can simply add `include:spf.mandrillapp.com` to the existing record. #### DKIM Configuration @@ -60,74 +116,78 @@ and the value to: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB; ``` -### Subject +### Configuring the Subject -You can use the following macros with the **Subject** field: +The **Subject** field supports all the [common variables](#common-variables) for templates, including: -* `{application.name}` -* `{connection.name}` -* `{user.email}` +* `application.name` +* `user.email` (and other properties of the `user` object) If the **Subject** field is empty, Auth0 will auto-populate this text depending on what type of email you are sending. For example, one subject line might be "*Verify your email.*" -### Redirect To URL +### Configuring the URL Lifetime + +The **Verification Email**, **Change Password** and **Blocked Account Email** contain links which allow users to verify their email address when signing up, confirm their password change, or unblock a blocked account respectively. -You can redirect users to a specific page on the **Allowed Callback URL** using the following: +You can modify the lifetime of this link for security purposes. By default, the lifetime is 432,000 seconds (five days). + +If users click on an expired link and a **Redirect To** URL is configured, they will be redirected to the configured **Redirect To** URL. The following text will be appended to the query string: ```text -{application.callback_domain}/result_page +http://myapplication.com/my_page/?email=john%contoso.com&message=Access%20expired.&success=false ``` -If your application has multiple **Allowed Callback URLs** configured, Auth0 will use the first URL listed. +### Configuring the Redirect To URL -#### Dynamic Redirect To URLs +The **Redirect To** URL is an optional destination to redirect the user to after the relevant action (verify account, reset password, unblock account) was performed. -You can set up a different Redirect To URLs based on your Client ID. For example: +::: panel Redirect URLs +With the Classic Experience, you can provide a URL to which users are redirected after they reset their password. Auth0 sends a success indicator and a message to the URL. -```text -{% if application.clientID == '${account.clientId}' %} http://jwt.io {% else %} http://auth0.com {% endif %} -``` - -::: note -For some single-page apps, the redirect to url can sometimes contain a hash that may be removed. This results in the **redirect To** url not working as expected. For more information, see: [Single-Page App Email Redirect Issue](/email/spa-redirect). +With the New Experience, Auth0 redirects users to the [default log in route](/universal-login/default-login-url) when the user succeeds in resetting the password. If not, Auth0 handles the errors as part of the Universal Login flow and ignores the redirect URL provided in the email template. ::: -### URL Lifetime +**Only the following three variables** are available on the **Redirect To** URL: -The **Verification Email** and **Change Password Confirmation Email** contain links which allow users to verify their email address when signing up, or confirm their password change, respectively. +* `application.name` (or its synonym `client.name`) +* `application.clientID` +* `application.callback_domain` (or its synonym `client.callback_domain`) + +The `application.callback_domain` variable will contain the origin of the **first** URL listed in the application's **Allowed Callback URL** list. This lets you redirect users to a path of the application that triggered the action by using a syntax like this: -You can modify the lifetime of this link for security purposes. By default, the lifetime is 432,000 seconds (five days). +```text +{{ application.callback_domain }}/result_page +``` -If users click on an expired link and a **Redirect To** URL is configured, they will be redirected to the configured **Redirect To** URL. The following text will be appended to the query string: +Note that while the variable is called `callback_domain`, it is really an *origin*, so it includes the protocol in addition to the domain, e.g. `https://myapp.com`. + +If your application has multiple **Allowed Callback URLs** configured, Auth0 will use the first URL listed. You can also provide a default origin using Liquid syntax: ```text -http://myapplication.com/my_page/?email=john%contoso.com&message=Access%20expired.&success=false +{{ application.callback_domain | default: "https://my-default-domain.com" }}/result_page ``` -## Email Templates +#### Dynamic Redirect To URLs -### Multilingual Email Templates +You can set up a different Redirect To URLs based on your application name. For example: -User attributes are available from the **Verification Email**, **Welcome Email**, **Change Password Confirmation Email** and **Blocked Account Email** templates. +```text +{% if application.name == 'JWT.io' %} https://jwt.io {% else %} https://auth0.com {% endif %} +``` -The available attributes vary depending on the syntax used. +Because the application name is encoded for security, you should always use an encoded value (especially if your application name contains a character that changes once encoded). For example, you'll want to use `My%20App` instead of `My App`. + +::: note +For some single-page apps, the redirect to url can sometimes contain a hash that may be removed. This results in the **redirect To** url not working as expected. For more information, see: [Single-Page App Email Redirect Issue](/email/spa-redirect). +::: -#### HTML + Liquid syntax -Liquid syntax is the currently supported templating syntax to use when accessing user attributes in your email templates. Here are the attributes available to you: +### Configuring the Message Body -* `email` -* `email_verified` -* `picture` -* `name` -* `nickname` -* `given_name` -* `family_name` -* `app_metadata` - stores information (such as a user's support plan, 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. -* `user_metadata` - stores user attributes (such as user preferences) that do not impact a user's core functionality. +Message bodies have HTML content, and Liquid syntax is the currently supported templating syntax to use. You can use all the [common variables](#common-variables) plus variables defined in each [individual template](#individual-templates-descriptions). -[Learn more about `app_metadata` and `user_metadata`](/metadata) +#### Multilingual Email Templates -For example, you can refer to attributes in the template to control flow as follows: +You can use Liquid syntax along with properties from the user object to alter the content based on the user preferred language. For example: ```text {% if user.user_metadata.lang == 'es' %} @@ -149,72 +209,73 @@ To assist your template development, we've added a custom `{% debug %}` liquid t Use of Markdown in email templates has been deprecated, so you will no longer be able to add new Markdown formatting. If you have an existing template in Markdown, you will be able to toggle from Markdown to Liquid, but changing this setting will result in you losing any existing Markdown, as well as the ability to use Markdown. ::: -The use of Markdown in email templating has been **deprecated**, and is only available for templates which were already using Markdown as the templating syntax. The available attributes for Markdown syntax are: - -* `email` -* `email_verified` -* `picture` -* `name` -* `nickname` -* `given_name` -* `family_name` +The use of Markdown in email templating has been **deprecated**, and is only available for templates which were already using Markdown as the templating syntax. +The Markdown syntax uses a `@@variable@@` format for variable substitution. The available variables are similar to those mentioned above for Liquid syntax. -For example, you can refer to attributes in the template as follows: +For example, you can refer to a user in the template as follows: ```text Hello @@user.given_name@@ @@user.family_name@@ ``` -### Verification Email +## Individual Templates Descriptions -When users sign-up or login for the first time, they will be sent a verification email. Clicking on the verification link in the email sets the 'email verified' property of their user profile to `true`. +### Verification Email (Using Link) -The following macros are available in the **Verification Email** template: +If you turn on the **Verification Email**, users who sign up on a database connection will receive a message asking to confirm their email address by clicking on a URL included in the message. -* `{application.name}` -* `{connection.name}` -* `{user.email}` +In addition to the [common variables](#common-variables) available for all email templates, the **Verification Email** provides the `url` variable that refers to the URL that the user will have to click. You will use it in the **Message** field to create a link that the user can follow, as in this example: -If you configure a **Redirect To** URL, the user will be directed to this URL after clicking the verification link. The following will be appended to the query string: - -```text -http://myapplication.com/my_page/ - ?email=john%40contoso.com - &message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application. - &success=true +```html +Confirm my account ``` +#### Redirect To Results for the Verification Email Template -### Welcome Email +You can [configure a **Redirect To** URL](#configuring-redirect-to) to send the users to after the email verification action was attempted. By default, Auth0 includes the following parameters: -Once a user verifies their email address, they will receive a **Welcome Email**. If you turn off the **Verification Email** feature, the **Welcome Email** will be sent to the user when they sign-up (or login for the first time). +* `success` with value `true` or `false` indicating whether the email verification was successful +* `message` with an additional description of the outcome. Some possible values are: + * `Your email was verified. You can continue using the application.` (with `success=true`) + * `This URL can be used only once` (with `success=false`) + * `Access expired.` (with `success=false`) + * `User account does not exist or verification code is invalid.` (with `success=false`) + * `This account is already verified.` (with `success=false`) +* `email` if `Include Email In Redirect` is enabled in the template. By default, `email` is not included -The following macros are available in the **Welcome Email** template: +The target URL handler should be prepared to gracefully handle other possible messages as well. -* `{application.name}` -* `{connection.name}` -* `{user.email}` +### Verification Email (Using Code) -### Change Password Confirmation Email +Azure AD and ADFS connections support an [email verification flow](/connections/azuread-email-verification#email-verification-flow-for-azure-ad/adfs- connections) using a one-time-use code. If you enable this feature, users will be prompted to enter the code before continuing the authentication flow. -If a user requests a password change, they will receive a **Change Password Confirmation Email**. Until the user clicks the verification link contained in the email, the password will remain unchanged. -If a user requests a password change, this email will be sent. The password will not be changed until the user follows the verification link in the email. @@url@@ (or {{ url }} if you are using the HTML + Liquid syntax) is a placeholder for the verification link. +### Welcome Email -The following macros are available in the **Change Password Confirmation** email template: +Once a user verifies their email address, they will receive a **Welcome Email**. If you turn off the **Verification Email** feature, the **Welcome Email** will be sent to the user when they sign-up (or login for the first time). -* `{application.name}` -* `{connection.name}` -* `{user.email}` +### Change Password Email -This email template has a [**Redirect To** URL field](#redirect-to-url), which contains the URL the user will be directed to URL after clicking the verification link. The following will be appended to the query string: +If a user requests a password change, they will receive a **Change Password** that contains a URL link. When the user clicks on the link, a [Password Reset page](/universal-login/password-reset) will be presented to enter the new password. -```text -http://myapplication.com/my_page/ - ?success=true - &message=You%20can%20now%20login%20to%20the%20application%20with%20the%20new%20password. +In addition to the [common variables](#common-variables) available for all email templates, the **Change Password** has the `url` variable that refers to the URL that the user will have to click. You will use it in the **Message** field to create a link that the user can follow, as in this example: + +```html +Click here to change your password ``` -This template also has a **URL Lifetime** field which is the lifetime of the URL in seconds. The default is 432000 seconds (5 days). +#### Redirect To Results for the Change Password Template + +You can [configure a **Redirect To** URL](#configuring-redirect-to) to send the users to after the password change action was attempted. By default, Auth0 includes the following parameters: + +* `success` with value `true` or `false` indicating whether the password change was successful +* `message` with an additional description of the outcome. Some possible values are: + * `You can now login to the application with the new password.` (with `success=true`) + * `This URL can be used only once` (with `success=false`) + * `Access expired.` (with `success=false`) + * `The operation cannot be completed. Please try again.` (with `success=false`) +* `email` if `Include Email In Redirect` is enabled in the template. By default, `email` is not included + +The target URL handler should be prepared to gracefully handle other possible messages as well. ### Blocked Account Email @@ -222,21 +283,88 @@ If a user attempts to login ten or more times unsuccessfully from the same IP ad If the user successfully logs in before they exhaust their ten allowed attempts, the counter is reset. -The following macros are available in the **Blocked Account Email** template: +In addition to the [common variables](#common-variables) available for all email templates, the following ones are available in the **Blocked Account Email** template: * `user.source_ip` * `user.city` * `user.country` -* `application.name` -* `connection.name` -### Password Breach Alert +This template also provides the `url` variable that should be used to create the link that the user needs to follow. E.g.: + +```html +Click here to unblock your account +``` + +#### Redirect To Results for the Blocked Account Email Template + +You can [configure a **Redirect To** URL](#configuring-redirect-to) to send the users to after the account unblocking action was attempted. When redirecting, Auth0 will include the following parameters: + +* `email` indicating the email of the user +* `success` with value `true` or `false` indicating whether the account unblocking was successful +* `message` with an additional description of the outcome. Some possible values are: + * `Your account has been unblocked.` (with `success=true`) + * `This URL can be used only once` (with `success=false`) + * `Access expired.` (with `success=false`) + +The target URL handler should be prepared to gracefully handle other possible messages as well. + +### Password Breach Alert Email This email type is sent whenever Auth0 detects that the user is trying to access the application using a password that has been leaked by a third party. These emails are only set after enabling **Breached Password Detection** in the [Anomaly Detection](${manage_url}/#/anomaly) section of the dashboard. -The following macros are available in the **Password Breach Alert** template: +Learn more about [Breached Password Detection](/anomaly-detection#breached-password-detection) + +### Multi-factor Authentication Enrollment Email + +This email will be generated when an multi-factor authentication enrollment invitation is sent. The message will contain a link that, when visited, will show the MFA enrollment experience. + +Besides the [common variables](#common-variables) available for all email templates, the `link` variable is available in this email type, containing the URL that you will use to construct the link for this action, as in this example: + +```html +Enroll your MFA device +``` -* `{application.name}` -* `{connection.name}` +Do note that, unlike other email templates, the correct variable name is `link` and not `url`. Also, the `connection.name` variable is not available on this email template type. + +### Verification Code for Email MFA + +This email will be generated when you use email as a MFA method and request a verification code to be sent. + +In addition to the [common variables](#common-variables) available, the template provides a `code` variable to render the code used for MFA verification. E.g.: + +```html +
      Your code is: {{ code }}
      +``` + +### Passwordless Email + +Unlike the previous email templates types, this email template is not configured from the Email Templates section. Instead, it's part of the [settings for the Email Passwordless Connection](${manage_url}/#/connections/passwordless). + +The Passwordless Email is sent when a passwordless access is requested, either by code (the user receives a code that types in the application) or by a link (the user clicks on a link and is taken directly to the application). + +You can use all the [common variables](#common-variables) available in all templates, plus the following variables defined specifically for the **Passwordless Email** template: + +* `send`, which will contain a value of `link`, `link_ios`, `link_android` or `code` depending on the type of passwordless email requested. +* `code` with the one-time-use code to access the application +* `link` with the link that can be clicked by the user to gain access to the application (only for link-type passwordless emails) +* `request_language` will have the language code of the user request, if available +* `operation`, which will be `change_email` if this is a passwordless email change operation. + +The default template uses the above variables to do something like this: + +```html + +{% if operation == 'change_email' %} +

      Your email address has been updated.

      +{% else %} + + {% if send == 'link' or send == 'link_ios' or send == 'link_android' %} +

      Click and confirm that you want to sign in to {{ application.name }}. This link will expire in five minutes.

      + Sign in to {{ application.name }} + {% elsif send == 'code' %} +

      Your verification code is: {{ code }}

      + {% endif %} +{% endif %} +``` -[Learn more about Breached Password Detection](/anomaly-detection#breached-password-detection) +Note that in the Passwordless Email template only the `email` property of the `user` object is available. diff --git a/articles/email/testing.md b/articles/email/testing.md index 7644627193..827791ceba 100644 --- a/articles/email/testing.md +++ b/articles/email/testing.md @@ -1,5 +1,10 @@ --- description: Auth0 recommends you setup a fake SMTP server while in development or testing. +topics: + - email + - smtp +contentType: how-to +useCase: customize-emails --- # Set Up a Test SMTP Provider @@ -16,6 +21,8 @@ You can either: Once you have either your own SMTP server set up or a test service available, you can provide its credentials the way you typically would for a [custom email provider](/email/providers#configure-a-custom-smtp-server-for-sending-email). +<%= include('../_includes/_email-domain-blacklist') %> + ## Resources to Consider ::: next-steps diff --git a/articles/errors/dbconnections/self_change_password.md b/articles/errors/dbconnections/self_change_password.md deleted file mode 100644 index 7f83c2fcfd..0000000000 --- a/articles/errors/dbconnections/self_change_password.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -description: Error messages for the self change password API. -public: false ---- -# 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/errors/dbconnections/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/articles/errors/deprecation-errors.md b/articles/errors/deprecation-errors.md index 95ab54074c..f3b68bb35f 100644 --- a/articles/errors/deprecation-errors.md +++ b/articles/errors/deprecation-errors.md @@ -2,6 +2,14 @@ title: Deprecation Error Reference description: A listing of errors and descriptions relating to deprecations. toc: true +topics: + - errors + - deprecation +contentType: + - reference + - concept + - how-to +useCase: error-management --- # Deprecation Error Reference @@ -9,11 +17,11 @@ When Auth0 features are deprecated, there may be errors or notices in the tenant ## How to search logs for deprecation warnings -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. +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/references/log-data-retention) is governed by the subscription level of your account. ### Search logs via 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}). +If your application uses a deprecated feature, a Deprecation Notice message will show up in the Logs section of the [Dashboard](${manage_url}/#/). ::: note In order to not overwhelm the logs with repetitive messages, deprecation notes will only be shown once per hour (the first time it occurs within that hour) rather than for each authentication transaction involving the deprecated feature. @@ -39,7 +47,7 @@ Customers can also use the Management API to search through logs for such messag To check your logs using the Management API, go to the [Management API](/api/management/v2). -If you have not already done so, [get and set up your API token](/api/management/v2/tokens#get-a-token-manually) in the API explorer. +If you have not already done so, [get and get an API token](/api/management/v2/tokens). ![Management API - Token Setup](/media/articles/errors/libraries/management-api-set-token.png) @@ -56,7 +64,7 @@ Click on the **TRY** button. If successful, you should see a screen similar to t * 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 Messages +## Deprecation Log Messages ### up-idp-initiated @@ -66,11 +74,10 @@ Click on the **TRY** button. If successful, you should see a screen similar to t | Cause | Resolution | | --- | --- | -| You are using a legacy version of embedded Lock or Auth0.js SDK. | [Migrate to Universal Login](/guides/login/migration-embedded-universal) if possible or [upgrade to Lock v11 / Auth0.js v9](/migrations#introducing-lock-v11-and-auth0-js-v9) (Reference guide for [Lock v11](/libraries/lock/v11) and for [Auth0.js v9](/libraries/auth0js/v9)). | -| Calling /login endpoint directly. | Migrate to use a form of the [/authorize endpoint](/api/authentication?http#login) as the start of authentication transactions. | -| Users bookmarking the login URL and trying to initiate login from that bookmarked link at a later time. | Educate users to bookmark instead the place in your app to which they want to return (such as the home page). Depending on your design choices, and if there's no valid session for the user in the app, the app will either start the authorization process or show a login button. | -| Users hitting the back button in the middle of a login transaction. | Educate users to start the login transaction again, starting from the initial login button/link, rather than using the back or forward button. | +| 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. | ### ssodata @@ -81,3 +88,7 @@ Click on the **TRY** button. If successful, you should see a screen similar to t | Cause | Resolution | | --- | --- | | Either calling the /ssodata directly or using old versions of embedded Lock or Auth0.js SDK to call a function which called the /ssodata endpoint. | [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). | + +## Legacy Lock API troubleshooting + +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. diff --git a/articles/errors/libraries/auth0-js/invalid-token.md b/articles/errors/libraries/auth0-js/invalid-token.md deleted file mode 100644 index 324b61a753..0000000000 --- a/articles/errors/libraries/auth0-js/invalid-token.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -public: true ---- - -# Errors with code 'invalid_token' - -## 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](/api-auth/why-use-access-tokens-to-secure-apis). - diff --git a/articles/errors/managment-v2/placeholder.md b/articles/errors/managment-v2/placeholder.md deleted file mode 100644 index 87f2df24fb..0000000000 --- a/articles/errors/managment-v2/placeholder.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -public: false ---- - -# Management API Errors \ No newline at end of file diff --git a/articles/errors/oauth/placeholder.md b/articles/errors/oauth/placeholder.md deleted file mode 100644 index 38f51cf4dd..0000000000 --- a/articles/errors/oauth/placeholder.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -public: false ---- - -# OAuth Errors \ No newline at end of file diff --git a/articles/errors/saml/placeholder.md b/articles/errors/saml/placeholder.md deleted file mode 100644 index 93cc830499..0000000000 --- a/articles/errors/saml/placeholder.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -public: false ---- - -# SAML Errors \ No newline at end of file diff --git a/articles/errors/wsfed/placeholder.md b/articles/errors/wsfed/placeholder.md deleted file mode 100644 index b8afff3b6c..0000000000 --- a/articles/errors/wsfed/placeholder.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -public: false ---- - -# WS-Fed Errors \ No newline at end of file diff --git a/articles/extend-integrate/index.md b/articles/extend-integrate/index.md new file mode 100644 index 0000000000..9c187be647 --- /dev/null +++ b/articles/extend-integrate/index.md @@ -0,0 +1,60 @@ +--- +classes: topic-page +title: Extend & Integrate +description: Learn how to extend the functionality of Auth0's base product and integrate Auth0 with other applications and services. +topics: + - extensions + - integrations +contentType: index +useCase: + - integrate-third-party-apps + - integrate-analytics + - integrate-marketing + - integrate-saas-sso + - extensibility-extensions +--- + +
      +
      +

      Extend & Integrate

      +

      + Learn how to extend the functionality of Auth0's base product and integrate Auth0 with other applications and services. + +

        +
      • + 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. Learn how to configure and use rules with Auth0. +

        +
        • +
      • + Hooks +

        + Hooks are secure, self-contained functions that allow you to customize the behavior of Auth0 when executed for selected [extensibility points](/hooks/extensibility-points) of the Auth0 platform. Learn how to configure and use hooks with Auth0. +

        +
        • +
      • + Extensions +

        + Auth0 provides pre-defined extensions that enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. +

        +
        • +
      • + Single Sign-On (SSO) Integrations +

        + Learn how to set up Single Sign-on (SSO) between Auth0 and various services. +

        +
        • +
      • + Marketing Integrations +

        + Learn how to import your Auth0 user data into marketing tools. +

        +
        • +
      • + Add-ons +

        + 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). +

        +
        • +
      \ No newline at end of file diff --git a/articles/extensions/_includes/_batch-size.md b/articles/extensions/_includes/_batch-size.md new file mode 100644 index 0000000000..139198c627 --- /dev/null +++ b/articles/extensions/_includes/_batch-size.md @@ -0,0 +1,16 @@ +### Batch size + +When setting your **BATCH_SIZE**, please keep the following information in mind. + +During each time frame/window (defined by your chosen **Schedule**), outstanding logs will be batched into groups and sent. The size of each group is determined by the **BATCH_SIZE** value. + +In other words, during each window, `NUM_BATCHES` batches of logs will be sent based on the following logic: + +``` +IF (NUM_LOGS modulo 100 == 0): + NUM_BATCHES = (NUM_LOGS / BATCH_SIZE) +ELSE: + NUM_BATCHES = (NUM_LOGS / BATCH_SIZE) + 1 +``` + +In the `ELSE` case, the last batch will have < 100 logs. \ No newline at end of file diff --git a/articles/extensions/_includes/_deployment-extension.md b/articles/extensions/_includes/_deployment-extension.md new file mode 100644 index 0000000000..7c3441a6bd --- /dev/null +++ b/articles/extensions/_includes/_deployment-extension.md @@ -0,0 +1,3 @@ +::: note +The deployment extension accepts an application name instead of the client ID in the `client_id` property. It will try to match the name to an existing application before creating the Client Grant. +::: \ No newline at end of file diff --git a/articles/extensions/_includes/_embedded-clients-array.md b/articles/extensions/_includes/_embedded-clients-array.md new file mode 100644 index 0000000000..f47346cf5e --- /dev/null +++ b/articles/extensions/_includes/_embedded-clients-array.md @@ -0,0 +1,3 @@ +::: note +The `enabled_clients` array, when used directly with the Management API v2, is a list of client IDs for which the connection is enabled. As an added convenience, the deployment extension will attempt to match entries in the `enabled_clients` array by client name and replace them with the appropriate client ID when a match is found, allowing you to specify `"my-client-name"` instead of `"my-client-id"` to refer to each application. +::: \ No newline at end of file diff --git a/articles/extensions/_includes/_use-default-error.md b/articles/extensions/_includes/_use-default-error.md new file mode 100644 index 0000000000..e98dfdcebc --- /dev/null +++ b/articles/extensions/_includes/_use-default-error.md @@ -0,0 +1,3 @@ +::: note +The `error_page` cannot be enabled/disabled. To use the default error page, remove the content of `error_page.html`. +::: diff --git a/articles/extensions/_troubleshoot-webhooks.md b/articles/extensions/_troubleshoot-webhooks.md index d0f173d98f..fe0a389dc8 100644 --- a/articles/extensions/_troubleshoot-webhooks.md +++ b/articles/extensions/_troubleshoot-webhooks.md @@ -6,7 +6,7 @@ However, there are certainly alternatives to the inefficient process we detailed 1. Check the [Logs](/logs) section of the [Dashboard](${manage_url}/#/logs) for helpful messages. -1. Analyze the requests your webhook is making using a tool like [Hookbin](https://hookbin.com/) or [Mockbin](http://mockbin.org/). +1. Analyze the requests your webhook is making using a tool like [Mockbin](http://mockbin.org/), [Beeceptor](https://beeceptor.com/), or (self-hosted) [RequestBin](https://github.com/Runscope/requestbin). 1. Mock requests using cURL or [Postman](https://www.getpostman.com/) diff --git a/articles/extensions/account-link.md b/articles/extensions/account-link.md index f5691e01b4..6c7e6f8a74 100644 --- a/articles/extensions/account-link.md +++ b/articles/extensions/account-link.md @@ -1,8 +1,14 @@ --- -toc: true description: The Account Link extension allows users with two accounts with the same email to be prompted to link them. +topics: + - extensions + - account-linking +contentType: + - how-to + - concept +useCase: extensibility-extensions --- -# Account Link +# Account Link Extension The **Account Link** extension prompts users that may have created a second account by mistake to link the new account with their old one on their first login. The user may choose to either link the two accounts or keep them separate if it was intentional. @@ -10,9 +16,7 @@ The **Account Link** extension prompts users that may have created a second acco To install this extension, click on the __Account Link__ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the dashboard. The __Install Extension__ window will open. -![Install Account Link Extension](/media/articles/extensions/account-link/install-extension.png) - -The extension will create a new **Application** named `auth0-account-link` to use internally and a new **Rule** to redirect users to the extension if they login with a new account that has an email matching an existing account. +The extension will create a new **Application** named `auth0-account-link` to use internally and a new **Rule** to redirect users to the extension if they login with a new account that has an email matching an existing account. This application needs to have enabled all the connections that you want to perform account linking with. ## Setup @@ -22,11 +26,11 @@ We recommend changing the name of the default application used for the extension ### Updating the Login Page -By default, Auth0's [universal login](/hosted-pages/login) allows a user to both login and sign up as one may expect. However, when the account linking asks you to authenticate your primary account in order to link it with the new account, providing a sign up option can be confusing for users. +By default, Auth0's [Universal Login](/universal-login) allows a user to both login and sign up as one may expect. However, when the account linking asks you to authenticate your primary account in order to link it with the new account, providing a sign up option can be confusing for users. To prevent this, we send over a query parameter to let the login page know that it should hide the **Sign Up** option. In order for this query parameter to take effect, however, we must first customize the login page. -First go to your [Dashboard](${manage_url}) and click on **Hosted Pages**. It should open to the login page by default. +First go to your [Dashboard](${manage_url}) and click on **Universal Login**. It should open to the login page by default. If it is not already enabled, toggle the **Customize Login Page** to enable the custom editor below. In the editor we're going to add a new line to the Lock config. @@ -42,6 +46,10 @@ Then save your changes and attempt to link an account. You'll notice that the ** ![Account Linking Hosted Page](/media/articles/extensions/account-link/hosted-page-example.png) +:::note +Hiding the Signup link is not supported in the New Universal Login Experience. +::: + ## Customization At installation, or any time after by clicking the **Settings** icon for the Account Link Extension, you can add a URL to a custom stylesheet if you would like to customize the extension page to look a bit different from the default theme. @@ -50,10 +58,6 @@ At installation, or any time after by clicking the **Settings** icon for the Acc ## Administration Panel -::: warning -This feature is available in version 2.0 and up. -::: - You can customize your account linking login page and widget using the extension administration panel. Go to **Dashboard > Extensions > Installed Extensions > Auth0 Account Link**. @@ -71,3 +75,25 @@ Do not remove `{{ ExtensionCSS }}`, `{{ CustomCSS }}`, `{{ Auth0Widget }}`, or ` ::: ![Widget Settings](/media/articles/extensions/account-link/widget-settings.png) + +## Custom domains + +If you're using a custom domain, you'll need to update the **auth0-account-link-extension** [rule](/rules) that is automatically created when you installed the extension. (You can find this rule in your Dashboard by going to **Rules** using the left-hand navigation bar). + +By default, line 27 of the rule is `issuer: auth0.domain`. You will need to change this to `issuer: "myCustomDomain.com"`, making sure to omit the protocol portion of the URL. + +:::note +Uninstalling/reinstalling, as well as updating, the extension may override this change. +::: + +## How does the extension work? + +The extension triggers after authentication, when there is an existing user account using a different provider but with an email address that is the same as that of the user who just authenticated. + +For example, if a user logs in with their Facebook account using the email `john@acme.com`, and then later authenticates with Google using the same email address, they will be prompted with a page like this: + +![Account Linking Extension](/media/articles/extensions/account-link/account-linking-extension.png) + +The extension does not automatically link users with the same email, even if emails are verified. Verified emails are not enough evidence to prove that the user can currently authenticate to both accounts. + +If the user clicks **Continue**, they will be redirected to Facebook to authenticate. If the user is already logged in, Facebook will redirect back to the application, and the user will be automatically linked. If they are not logged in, they will be prompted first to authenticate with their Facebook credentials. Then, the account will be linked with the Google account after Facebook redirects back to Auth0. This process ensures that it is the same user who has the credentials to authenticate to both accounts. This allows the accounts to be linked safely without fear of linking accounts incorrectly. diff --git a/articles/extensions/adldap-connector.md b/articles/extensions/adldap-connector.md index 9ae21de4d5..3d4b011dee 100644 --- a/articles/extensions/adldap-connector.md +++ b/articles/extensions/adldap-connector.md @@ -1,8 +1,14 @@ --- description: This page explains the Auth0 AD/LDAP Connector Health Monitor Extension and how to install and configure it. +topics: + - extensions + - ad/ldap-connector +contentType: + - how-to +useCase: extensibility-extensions --- -# Auth0 Extension: Auth0 AD/LDAP Connector Health Monitor +# Auth0 AD/LDAP Connector Health Monitor The Auth0 AD/LDAP Connector Health Monitor exposes an API endpoint of your choice so that you can monitor your AD/LDAP connectors. diff --git a/articles/extensions/application-insight.md b/articles/extensions/application-insight.md index c02af1f1b1..b530aa911f 100644 --- a/articles/extensions/application-insight.md +++ b/articles/extensions/application-insight.md @@ -1,52 +1,45 @@ --- description: This page explains how to configure and install Auth0's Logs to Application Insights extension. +topics: + - extensions + - application-insights +contentType: + - how-to +useCase: extensibility-extensions --- - # Auth0 Logs to Application Insights The *Auth0 Logs to Application Insights* is a scheduled job takes all of your Auth0 logs and exports them to [Application Insights](https://azure.microsoft.com/en-us/services/application-insights/). ## Configure the Extension -To install and configure this extension, click on the __Auth0 Logs to Application Insights__ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [dashboard](${manage_url}). The __Install Extension__ window pops open. - -![Install Extension](/media/articles/extensions/appinsights/ext-mgmt-appinsights.png) +To install and configure this extension, click on the __Auth0 Logs to Application Insights__ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [Dashboard](${manage_url}). -At this point you should set the following configuration variables: +The __Install Extension__ window pops open, and you will be asked to set the following configuration variables: - __Schedule__: The frequency with which logs should be exported. -- __Batch_Size__: TThe amount of logs to be read on each execution. Maximun is 100. -- __AppInsights_Instrumentation_Key__: The Application Insights instrumentation key. - - Once you have provided the appropriate values for the above fields, click __Install__ to proceed. - -## Retrieve the required information from Application Insights - -Let's see how we can retrieve the __AppInsights_Instrumentation_Key__ information. +- __Batch_Size__: The amount of logs to be read on each execution. Maximum is 100. +- __Start_From__: The ID of the log that you want to start sending from +- __Slack_Incoming_Webhook_URL__: The Slack webhook URL that you want to use to receive notifications regarding your log-sending process +- __Slack_Send_Success__: If yes, Auth0 will send verbose notifications to Slack +- __Log_Level__: The log level of events to be sent; Auth0 will send all logs at the selected above and higher +- __Log_Types__: The types of logs you want send; leave blank to send all log events +- __AppInsights_Instrumentation_Key__: The Application Insights instrumentation key (see the following section for information on obtaining the instrumentation key if you do not already have it) -1. Login to your [Azure Portal](https://portal.azure.com/#) and add a new _Application Insights_ instance in your subscription. To do so click __New__ and search for `Application Insights`. + When done, click __Install__ to proceed. -![New Application Insights instance](/media/articles/extensions/appinsights/new-appinsights.png) + <%= include('./_includes/_batch-size') %> -2. Click __Create__ and fill in the required information, such as the name of your instance, the application type and the resource group. Click __Create__ to trigger the provisioning process. - -![Configure Application Insights instance](/media/articles/extensions/appinsights/conf-appinsights.png) - -3. Once the provisioning is complete (after a few seconds usually) you can get the __Instrumentation Key__ from the Properties page. - -![Application Insights Properties](/media/articles/extensions/appinsights/appinsights-properties.png) - -4. Copy this value and head back to your [Auth0 dashboard](${manage_url}). Set it at the __AppInsights_Instrumentation_Key__ field. Save your changes. +## Retrieve the required information from Application Insights +When configuring the extension, you'll be asked by Auth0 to provide the [instrumentation key](https://docs.microsoft.com/en-us/azure/azure-monitor/app/create-new-resource#copy-the-instrumentation-key) for Application Insights. You will need to have [created an Application Insights resource](https://docs.microsoft.com/en-us/azure/azure-monitor/app/create-new-resource#copy-the-instrumentation-key) with Azure before you can obtain this value. ## Use Your Installed Extension -To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page of the [dashboard](${manage_url}), click on the __Installed Extensions__ link, and select the __Auth0 Logs to Application Insights__ line. There you can see the job you just created, modify its state by toggling the __State__ switch, see when the next run is due and what was the result of the last execution. - -![View Cron Jobs](/media/articles/extensions/appinsights/view-cron-jobs.png) +To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Dashboard](${manage_url}). Click on the __Installed Extensions__ link, and select the __Auth0 Logs to Application Insights__ line. -You can view more details by clicking on the job you created. In this page you can view details for each execution, reschedule, access realtime logs, and more. +There, you can see the job you just created, modify its state by toggling the __State__ switch, and see when the next run is due and what was the result of the last execution. -![View Cron Details](/media/articles/extensions/appinsights/view-cron-details.png) +You can view more details by clicking on the job you created. On this page you can view details for each execution, reschedule, access real-time logs, and more. -That's it, you are done! You can now navigate to your [Azure Portal](https://portal.azure.com/#) and view your [Auth0 Logs](${manage_url}/#/logs). +At this point, you can navigate to your [Azure Portal](https://portal.azure.com/#) to view your [Auth0 Logs](${manage_url}/#/logs). diff --git a/articles/extensions/authentication-api-debugger.md b/articles/extensions/authentication-api-debugger.md index 195143f5d5..bb6b1fdf26 100644 --- a/articles/extensions/authentication-api-debugger.md +++ b/articles/extensions/authentication-api-debugger.md @@ -1,5 +1,11 @@ --- description: This page explains how to use the Authentication API Debugger +topics: + - extensions + - auth-api-debugger +contentType: + - how-to +useCase: extensibility-extensions --- # Authentication API Debugger Extension diff --git a/articles/extensions/authentication-api-webhooks.md b/articles/extensions/authentication-api-webhooks.md index a4a05f6797..b1fe440de1 100644 --- a/articles/extensions/authentication-api-webhooks.md +++ b/articles/extensions/authentication-api-webhooks.md @@ -1,5 +1,11 @@ --- description: This page explains how to configure and install Auth0's Authentication API Webhooks extension. +topics: + - extensions + - auth-api-webhooks +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Authentication API Webhooks @@ -11,12 +17,14 @@ The Auth0 Authentication API Webhooks Extension is a scheduled job that allows y To complete installation of this extension, click on the Auth0 Authentication API Webhooks box in the list of provided extensions on the Extensions page of the Management Portal. In the "Install Extension" window that then pops open, you will be asked to provide the following configuration variables: - __Schedule__: The frequency with which the job runs -- __Auth0_Domain__: The domain of your Auth0 app -- __Auth0_Global_Client_ID__: The Client ID of your Auth0 app -- __Auth0_Global_Client_Secret__: The Client Secret of your Auth0 app -- __Auth0_API_Endpoints__: The specific Auth0 Management API endpoints you want to monitor/call -- __Webhook URL__: The URL of your webhook -- __Webhook_Concurrent_Calls__: The maximum number of concurrent calls that will be made to your webhook +- __Batch_Size__: The amount of logs the extension will attempt to read and send on each execution. Extension could send multiple batches per run, depending on amount of time necessary to process. Maximum batch size is 100. +- __Webhook_URL__: The URL of your webhook +- __Authorization__: String to be added as `Authorization` header. +- __Send_as_Batch__: If enabled, the extension will send the whole batch of logs to the webhook in a single request. Otherwise, extension sends logs one-by-one to webhook. Only disable if your webhook does not support batched messages. +- __Webhook_Concurrent_Calls__: The maximum number of concurrent calls that will be made to your webhook. +- __Start_From__: Log Checkpoint to start from. +- __Slack_Incoming_Webhook_URL__: Extension can report statistics and possible failures to the Slack. +- __Slack_Send_Success__: If enabled, extension will be sending messages on each run. Otherwise - only on fails. - __Log_Level__: The minimal log level of events that you would like sent - __Log_Types__: The specific events for which logs should be exported @@ -64,4 +72,4 @@ Here is an example of the payload that will be sent: } ``` -<%= include('./_troubleshoot-webhooks') %> \ No newline at end of file +<%= include('./_troubleshoot-webhooks') %> diff --git a/articles/extensions/authorization-extension/v1/index.md b/articles/extensions/authorization-extension/v1/index.md index 75935b5d39..eefc569539 100644 --- a/articles/extensions/authorization-extension/v1/index.md +++ b/articles/extensions/authorization-extension/v1/index.md @@ -1,5 +1,12 @@ --- description: This page explains how to setup and manage the Authorization Extension v1. +topics: + - extensions + - authorization_v1 +contentType: + - tutorial + - concept +useCase: extensibility-extensions --- # Auth0 Authorization Extension v1 @@ -8,7 +15,7 @@ description: This page explains how to setup and manage the Authorization Extens This document covers an outdated version. We recommend you to [upgrade to v2](/extensions/authorization-extension/v2). ::: -The Auth0 Authorization Extension provides user authorization support in Auth0. Version 1 of the extension supports authorizations using Groups. Upgrade to [version 2](/extensions/authorization-extension) to support authorizations with Roles and Permissions. +The Auth0 Authorization Extension provides user authorization support in Auth0. Version 1 of the extension supports authorizations using Groups. Upgrade to [version 2](/extensions/authorization-extension) to support authorizations with Roles and Permissions. ## Setting Up a New Authorization Extension diff --git a/articles/extensions/authorization-extension/v2/api-access.md b/articles/extensions/authorization-extension/v2/api-access.md index 211293e8de..c724cb1f4c 100644 --- a/articles/extensions/authorization-extension/v2/api-access.md +++ b/articles/extensions/authorization-extension/v2/api-access.md @@ -1,10 +1,21 @@ --- title: Enabling API Access to the Authorization Extension description: How to enable API access to the Authorization Extension +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: API Access -Once configured and set up, your extension should contain users, as well as groups, roles, and permissions. You can automate provisioning and query the authorization context of your users in real-time if you enable API access to your extension. +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: + +Once configured and set up, your extension should contain users, as well as groups, roles, and permissions. You can automate provisioning and query the authorization context of your users in real-time if you enable API access to your extension. ## Enable API Access @@ -34,27 +45,27 @@ You'll be redirected to the **Quick Start** page of the Application, where you c Since this is the first time you're working with the API and Application together, you'll see a message that says, "This application is not authorized for this API." To authorize the application for use with the API, click **Navigate to the API and Authorize**. -![Application Quick Start Page](/media/articles/extensions/authorization/application-quick-start.png) +![Application Quick Start Page](/media/articles/extensions/authorization/client-quick-start.png) You'll see a list of Machine to Machine Applications you can use with your API. Click the slider next to the Application you just created to authorize it. -![Authorize Application](/media/articles/extensions/authorization/applications-for-api.png) +![Authorize Application](/media/articles/extensions/authorization/clients-for-api.png) Once you've authorized the Application, you'll see the **Grant ID**. You can also select the **Scopes** to be granted to the Application. The scopes you grant depends on the endpoints you want to access. For example, you'd grant `read:users` to [get all users](hapi/authorization-extension#get-all-users). If you make any changes to the scopes, click **Update** to save. -![Scopes](/media/articles/extensions/authorization/application-scopes.png) +![Scopes](/media/articles/extensions/authorization/client-scopes.png) ### Get the Access Token -To access the API, you'll need to [ask for and obtain the appropriate token](https://auth0.com/docs/api-auth/tutorials/client-credentials#ask-for-a-token). +To access the API, you'll need to [ask for and obtain the appropriate token](/flows/guides/client-credentials/call-api-client-credentials#request-token). ### Call the API You can call the API via: -* An HTTML request +* An HTML request * A cURL command You can also find detailed information about the endpoints, as well as samples on how to call each endpoint using the three methods above, in the [Authorization Extension API Explorer](/api/authorization-extension). @@ -71,4 +82,4 @@ Click over to the **Explorer** page for the API documentation. * [Use the Authorization Extension's Data in Rules](/extensions/authorization-extension/v2/rules) * [Import/Export Data](/extensions/authorization-extension/v2/import-export-data) * [Troubleshoot Errors](/extensions/authorization-extension/v2/troubleshooting) -::: \ No newline at end of file +::: diff --git a/articles/extensions/authorization-extension/v2/implementation/configuration.md b/articles/extensions/authorization-extension/v2/implementation/configuration.md index 56e6a5a7fc..8182bf0e25 100644 --- a/articles/extensions/authorization-extension/v2/implementation/configuration.md +++ b/articles/extensions/authorization-extension/v2/implementation/configuration.md @@ -2,10 +2,21 @@ title: Configuring the Authorization Extension description: How to configure the Authorization Extension toc: true +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Configuration +::: note +<%= include('../../../../_includes/_rbac_methods') %> +::: + Before the extension can enforce your authorization logic, you'll need to configure how it will behave during the login transaction. Your configuration settings will be captured in a [rule](/rules) that's executed during runtime. ## Configure the Extension @@ -18,7 +29,13 @@ This brings you to the **Rule Configuration** section of the **Configuration** p ![Configuration page](/media/articles/extensions/authorization/configuration.png) -All of the changes you make in the sections under **Token Contents**, such as those related to groups, roles, and permissions, will be reflected in the rule you export at the completion of this step. +All of the changes you make in the sections under **Token Contents**, such as those related to groups, roles, and permissions, will be reflected in the rule you export at the completion of this step. + +### ApiKey + +The rule is using ApiKey to communicate with the Authorization Extension API and can be used only to get the policy. ApiKey is stored as a rule config and it will be created automatically when the rule is published. You can rotate the ApiKey by pressing the "Rotate" button. It will update the rule config automatically. + +![ApiKey config](/media/articles/extensions/authorization/apikey-config.png) ## Add Authorization Information to the Token Issued @@ -68,4 +85,4 @@ You can open it up to see the exact rules configuration. * [Use the Authorization Extension's Data in Rules](/extensions/authorization-extension/v2/rules) * [Troubleshoot Errors](/extensions/authorization-extension/v2/troubleshooting) * [Set Up the Authorization Extension](/extensions/authorization-extension/v2/implementation/setup) -::: \ No newline at end of file +::: diff --git a/articles/extensions/authorization-extension/v2/implementation/installation.md b/articles/extensions/authorization-extension/v2/implementation/installation.md index a324a556d6..5d74a9501f 100644 --- a/articles/extensions/authorization-extension/v2/implementation/installation.md +++ b/articles/extensions/authorization-extension/v2/implementation/installation.md @@ -2,16 +2,27 @@ title: Installing the Authorization Extension description: How to install the Authorization Extension toc: true +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Installation +::: note +<%= include('../../../../_includes/_rbac_methods') %> +::: + This doc walks you through the process of installing the Authorization Extension. Before you begin, make sure that you have an existing [application](/application) that can be used with the Authorization Extension. Currently, you can use the following types of applications: * Native * Regular Web Applications -* Single Page Applications +* Single-Page Applications Applications without an assigned type or Machine to Machine Applications cannot be used with this extension. @@ -73,7 +84,7 @@ This extension has limitations in terms of performance and is not meant to be us ``` ::: note -Amazon S3 is a file-based storage platform, which means it writes in parallel. This may cause issues, but the extension's storage logic attempts to take this into account. However, if you automate the creation of groups/roles/permissions, we suggest that you do so using sequential calls to the API. +Amazon S3 is a file-based storage platform, which means it writes in parallel. This may cause issues, but the extension's storage logic attempts to take this into account. However, if you automate the creation of groups/roles/permissions, we suggest that you do so using sequential calls to the API. ::: ![Install Authorization Extension](/media/articles/extensions/authorization/app-install-v2.png) diff --git a/articles/extensions/authorization-extension/v2/implementation/setup.md b/articles/extensions/authorization-extension/v2/implementation/setup.md index 12599f5f7a..513be6bc06 100644 --- a/articles/extensions/authorization-extension/v2/implementation/setup.md +++ b/articles/extensions/authorization-extension/v2/implementation/setup.md @@ -2,11 +2,22 @@ title: Setting Up the Authorization Extension description: How to set up the Authorization Extension toc: true +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Setup -In this paragraph, we'll briefly cover the basics of users, groups, roles, and permissions. +::: note +<%= include('../../../../_includes/_rbac_methods') %> +::: + +In this article we'll cover the basics of users, groups, roles, and permissions. Let's say that you have an application that is accessible to everyone within your corporation. The **users** are the individuals to whom you'd like to grant access to your application. @@ -39,7 +50,7 @@ Rather than assigning both permissions to groups/users, you can roll the two (al ## Users -The **Users** section lists all the current users of your applications. You can use this to search for and select a specific user to see their profile, view or edit their group affiliations, and view or edit their roles. +The **Users** section lists all the current users of your applications. Here you can find a specific user, see their profile, change their group affiliations, and change their roles. ![Users Section](/media/articles/extensions/authorization/users.png) @@ -105,7 +116,7 @@ You can create different types of Roles such as: Expense Admins, Expense Manager ![Roles](/media/articles/extensions/authorization/roles.png) -To add a role, click the **CREATE ROLE** button from the **Roles** section of the dashboard. Then choose the application this Role applies to (such as Expense Management Tool) and then add a name of the role (such as Expense Admins) and a description of the role. Then select the permissions you wish to grant to this role. If you haven't yet created your permissions you can add them later to an exisiting Role. +To add a role, click the **CREATE ROLE** button from the **Roles** section of the dashboard. Then choose the application this Role applies to (such as Expense Management Tool) and then add a name of the role (such as Expense Admins) and a description of the role. Then select the permissions you wish to grant to this role. If you haven't yet created your permissions you can add them later to an existing Role. ![Add a New Role](/media/articles/extensions/authorization/add-role.png) diff --git a/articles/extensions/authorization-extension/v2/import-export-data.md b/articles/extensions/authorization-extension/v2/import-export-data.md index d540b48fc7..2486b60091 100644 --- a/articles/extensions/authorization-extension/v2/import-export-data.md +++ b/articles/extensions/authorization-extension/v2/import-export-data.md @@ -1,14 +1,25 @@ --- title: Importing Data Into and Exporting Data from the Authorization Extension description: How to import/export Authorization Extension Data +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Import/Export Data +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: + You can import new data from or export existing authorization data to a JSON file. This can be useful when moving environments. ::: warning -Roles and permissions are linked to specific applications. If you export your JSON file and import it into a different environment, you will need to change the client ID for these records. +Roles and permissions are linked to specific applications. If you export your JSON file and import it into a different environment, you will need to change the client ID for these records. ::: You can get to the **Import/Export** section by clicking **Configuration** on the drop-down menu accessible by clicking on your tenant name at the top right of the **Authorization Dashboard**. diff --git a/articles/extensions/authorization-extension/v2/index.md b/articles/extensions/authorization-extension/v2/index.md index 34520d7d2a..90af84435f 100644 --- a/articles/extensions/authorization-extension/v2/index.md +++ b/articles/extensions/authorization-extension/v2/index.md @@ -3,13 +3,61 @@ toc: true classes: topic-page title: Authorization Extension description: Control user authorization behavior during runtime with the Authorization Extension +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension -The Authorization Extension provides support for user authorization via Groups, Roles, and Permissions. You can define the expected behavior during the login process, and your configuration settings will be captured in a [rule](/rules) that's executed during runtime. +::: panel Breaking Changes +Authorization Extension 2.6 contains breaking changes that result from changed logic for storing and handling the API Key; these require you to perform additional steps upon upgrade, as detailed below. Failing to complete these steps will result in either an `InvalidApiKey` or `You are not allowed to access this application` error on rule execution. For more info, see the [changelog](https://github.com/auth0/auth0-authorization-extension/blob/master/CHANGELOG.md). -You can store authorization data like groups, roles, or permissions in the outgoing token issued by Auth0. Your application can then consume this information by inspecting the token and take appropriate actions based on the user's current authorization context. +Upgrades from version 2.6 or later do not have breaking changes and require no further action. + +**If you are upgrading from a version before 2.6, you must:** + +Upgrade the Authorization Extension + +1. Navigate to the [Extensions](${manage_url}/#/extensions) page in the [Auth0 Dashboard](${manage_url}), and click the **Installed Extensions** tab. +2. Locate **Auth0 Authorization**, click **Upgrade**, and confirm. Wait for the upgrade to complete. + +Rotate the extension's API Key + +1. Click on **Auth0 Authorization** to open the extension. +2. From the dropdown menu in the top-right of the extension dashboard, select **Configuration**. +3. Locate the **API Key** section, and click **Rotate**. + +Republish the extension's Rule + +1. Click **Publish Rule**. + +Delete the old extension Rule, if it exists + +1. Navigate to the [Rules](${manage_url}/#/rules) page in the [Auth0 Dashboard](${manage_url}) +2. Locate the `auth0-authz` rule. If it does not exist, you are done.; otherwise, continue with these steps: +3. Locate the `auth0-authorization-extension` rule and drag it into the position below the `auth0-authz` rule. +4. Check that the `auth0-authz` rule: + * was authored by the Authorization Extension and has not been modified manually + * will not change the authorization flow in a way that will grant access or privileges to undesired users if it is removed +5. If the above conditions are true, use the toggle to disable the `auth0-authz` rule. After verifying that everything works appropriately, you can decide whether to leave the rule disabled or remove it entirely. +::: + +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: + +<%= include('../../../_includes/_rbac_vs_extensions') %> + +The Authorization Extension provides support for user authorization via Groups, Roles, and Permissions. You can define the expected behavior during the login process, and your configuration settings will be captured in a [rule](/rules) that's executed during runtime. + +With the Authorization Extension, you can store authorization data like groups, roles, or permissions in the outgoing token issued by Auth0. Your application can then consume this information by inspecting the token and take appropriate actions based on the user's current authorization context. + +With the Authorization Extension, roles and permissions are set on a per-application basis. If you need the same roles or permissions on another application, you'll have to create them separately. Conversely, the [Authorization Core](/authorization/concepts/core-vs-extension) feature set provides much more flexibility with roles and permissions. ## Get Started diff --git a/articles/extensions/authorization-extension/v2/migration.md b/articles/extensions/authorization-extension/v2/migration.md index 4ef03613c2..fb2d873770 100644 --- a/articles/extensions/authorization-extension/v2/migration.md +++ b/articles/extensions/authorization-extension/v2/migration.md @@ -1,10 +1,21 @@ --- title: Installing the Authorization Extension v2 description: How to install the Authorization Extension v2 +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Migrate from Version 1 to Version 2 +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: + ::: warning Migrating from Version 1 to Version 2 is a breaking change ::: diff --git a/articles/extensions/authorization-extension/v2/rules.md b/articles/extensions/authorization-extension/v2/rules.md index 4a01391891..5a9fc25412 100644 --- a/articles/extensions/authorization-extension/v2/rules.md +++ b/articles/extensions/authorization-extension/v2/rules.md @@ -2,22 +2,33 @@ title: Using Rules with the Authorization Extension description: How to use information from the extension in rules toc: true +topics: + - extensions + - authorization_v2 +contentType: + - how-to + - concept +useCase: extensibility-extensions --- # Authorization Extension: Rules +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: + You can use [rules](/rules) with the Authorization Extension to do things like: -* Add [custom claims](/scopes/current#custom-claims) to the issued token -* Determining the user's group membership, roles and permissions +* Add [custom claims](/tokens/concepts/jwt-claims#custom-claims) to the issued token +* Determining the user's group membership, roles and permissions * Storing the user's groups, roles and permissions info as [part of the `app_metadata`](/extensions/authorization-extension/v2/configuration#persistence) -* Adding the user's groups, roles and permissions to the [outgoing token]((/extensions/authorization-extension/v2/configuration#token-contents)) (which can be requested via the `openid groups permissions roles` scope) +* Adding the user's groups, roles and permissions to the [outgoing token](/extensions/authorization-extension/v2/configuration#token-contents) (which can be requested via the `openid groups permissions roles` scope) Because the above logic is part of a rule, it will only be executed in the context of a login. If users are added to or removed from a group, this change will only be reflected in Auth0 after the user's next login. ## Add Custom Claims to the Issued Token -If you'd like to add custom claims to your tokens, you can do so by creating additional [rule](/rules) that allows the Authorization Extension to do so. +If you'd like to add custom claims to your tokens, you can do so by creating additional [rule](/rules) that allows the Authorization Extension to do so. Custom claims should be [namespaced](/tokens/guides/create-namespaced-custom-claims). ::: note You should [limit the number of claims](/extensions/authorization-extension/v2/configuration#data-limitations) you add to the token. @@ -48,7 +59,7 @@ You can also write rules that are executed after the Authorization Extension rul ### Step 1: Set the Application Metadata's `required_roles` -In this step, you'll set the Application's metadata with it's roles, which are groups of permissions that you've grouped together to create a specific set of functionality. You can think of this step as "tagging" the Application so that the rules you'll set up in the next step know which Application to act on. +In this step, you'll set the Application's metadata with its roles, which are groups of permissions that you've grouped together to create a specific set of functionality. You can think of this step as "tagging" the Application so that the rules you'll set up in the next step know which Application to act on. ⁠⁠⁠⁠1. To set the `context.clientMetadata` field with `required_roles`, begin by selecting the application you want to work with [in the dashboard](${manage_url}/#/applications). @@ -101,4 +112,4 @@ function (user, context, callback) { * [Import/Export Data](/extensions/authorization-extension/v2/import-export-data) * [Troubleshoot Errors](/extensions/authorization-extension/v2/troubleshooting) * [Enable API Access to the Extension](/extensions/authorization-extension/v2/api-access) -::: \ No newline at end of file +::: diff --git a/articles/extensions/authorization-extension/v2/troubleshooting.md b/articles/extensions/authorization-extension/v2/troubleshooting.md index 479c325880..2d54316712 100644 --- a/articles/extensions/authorization-extension/v2/troubleshooting.md +++ b/articles/extensions/authorization-extension/v2/troubleshooting.md @@ -1,18 +1,32 @@ --- -title: Troubleshooting the Authorization Extension -description: How to troubleshoot the Authorization Extension +title: Troubleshoot the Authorization Extension +description: Learn how to troubleshoot the Authorization Extension, +topics: + - extensions + - authorization_v2 +contentType: + - how-to +useCase: extensibility-extensions --- -# Authorization Extension: Troubleshoot Issues +# Troubleshoot the Authorization Extension + +::: note +<%= include('../../../_includes/_rbac_methods') %> +::: The following are some issues you might see when setting up the Authorization Extension, as well as some tips to help you identify the cause. ## The authentication results in a token that contains groups information, but not roles or permissions information. -If this happens, chances are that you created roles and permissions for one application, but your users are authenticating using another application. For example, let's say that you created all your roles/permissions against Website A. However, you also create another website application in Auth0 for Website B. Then, you use the `client_id` and `client_secret` for Website B, instead of those for Website A, in your app. +If this happens, chances are that you created roles and permissions for one application, but your users are authenticating using another application. For example, let's say that you created all your roles/permissions against Website A. However, you also create another website application in Auth0 for Website B. Then, you use the `client_id` and `client_secret` for Website B, instead of those for Website A, in your app. Alternatively, you might see this if you click the **Try** button in the Auth0 Dashboard on a Connection that contains one of your users. This will execute an authentication flow using the Auth0 _global application_, but this is not the same as the application you configured in the extension. ## My application is not shown in the drop-down menu when setting up the extension. -The supported application types for the Authorization extension are: **Native**, **Single Page Web Applications** and **Regular Web Applications**. Applications with no type assigned and **Machine to Machine Applications** are not supported. \ No newline at end of file +The supported application types for the Authorization extension are: **Native**, **Single-Page Web Applications** and **Regular Web Applications**. Applications with no type assigned and **Machine to Machine Applications** are not supported. + +## I upgraded to v2 and my users get an error upon login + +If you see the error `You are not allowed to access this application`, most probably there is some conflict with the old rule. Turn off the persistence settings, delete the existing rule, re-enable the settings, and test again. diff --git a/articles/extensions/azure-blob-storage.md b/articles/extensions/azure-blob-storage.md index 150b17c26c..d4c14196f0 100644 --- a/articles/extensions/azure-blob-storage.md +++ b/articles/extensions/azure-blob-storage.md @@ -1,5 +1,12 @@ --- description: This page explains how to configure and use Auth0's extension for Auth0 Logs to Azure Blob Storage. +topics: + - extensions + - azure + - blob-storage +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Azure Blob Storage @@ -26,6 +33,8 @@ At this point you should set the following configuration variables: Once you have provided this information, click the *Install* button to finish installing the extension. +<%= include('./_includes/_batch-size') %> + ## Retrieve the required information from Azure Portal We need the following information: Account Name, Account Key, and Container Name. Let's see how we can retrieve these values from Azure Portal. @@ -36,7 +45,9 @@ Log into your Azure account and click on __Storage accounts__ on the left-hand s The __Account Name__ is the name of your storage account, the one we created is named `azureauth0logs`. -This value should be set as __Storage_Account_Name__. +This value should be set as __Storage_Account_Name__. + +The value **Kind** should be set as **Storage**. ![Azure Storage Account Name](/media/articles/extensions/azure/storage-accnt-name.png) @@ -54,8 +65,7 @@ Click on the __Access keys__ tab. Here you can find the value for __Storage_Acco Now that you have retrieved all three values head back to the [Auth0 dashboard](${manage_url}) and set them at the corresponding fields. You 're done! - -## Use Your Installed Extension +## Use installed Extension To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page, click on the __Installed Extensions__ link, and select the __Auth0 Logs to Azure Blob Storage__ line. There you can see the job you just created, modify its state by toggling the __State__ switch, see when the next run is due and what was the result of the last execution. diff --git a/articles/extensions/bitbucket-deploy.md b/articles/extensions/bitbucket-deploy.md index c05a2580fc..c597432fed 100644 --- a/articles/extensions/bitbucket-deploy.md +++ b/articles/extensions/bitbucket-deploy.md @@ -1,11 +1,17 @@ --- toc: true description: The Bitbucket Deployments extension allows you to deploy Rules and Database Connection scripts from Bitbucket to Auth0. +topics: + - extensions + - bitbucket-deployments +contentType: + - how-to +useCase: extensibility-extensions --- # Bitbucket Deployments -The **Bitbucket Deployments** extension allows you to deploy [Rules](/rules) and Database Connection scripts from Bitbucket to Auth0. You can configure a Bitbucket repository, keep all of your Rules and Database Connection scripts there, and have them automatically deployed to Auth0 whenever you push changes to your repository. +The **Bitbucket Deployments** extension allows you to deploy [rules](/rules), rules configs, connections, database connection scripts, clients, client grants, resource servers, Universal Login pages and email templates from Bitbucket to Auth0. You can configure a Bitbucket repository, keep all of your Rules and Database Connection scripts there, and have them automatically deployed to Auth0 whenever you push changes to your repository. ## Configure the Extension @@ -15,11 +21,17 @@ To install and configure this extension, click on the **Bitbucket Deployments** Set the following configuration variables: -* **BITBUCKET_REPOSITORY**: the repository from which you want to deploy your Rules and Database Connection scripts (this can be either a public or private repository); -* **BITBUCKET_BRANCH**: the branch the extension will monitor for changes; -* **BITBUCKET_USER**: the username used to access the Bitbucket account; -* **BITBUCKET_PASSWORD**: the password associated with the username used to access the Bitbucket account; -* **SLACK_INCOMING_WEBHOOK**: the Webhook URL for Slack used to notify you of successful and failed deployments. +* **REPOSITORY**: The repository from which you want to deploy your Rules and Database Connection scripts. This can be either a public or private repository +* **BRANCH**: The branch the extension will monitor for changes +* **USER**: The username used to access the Bitbucket account. Make sure you use the username, and not the email +* **PASSWORD**: The user password or an app password you create through the Bitbucket settings to grant permissions to certain apps (`Repositories: Read` permission is required) +* **BASE_DIR**: The base directory, where all your tenant settings are stored +* **AUTO_REDEPLOY**: If enabled, the extension redeploys the last successful configuration in the event of a deployment failure. Manual deployments and validation errors does not trigger auto-redeployment +* **SLACK_INCOMING_WEBHOOK**: The Webhook URL for Slack used to notify you of successful and failed deployments + +::: note +Some of the configuration variables were changed in version **2.6.0** of this extension. If you are updating the extension from a prior version, make sure that you update your configuration accordingly. +::: Once you have provided this information, click **Install**. @@ -45,7 +57,16 @@ You can find details on how to configure a webhook at [Creating Webhooks](https: Once you have set up the webhook in Bitbucket using the provided information, you are ready to start committing to your repository. -With each commit you push to your configured Bitbucket repository, the webhook will call the extension to initiate a deployment if changes were made to the `rules` and/or the `database-connection` folders. +With each commit you push to your configured Bitbucket repository, the webhook will call the extension to initiate a deployment if changes were made to one of these folders: +- `clients` +- `grants` +- `emails` +- `resource-servers` +- `connections` +- `database-connections` +- `rules-configs` +- `rules` +- `pages` The **Deploy** button on the **Deployments** tab of the extension allows you to manually deploy the Rules and Database Connection scripts that you already have in your Bitbucket repository. This is useful if your repository already contains items that you want to deploy once you have set up the extension or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your repository. @@ -70,22 +91,55 @@ For a generic Custom Database Connection, only the `login.js` script is required You can find examples in [the Auth0 Samples repository](https://github.com/auth0-samples/github-source-control-integration/tree/master/database-connections/my-custom-db). While the samples were authored for GitHub, it will work for a Bitbucket integration as well. -### Deploy Hosted Pages +#### Deploy Database Connection Settings + +To deploy Database Connection settings, you must create `database-connections/[connection-name]/database.json`. + +_This will work only for Auth0 connections (strategy === auth0); for non-Auth0 connections use `connections`._ + +_Support for using `settings.json` has been deprecated in favor of `database.json` since v3.1.1 of the extension and may be dropped in a future release._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/patch_connections_by_id) for more info on allowed attributes for Connections. + +### Deploy Connections + +To deploy a connection, you must create a JSON file under the `connections` directory of your Bitbucket repository. Example: + +__facebook.json__ +```json +{ + "name": "facebook", + "strategy": "facebook", + "enabled_clients": [ + "my-client" + ], + "options": {} +} +``` + +<%= include('./_includes/_embedded-clients-array') %> + +_This will work only for non-Auth0 connections (`strategy !== auth0`); for Auth0 connections, use `database-connections`._ + +For more info on the allowed attributes for connections, see the [Post Connections endpoint] (/api/management/v2#!/Connections/post_connections). + +### Deploy Universal Login Pages + +The supported pages are: -The supported hosted pages are: - `error_page` - `guardian_multifactor` - `login` - `password_reset` -To deploy a page, you must create an HTML file under the `pages` directory of your Bitbucket repository. For each HTML page you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, in order to deploy an `error_page`, you would create two files: +To deploy a page, you must create an HTML file under the `pages` directory of your Bitbucket repository. For each HTML page, you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, to deploy a `password_reset`, you would create two files: ```text -your-bitbucket-repo/pages/error_page.html -your-bitbucket-repo/pages/error_page.json +your-bitbucket-repo/pages/password_reset.html +your-bitbucket-repo/pages/password_reset.json ``` -To enable the page the `error_page.json` would contain the following: +To enable the page, the `password_reset.json` would contain the following: ```json { @@ -93,9 +147,11 @@ To enable the page the `error_page.json` would contain the following: } ``` +<%= include('./_includes/_use-default-error') %> + ### Deploy Rules -To deploy a rule, you must first create a JavaScript file under the `rules` directory of your Bitbucket repository. Each Rule must be in its own `.js` file. +To deploy a rule, you must first create a JavaScript file under the `rules` directory of your Bitbucket repository. Each Rule must be in its own JavaScript file. For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. @@ -103,10 +159,6 @@ For example, if you create the file `rules/set-country.js`, the extension will c If you plan to use source control integration for an existing account, first rename your Rules in Auth0 to match the name of the files you will be deploying to this directory. ::: -You can mark rules as manual. In that case, the source control extension will not delete or update them. To mark a rule navigate to the **Rules Configuration** tab of the **Bitbucket Integration** page. Toggle the **Manual Rule** switch for the rules you want to mark as manual. Click **Update Manual Rules** to save your changes. - -![](/media/articles/extensions/bitbucket-deploy/manual-rules.png) - You can control the Rule order and status (`enabled`/`disabled`) by creating a JSON file with the same name as your JavaScript file. For this example, you would create a file named `rules/set-country.json`. __set-country.js__ @@ -120,7 +172,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -132,7 +184,158 @@ You can find a `login_success` example in [the Auth0 Samples repository](https:/ #### Set Rule Order -To avoid conflicts, you are cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk for conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). +To avoid conflicts, you cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk of conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). + +### Deploy Rules Configs + +To deploy a rule config, you must create a JSON file under the `rules-configs` directory of your Bitbucket repository. Example: + +__secret_number.json__ +```json +{ + "key": "secret_number", + "value": 42 +} +``` + +### Deploy Clients + +To deploy a client, you must create a JSON file under the `clients` directory of your Bitbucket repository. Example: + +__my-client.json__ +```json +{ + "name": "my-client" +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Clients/post_clients) for more info on allowed attributes for Clients and Client Grants. + +### Deploy Clients Grants + +You can specify the client grants for each client by creating a JSON file in the `grants` directory. + +__my-client-api.json__ +```json +{ + "client_id": "my-client", + "audience": "https://myapp.com/api/v1", + "scope": [ + "read:users" + ] +} +``` + +<%= include('./_includes/_deployment-extension') %> + +### Deploy Resource Servers + +To deploy a resource server, you must create a JSON file under the `resource-servers` directory of your Bitbucket repository. Example: + +__my-api.json__ +```json +{ + "name": "my-api", + "identifier": "https://myapp.com/api/v1", + "scopes": [ + { + "value": "read:users", + "description": "Allows getting user information" + } + ] +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Resource_Servers/post_resource_servers) for more info on allowed attributes for Resource Servers. + +### Deploy Email Provider + +To deploy an email provider, you must create `provider.json` file under the `emails` directory of your Bitbucket repository. Example: + +__provider.json__ +```json +{ + "name": "smtp", + "enabled": true, + "credentials": { + "smtp_host": "smtp.server.com", + "smtp_port": 25, + "smtp_user": "smtp_user", + "smtp_pass": "smtp_secret_password" + } +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Emails/patch_provider) for more info on allowed attributes for Email Provider. + +### Deploy Email Templates + +The supported email templates are: +- `verify_email` +- `reset_email` +- `welcome_email` +- `blocked_account` +- `stolen_credentials` +- `enrollment_email` +- `mfa_oob_code` + +To deploy an email template, you must create an HTML file under the `emails` directory of your Bitbucket repository. For each HTML file, you need to create a JSON file (with the same name) with additional options for that template. For example, to deploy a `blocked_account` template, you would create two files: + +```text +your-bitbucket-repo/emails/blocked_account.html +your-bitbucket-repo/emails/blocked_account.json +``` + +__blocked_account.json__ +```json +{ + "template": "blocked_account", + "from": "", + "subject": "", + "resultUrl": "", + "syntax": "liquid", + "body": "./blocked_account.html", + "urlLifetimeInSeconds": 432000, + "enabled": true +} +``` + +## Excluded records + +You can exclude the following records from the deployment process: `rules`, `clients`, `databases`, `connections` and `resourceServers`. If excluded, the records will not be modified by deployments. + +![](/media/articles/extensions/deploy-extensions/excluded-rules.png) + +## Keywords Mapping + +Beginning with version **3.0.0**, you can use keywords mapping to manage your secrets and tenant-based environment variables. + +There are two ways to use the keyword mappings. You can either wrap the key using `@` symbols (e.g., `@@key@@`), or you can wrap the key using `#` symbols (e.g., `##key##`). + + - If you use `@` symbols, your value will be converted from a JavaScript object or value to a JSON string. + + - If you use `#` symbols, Auth0 will perform a literal replacement. + +This is useful for something like specifying different variables across your environments. For example, you could specify different JWT timeouts for your Development, QA/Testing, and Production environments. + +Refer to the snippets below for sample implementations: + +__Client.json__ +```json +{ + ... + "callbacks": [ + "##ENVIRONMENT_URL##/auth/callback" + ], + "jwt_configuration": { + "lifetime_in_seconds": ##JWT_TIMEOUT##, + "secret_encoded": true + } + ... +} +``` + +![](/media/articles/extensions/deploy-extensions/mappings.png) ## Track Deployments diff --git a/articles/extensions/cloudwatch.md b/articles/extensions/cloudwatch.md new file mode 100644 index 0000000000..c68d6e3624 --- /dev/null +++ b/articles/extensions/cloudwatch.md @@ -0,0 +1,69 @@ +--- +description: How to install and configure the Auth0 Logs to CloudWatch extension. +topics: + - extensions + - cloudwatch +contentType: + - how-to +useCase: extensibility-extensions +--- + +# Auth0 Logs to CloudWatch + +The **Auth0 Logs to CloudWatch** extension is a scheduled job that exports your Auth0 logs to [CloudWatch](https://aws.amazon.com/cloudwatch/). Amazon CloudWatch is a monitoring and management service built for developers, system operators, site reliability engineers (SRE), and IT managers. + +## Configure the Extension + +To install and configure this extension, click on the **Auth0 Logs to CloudWatch** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}). The **Install Extension** window pops open. + +At this point you should set the following configuration variables: + +| Parameter | Description | +|:-----------------|:------------| +| **Schedule** | The frequency with which logs should be exported. The schedule can be customized even further after creation. | +| **BATCH_SIZE** | The amount of logs to be read on each execution. Maximun, and default, is `100`. | +| **START_FROM** | The checkpoint ID of the log from where you want to start. | +| **SLACK_INCOMING_WEBHOOK** | The Slack incoming webhook URL used to send relevant updates. | +| **SLACK_SEND_SUCCESS** | Toggle for sending verbose notifications to Slack. | +| **LOG_LEVEL** | The minimal log level of events that you would like sent to CloudWatch. | +| **LOG_TYPES** | The events for which logs should be exported. | +| **CLOUDWATCH_LOG_GROUP_NAME**
      Required | CloudWatch log group name, created in CloudWatch. | +| **CLOUDWATCH_LOG_STREAM_NAME**
      Required | CloudWatch log stream name. | +| **AWS_ACCESS_KEY_ID**
      Required | AWS access key ID | +| **AWS_SECRET_KEY**
      Required | AWS secret key | +| **AWS_REGION**
      Required | Your AWS region | + +### Required permissions + +Extension requires these AWS permissions in order to send logs to CloudWatch: +- `logs:PutLogEvents` +- `logs:DescribeLogStreams` + +Once you have provided this information, click the _Install_ button to finish installing the extension. + +<%= include('./_includes/_batch-size') %> + +## Use the Extension + +You can monitor activity by logging into the extension. There you can find reports on most recent runs. Reports contains amount of logs processed and errors, if any. + +## Replay Logs + +In the event of a CloudWatch failure or service interruption you can replay the logs starting from the failed log. + +To replay logs: + +1. Get the checkpoint ID of the failed log. +2. Go to the Auth0 Logs to CloudWatch extension settings. +3. Enter the checkpoint in the **START_FROM** field. +4. Click the **Save** button to replay the failed logs. + +## Slack Integration + +To set up [Slack](https://slack.com/) integration, provide an [Incoming Webhook URL](https://api.slack.com/incoming-webhooks) to the **SLACK_INCOMING_WEBHOOK** field in the Auth0 Logs to CloudWatch [extension settings](${manage_url}/#/extensions). + +![Slack Settings](/media/articles/extensions/logstash/slack-settings.png) + +The extension sends failed transaction notifications to Slack with the checkpoint code displayed in the message. You can also enable verbose notifications by turning on the `SLACK_SEND_SUCCESS` setting. + +![Slack Message](/media/articles/extensions/logstash/slack-message.png) diff --git a/articles/extensions/custom-social-extensions.md b/articles/extensions/custom-social-extensions.md index f1170c6b98..436b0117c4 100644 --- a/articles/extensions/custom-social-extensions.md +++ b/articles/extensions/custom-social-extensions.md @@ -1,35 +1,38 @@ --- description: How to configure a Custom Social Connection to your Auth0 app. toc: true +topics: + - extensions + - custom-social-connections +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Extension: Custom Social Connections -The Custom Social Connections extension allows you to easily manage multiple social connections. +The Custom Social Connections extension allows you to manage multiple social connections easily. -## Set Up a New Social Connection +## Set Up a New Social Connection Extension -To install the Custom Social Connection app, click on the **Custom Social Connections** box on the main [Extensions](${manage_url}/#/extensions) page of the Management Portal. You will be prompted to install the app. -![](/media/articles/extensions/installing-custom-social-connections.png) +To install the Custom Social Connections extension, log in to the Dashboard and go to [Extensions](${manage_url}/#/extensions). Click the **Custom Social Connections** box. You will be prompted to install the app. -At this point, you will see the app listed under the **Installed Extensions** tab. +When the extension has been installed, you'll be redirected to a page that lists your extension under **Installed Extensions** tab. -![](/media/articles/extensions/installed-custom-social-extension.png) +## Configure the Social Connection Extension settings Once you have installed the app, you will need to configure it to work with whichever social providers you require. To do so, click on the **Custom Social Connections** link listed under **Installed Extensions**. You will be asked to authorize the Custom Social Connections app. After you do so, the **New Connection** window will open. -![](/media/articles/extensions/custom-social-connections.png) +Click the slider next to the social provider(s) you want to set up. The slider will turn from grey to green, indicating that a connection to that provider exists. -Click the slider next to the social provider you want to set up. The slider will turn from grey to green, indicating that a connection to that provider exists. For additional information on how each individual provider handles authentication, see that provider's documentation. +For information on how each provider handles authentication, see that provider's documentation. -### Configure the Social Connection Settings +### Settings configuration -The **New Connection** window contains two tabs: **Settings** and **Apps**: - -![](/media/articles/extensions/new-custom-social-connection.png) +As soon as you enable a specific social connection, Auth0 displays a pop-up **New Connection** window that contains two tabs: **Settings** and **Apps**. You will need to update these tabs accordingly so that your connection works as expected. #### New Connection: Settings @@ -39,16 +42,16 @@ The Settings page is used to provide the information required to set up the soci - __Client ID__: The provider's client ID; - __Client Secret__: The provider's client secret; - __Authorization URL__: The URL where the transaction begins and authorization occurs; -- __Token URL__: The URL used to exchange the code generated from the information you provide for an access_token; +- __Token URL__: The URL used to exchange the code generated from the information you provide for an Access Token; - __Scope__: The scope parameters for which you want access rights; - __Fetch User Profile Script__: The JS function that returns the user profile and associated information. It will be auto-generated with the appropriate fields depending on the chosen provider. - __Custom Headers__: An optional JSON object that lets you provide custom headers to be included in the HTTP calls to the provider. Should be in the format of: ``` { - "Header1" : "Value", - "Header2" : "Value" - // ... + "Header1" : "Value", + "Header2" : "Value" + // ... } ``` @@ -58,18 +61,18 @@ After you have provided values for the required fields, click **Save**. Once you have successfully configured the connection, you will be presented with a list of apps associated with your Auth0 tenant under the **Apps** tab of the **New Connection** window. -Using the slider, enable this social connection for the apps that you want to use it with. +Using the slider, enable this social connection for the apps that you want to use it with. **If you do not enable *any* of the listed apps, you will not be able to use the connection.** Once you have enabled/disabled the appropriate apps, click **Save**. ### Provide your Callback URL to the Identity Provider -The callback URL is the URL that is invoked by the provider after the authentication request has finished. +The callback URL is the URL that is invoked by the provider after the authentication request has finished. Your provider will ask you to provide this URL at some point during the setup process. Use this value for the **Callback URL**: `https://${account.namespace}/login/callback` -Depending on the provider, this field can be referred to by different names. Sometimes called a **Redirect URI** the callback URL may also be be referred to as: "Valid OAuth redirect URI", "Authorized redirect URI", "Allowed Return URL" or something similar. +Depending on the provider, this field can be referred to by different names. Sometimes called a **Redirect URI**, the callback URL may also be referred to as: "Valid OAuth redirect URI," "Authorized redirect URI," "Allowed Return URL," or something similar. ## Use your new connection @@ -85,13 +88,13 @@ Lock does not currently support displaying buttons for custom social connections ## Optional: Set up Basic Authentication -By default, when invoking the __Token URL__ to exchange the authentication code for an access_token, Auth0 will provide the `client ID` and `client secret` as part of the body of the POST. Some identity providers require [HTTP Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), which involves providing those same credentials in a HTTP header. +By default, when invoking the __Token URL__ to exchange the authentication code for an Access Token, Auth0 will provide the `client ID` and `client secret` as part of the body of the POST. Some identity providers require [HTTP Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), which involves providing those same credentials in an HTTP header. -If the identity provider requires Basic Authentication, you can be use the __Custom Headers__ setting with a JSON object like this: +If the identity provider requires Basic Authentication, you can use the __Custom Headers__ setting with a JSON object like this: ``` { - "Authorization" : "Basic xxxxxxxx" + "Authorization" : "Basic xxxxxxxx" } ``` @@ -99,14 +102,10 @@ If the identity provider requires Basic Authentication, you can be use the __Cus ``` { - "Authorization" : "Basic MTIzNDU2OmFiY2RlZg==" + "Authorization" : "Basic MTIzNDU2OmFiY2RlZg==" } ``` ## Additional Steps -Depending on which social providers you are you using, there may be additional steps in the provider configuration to enable the connection. - -### WordPress - -You will need to add the associated **Plugin** in WordPress for the social connection. For example, to enable login with Slack the Slack plugin will need to be enabled in WordPress (make sure you’re logged in as an Administrator). \ No newline at end of file +Depending on which social providers you are you using, there may be additional steps in the provider configuration to enable the connection. Please refer to the provider-specific documentation for clarifying details. diff --git a/articles/extensions/delegated-admin/hooks.md b/articles/extensions/delegated-admin/hooks.md deleted file mode 100644 index 9cc6360457..0000000000 --- a/articles/extensions/delegated-admin/hooks.md +++ /dev/null @@ -1,319 +0,0 @@ ---- -description: How to customize the behavior of the Delegated Administration extension using Hooks -toc: true ---- - -# Delegated Administration: Hooks - -If you are a user with the `Delegated Admin - Administrator` role in your User Profile, log in to the Delegated Administration Dashboard, and click on your name in the top right corner, you'll see a *Configure* option. On the Configuration page, you can manage the different Hooks and queries that allow you to customize the behavior of the Delegated Administration extension. - -![](/media/articles/extensions/delegated-admin/dashboard-configuration.png) - -## Hooks Signature - -Hooks always have the following signature: - -```js -function(ctx, callback) { - // First do some work - ... - - // Done - return callback(null, something); -} -``` - -The context object will expose a few helpers and information about the current request. The following methods and properties are available in every Hook. - -**1. Logging** - - To add a message to the Webtask logs (which you can view using the [Realtime Webtask Logs](/extensions/realtime-webtask-logs) extension), call the `log` method: - - ```js - ctx.log('Hello there', someValue, otherValue); - ``` - -**2. Caching** - - To cache something (such as a long list of departments), you can store it on the context's `global` object. This object will be available until the Webtask container recycles. - - ```js - ctx.global.departments = [ 'IT', 'HR', 'Finance' ]; - ``` - -**3. Custom Data** - - You can store custom data within the extension. This is field is limited to 400kb of data. - - ```js - var data = { - departments: [ 'IT', 'HR', 'Finance' ] - }; - - ctx.write(data) - .then(function() { - ... - }) - .catch(function(err) { - ... - }); - ``` - - To read the data: - - ```js - ctx.read() - .then(function(data) { - ... - }) - .catch(function(err) { - ... - }); - ``` - -**4. Payload and Request** - - Each Hook exposes the current payload and/or request with specific information. The request will always contain information about the user that is logged into the Users Dashboard: - - ```js - var currentUser = ctx.request.user; - ``` - -**5. Remote Calls** - - If you want to call an external service (such as an API) to validate data or to load memberships, you can do this using the `request` module. - - ```js - function(ctx, callback) { - var request = require('request'); - request('http://api.mycompany.com/departments', function (error, response, body) { - if (error) { - return callback(error); - } - - ... - }); - } - ``` - -## The Filter Hook - -By default, users with the **Delegated Admin - User** role see *all* users associated with the Auth0 account. However, you can filter the data users see using the **Filter Hook**. - -### The Hook contract: - - - `ctx`: The context object - - `callback(error, query)`: The callback to which you can return an error or the [lucene query](/api/management/v2/query-string-syntax) used when filtering the users. The extension will send this query to the [`GET Users` endpoint](/api/management/v2#!/Users/get_users) of the Management API - -### Example - -If **Kelly** manages the Finance department, she should only see the users that are also part of the Finance department. We'll filter the users with respect to the department of the current user. - -```js -function(ctx, callback) { - // Get the department from the current user's metadata. - var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; - if (!department || !department.length) { - return callback(new Error('The current user is not part of any department.')); - } - - // The IT department can see all users. - if (department === 'IT') { - return callback(); - } - - // Return the lucene query. - return callback(null, 'app_metadata.department:"' + department + '"'); -} -``` - -::: panel-warning Using Special Characters -Do not use single quotes, double quotes, or any other special characters (such as `+` or `-`) in any term on which you'll want to filter. This might cause issues with the Lucene query. -::: - -If you do not configure this Hook, the search returns **all users**. - -## The Access Hook - -While the **Filter Hook** only applies filtering logic you'll need a second layer of logic to determine if the current user is allowed to access a specific user. This is what the **Access Hook** allows you to do, determine if the current user is allowed to read, delete, block, or unblock a specific user. - -### The Hook contract: - - - `ctx`: The context object - - `payload`: The payload object - - `action`: The current action (eg: `delete:user`) that is being executed - - `user`: The user on which the action is being executed - - `callback(error)`: The callback to which you can return an error if access is denied - -Example: **Kelly** manages the Finance department and she should only be able to access users within her department. - -```js -function(ctx, callback) { - if (ctx.payload.action === 'delete:user') { - return callback(new Error('You are not allowed to delete users.')); - } - - // Get the department from the current user's metadata. - var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; - if (!department || !department.length) { - return callback(new Error('The current user is not part of any department.')); - } - - // The IT department can access all users. - if (department === 'IT') { - return callback(); - } - - ctx.log('Verifying access:', ctx.payload.user.app_metadata.department, department); - - if (!ctx.payload.user.app_metadata.department || ctx.payload.user.app_metadata.department !== department) { - return callback(new Error('You can only access users within your own department.')); - } - - return callback(); -} -``` - -If this hook is not configured all users will be accessible. - -Supported action names: - - - `read:user` - - `delete:user` - - `reset:password` - - `change:password` - - `change:username` - - `change:email` - - `read:devices` - - `read:logs` - - `remove:multifactor-provider` - - `block:user` - - `unblock:user` - - `send:verification-email` - -#### Create Hook - -Whenever new users are created you'll want these users to be assigned to the group/department/vendor/... of the current user. This is what the **Create Hook** allows you to configure. - -Hook contract: - - - `ctx`: The context object. - - `payload`: The payload object. - - `memberships`: An array of memberships that were selected in the UI when creating the user. - - `email`: The email address of the user. - - `password`: The password of the user. - - `connection`: The name of the user. - - `callback(error, user)`: The callback to which you can return an error and the user object that should be sent to the Management API. - -Example: **Kelly** manages the Finance department. When she creates users, these users should be assigned to her department. - -```js -function(ctx, callback) { - if (!ctx.payload.memberships || ctx.payload.memberships.length === 0) { - return callback(new Error('The user must be created within a department.')); - } - - // Get the department from the current user's metadata. - var currentDepartment = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; - if (!currentDepartment || !currentDepartment.length) { - return callback(new Error('The current user is not part of any department.')); - } - - // If you're not in the IT department, you can only create users within your own department. - // IT can create users in all departments. - if (currentDepartment !== 'IT' && ctx.payload.memberships[0] !== currentDepartment) { - return callback(new Error('You can only create users within your own department.')); - } - - // This is the payload that will be sent to API v2. You have full control over how the user is created in API v2. - return callback(null, { - email: ctx.payload.email, - password: ctx.payload.password, - connection: ctx.payload.connection, - app_metadata: { - department: ctx.payload.memberships[0] - } - }); -} -``` - -::: warning -Auth0 only supports user creation with Database Connections. -::: - -## The Memberships Query Hook - -When creating a new user, the UI shows a drop-down where you can choose the membership(s) you want assigned to a user. These memberships are then defined using the **Memberships Query**. - -### The Hook contract: - - - `ctx`: The context object - - `callback(error, { createMemberships: true/false, memberships: [ ...] })`: The callback to which you can return an error and an object containing the membership configuration - -Example: Users of the IT department should be able to create users in other departments. Users from other departments should only be able to create users for their own departments. - -```js -function(ctx, callback) { - var currentDepartment = ctx.payload.user.app_metadata.department; - if (!currentDepartment || !currentDepartment.length) { - return callback(null, [ ]); - } - - if (currentDepartment === 'IT') { - return callback(null, [ 'IT', 'HR', 'Finance', 'Marketing' ]); - } - - return callback(null, [ ctx.payload.user.app_metadata.department ]); -} -``` - -**Notes**: - -* Because you can only use this query in the UI, you'll need to assign memberships using the *Create Users* function if you need to enforce the assigning of users to specific departments. -* If there is only one membership possible, this field will not show in the UI. - -You can allow the end user to enter any value `memberships` by setting `createMemberships` to true. - -```js -function(ctx, callback) { - var currentDepartment = ctx.payload.user.app_metadata.department; - if (!currentDepartment || !currentDepartment.length) { - return callback(null, [ ]); - } - - return callback(null, { - createMemberships: ctx.payload.user.app_metadata.department === 'IT' ? true : false, - memberships: [ ctx.payload.user.app_metadata.department ] - }); -} -``` - -## The Settings Query Hook - -The **Settings Query** allows you to customize the look and feel of the extension. - -### The Hook contract - - - `ctx`: The context object - - `callback(error, settings)`: The callback to which you can return an error and a settings object - -Example: - -```js -function(ctx, callback) { - var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; - - return callback(null, { - // Only these connections should be visible in the connections picker. - // If only one connection is available, the connections picker will not be shown in the UI. - connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], - // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. - dict: { - title: department ? department + ' User Management' : 'User Management Dashboard', - memberships: 'Departments' - }, - // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) - css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css' - }); -} -``` diff --git a/articles/extensions/delegated-admin/index.md b/articles/extensions/delegated-admin/index.md deleted file mode 100644 index 995602bc43..0000000000 --- a/articles/extensions/delegated-admin/index.md +++ /dev/null @@ -1,173 +0,0 @@ ---- -description: The Delegated Administration extension allows you to expose the Users dashboard to a group of users, without allowing them access to the dashboard. -url: /extensions/delegated-admin -toc: true ---- - -# Delegated Administration - -The **Delegated Administration** extension allows you to grant a select group of people administrative permissions to the [Users page](${manage_url}/#/users) without providing access to any other area. This is done by exposing the [Users Dashboard](${manage_url}/#/users) as an Auth0 application. - -:::panel PSaaS Appliance Availability -The Delegated Administration extension is available for [PSaaS Appliance](/appliance) customers who are running build `10755` or later, and have User Search enabled. -::: - -Prior to configuring the extension, you will need to: - -* [Create and configure an Auth0 Application](#create-an-application) -* [Enable a Connection on the Application](#enable-a-connection-on-the-application) -* [Add a user to the Connection](#add-a-user-to-the-new-connection) - -## Create an Application - -The first step is to create the Application that the extension exposes to those who should have administrative privileges to the Users page. - -After you've logged into the [Management Dashboard](${manage_url}), navigate to [Applications](${manage_url}/#/applications) and click on **+Create Application**. Provide a name for your Application (such as `Users Dashboard`) and set the Application type to `Single Page Web Applications`. Click **Create** to proceed. - -![Create an Application](/media/articles/extensions/delegated-admin/create-client.png) - -### Configure Application Settings - -Once you've created your Application, you'll need to make the following Application configuration changes. - -Click on the **Settings** tab and set the **Allowed Callback URLs**. This varies based on your location: - -| Location | Allowed Callback URL | -| --- | --- | -| USA | `https://${account.tenant}.us.webtask.io/auth0-delegated-admin/login` | -| Europe | `https://${account.tenant}.eu.webtask.io/auth0-delegated-admin/login` | -| Australia | `https://${account.tenant}.au.webtask.io/auth0-delegated-admin/login` | - -You will also need to configure the **Allowed Logout URLs**: - -| Location | Allowed Logout URL | -| --- | --- | -| USA | `https://${account.tenant}.us.webtask.io/auth0-delegated-admin` | -| Europe | `https://${account.tenant}.eu.webtask.io/auth0-delegated-admin` | -| Australia | `https://${account.tenant}.au.webtask.io/auth0-delegated-admin` | - -Copy the **Client ID** value. - -Navigate to **Settings > Show Advanced Settings > OAuth** and paste the **Client ID** value to the **Allowed APPs / APIs** field. - -Next, set the **JsonWebToken Signature Algorithm** to `RS256`, and make sure the **OIDC Conformant** toggle is disabled. - -::: note -The **Delegated Administration** extension requires applications to disable the **OIDC Conformant** flag. After turning off **OIDC Conformant** on the dashboard, ensure your application's authentication code is updated as well. -::: - -![Change Advanced OAuth Settings](/media/articles/extensions/delegated-admin/oauth-settings.png) - -Click **Save Changes** to proceed. - -### Enable a Connection on the Application - -When you create a new Application, Auth0 enables all [Connections](/identityproviders) associated with your tenant by default. For the purposes of this tutorial, we will disable all Connections (this helps keep our Application secure, since no one can add themselves using one of our existing Connections), create a new Database Connection, and enable only the newly-created Database Connection. However, you can choose to use any type of Connection. - -#### Disable All Existing Connections - -Switch over to the Application's **Connections** tab and disable all the Connections using the associated switches. - -#### Create a New Connection - -In the navigation pane of the Management Dashboard, click on **Connections** > [Database Connections](${manage_url}/#/connections/database). - -On the Database Connections page, click on **+Create DB Connection**. Provide a name for your Connection, such as `Helpdesk`. - -Click **Save** to proceed. - -![Create DB Connection](/media/articles/extensions/delegated-admin/create-connection.png) - -Navigate to the **Settings** tab of your new Connection and enable the **Disable Sign Ups** option. For security reasons, this ensures that even users who have the link to our Connection cannot sign themselves up. - -![Disable Sign Ups](/media/articles/extensions/delegated-admin/disable-signup.png) - -Under the **Applications Using This Connection** section, enable this Connection for your `Users Dashboard` Application. - -### Add a User to the New Connection - -You will need to add at least one user to your Connection. You can do this via the [Users page](${manage_url}/#/users), where you can specify the Connection for the user during the configuration process. - -### Assign Roles to Users - -Auth0 grants the user(s) in your Connection access to the Delegated Administration extension based on their roles: - -- **Delegated Admin - User**: Grants permission to search for users, create users, open users and execute actions on these users (such as `delete`, `block`, and so on); - -- **Delegated Admin - Administrator**: In addition to all of the rights a user has, administrators can see all logs in the tenant and configure Hooks. - -To use the extension, users must have either of these roles defined in one of the following fields of their user profiles: - -* `user.roles` -* `user.app_metadata.roles` -* `user.app_metadata.authorization.roles` - -You can set these fields manually or via [rules](/rules). - -#### Set User Roles via Rules - -This rule gives users from the `IT Department` the `Delegated Admin - Administrator` role and users from `Department Managers` are the `Delegated Admin - User` role. - -```js -function (user, context, callback) { - if (context.clientID === 'CLIENT_ID') { -   if (user.groups && user.groups.indexOf('IT Department') > -1) { - user.roles = user.roles || [ ]; - user.roles.push('Delegated Admin - Administrator'); - return callback(null, user, context); - } else if (user.app_metadata && user.app_metadata.isDepartmentManager && user.app_metadata.department && user.app_metadata.department.length) { - user.roles = user.roles || [ ]; - user.roles.push('Delegated Admin - User'); - return callback(null, user, context); - } - - return callback(new UnauthorizedError('You are not allowed to use this application.')); - } - - callback(null, user, context); -} -``` - -## Install the Extension - -Now that we've created and configured an Application, a Connection, and our users, we can install and configure the extension itself. - -On the Management Dashboard, navigate to the [Extensions](${manage_url}/#/extensions) page. Click on the **Delegated Administration** box in the list of provided extensions. The **Install Extension** window will open. - -![Install Extension](/media/articles/extensions/delegated-admin/install-extension.png) - -Set the following configuration variables: - -- **EXTENSION_CLIENT_ID**: The **Client ID** value of the Application you will use. You can find this value on the **Settings** page of your Application. - -- **TITLE** (optional): Set a title for your Application. It will be displayed at the header of the page. - -- **CUSTOM_CSS** (optional): Provide a CSS script to customize the look and feel of your Application. - -Once done, click **Install**. Your extension is now ready to use! - -If you navigate back to the [Applications](${manage_url}/#/applications) view, you will see that the extension automatically created an additional application called `auth0-delegated-admin`. - -![](/media/articles/extensions/delegated-admin/two-clients.png) - -Because the application is authorized to access the [Management API](/api/management/v2), you shouldn't modify it. - -## Use the Extension - -To access your newly created users dashboard, navigate to [**Extensions**](${manage_url}/#/extensions) > **Installed Extensions** > **Delegated Administration Dashboard**. - -A new tab will open to display the login prompt. - -![](/media/articles/extensions/delegated-admin/login-prompt.png) - -Because we disabled signups for this Connection during the configuration period, the login screen doesn't display a Sign Up option. - -Once you provide valid credentials, you'll be redirected to the *Delegated Administration Dashboard*. - -![](/media/articles/extensions/delegated-admin/standard-dashboard.png) - -## Keep Reading - -* [Customizing the Delegated Administration Extension Using Hooks](/extensions/delegated-admin/hooks) - -* [Managing Users in the Delegated Administration Extension Dashboard](/extensions/delegated-admin/manage-users) diff --git a/articles/extensions/delegated-admin/index.yml b/articles/extensions/delegated-admin/index.yml new file mode 100644 index 0000000000..96e0fc8807 --- /dev/null +++ b/articles/extensions/delegated-admin/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: extensions/delegated-admin + current: v3 + versions: + - v2 + - v3 + defaultArticles: + v2: index + v3: index \ No newline at end of file diff --git a/articles/extensions/delegated-admin/manage-users.md b/articles/extensions/delegated-admin/manage-users.md deleted file mode 100644 index e5f1cbf662..0000000000 --- a/articles/extensions/delegated-admin/manage-users.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -description: How to manage users in the Delegated Administration extension -toc: true ---- - -# Delegated Administration: Manage Users - -In the Application exposed by the Delegated Administration extension, there are two views available: *Users* and *Logs*. On the *Users* view, you can see the display and modify users associated with your Auth0 account. - -By default, all users are displayed, but you can filter the displayed list by configuring a [filter hook](/extensions/delegated-admin/hooks#the-filter-hook). - -## Available User Actions in the Delegated Administration Dashboard - -The table below lists the options you can perform on users, as well as information on whether the option is available via the [Management Dashboard](${manage_url}/#/) and/or the Delegated Administration extension. To limit the number of options someone with access to the Dashboard exposed by the Delegated Administration extension, configure an [access hook](#access-hook). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Action Available in the Management Dashboard Available in the Delegated Administration Extension
      Create UserYesYes
      Contact UserYesNo
      Sign in as User (Impersonation)YesNo
      Block UserYesYes
      Delete UserYesYes
      Send Verification EmailYesYes
      Change EmailYesYes
      Change PasswordYesYes
      Reset PasswordNoYes
      - -Notice the new *Reset Password* option available via the extension. This option will send an email to the user allowing them to choose a new password. To do this click on a user and select *Actions > Reset Password*. - -![](/media/articles/extensions/delegated-admin/reset-pass-01.png) - -This will send an email to the user, containing a link to change the password. - -If your profile indicates that you have the `Delegated Admin - Administrator` role, the *Logs* view allows you to see a list of authentications made by your users (this tab is only visible to users with the `Delegated Admin - Administrator` role). The contents of this view are a subset of the data displayed in the [Logs Dashboard](${manage_url}/#/logs). The Log Dashboard also displays data on administrative actions taken in the Dashboard. - -## Create Users - -You can create a new user by selecting the **+ Create User** button on the *Users* view. You need to specify are email and password. Depending on your role, you may not be able to set the *Department* to which the new user belongs. - -For example, users with the `Delegated Admin - Administrator` role can see the **Department** field and select any of its values. - -![](/media/articles/extensions/delegated-admin/create-user-admin.png) - -On the other hand, Kelly who has the `Delegated Admin - User` role and belongs to the Finance department cannot see this field. The user she creates will be automatically assigned to the Finance department. - -![](/media/articles/extensions/delegated-admin/create-user-kelly.png) diff --git a/articles/extensions/delegated-admin/v2/hooks.md b/articles/extensions/delegated-admin/v2/hooks.md new file mode 100644 index 0000000000..b9a7b57ce6 --- /dev/null +++ b/articles/extensions/delegated-admin/v2/hooks.md @@ -0,0 +1,323 @@ +--- +description: How to customize the behavior of the Delegated Administration extension using Hooks +toc: true +topics: + - extensions + - delegated-admin + - hooks +--- + +# Delegated Administration: Hooks + +If you are a user with the `Delegated Admin - Administrator` role in your User Profile, log in to the Delegated Administration Dashboard, and click on your name in the top right corner, you'll see a *Configure* option. On the Configuration page, you can manage the different Hooks and queries that allow you to customize the behavior of the Delegated Administration extension. + +![](/media/articles/extensions/delegated-admin/dashboard-configuration.png) + +## Hooks Signature + +Hooks always have the following signature: + +```js +function(ctx, callback) { + // First do some work + ... + + // Done + return callback(null, something); +} +``` + +The context object will expose a few helpers and information about the current request. The following methods and properties are available in every Hook. + +**1. Logging** + + To add a message to the Webtask logs (which you can view using the [Realtime Webtask Logs](/extensions/realtime-webtask-logs) extension), call the `log` method: + + ```js + ctx.log('Hello there', someValue, otherValue); + ``` + +**2. Caching** + + To cache something (such as a long list of departments), you can store it on the context's `global` object. This object will be available until the Webtask container recycles. + + ```js + ctx.global.departments = [ 'IT', 'HR', 'Finance' ]; + ``` + +**3. Custom Data** + + You can store custom data within the extension. This is field is limited to 400kb of data. + + ```js + var data = { + departments: [ 'IT', 'HR', 'Finance' ] + }; + + ctx.write(data) + .then(function() { + ... + }) + .catch(function(err) { + ... + }); + ``` + + To read the data: + + ```js + ctx.read() + .then(function(data) { + ... + }) + .catch(function(err) { + ... + }); + ``` + +**4. Payload and Request** + + Each Hook exposes the current payload and/or request with specific information. The request will always contain information about the user that is logged into the Users Dashboard: + + ```js + var currentUser = ctx.request.user; + ``` + +**5. Remote Calls** + + If you want to call an external service (such as an API) to validate data or to load memberships, you can do this using the `request` module. + + ```js + function(ctx, callback) { + var request = require('request'); + request('http://api.mycompany.com/departments', function (error, response, body) { + if (error) { + return callback(error); + } + + ... + }); + } + ``` + +## The Filter Hook + +By default, users with the **Delegated Admin - User** role see *all* users associated with the Auth0 account. However, you can filter the data users see using the **Filter Hook**. + +### The Hook contract: + + - `ctx`: The context object + - `callback(error, query)`: The callback to which you can return an error or the [lucene query](/api/management/v2/query-string-syntax) used when filtering the users. The extension will send this query to the [`GET Users` endpoint](/api/management/v2#!/Users/get_users) of the Management API + +### Example + +If **Kelly** manages the Finance department, she should only see the users that are also part of the Finance department. We'll filter the users with respect to the department of the current user. + +```js +function(ctx, callback) { + // Get the department from the current user's metadata. + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!department || !department.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // The IT department can see all users. + if (department === 'IT') { + return callback(); + } + + // Return the lucene query. + return callback(null, 'app_metadata.department:"' + department + '"'); +} +``` + +::: panel-warning Using Special Characters +Do not use single quotes, double quotes, or any other special characters (such as `+` or `-`) in any term on which you'll want to filter. This might cause issues with the Lucene query. +::: + +If you do not configure this Hook, the search returns **all users**. + +## The Access Hook + +While the **Filter Hook** only applies filtering logic you'll need a second layer of logic to determine if the current user is allowed to access a specific user. This is what the **Access Hook** allows you to do, determine if the current user is allowed to read, delete, block, or unblock a specific user. + +### The Hook contract: + + - `ctx`: The context object + - `payload`: The payload object + - `action`: The current action (eg: `delete:user`) that is being executed + - `user`: The user on which the action is being executed + - `callback(error)`: The callback to which you can return an error if access is denied + +Example: **Kelly** manages the Finance department and she should only be able to access users within her department. + +```js +function(ctx, callback) { + if (ctx.payload.action === 'delete:user') { + return callback(new Error('You are not allowed to delete users.')); + } + + // Get the department from the current user's metadata. + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!department || !department.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // The IT department can access all users. + if (department === 'IT') { + return callback(); + } + + ctx.log('Verifying access:', ctx.payload.user.app_metadata.department, department); + + if (!ctx.payload.user.app_metadata.department || ctx.payload.user.app_metadata.department !== department) { + return callback(new Error('You can only access users within your own department.')); + } + + return callback(); +} +``` + +If this hook is not configured all users will be accessible. + +Supported action names: + + - `read:user` + - `delete:user` + - `reset:password` + - `change:password` + - `change:username` + - `change:email` + - `read:devices` + - `read:logs` + - `remove:multifactor-provider` + - `block:user` + - `unblock:user` + - `send:verification-email` + +#### Create Hook + +Whenever new users are created you'll want these users to be assigned to the group/department/vendor/... of the current user. This is what the **Create Hook** allows you to configure. + +Hook contract: + + - `ctx`: The context object. + - `payload`: The payload object. + - `memberships`: An array of memberships that were selected in the UI when creating the user. + - `email`: The email address of the user. + - `password`: The password of the user. + - `connection`: The name of the user. + - `callback(error, user)`: The callback to which you can return an error and the user object that should be sent to the Management API. + +Example: **Kelly** manages the Finance department. When she creates users, these users should be assigned to her department. + +```js +function(ctx, callback) { + if (!ctx.payload.memberships || ctx.payload.memberships.length === 0) { + return callback(new Error('The user must be created within a department.')); + } + + // Get the department from the current user's metadata. + var currentDepartment = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // If you're not in the IT department, you can only create users within your own department. + // IT can create users in all departments. + if (currentDepartment !== 'IT' && ctx.payload.memberships[0] !== currentDepartment) { + return callback(new Error('You can only create users within your own department.')); + } + + // This is the payload that will be sent to API v2. You have full control over how the user is created in API v2. + return callback(null, { + email: ctx.payload.email, + password: ctx.payload.password, + connection: ctx.payload.connection, + app_metadata: { + department: ctx.payload.memberships[0] + } + }); +} +``` + +::: warning +Auth0 only supports user creation with Database Connections. +::: + +## The Memberships Query Hook + +When creating a new user, the UI shows a drop-down where you can choose the membership(s) you want assigned to a user. These memberships are then defined using the **Memberships Query**. + +### The Hook contract: + + - `ctx`: The context object + - `callback(error, { createMemberships: true/false, memberships: [ ...] })`: The callback to which you can return an error and an object containing the membership configuration + +Example: Users of the IT department should be able to create users in other departments. Users from other departments should only be able to create users for their own departments. + +```js +function(ctx, callback) { + var currentDepartment = ctx.payload.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(null, [ ]); + } + + if (currentDepartment === 'IT') { + return callback(null, [ 'IT', 'HR', 'Finance', 'Marketing' ]); + } + + return callback(null, [ ctx.payload.user.app_metadata.department ]); +} +``` + +**Notes**: + +* Because you can only use this query in the UI, you'll need to assign memberships using the *Create Users* function if you need to enforce the assigning of users to specific departments. +* If there is only one membership possible, this field will not show in the UI. + +You can allow the end user to enter any value `memberships` by setting `createMemberships` to true. + +```js +function(ctx, callback) { + var currentDepartment = ctx.payload.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(null, [ ]); + } + + return callback(null, { + createMemberships: ctx.payload.user.app_metadata.department === 'IT' ? true : false, + memberships: [ ctx.payload.user.app_metadata.department ] + }); +} +``` + +## The Settings Query Hook + +The **Settings Query** allows you to customize the look and feel of the extension. + +### The Hook contract + + - `ctx`: The context object + - `callback(error, settings)`: The callback to which you can return an error and a settings object + +Example: + +```js +function(ctx, callback) { + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + + return callback(null, { + // Only these connections should be visible in the connections picker. + // If only one connection is available, the connections picker will not be shown in the UI. + connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], + // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. + dict: { + title: department ? department + ' User Management' : 'User Management Dashboard', + memberships: 'Departments' + }, + // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) + css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css' + }); +} +``` diff --git a/articles/extensions/delegated-admin/v2/index.md b/articles/extensions/delegated-admin/v2/index.md new file mode 100644 index 0000000000..79818e9038 --- /dev/null +++ b/articles/extensions/delegated-admin/v2/index.md @@ -0,0 +1,196 @@ +--- +description: The Delegated Administration extension allows you to expose the Users dashboard to a group of users, without allowing them access to the dashboard. +toc: true +topics: + - extensions + - delegated-admin +contentType: + - how-to + - concept + - index +useCase: extensibility-extensions +--- + +# Delegated Administration + +The **Delegated Administration** extension allows you to grant a select group of people administrative permissions to the [Users page](${manage_url}/#/users) without providing access to any other area. This is done by exposing the [Users Dashboard](${manage_url}/#/users) as an Auth0 application. + +Prior to configuring the extension, you will need to: + +* [Create and configure an Auth0 Application](#create-an-application) +* [Enable a Connection on the Application](#enable-a-connection-on-the-application) +* [Add a user to the Connection](#add-a-user-to-the-new-connection) + +## Create an Application + +The first step is to create the Application that the extension exposes to those who should have administrative privileges to the Users page. + +After you've logged into the [Management Dashboard](${manage_url}), navigate to [Applications](${manage_url}/#/applications) and click on **+Create Application**. Provide a name for your Application (such as `Users Dashboard`) and set the Application type to `Single-Page Web Applications`. Click **Create** to proceed. + +![Create an Application](/media/articles/extensions/delegated-admin/create-client.png) + +### Configure Application Settings + +Once you've created your Application, you'll need to make the following Application configuration changes. + +Click on the **Settings** tab and set the **Allowed Callback URLs**. This varies based on your location: + +If you are using Node 8: + +| Location | Allowed Callback URL | +| --- | --- | +| USA | `https://${account.tenant}.us8.webtask.io/auth0-delegated-admin/login` | +| Europe | `https://${account.tenant}.eu8.webtask.io/auth0-delegated-admin/login` | +| Australia | `https://${account.tenant}.au8.webtask.io/auth0-delegated-admin/login` | + +If you are using Node 12: + +| Location | Allowed Callback URL | +| --- | --- | +| USA | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin/login` | +| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin/login` | +| Australia | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin/login` | + +You will also need to configure the **Allowed Logout URLs**: + +If you are using Node 8: + +| Location | Allowed Logout URL | +| --- | --- | +| USA | `https://${account.tenant}.us8.webtask.io/auth0-delegated-admin` | +| Europe | `https://${account.tenant}.eu8.webtask.io/auth0-delegated-admin` | +| Australia | `https://${account.tenant}.au8.webtask.io/auth0-delegated-admin` | + +If you are using Node 12: + +| Location | Allowed Logout URL | +| --- | --- | +| USA | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin` | +| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin` | +| Australia | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin` | + +Copy the **Client ID** value. + +Navigate to **Settings > Show Advanced Settings > OAuth** and paste the **Client ID** value to the **Allowed APPs / APIs** field. + +Next, set the **JsonWebToken Signature Algorithm** to `RS256`, and make sure the **OIDC Conformant** toggle is disabled. + +::: note +The **Delegated Administration** extension requires applications to disable the **OIDC Conformant** flag. After turning off **OIDC Conformant** on the dashboard, ensure your application's authentication code is updated as well. +::: + +![Change Advanced OAuth Settings](/media/articles/extensions/delegated-admin/oauth-settings.png) + +Click **Save Changes** to proceed. + +### Enable a Connection on the Application + +When you create a new Application, Auth0 enables all [Connections](/identityproviders) associated with your tenant by default. For the purposes of this tutorial, we will disable all Connections (this helps keep our Application secure, since no one can add themselves using one of our existing Connections), create a new Database Connection, and enable only the newly-created Database Connection. However, you can choose to use any type of Connection. + +#### Disable All Existing Connections + +Switch over to the Application's **Connections** tab and disable all the Connections using the associated switches. + +#### Create a New Connection + +In the navigation pane of the Management Dashboard, click on **Connections** > [Database Connections](${manage_url}/#/connections/database). + +On the Database Connections page, click on **+Create DB Connection**. Provide a name for your Connection, such as `Helpdesk`. + +Click **Save** to proceed. + +![Create DB Connection](/media/articles/extensions/delegated-admin/create-connection.png) + +Navigate to the **Settings** tab of your new Connection and enable the **Disable Sign Ups** option. For security reasons, this ensures that even users who have the link to our Connection cannot sign themselves up. + +![Disable Sign Ups](/media/articles/extensions/delegated-admin/disable-signup.png) + +Under the **Applications Using This Connection** section, enable this Connection for your `Users Dashboard` Application. + +### Add a User to the New Connection + +You will need to add at least one user to your Connection. You can do this via the [Users page](${manage_url}/#/users), where you can specify the Connection for the user during the configuration process. + +### Assign Roles to Users + +Auth0 grants the user(s) in your Connection access to the Delegated Administration extension based on their roles: + +- **Delegated Admin - User**: Grants permission to search for users, create users, open users and execute actions on these users (such as `delete`, `block`, and so on); + +- **Delegated Admin - Administrator**: In addition to all of the rights a user has, administrators can see all logs in the tenant and configure Hooks. + +To use the extension, users must have either of these roles defined in one of the following fields of their user profiles: + +* `user.app_metadata.roles` +* `user.app_metadata.authorization.roles` + +You can set these fields manually or via [rules](/rules). + +#### Set User Roles via Rules + +This rule gives users from the `IT Department` the `Delegated Admin - Administrator` role and users from `Department Managers` are the `Delegated Admin - User` role. + +```js +function (user, context, callback) { + if (context.clientID === 'CLIENT_ID') { + // If you are using Node 8, uncomment the following line + //const namespace = 'https://${account.tenant}.us8.webtask.io/auth0-delegated-admin'; + //If you are using Node 12, uncomment the following line + //const namespace = 'https://${account.tenant}.us12.webtask.io/auth0-delegated-admin'; +   if (user.groups && user.groups.indexOf('IT Department') > -1) { + context.idToken[namespace] = { roles: [ 'Delegated Admin - Administrator' ] }; + return callback(null, user, context); + } else if (user.app_metadata && user.app_metadata.isDepartmentManager && user.app_metadata.department && user.app_metadata.department.length) { + context.idToken[namespace] = { roles: [ 'Delegated Admin - User' ] }; + return callback(null, user, context); + } + + return callback(new UnauthorizedError('You are not allowed to use this application.')); + } + + callback(null, user, context); +} +``` + +## Install the Extension + +Now that we've created and configured an Application, a Connection, and our users, we can install and configure the extension itself. + +On the Management Dashboard, navigate to the [Extensions](${manage_url}/#/extensions) page. Click on the **Delegated Administration** box in the list of provided extensions. The **Install Extension** window will open. + +![Install Extension](/media/articles/extensions/delegated-admin/install-extension.png) + +Set the following configuration variables: + +- **EXTENSION_CLIENT_ID**: The **Client ID** value of the Application you will use. You can find this value on the **Settings** page of your Application. + +- **TITLE** (optional): Set a title for your Application. It will be displayed at the header of the page. + +- **CUSTOM_CSS** (optional): Provide a CSS script to customize the look and feel of your Application. + +Once done, click **Install**. Your extension is now ready to use! + +If you navigate back to the [Applications](${manage_url}/#/applications) view, you will see that the extension automatically created an additional application called `auth0-delegated-admin`. + +![](/media/articles/extensions/delegated-admin/two-clients.png) + +Because the application is authorized to access the [Management API](/api/management/v2), you shouldn't modify it. + +## Use the Extension + +To access your newly created users dashboard, navigate to [**Extensions**](${manage_url}/#/extensions) > **Installed Extensions** > **Delegated Administration Dashboard**. + +A new tab will open to display the login prompt. + +![](/media/articles/extensions/delegated-admin/login-prompt.png) + +Because we disabled signups for this Connection during the configuration period, the login screen doesn't display a Sign Up option. + +Once you provide valid credentials, you'll be redirected to the *Delegated Administration Dashboard*. + +![](/media/articles/extensions/delegated-admin/standard-dashboard.png) + +## Keep Reading + +* [Customize the Delegated Administration Extension Using Hooks](/extensions/delegated-admin/hooks) +* [Manage Users in the Delegated Administration Extension Dashboard](/extensions/delegated-admin/manage-users) diff --git a/articles/extensions/delegated-admin/v2/manage-users.md b/articles/extensions/delegated-admin/v2/manage-users.md new file mode 100644 index 0000000000..83625916d1 --- /dev/null +++ b/articles/extensions/delegated-admin/v2/manage-users.md @@ -0,0 +1,92 @@ +--- +description: How to manage users in the Delegated Administration extension +toc: true +topics: + - extensions + - delegated-admin + - users +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- + +# Delegated Administration: Manage Users + +In the Application exposed by the Delegated Administration extension, there are two views available: *Users* and *Logs*. On the *Users* view, you can see the display and modify users associated with your Auth0 account. + +By default, all users are displayed, but you can filter the displayed list by configuring a [filter hook](/extensions/delegated-admin/hooks#the-filter-hook). + +## Available User Actions in the Delegated Administration Dashboard + +The table below lists the options you can perform on users, as well as information on whether the option is available via the [Management Dashboard](${manage_url}/#/) and/or the Delegated Administration extension. To limit the number of options someone with access to the Dashboard exposed by the Delegated Administration extension, configure an [access hook](#access-hook). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Action Available in the Management Dashboard Available in the Delegated Administration Extension
      Create UserYesYes
      Contact UserYesNo
      Block UserYesYes
      Delete UserYesYes
      Send Verification EmailYesYes
      Change EmailYesYes
      Change PasswordYesYes
      Reset PasswordNoYes
      + +Notice the new *Reset Password* option available via the extension. This option will send an email to the user allowing them to choose a new password. To do this click on a user and select *Actions > Reset Password*. + +![](/media/articles/extensions/delegated-admin/reset-pass-01.png) + +This will send an email to the user, containing a link to change the password. + +If your profile indicates that you have the `Delegated Admin - Administrator` role, the *Logs* view allows you to see a list of authentications made by your users (this tab is only visible to users with the `Delegated Admin - Administrator` role). The contents of this view are a subset of the data displayed in the [Logs Dashboard](${manage_url}/#/logs). The Log Dashboard also displays data on administrative actions taken in the Dashboard. + +## Create Users + +You can create a new user by selecting the **+ Create User** button on the *Users* view. You need to specify are email and password. Depending on your role, you may not be able to set the *Department* to which the new user belongs. + +For example, users with the `Delegated Admin - Administrator` role can see the **Department** field and select any of its values. + +![](/media/articles/extensions/delegated-admin/create-user-admin.png) + +On the other hand, Kelly who has the `Delegated Admin - User` role and belongs to the Finance department cannot see this field. The user she creates will be automatically assigned to the Finance department. + +![](/media/articles/extensions/delegated-admin/create-user-kelly.png) diff --git a/articles/extensions/delegated-admin/v3/_session-timeout.md b/articles/extensions/delegated-admin/v3/_session-timeout.md new file mode 100644 index 0000000000..3ddda0e079 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/_session-timeout.md @@ -0,0 +1,3 @@ +::: panel Session Timeout +By default, token expiration time is 10 hours. However, when using Delegated Administration, Auth0 doesn't save a token to cookies or `sessionStorage` for security reasons, so you will need to start a new session on each page reload. +::: diff --git a/articles/extensions/delegated-admin/v3/hooks/_stepnav.html b/articles/extensions/delegated-admin/v3/hooks/_stepnav.html new file mode 100644 index 0000000000..38681ec1e0 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/_stepnav.html @@ -0,0 +1,14 @@ +
      + <% if (typeof prev !== 'undefined') { %> +
      +
      Go Back
      + ${prev[0]} +
      + <% } %> + <% if (typeof next !== 'undefined') { %> +
      +
      Delegated Admin
      + ${next[0]} +
      + <% } %> +
      \ No newline at end of file diff --git a/articles/extensions/delegated-admin/v3/hooks/access.md b/articles/extensions/delegated-admin/v3/hooks/access.md new file mode 100644 index 0000000000..e6010a7e5f --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/access.md @@ -0,0 +1,79 @@ +--- +description: How to use the Access Hook with the Delegated Administration extension +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- +# Delegated Administration Hooks: The Access Hook + +Because the [Filter Hook](/extensions/delegated-admin/v3/hooks/filter) only applies filtering logic, you'll need a second layer of logic to determine if the current user (or the person acting as the administrator) is allowed to access a specific user. + +The **Access Hook** allows you to determine if the current user is allowed to read, delete, block, unblock, or update a specific user. + +## The Hook Contract + + - **ctx**: The context object + - **payload**: The payload object + - **action**: The current action (eg: **delete:user**) that is being executed + - **user**: The user on which the action is being executed + - **callback(error)**: The callback to which you can return an error if access is denied + +## Sample Usage + +Kelly manages the Finance department, and she should only be able to access users within her department. + +```js +function(ctx, callback) { + if (ctx.payload.action === 'delete:user') { + return callback(new Error('You are not allowed to delete users.')); + } + + // Get the department from the current user's metadata. + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!department || !department.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // The IT department can access all users. + if (department === 'IT') { + return callback(); + } + + ctx.log('Verifying access:', ctx.payload.user.app_metadata.department, department); + + if (!ctx.payload.user.app_metadata.department || ctx.payload.user.app_metadata.department !== department) { + return callback(new Error('You can only access users within your own department.')); + } + + return callback(); +} +``` + +## Notes + +If this hook is not configured, all users will be accessible to the current user. + +The Hook supports the following action names (which you set using as the value for **ctx.payload.action**: + +- **read:user** +- **delete:user** +- **reset:password** +- **change:password** +- **change:username** +- **change:email** +- **read:devices** +- **read:logs** +- **remove:multifactor-provider** +- **block:user** +- **unblock:user** +- **send:verification-email** + +<%= include('./_stepnav', { + prev: ["Delegated Admin: Hooks", "/extensions/delegated-admin/hooks"] +}) %> \ No newline at end of file diff --git a/articles/extensions/delegated-admin/v3/hooks/filter.md b/articles/extensions/delegated-admin/v3/hooks/filter.md new file mode 100644 index 0000000000..c0deeadf43 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/filter.md @@ -0,0 +1,61 @@ +--- +description: How to use the Filter Hook with the Delegated Administration extension +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- +# Delegated Administration Hooks: The Filter Hook + +By default, users with the **Delegated Admin - User** role see *all* users associated with the Auth0 account. However, you can filter the data users see using the **Filter Hook**. + +## The Hook Contract + + - **ctx**: The context object + - **callback(error, query)**: The callback to which you can return an error or the [lucene query](/api/management/v2/query-string-syntax) used when filtering the users. The extension will send this query to the [**GET Users** endpoint](/api/management/v2#!/Users/get_users) of the Management API + +### Sample Usage + +If Kelly manages the Finance department, she should only see the users that are also part of the Finance department. We'll filter the users with respect to the department of the current user (which, in this case, is the Finance department and Kelly, respectively). + +```js +function(ctx, callback) { + // Get the department from the current user's metadata. + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!department || !department.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // The IT department can see all users. + if (department === 'IT') { + return callback(); + } + + // Return the lucene query. + return callback(null, 'app_metadata.department:"' + department + '"'); +} +``` + +### Search Engine Override + +You can override the default search engine by specifying your choice in the response. + +```js + // Return the lucene query. + return callback(null, { query: 'app_metadata.department:"' + department + '"', searchEngine: 'v2' }); +``` + +## Notes + +Do not use single quotes, double quotes, or any other special characters (such as **+** or **-**) in terms on which you'll want to filter. This may cause issues with the Lucene query. + +If you do not configure this Hook, the search returns **all users**. + +<%= include('./_stepnav', { + prev: ["Delegated Admin: Hooks", "/extensions/delegated-admin/hooks"] +}) %> diff --git a/articles/extensions/delegated-admin/v3/hooks/index.md b/articles/extensions/delegated-admin/v3/hooks/index.md new file mode 100644 index 0000000000..737643c706 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/index.md @@ -0,0 +1,182 @@ +--- +description: How to customize the behavior of the Delegated Administration extension using Hooks +toc: true +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept + - index +useCase: extensibility-extensions +--- + +# Delegated Administration: Hooks + +If you're a user assigned the **Delegated Admin - Administrator** role, you can manage the different Hooks and queries that allow you to customize the behavior of the Delegated Administration extension. + +To access the configuration area: + +1. Log in to the Delegated Administration Dashboard +2. Click on your name in the top right corner. You'll see a drop-down menu; click on the **Configure** option. + +The **Configuration** page to which you're redirected is where you can manage your Hooks and queries. + +## Hooks Signature + +Hooks always have the following signature: + +```js +function(ctx, callback) { + // First do some work + ... + + // Done + return callback(null, something); +} +``` + +The context (**ctx**) object will expose a few helpers and information about the current request. The following methods and properties are available in every Hook: + +* Logging +* Caching +* Custom Data +* Payload and Request +* Remote Calls + +### Logging + +To add a message to the Webtask logs (which you can view using the [Realtime Webtask Logs](/extensions/realtime-webtask-logs) extension), call the **log** method: + +```js +ctx.log('Hello there', someValue, otherValue); + ``` + +### Caching + +To cache something (such as a long list of departments), you can store it on the context's **global** object. This object will be available until the Webtask container recycles. + +```js +ctx.global.departments = [ 'IT', 'HR', 'Finance' ]; +``` + +### Custom Data + +You can store custom data within the extension. This field is limited to 400kb of data. + +```js +var data = { +departments: [ 'IT', 'HR', 'Finance' ] +}; + +ctx.write(data) +.then(function() { + ... +}) +.catch(function(err) { + ... +}); +``` + +To read the data: + +```js +ctx.read() +.then(function(data) { + ... +}) +.catch(function(err) { + ... +}); +``` + +### Payload and Request + +Each Hook exposes the current payload or request with specific information. The request will always contain information about the user that is logged into the Users Dashboard: + +```js +var currentUser = ctx.request.user; +``` + +### Remote Calls + +If you want to call an external service (such as an API) to validate data or to load memberships, you can do this using the `request` module. + +```js +function(ctx, callback) { +var request = require('request'); + request('http://api.mycompany.com/departments', function (error, response, body) { + if (error) { + return callback(error); + } + + ... + }); +} +``` + +### The Hook contract: + + - `ctx`: The context object + - `payload`: The payload object + - `action`: The current action (for example, `delete:user`) that is being executed + - `user`: The user on which the action is being executed + - `callback(error)`: The callback to which you can return an error if access is denied + +Example: Kelly manages the Finance department, and she should only be able to access users within her department. + +```js +function(ctx, callback) { + if (ctx.payload.action === 'delete:user') { + return callback(new Error('You are not allowed to delete users.')); + } + + // Get the department from the current user's metadata. + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!department || !department.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // The IT department can access all users. + if (department === 'IT') { + return callback(); + } + + ctx.log('Verifying access:', ctx.payload.user.app_metadata.department, department); + + if (!ctx.payload.user.app_metadata.department || ctx.payload.user.app_metadata.department !== department) { + return callback(new Error('You can only access users within your own department.')); + } + + return callback(); +} +``` + +If this hook is not configured, all users will be accessible. + +Supported action names: + + - `read:user` + - `delete:user` + - `reset:password` + - `change:password` + - `change:username` + - `change:email` + - `read:devices` + - `read:logs` + - `remove:multifactor-provider` + - `block:user` + - `unblock:user` + - `send:verification-email` + +## Available Hooks + +The following Hooks are available for use with your Delegated Administration extension: + +* [The Access Hook](/extensions/delegated-admin/v3/hooks/access) +* [The Filter Hook](/extensions/delegated-admin/v3/hooks/filter) +* [The Memberships Query Hook](/extensions/delegated-admin/v3/hooks/membership) +* [The Settings Query Hook](/extensions/delegated-admin/v3/hooks/settings) +* [The Write Hook](/extensions/delegated-admin/v3/hooks/write) \ No newline at end of file diff --git a/articles/extensions/delegated-admin/v3/hooks/membership.md b/articles/extensions/delegated-admin/v3/hooks/membership.md new file mode 100644 index 0000000000..5d0799bce1 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/membership.md @@ -0,0 +1,65 @@ +--- +description: How to use the Memberships Query Hook with the Delegated Administration extension +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- +# Delegated Administration Hooks: The Memberships Query Hook + +When creating a new user, the User Interface shows a drop-down where you can choose the membership(s) you want assigned to a user. These memberships are then defined using the **Memberships Query Hook**. + +## The Hook Contract + + - **ctx**: The context object + - **callback(error, { createMemberships: true/false, memberships: [ ...] })**: The callback to which you can return an error and an object containing the membership configuration + +## Sample Usage + +Users of the IT department should be able to create users in other departments. Users from other departments should only be able to create users for their departments. + +```js +function(ctx, callback) { + var currentDepartment = ctx.payload.user.app_metadata && ctx.payload.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(null, [ ]); + } + + if (currentDepartment === 'IT') { + return callback(null, [ 'IT', 'HR', 'Finance', 'Marketing' ]); + } + + return callback(null, [ ctx.payload.user.app_metadata.department ]); +} +``` + +## Notes + +Because you can only use this query in the UI, you'll need to assign memberships using the **Write Hook** if you need to enforce rules regarding the assignment of users to specific departments. + +If there is only one membership group possible, the Memberships field will not show in the UI. + +You can allow the end user to enter any value into the **memberships** field by setting **createMemberships** to true: + +```js +function(ctx, callback) { + var currentDepartment = ctx.payload.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(null, [ ]); + } + + return callback(null, { + createMemberships: ctx.payload.user.app_metadata.department === 'IT' ? true : false, + memberships: [ ctx.payload.user.app_metadata.department ] + }); +} +``` + +<%= include('./_stepnav', { + prev: ["Delegated Admin: Hooks", "/extensions/delegated-admin/hooks"] +}) %> diff --git a/articles/extensions/delegated-admin/v3/hooks/settings.md b/articles/extensions/delegated-admin/v3/hooks/settings.md new file mode 100644 index 0000000000..2a032aaaba --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/settings.md @@ -0,0 +1,354 @@ +--- +description: How to use the Settings Query Hook with the Delegated Administration extension +toc: true +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- +# Delegated Administration Hooks: The Settings Query Hook + +The **Settings Query Hook** allows you to customize the look and feel of the Delegated Admin extension. + +## The Hook Contract + + - **ctx**: The context object + - **request.user**: The user currently logged in + - **locale**: The locale (as inferred from the URL) -- `https://${account.tenant}.us.webtask.io/auth0-delegated-admin/en/users` will set **locale** to `en`. + - **callback(error, settings)**: The callback to which you can return an error and a settings object + +## Sample Usage + +```js +function(ctx, callback) { + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + + return callback(null, { + // Only these connections should be visible in the connections picker. If only one connection is available, the connections picker will not be shown in the UI. + connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], + // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. + dict: { + title: department ? department + ' User Management' : 'User Management Dashboard', + memberships: 'Departments', + menuName: ctx.request.user.name + }, + // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) + css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css', + // This option allows you to restrict creating new users + canCreateUser: (department === 'IT') + }); +} +``` + +### Properties + +- **connections**: The list of the connections this admin is allowed to create and edit users within +- **dict**: The dictionary allows you to overwrite the title of the dashboard and the **Memberships** label in the Create User dialog + - **dict.title**: The title to display at the top of the UI + - **dict.memberships**: The label to set for memberships fields + - **dict.menuName**: The name to set for the upper right-hand dropdown menu + - **dict.logoutUrl**: An alternate URL for the logout menu option +- **userFields**: An array of user fields (see [Custom Fields](#custom-fields)) +- **css**: A string URL to import CSS +- **altcss**: A string URL to import a second set of CSS. You can use this to specify things like accessibility CSS for larger fonts. The user will be presented with a menu item allowing them to toggle this set of CSS on/off +- **languageDictionary**: A string URL or Dictionary Object (see [Localization](#localization)) +- **suppressRawData**: Set to **true** to skip pages that show raw JSON +- **errorTranslator**: A function that translates error messages based on localization. Example: `(function (error, languageDictionary) { return languageDictionary.customErrors[error] || error; }).toString()` +- **canCreateUser**: A boolean flag. If set to `false`, removes `Create User` button and forbids creating new users, `true` by default. + +## Custom Fields + +Beginning with version 3.0 of the Delegated Admin Extension, you can define custom fields and specify their values. Custom fields can be stored in the **user metadata** and **app metadata** fields accessible during the user creation or update processes. + +You may also customize existing fields defined by Auth0, such as email, username, name, and connection. + +To utilize custom fields, you must: + +- Add your list of **userFields** to the Settings Query Hook +- Implement a [Write Hook](/extensions/delegated-admin/v3/hooks/write). Custom Fields require the use of the [Write Hook](/extensions/delegated-admin/v3/hooks/write) to properly update `user_metadata` and `app_metadata`. You must [update the user object passed to the callback function](/extensions/delegated-admin/v3/hooks/write#sample-usage) with the `user_metadata` and `app_metadata` from the context (`ctx` object) provided to the hook. + +Sample schema for **userFields**: + +```js +userFields: [ + { + "property": string, // required + "label": string, + "sortProperty": string, + "display": true || function.toString(), + "search": false || { + "display": true || function.toString() + "listOrder": 1, + "listSize": string(###%), // e.g. 15% + "filter": boolean, + "sort": boolean + }, + "edit": false || { + "display": true || function.toString() + "type": "text || select || password || hidden", + "component": "InputText || Input Combo || InputMultiCombo || InputSelectCombo", + "options": Array(string) || Array ({ "value": string, "label": string }), + "disabled": true || false, + "validationFunction": function.toString() + }, + "create": false || { + "display": true || function.toString() + "type": "text || select || password || hidden", + "component": "InputText || Input Combo || InputMultiCombo || InputSelectCombo", + "options": Array(string) || Array ({ "value": string, "label": string }), + "disabled": true || false, + "validationFunction": function.toString() + } + }, + ... +] +``` + +- **property** (**required**): The property name of the **ctx.payload** object for the Write hook. In the Write hook, `"property": "app_metadata.dbId"` sets `ctx.payload.app_metadata.dbId` +- **label**: The label that will be used when adding a label to the field on the user info page, create page, edit profile page, or search page +- **sortProperty**: If sorting by a different field than this for the search table, use this field. Dot notation is allowed. +- **display**: true || false || stringified => This is the default display value. If not overridden in search, edit, or create, it will use this value. + - if `true` will just return `user.` + - Default: if `false` this value will not be displayed on any page (unless overridden in search, edit, or create) + - if stringified function: executes function to get the value to display. Example: `(function display(user, value, languageDictionary) { return moment(value).fromNow(); }).toString()` +- **search**: false || object => This describes how this field will behave on the search page + - Default: if `false` will not show up in the search table + - **search.display**: This will override the default display value + - **search.listOrder**: This will specify the column order for the search display table + - **search.listSize**: This will specify the default width of the column + - **search.filter**: This will specify whether to allow this field to be search in the search dropdown. Default is false. + - **search.sort**: This will specify whether this column is sortable. Use sortProperty if you want to sort by a field other than property. Default is false. +- **edit**: false || object => This describes whether the field shows up on the edit dialogs. If not a default field and set to an object, this will show up in the `Change Profile` page on the User Actions dropdown on the user page. + - Default: if `false` will not show up on any edit/update page + - **edit.display**: This will override the default display value + - **edit.required**: set to true to fail if it does not have a value. Default is false. + - **edit.type** **required**: text || select || password + - **edit.component**: InputText || Input Combo || InputMultiCombo || InputSelectCombo + - **InputText** (default): A simple text box + - **InputCombo**: A searchable dropdown, single value only + - **InputMultiCombo**: A searchable dropdown, with multiple values allowed + - **InputSelectCombo**: A select dropdown of options + - **edit.options**: if component is one of InputCombo, InputMultiCombo, InputSelectCombo, the option values need to be specified. + - **Array(string)**: An array of values (the label and value fields will be set to the same value) + - **Array({ "value": string, "label": string })**: Allows you to set separate values for the value and label. NOTE: This will result in the value in the write hook having the same value, but it can be trimmed down to just the value in the write hook. + - Server-side validation will ensure that any value specified for this field appears in the options array + - **edit.disabled**: `true` if the component should be read only; default is false + - **edit.validateFunction**: stringified function for validation. Note that this validation function will run on both the server- and client-side. Example: `(function validate(value, values, context, languageDictionary) { if (value...) return 'something went wrong'; return false; }).toString()` +- **create**: false || object => This describes whether the field shows up on the create dialog. + - Default: if `false` will not show up on the create page + - **create.placeholder**: Provide placeholder text to show when input is empty. + - **create.required**: set to true to fail if it does not have a value. Default is false. + - **create.type** **required**: text || select || password + - **create.component**: InputText || Input Combo || InputMultiCombo || InputSelectCombo + - **InputText** (default): A text box. Default for type text and password. + - **InputCombo**: A searchable dropdown, single value only + - **InputMultiCombo**: A searchable dropdown, with multiple values allowed + - **InputSelectCombo**: A select dropdown of options + - **create.options**: if component is one of InputCombo, InputMultiCombo, InputSelectCombo, the option values need to be specified. + - **Array(string)**: A simple array of values, label and value will be set to the same + - **Array({ "value": string, "label": string })**: Allows you to set separate values for both the value and label. NOTE: This will result in the value in the write hook having the same value, but it can be trimmed down to just the value in the write hook. + - The server side validation will ensure that any value specified for this field is in the options array. + - **create.disabled**: true if component should be read only, default is false + - **create.validateFunction**: stringified function for checking the validation + - Example: `(function validate(value, values, context, languageDictionary) { if (value...) return 'something went wrong'; return false; }).toString()` + - This validation function will run on both the server- and client-side. + +## Pre-Defined Fields + +There are a set of pre-defined, searchable fields for default behavior. + +You can override the default behavior by adding the field as a userField and then overriding the behavior you would like to change. This would often be done to suppress a field by setting the display to false. + +### Search Fields + +- **name**: A constructed field from other fields: default display function: `(function(user, value) { return (value || user.nickname || user.email || user.user_id); }).toString()` +- **email**: email address or N/A +- **last_login_relative**: The last login time +- **logins_count**: The number of logins +- **connection**: Their database connection + +### User Info Fields: + +- **user_id**: The user ID +- **name**: The user's name +- **username**: The user's username +- **email**: The user's email +- **identity.connection**: The connection value +- **isBlocked**: Whether or not the user is blocked +- **blocked_for**: Whether or not the user has anomaly detection blocks +- **last_ip**: What the last IP was the user used to log in +- **logins_count**: How many times the user has logged in +- **currentMemberships**: The list of memberships for this user +- **created_at**: How long ago the user was created. +- **updated_at**: How long ago the user was updated. +- **last_login**: How long ago the user last logged in. + +### Create and Edit User Fields + +- **connection**: The user's database +- **password**: The new password +- **repeatPassword**: A repeat of the user's password +- **email**: The user's email +- **username**: The user's username + +### Sample Usage + +```js +function(ctx, callback) { + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + + return callback(null, { + // Only these connections should be visible in the connections picker. + // If only one connection is available, the connections picker will not be shown in the UI. + connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], + // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. + dict: { + title: department ? department + ' User Management' : 'User Management Dashboard', + memberships: 'Departments' + }, + // User Fields are the custom fields that can be displayed in create and edit, and can also be used for searching, and can be used to customize the view user page + userFields: [ + { + "label": "Connection", + "property": "connection", + "display": false, + "create": false, + "edit": false, + "search": false + }, + { + "label": "First Name", + "property": "user_metadata.given_name", + "display": true, + "create": { + "type": "text" + }, + "edit": { + "type": "text" + }, + "search": { + "listSize": "10%", + "listOrder": 0 + } + }, + { + "label": "Last Name", + "property": "user_metadata.family_name", + "display": true, + "create": { + "type": "text" + }, + "edit": { + "type": "text" + }, + "search": { + "listSize": "10%", + "listOrder": 1, + "sort": true + } + } + ], + // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) + css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css' + }); +} +``` + +## Localization + +Beginning with version 3.0 of the Delegated Admin Extension, you can provide a language dictionary for use with localization. The language dictionary is used only for static page content - for field level content, you must use **userFields** labels. + +::: note +Localization is aimed at those working with non-administrative functions when managing users. Auth0 currently does not support localization on any of the Configuration pages. +::: + +To specify the locale, you can use the path. For example: https://${account.tenant}.us.webtask.io/auth0-delegated-admin/en/users will set context.locale to `en` in the settings query. + +The **languageDictionary** is set as part of the settings query, which allows you to: + +* Explicitly define **languageDictionary** +* Provide URL to fetch the contents for the **languageDictionary** parameter + +Here is a sample of what a [complete Language Dictionary file](https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/tests/utils/en.json) looks like. + +### Example: Providing a Link to a Language Dictionary File + +```js +function(ctx, callback) { + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + + return callback(null, { + // Only these connections should be visible in the connections picker. + // If only one connection is available, the connections picker will not be shown in the UI. + connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], + // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. + dict: { + title: department ? department + ' User Management' : 'User Management Dashboard', + memberships: 'Departments' + }, + // User Fields are the custom fields that can be displayed in create and edit, and can also be used for searching, and can be used to customize the view user page + userFields: [ + { + "label": "Conexión", + "property": "connection", + }, + { + "label": "Correo Electrónico", + "property": "email", + }, + ... + ], + // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) + css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css', + languageDictionary: 'https://your-cdn.com/locale/es.json' + }); +} +``` + +### Example: Providing a Language Dictionary Object + +```js +function(ctx, callback) { + var department = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + + return callback(null, { + // Only these connections should be visible in the connections picker. + // If only one connection is available, the connections picker will not be shown in the UI. + connections: [ 'Username-Password-Authentication', 'My-Custom-DB' ], + // The dictionary allows you to overwrite the title of the dashboard and the "Memberships" label in the Create User dialog. + dict: { + title: department ? department + ' User Management' : 'User Management Dashboard', + memberships: 'Departments' + }, + // User Fields are the custom fields that can be displayed in create and edit, and can also be used for searching, and can be used to customize the view user page + userFields: [ + { + "label": "Conexión", + "property": "connection", + }, + { + "label": "Correo Electrónico", + "property": "email", + }, + ... + ], + // The CSS option allows you to inject a custom CSS file depending on the context of the current user (eg: a different CSS for every customer) + css: (department && department !== 'IT') && 'https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css', + languageDictionary: { + loginsCountLabel: 'Cantidad de Logins:', + searchBarPlaceholder: 'Busqueda de usuarios usando la sintaxis de Lucene', + deviceNameColumnHeader: 'Dispositivo', + ... + } + }); +} +``` + +<%= include('./_stepnav', { + prev: ["Delegated Admin: Hooks", "/extensions/delegated-admin/hooks"] +}) %> diff --git a/articles/extensions/delegated-admin/v3/hooks/write.md b/articles/extensions/delegated-admin/v3/hooks/write.md new file mode 100644 index 0000000000..d545e8f82b --- /dev/null +++ b/articles/extensions/delegated-admin/v3/hooks/write.md @@ -0,0 +1,89 @@ +--- +description: How to use the Write Hook with the Delegated Administration extension +topics: + - extensions + - delegated-admin + - users + - hooks +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- +# Delegated Administration Hooks: The Write Hook + +The Write Hook, which runs anytime you create or update a user, allows you to do things like: + +* Changing the user's password +* Changing the user's email address +* Updating the user's profile + +You can also use the Write Hook to set default values for newly-created users automatically. For example, you might want to automatically assign a user to the same group, department, or vendor as the ones to which you've been assigned. + +::: warning +Auth0 only supports user creation with Database Connections. +::: + +## The Hook Contract + + - **ctx**: The context object. + - **request.originalUser**: The current user's values where the **payload** is the new set of fields. Only available when the method is **update** + - **payload**: The payload object + - **memberships**: An array of memberships that were selected in the UI when creating the user + - **email**: The email address of the user + - **password**: The password of the user + - **connection**: The name of the database connection + - **app_metadata**: The data that's included if a Custom Field being modified is saved in `app_metadata`. + - **user_metadata**: The data that's included if a Custom Field being modified is saved in `user_metadata`. + - **userFields**: The user fields array (if specified in the [settings query](#the-settings-query-hook)) + - **method**: Either **create** or **update** depending on whether this is being called as a result of a create or an update call + - **callback(error, user)**: The callback to which you can return an error and the user object that should be sent to the Management API + +## Sample Usage + +Kelly manages the Finance department. When she creates users, these users should be assigned as members of the Finance department. + +```js +function(ctx, callback) { + var newProfile = { + email: ctx.payload.email, + password: ctx.payload.password, + connection: ctx.payload.connection, + user_metadata: ctx.payload.user_metadata, + app_metadata: { + department: ctx.payload.memberships && ctx.payload.memberships[0], + ...ctx.payload.app_metadata + } + }; + + if (!ctx.payload.memberships || ctx.payload.memberships.length === 0) { + return callback(new Error('The user must be created within a department.')); + } + + // Get the department from the current user's metadata. + var currentDepartment = ctx.request.user.app_metadata && ctx.request.user.app_metadata.department; + if (!currentDepartment || !currentDepartment.length) { + return callback(new Error('The current user is not part of any department.')); + } + + // If you're not in the IT department, you can only create users within your own department. + // IT can create users in all departments. + if (currentDepartment !== 'IT' && ctx.payload.memberships[0] !== currentDepartment) { + return callback(new Error('You can only create users within your own department.')); + } + + if (ctx.method === 'update') { + // If updating, only set the fields we need to send + Object.keys(newProfile).forEach(function(key) { + if (newProfile[key] === ctx.request.originalUser[key]) delete newProfile[key]; + }); + } + + // This is the payload that will be sent to API v2. You have full control over how the user is created in API v2. + return callback(null, newProfile); +} +``` + +<%= include('./_stepnav', { + prev: ["Delegated Admin: Hooks", "/extensions/delegated-admin/hooks"] +}) %> diff --git a/articles/extensions/delegated-admin/v3/index.md b/articles/extensions/delegated-admin/v3/index.md new file mode 100644 index 0000000000..55e03b3f4e --- /dev/null +++ b/articles/extensions/delegated-admin/v3/index.md @@ -0,0 +1,117 @@ +--- +title: Delegated Administration Extension +description: Learn about Auth0's Delegated Administration Extension, which allows you to expose the Users section of the Auth0 Dashboard to a select group of users without allowing them access to the rest of the Dashboard. +toc: true +topics: + - extensions + - delegated-admin +contentType: + - how-to + - concept + - index +useCase: extensibility-extensions +--- + +# Delegated Administration Extension + +The **Delegated Administration Extension (DAE)** allows you to grant a select group of people administrative permissions to the [Users page](${manage_url}/#/users) of the Auth0 Dashboard without providing access to any other area. This guide will show you how to do this by exposing the [Users area](${manage_url}/#/users) as an Auth0 application. + +## Steps + +To set up the Delegate Administration Extension (DAE), you must: + +1. [Register an Application with Auth0](#register-an-application-with-auth0) +2. [Create a database connection](#create-a-database-connection) +3. [Disable all other connections for your Auth0 Application](#disable-all-other-connections-for-your-auth0-application) +4. [Create a user for the database connection](#create-a-user-for-the-database-connection) +5. [Assign roles to the user](#assign-roles-to-the-user) +6. [Install and configure the extension](#install-and-configure-the-extension) +7. [Use the extension](#use-the-extension) + +### Register an Application with Auth0 + +First, you must create the Application that the Delegated Administration Extension will expose to those who should have administrative privileges for the Users page. To do this, [create a delegated admin application](/dashboard/guides/extensions/delegated-admin-create-app) in Auth0. + +When finished, make sure to note the application's **Client ID**. + +### Create a database connection + +In this example, a database connection will serve as the source of your users who are allowed access to the Users area. To configure this, [create a database connection](/dashboard/guides/connections/set-up-connections-database). + +While setting up your connection, make sure you use the following settings: + +* For connection name, use an appropriate name, such as `HelpDesk`. +* Enable the **Disable Sign Ups** toggle, which, for security purposes, will ensure that even users who have the link to the database connection cannot sign themselves up. + +### Disable all other connections for your Auth0 Application + +By default, Auth0 enables all connections associated with your tenant when you create a new Application. For this example, we will disable all connections other than our newly-created database connection. This will help keep the application secure because no one will be able to add themselves using one of our existing connections. + +To configure this, [update application connections](/dashboard/guides/applications/update-app-connections). + +### Create a user for the database connection + +To continue, you must [create at least one user](/dashboard/guides/users/create-users) and attach it to your connection. + +### Assign roles to the user + +<%= include('../../../_includes/_rbac_vs_extensions') %> + +Auth0 grants access to the Delegated Administration Extension (DAE) for the user(s) attached to your connection based on their roles. DAE-specific roles include: + +- **Delegated Admin - User**: Grants permission to search for users, create users, open users, and execute actions on users (e.g., `delete`, `block`). + +- **Delegated Admin - Administrator**: Grants all the rights of **Delegated Admin - User**, plus the ability to see all logs in the tenant and configure Hooks. + +- **Delegated Admin - Auditor**: Grants permission to search for users and view user information, but does not allow any changes to be made. This role also changes the UI to remove action-based buttons. + +- **Delegated Admin - Operator**: Grants permission to access user management and logs, but does not allow access to the extension configuration section. + +When working with roles, we recommend that you use the Authorization Core feature set: + +1. [Create DAE roles](/dashboard/guides/roles/create-roles). The names of the roles you create must match the names of the [pre-defined DAE roles above](#assign-roles-to-users). + +2. [Assign the DAE role to a user manually](/dashboard/guides/users/assign-roles-users), then add the user roles to the DAE namespace in the ID Token using the following rule, remembering to replace the `CLIENT_ID` placeholder with your delegated admin application's **Client ID**. + +```js +function (user, context, callback) { + if (context.clientID === 'CLIENT_ID') { + const namespace = 'https://example.com/auth0-delegated-admin'; + context.idToken[namespace] = { + roles: (context.authorization || {}).roles + }; + } + callback(null, user, context); +} +``` + +See this guide with more [information about creating rules](/dashboard/guides/rules/create-rules). + +::: note +Your claim should be [namespaced](/tokens/guides/create-namespaced-custom-claims). +::: + +::: note +Using Authorization Core will define roles in the `context.authorization` object. + +If you choose not to use Authorization Core, you should define DAE roles in one of the following fields on the user profile: + +* `user.app_metadata.roles` +* `user.app_metadata.authorization.roles` +::: + +## Install and configure the extension + +Now that we've created and configured an application, a connection, and our user, we can [install and configure the Delegated Admin Extension](/dashboard/guides/extensions/delegated-admin-install-extension) itself. + +## Use the extension + +Once installed, you are ready to [use the Delegated Admin Extension](/dashboard/guides/extensions/delegated-admin-use-extension). + +<%= include('./_session-timeout.md') %> + +## Keep reading + +* [Customizing the Delegated Administration Extension using Hooks](/extensions/delegated-admin/hooks) + +* [Managing users in the Delegated Administration Dashboard](/extensions/delegated-admin/manage-users) diff --git a/articles/extensions/delegated-admin/v3/manage-users.md b/articles/extensions/delegated-admin/v3/manage-users.md new file mode 100644 index 0000000000..b943aaf9a0 --- /dev/null +++ b/articles/extensions/delegated-admin/v3/manage-users.md @@ -0,0 +1,106 @@ +--- +description: How to manage users in the Delegated Administration extension +toc: true +topics: + - extensions + - delegated-admin + - users +contentType: + - how-to + - concept +useCase: extensibility-extensions +--- + +# Delegated Administration: Manage Users + +In the Application exposed by the Delegated Administration extension, there are two views available: *Users* and *Logs*. On the *Users* view, you can see the display and modify users associated with your Auth0 account. + +By default, all users are displayed, but you can filter the displayed list by configuring a [filter hook](/extensions/delegated-admin/v3/hooks/filter). + +## Available User Actions in the Delegated Administration Dashboard + +The table below lists the options you can perform on users, as well as information on whether the option is available via the [Management Dashboard](${manage_url}/#/) and/or the Delegated Administration extension. To limit the number of options someone with access to the Dashboard exposed by the Delegated Administration extension, configure an [access hook](/extensions/delegated-admin/v3/hooks/access). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Action Available in the Management Dashboard Available in the Delegated Administration Extension
      Create UserYesYes
      Contact UserYesNo
      Block UserYesYes
      Delete UserYesYes
      Send Verification EmailYesYes
      Change EmailYesYes
      Change PasswordYesYes
      Reset PasswordNoYes
      Change ProfileYesYes
      Remove MFANoYes
      + +The *Change Profile* option is available only if you have configured custom fields. + +Notice the new *Reset Password* option available via the extension. This option will send an email to the user allowing them to choose a new password. To do this click on a user and select *Actions > Reset Password*. + +![](/media/articles/extensions/delegated-admin/reset-pass-01.png) + +This will send an email to the user, containing a link to change the password. + +If your profile indicates that you have the `Delegated Admin - Administrator` role, the *Logs* view allows you to see a list of authentications made by your users (this tab is only visible to users with the `Delegated Admin - Administrator` role). The contents of this view are a subset of the data displayed in the [Logs Dashboard](${manage_url}/#/logs). The Log Dashboard also displays data on administrative actions taken in the Dashboard. + +## Create Users + +You can create a new user by selecting the **+ Create User** button on the *Users* view. You need to specify are email and password. Depending on your role, you may not be able to set the *Department* to which the new user belongs. + +For example, users with the `Delegated Admin - Administrator` role can see the **Department** field and select any of its values. + +![](/media/articles/extensions/delegated-admin/create-user-admin.png) + +On the other hand, Kelly who has the `Delegated Admin - User` role and belongs to the Finance department cannot see this field. The user she creates will be automatically assigned to the Finance department. + +![](/media/articles/extensions/delegated-admin/create-user-kelly.png) + +<%= include('./_session-timeout.md') %> diff --git a/articles/extensions/deploy-cli/_includes/_limitations.md b/articles/extensions/deploy-cli/_includes/_limitations.md new file mode 100644 index 0000000000..3f26e0cdb8 --- /dev/null +++ b/articles/extensions/deploy-cli/_includes/_limitations.md @@ -0,0 +1,3 @@ +### Limitations + +Some of the settings cannot be exported, such as `rulesConfigs` values. After exporting, you may need to update the values in `tenant.yaml` if you see schema-related errors during the import process. diff --git a/articles/extensions/deploy-cli/_includes/_strip-option.md b/articles/extensions/deploy-cli/_includes/_strip-option.md new file mode 100644 index 0000000000..ab0a70fece --- /dev/null +++ b/articles/extensions/deploy-cli/_includes/_strip-option.md @@ -0,0 +1 @@ +When importing objects into Auth0 tenants, Auth0 generates new IDs. To avoid import failure, identifier fields are stripped from the Auth0 objects on export by default. To override this behavior, use `--export_ids` or `AUTH0_EXPORT_IDENTIFIERS: true`. diff --git a/articles/extensions/deploy-cli/_includes/_upgrade-v4.md b/articles/extensions/deploy-cli/_includes/_upgrade-v4.md new file mode 100644 index 0000000000..beab3977fd --- /dev/null +++ b/articles/extensions/deploy-cli/_includes/_upgrade-v4.md @@ -0,0 +1,9 @@ +::: panel Upgrading to Deploy CLI Tool v4 +Upgrading to Deploy CLI Tool v4 requires that the **auth0-deploy-cli-extension** application be granted the following additional permissions (scopes) for the Auth0 Management API: `create:hooks`, `read:hooks`, `update:hooks`, and `delete:hooks`. Upgrading the **Auth0 Deploy CLI** extension will take care of this automatically. To upgrade the extension: + +1. Navigate to the [Extensions](${manage_url}/#/extensions) page in the [Auth0 Dashboard](${manage_url}), and click the **Installed Extensions** tab. + +2. Locate **Auth0 Deploy CLI**, click **Upgrade**, and confirm. Wait for the upgrade to complete. + +If necessary, you can check and [manually modify required scopes](/extensions/deploy-cli/guides/create-deploy-cli-application-manually#modify-deploy-cli-application-scopes). +::: \ No newline at end of file diff --git a/articles/extensions/deploy-cli/guides/call-deploy-cli-programmatically.md b/articles/extensions/deploy-cli/guides/call-deploy-cli-programmatically.md new file mode 100644 index 0000000000..4347f51a29 --- /dev/null +++ b/articles/extensions/deploy-cli/guides/call-deploy-cli-programmatically.md @@ -0,0 +1,67 @@ +--- +title: Call Deploy CLI Tool Programmatically +description: Learn how call the Auth0 Deploy Command Line Interface (CLI) programmatically. +topics: + - extensions + - deploy-cli +contentType: + - how-to +useCase: extensibility-extensions +--- +# Call Deploy CLI Tool Programmatically + +You can call the CLI tool programmatically as shown in the following example: + +```js +import { deploy, dump } from 'auth0-deploy-cli'; + +const config = { + AUTH0_DOMAIN: process.env.AUTH0_DOMAIN, + AUTH0_CLIENT_SECRET: process.env.AUTH0_CLIENT_SECRET, + AUTH0_CLIENT_ID: process.env.AUTH0_CLIENT_ID, + AUTH0_ALLOW_DELETE: false +}; + + +// Export Tenant Config +dump({ + output_folder: 'path/to/yaml/or/directory', // Input file for directory, change to .yaml for YAML + base_path: basePath, // Allow to override basepath, if not take from input_file + config_file: configFile, // Option to a config json + config: configObj, // Option to sent in json as object + strip, // Strip the identifier field for each object type + secret // Optionally pass in auth0 client secret separate from config +}) + .then(() => console.log('yey dump was successful')) + .catch(err => console.log(`Oh no, something went wrong. <%= "Error: ${err}" %>`)); + + +// Import tenant config +deploy({ + input_file: 'path/to/yaml/or/directory', // Input file for directory, change to .yaml for YAML + base_path: basePath, // Allow to override basepath, if not take from input_file + config_file: configFile, // Option to a config json + config: configObj, // Option to sent in json as object + env, // Allow env variable mappings from process.env + secret // Optionally pass in auth0 client secret separate from config +}) + .then(() => console.log('yey deploy was successful')) + .catch(err => console.log(`Oh no, something went wrong. <%= "Error: ${err}" %>`)); +``` + +## Troubleshooting + +The `auth0-deploy-cli` tool uses the Management API to pass through objects for create, update, and delete actions. + +You may occasionally see `Bad Request` and `Payload validation` errors returned by the Management API. These errors usually mean the object you're working with has attributes which are not writable or no longer available. This can happen when you are exporting from an older Auth0 tenant and importing into a newly-created tenant. + +If this is the case, update your configuration to support the new object format used by Auth0. + +## Keep reading + +* [Install the Deploy CLI Tool](/extensions/deploy-cli/guides/install-deploy-cli) +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) \ No newline at end of file diff --git a/articles/extensions/deploy-cli/guides/create-deploy-cli-application-manually.md b/articles/extensions/deploy-cli/guides/create-deploy-cli-application-manually.md new file mode 100644 index 0000000000..89ca93dd16 --- /dev/null +++ b/articles/extensions/deploy-cli/guides/create-deploy-cli-application-manually.md @@ -0,0 +1,114 @@ +--- +title: Create and Configure the Deploy CLI Application Manually +description: Learn how to create and configure the Deploy CLI application for use with the Deploy CLI tool. This can be done programmatically using the Auth0 Deploy CLI extension. +topics: + - extensions + - deploy-cli + - dashboard +contentType: + - how-to +useCase: extensibility-extensions +--- +# Create and Configure the Deploy CLI Application Manually + +To use the Deploy CLI tool, your tenant must be configured appropriately. + +::: note +Generally, you do this programmatically by [installing the **Auth0 Deploy CLI** extension](/extensions/deploy-cli/guides/install-deploy-cli#install-the-deploy-cli-extension), which will create and configure an Application that is authorized to call the Management API. +::: + +Sometimes, you may wish to create and configure this application manually. At a later time, you may also want to modify scopes for an application that has been created previously. + +## Create the Initial Deploy CLI Application + +To create and configure the initial Deploy CLI Application: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}), and click **+ Create Application**. + +2. Enter `auth0-deploy-cli-extension` as the name for your Application, select **Machine to Machine Applications**, and click **Create**. + +![Select Application Name and Type](/media/articles/applications/create-client-popup.png) + +3. When asked which API you want to call from your application, select **Auth0 Management API**. + +![Select API](/media/articles/applications/m2m-select-api.png) + +4. Select the [required scopes](#required-scopes) to enable them for your Application, and click **Authorize**. These scopes will be issued as part of your Application's Access Token. + +![Select Scopes](/media/articles/applications/m2m-select-scopes.png) + +## Modify Deploy CLI Application Scopes +To modify permissions (scopes) for an application that has been created previously: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the `auth0-deploy-cli-extension` application. + +![View Applications](/media/articles/extensions/deploy-cli/deploy-cli-app-list.png) + +2. Click the **APIs** tab, expand the **Auth0 Management API**, and enable any [required scopes](#required-scopes) that appear to have been disabled. + +![Enable Permissions](/media/articles/extensions/deploy-cli/deploy-cli-enable-permissions.png) + +::: warning +If the APIs tab is not visible: + +1. For **Application Type**, and select **Machine to Machine**. + +2. Click **Save Changes**, then refresh the page. The APIs tab should now be visible. +::: + +## Required Scopes + +The following scopes are required to be enabled on the `auth0-deploy-cli-extension` Application to ensure it is configured for proper access to the Management API. + + - read:client_grants + - create:client_grants + - delete:client_grants + - update:client_grants + - read:clients + - update:clients + - delete:clients + - create:clients + - read:client_keys + - update:client_keys + - delete:client_keys + - create:client_keys + - read:connections + - update:connections + - delete:connections + - create:connections + - read:resource_servers + - update:resource_servers + - delete:resource_servers + - create:resource_servers + - read:rules + - update:rules + - delete:rules + - create:rules + - read:hooks + - create:hooks + - update:hooks + - delete:hooks + - read:rules_configs + - update:rules_configs + - delete:rules_configs + - read:email_provider + - update:email_provider + - delete:email_provider + - create:email_provider + - read:tenant_settings + - update:tenant_settings + - read:grants + - delete:grants + - read:guardian_factors + - update:guardian_factors + - read:email_templates + - create:email_templates + - update:email_templates + - read:roles + - create:roles + - delete:roles + - update:roles + - read:prompts + - update:prompts + - read:branding + - update:branding \ No newline at end of file diff --git a/articles/extensions/deploy-cli/guides/import-export-directory-structure.md b/articles/extensions/deploy-cli/guides/import-export-directory-structure.md new file mode 100644 index 0000000000..cc16fc1cf4 --- /dev/null +++ b/articles/extensions/deploy-cli/guides/import-export-directory-structure.md @@ -0,0 +1,175 @@ +--- +title: Import/Export Tenant Configuration to Directory Structure +description: Understand how the Auth0 Deploy Command Line Interface (CLI) tool works. +topics: + - extensions + - deploy-cli +contentType: + - how-to +useCase: extensibility-extensions +--- +# Import/Export Tenant Configuration to Directory Structure + +The `auth0-deploy-cli` tool includes a **directory option** that allows you to export and import an existing Auth0 tenant configuration into a predefined directory structure. + +::: note +For information on how the files are expected to be laid out to work with the source control configuration utilities, see [GitHub Deployments](/extensions/github-deploy). +::: + +## Import tenant configuration + +1. Copy `config.json.example`, making sure to replace the placeholder values with the values specific to your configuration. + + ```json + { + "AUTH0_DOMAIN": ".auth0.com", + "AUTH0_CLIENT_ID": "", + "AUTH0_CLIENT_SECRET": "", + "AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "AUTH0_TENANT_NAME": "", + "ENV": "DEV" + }, + "AUTH0_ALLOW_DELETE": false, + "AUTH0_EXCLUDED_RULES": [ + "rule-1-name", + "rule-2-name" + ], + "INCLUDED_PROPS": { + "clients": [ "client_secret" ] + }, + "EXCLUDED_PROPS": { + "connections": [ "options.client_secret" ] + } + } + ``` + +Use the `client ID` and secret from your newly-created client (the client is named `auth0-deploy-cli-extension` if you used the extension). + +By default, the tool merges with your current environment variables and overrides the `config.json` file (which has the same top key). You can use the `--no-env` option to disable the override via the command line. + +You can either set the environment variables, or you can place the values in a configuration file anywhere on the file system that is accessible by the CLI tool. + +2. Deploy using the following command: + +```bash +a0deploy import --config_file config.json --input_file . +``` + +### Example: configuration file + +Here is an example of a `config.json` file: + +```json +{ + "AUTH0_DOMAIN": "", + "AUTH0_CLIENT_SECRET": "", + "AUTH0_CLIENT_ID": "", + "AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "YOUR_ARRAY_KEY": [ + "http://localhost:8080", + "https://somedomain.com" + ], + "YOUR_STRING_KEY": "some environment specific string" + }, + "AUTH0_ALLOW_DELETE": false, + "INCLUDED_PROPS": { + "clients": [ "client_secret" ] + }, + "EXCLUDED_PROPS": { + "connections": [ "options.client_secret" ] + }, + "AUTH0_EXCLUDED_RULES": [ "auth0-account-link-extension" ], + "AUTH0_EXCLUDED_CLIENTS": [ "auth0-account-link" ], + "AUTH0_EXCLUDED_RESOURCE_SERVERS": [ "SSO Dashboard API" ], + "AUTH0_EXCLUDED_DEFAULTS": ["emailProvider"] +} +``` + +## Export tenant configuration + +To export your current tenant configuration, run a command that's similar to: + +`a0deploy export --config_file config.json --format directory --output_folder path/to/export` + +<%= include('../_includes/_strip-option') %> + +<%= include('../_includes/_limitations') %> + +For more information, see [Environment Variables and Keyword Mappings](/extensions/deploy-cli/references/environment-variables-keyword-mappings). + +### Directory structure example + +Here is a sample of what the export directory structure looks like (for full details on everything that can be included, please refer to the [extension's repository](https://github.com/auth0/auth0-deploy-cli/tree/master/examples/directory): + +``` +repository => + clients + client1.json + client2.json + connections + connection1.json + database-connections + connection1 + database.json + create.js + delete.js + get_user.js + login.js + verify.js + emails + provider.json + verify_email.json + verify_email.html + welcome_email.json + welcome_email.html + grants + grant1.json + pages + login.html + login.json + password_reset.html + password_reset.json + resource-servers + resource_server1.json + resource_server2.json + rules + rule1.js + rule1.json + rule2.js + rules-configs + env_param1.json + some_secret1.json + hooks + hook1.js + hook1.json + guardian + factors + sms.json + email.json + otp.json + push-notification.json + provider + sms-twilio.json + templates + sms.json +``` + +::: note +To add hook secrets to your environment, add secrets in the .json configuration file (in this example, hook1.json) as follows: + +```json +"secrets": { + "api-key": "my custom api key" +} +``` + +The `secrets` object cannot be nested, so remember to prefix your secrets. +::: + +## Keep reading + +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Call Deploy CLI Tool Programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/guides/import-export-yaml-file.md b/articles/extensions/deploy-cli/guides/import-export-yaml-file.md new file mode 100644 index 0000000000..e66ab2e842 --- /dev/null +++ b/articles/extensions/deploy-cli/guides/import-export-yaml-file.md @@ -0,0 +1,272 @@ +--- +title: Import/Export Tenant Configuration to YAML File +description: Learn how to use the YAML option of the Auth0-deploy-cli tool. +topics: + - extensions + - deploy-cli +contentType: + - how-to +useCase: extensibility-extensions +--- +# Import/Export Tenant Configuration to YAML File + +The `auth0-deploy-cli` tool's **YAML option** supports the exporting to and importing of an Auth0 tenant configuration using a [YAML](http://yaml.org/) file. You can find an [example config file and other examples of using `auth0-deploy-cli`](https://github.com/auth0/auth0-deploy-cli/) in the Github repo. + +## Import tenant configuration + +To import an Auth0 tenant configuration: + +1. Copy `config.json.example`, making sure to replace the placeholder values with the values specific to your configuration. + + ```json + { + "AUTH0_DOMAIN": ".auth0.com", + "AUTH0_CLIENT_ID": "", + "AUTH0_CLIENT_SECRET": "", + "AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "AUTH0_TENANT_NAME": "", + "ENV": "DEV" + }, + "AUTH0_ALLOW_DELETE": false, + "AUTH0_EXCLUDED_RULES": [ + "rule-1-name", + "rule-2-name" + ], + "INCLUDED_PROPS": { + "clients": [ "client_secret" ] + }, + "EXCLUDED_PROPS": { + "connections": [ "options.client_secret" ] + } + } + ``` + + Use the `client ID` and secret from your newly-created client (the client is named `auth0-deploy-cli-extension` if you used the extension). + + By default, the tool merges with your current environment variables and overrides the `config.json` file (which has the same top key). You can use the `--no-env` option to disable the override via the command line. + + You can either set the environment variables, or you can place the values in a configuration file anywhere on the file system that is accessible by the CLI tool. + +2. Deploy using the following command: + + ```bash + a0deploy import --config_file config.json --input_file tenant.yaml + ``` + +### Example: configuration file + +Here is the example of a `config.json` file: + +```json +{ + "AUTH0_DOMAIN": "", + "AUTH0_CLIENT_SECRET": "", + "AUTH0_CLIENT_ID": "", + "AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "YOUR_ARRAY_KEY": [ + "http://localhost:8080", + "https://somedomain.com" + ], + "YOUR_STRING_KEY": "some environment specific string" + }, + "AUTH0_ALLOW_DELETE": false, + "INCLUDED_PROPS": { + "clients": [ "client_secret" ] + }, + "EXCLUDED_PROPS": { + "connections": [ "options.client_secret" ], + "emailProvider": ["name", "credentials", "default_from_address", "enabled"] + }, + "AUTH0_EXCLUDED_RULES": [ "auth0-account-link-extension" ], + "AUTH0_EXCLUDED_CLIENTS": [ "auth0-account-link" ], + "AUTH0_EXCLUDED_RESOURCE_SERVERS": [ "SSO Dashboard API" ], + "AUTH0_EXCLUDED_DEFAULTS": ["emailProvider"] +} +``` + +### Import configuration example + +The following is an example of an import config file called `tenant.yaml` (for full details on everything that can be included, please refer to the [extension's repository](https://github.com/auth0/auth0-deploy-cli/tree/master/examples/directory): + +```yaml +tenant: + # Any tenant settings can go here https://auth0.com/docs/api/management/v2#!/Tenants/get_settings + friendly_name: 'Auth0 Deploy Example' + +pages: + - name: "login" + html: "pages/login.html" + + - name: "password_reset" + html: "pages/password_reset.html" + + - name: "guardian_multifactor" + html: "pages/guardian_multifactor.html" + enabled: false + + - name: "error_page" + html: "pages/error_page.html" + +clients: + - + name: "My SPA" + app_type: "spa" + # Add other client settings https://auth0.com/docs/api/management/v2#!/Clients/post_clients + - + name: "My M2M" + app_type: "non_interactive" + # Add other client settings https://auth0.com/docs/api/management/v2#!/Clients/post_clients + +databases: + - name: "users" + enabled_clients: + - "My SPA" + options: + enabledDatabaseCustomization: true + customScripts: + login: "databases/users/login.js" + create: "databases/users/create.js" + delete: "databases/users/delete.js" + get_user: "databases/users/get_user.js" + change_email: "databases/users/change_email.js" + change_password: "databases/users/change_password.js" + verify: "databases/users/verify.js" + +connections: + - name: "myad-waad" + strategy: "waad" + enabled_clients: + - "My SPA" + options: + tenant_domain: 'office.com' + client_id: 'some_client_id' + client_secret: 'some_client_secret' + domain: 'office.com' + waad_protocol: 'openid-connect' + api_enable_users: true + basic_profile: true + ext_profile: true + ext_groups: true + # Add other connection settings (https://auth0.com/docs/api/management/v2#!/Connections/post_connections) + +rules: + - name: "Common-Functions" + order: 10 + script: "rules/enrich_tokens.js" + +rulesConfigs: + # Key/Value pairs for Rule configuration settings + - key: "SOME_SECRET" + value: 'some_key' + +hooks: + - name: "Client Credentials Exchange" + triggerId: "credentials-exchange" + enabled: true + secrets: + api-key: "my custom api key" + dependencies: + bcrypt: "3.0.6" + script: "hooks/client-credentials-exchange.js" + +resourceServers: + - + name: "My API" + identifier: "https://##ENV##.myapp.com/api/v1" + scopes: + - value: "update:account" + description: "update account" + - value: "read:account" + description: "read account" + # Add other resource server settings (https://auth0.com/docs/api/management/v2#!/Resource_Servers/post_resource_servers) + +emailProvider: + name: "smtp" + enabled: true + credentials: + smtp_host: "smtp.mailtrap.io" + smtp_port: 2525 + smtp_user: "smtp_user" + smtp_pass: "smtp_secret_password" + +emailTemplates: + - template: "verify_email" + enabled: true + syntax: "liquid" + from: "test@email.com" + subject: "something" + body: "emails/change_email.html" + + - template: "welcome_email" + enabled: true + syntax: "liquid" + from: "test@email.com" + subject: "something" + body: "emails/change_email.html" + +clientGrants: + - client_id: "My M2M" + audience: "https://##ENV##.myapp.com/api/v1" + scope: + - "update:account" + +guardianFactors: + - name: sms + enabled: true + - name: push-notification + enabled: true + - name: otp + enabled: true + - name: email + enabled: false + - name: duo + enabled: false + +guardianFactorProviders: + - name: sms + provider: twilio + auth_token: "some_token" + sid: "some_sid" + messaging_service_sid: "some_message_sid" + +guardianFactorTemplates: + - name: sms + enrollment_message: >- + {{code}} is your verification code for {{tenant.friendly_name}}. Please + enter this code to verify your enrollment. + verification_message: '{{code}} is your verification code for {{tenant.friendly_name}}' + +roles: + - name: Admin + description: App Admin + permissions: + - permission_name: 'update:account' + resource_server_identifier: 'https://##ENV##.myapp.com/api/v1' + - permission_name: 'read:account' + resource_server_identifier: 'https://##ENV##.myapp.com/api/v1' + - name: User + description: App User + permissions: + - permission_name: 'read:account' + resource_server_identifier: 'https://##ENV##.myapp.com/api/v1' +``` + +## Export tenant configuration + +To export your current tenant configuration, run a command that's similar to: + +`a0deploy export --config_file config.json --format yaml --output_folder path/to/export` + +<%= include('../_includes/_strip-option') %> + +<%= include('../_includes/_limitations') %> + +For more information, see [Environment Variables and Keyword Mappings](/extensions/deploy-cli/references/environment-variables-keyword-mappings). + +## Keep reading + +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Call Deploy CLI Tool Programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment.md b/articles/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment.md new file mode 100644 index 0000000000..d535b82f6f --- /dev/null +++ b/articles/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment.md @@ -0,0 +1,73 @@ +--- +title: Incorporate Deploy CLI into Build Environment +description: Learn how to incorporate the Deploy CLI tool into your build environment. +topics: + - extensions + - deploy-cli +contentType: + - how-to +useCase: extensibility-extensions +--- +# Incorporate Deploy CLI into Build Environment + +Auth0 offers a Deploy CLI tool that we recommend you incorporate into your build system. The Deploy CLI tool allows you to: + +* Deploy using the command line +* Create a repository to store your deployment configuration +* Create a set of configuration files for each environment (e.g., development, production) +* Have a deployment build for each environment that updates a local copy of the deployment configuration repository on your continuous integration server + +## Auth0 tenant layout + +We recommend that you have a separate Auth0 tenant/account for each environment you have. For example, you might have the following environments and Auth0 tenants: + +| Environment | Tenant | +| - | - | +| Development | *fabrikam-dev* | +| Testing | *fabrikam-uat* | +| Staging | *fabrikam-staging* | +| Production | *fabrikam-prod* | + +### Your deploy configuration repository + +Your configuration repository should contain a specific set of files based on how you've chosen to import/export your tenant configuration information: + +* [Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) + +You should have at least one branch for each tenant/account in your repository, which allows you to make changes without deploying them (the changes would only deploy when you merged your branch into the master, or primary, branch). With this setup, you can have a continuous integration task for each environment that automatically deploys changes to the targeted environment whenever the master branch receives updates. + +Your workflow would, therefore, look something like this: + +1. Make changes to development. +2. Merge changes to testing (or `uat`). +3. Test changes to `uat`. When ready, move and merge the changes to `staging`. +4. Test `staging`. When ready, move and merge the changes to `production`. + +You may want to set your production environment to deploy only when triggered manually. + +### Your continuous integration (CI) server configuration + +Your CI server should have a different deploy task and config for each environment. Since each tenant/account needs to have the `auth0-deploy-cli-extension` installed and using a different domain, client ID, and secret, you will need to create individual configurations -- this has the bonus of helping you avoid accidental deployments to the wrong environment. + +The deploy task should do the following: + + 1. Update the local repo to include the latest changes (each environment should have its own branch of the repository that can later be merged with other branches) + 1. If there are changes, call `a0deploy`. + 1. Run a suite of tests to confirm configuration is working. + 1. (Optional) Merge to next branch (e.g. `development` to `uat` or `uat` to `staging`. + +### Use keyword mappings to handle differences between the environments + +You should not have to store differences between environments in the Deploy Configuration Repository. Use the keyword mappings to allow the repository to be environment agnostic, and save the differences in the separate `config.json` files for each environment on the CI server. + +For more information, see [Environment Variables and Keyword Mappings](/extensions/deploy-cli/references/environment-variables-keyword-mappings). + +## Keep reading + +* [Install the Deploy CLI Tool](/extensions/deploy-cli/guides/install-deploy-cli) +* [Call Deploy CLI Tool Programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/guides/install-deploy-cli.md b/articles/extensions/deploy-cli/guides/install-deploy-cli.md new file mode 100644 index 0000000000..fd08de5bcf --- /dev/null +++ b/articles/extensions/deploy-cli/guides/install-deploy-cli.md @@ -0,0 +1,81 @@ +--- +title: Install and Configure the Deploy CLI Tool +description: Learn how to install and configure the Deploy CLI tool. +topics: + - extensions + - deploy-cli +contentType: + - how-to +useCase: extensibility-extensions +--- +# Install and Configure the Deploy CLI Tool + +This guide will show you how to install the Deploy CLI tool and configure it using the Deploy CLI extension. To do this, you must: + +1. [Install the Deploy CLI Tool](#install-the-deploy-cli-tool) +2. [Install the Deploy CLI Extension](#install-the-deploy-cli-extension) +3. [Configure the Deploy CLI Tool](#configure-the-deploy-cli-tool) +4. [Run the Deploy CLI Tool](#run-the-deploy-cli-tool) + +You can also upgrade from a previous version of the tool. The `auth0-deploy-cli` tool was completely rewritten from version 1 to [version 2 or later](/extensions/deploy-cli/references/whats-new), which means that it is not backwards compatible. Please consider the following when upgrading: + +- The directory structure and format has changed to allow for additional object types. +- The command line parameters have changed to allow for additional options, such as export. + +## Install the Deploy CLI Tool + +To install the Deploy CLI Tool, use the command-line interface to run: + +```bash +npm i -g auth0-deploy-cli +``` + +## Install the Deploy CLI Extension + +The Deploy CLI tool must be authorized to call the Management API. To do this, the **Auth0 Deploy CLI** extension configures your tenant by creating and configuring an application named **auth0-deploy-cli-extension** and authorizing it for use with the Management API. Later, you will use the Client ID and Secret from this application to configure the Deploy CLI Tool. + +1. Navigate to the [Extensions](${manage_url}/#/extensions) page in the [Auth0 Dashboard](${manage_url}), locate the **Auth0 Deploy CLI** extension, and click the extension. + +![Find Deploy CLI Extension](/media/articles/extensions/deploy-cli/deploy-cli-find-extension.png) + +2. Click **Install**. + +![Install Deploy CLI Extension](/media/articles/extensions/deploy-cli/deploy-cli-install-extension.png) + +3. From the list of installed extensions, click **Auth0 Deploy CLI**, then click **Accept** to consent to allow the extension to access your data. + +::: note +If necessary, you can also [manually create and configure the **auth0-deploy-cli-extension** application](/extensions/deploy-cli/guides/create-deploy-cli-application-manually#create-the-initial-deploy-cli-application) and [manually modify required scopes](/extensions/deploy-cli/guides/create-deploy-cli-application-manually#modify-deploy-cli-application-scopes). +::: + +## Configure the Deploy CLI Tool + +To configure the Deploy CLI tool to use the Deploy CLI application, create a **config.json** file, including the **Client ID** and **Client Secret** from the **auth0-deploy-cli-extension** application. You can find this application on the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}). + +```json +{ + "AUTH0_DOMAIN": "${account.namespace}", + "AUTH0_CLIENT_ID": "${account.clientId}", + "AUTH0_CLIENT_SECRET": "YOUR_CLIENT_SECRET", + "AUTH0_KEYWORD_REPLACE_MAPPINGS": { "AUTH0_TENANT_NAME": "${account.tenant}" }, + "AUTH0_ALLOW_DELETE": false, + "AUTH0_EXCLUDED_RULES": [ "rule-1-name" ] +} +``` + +## Run the Deploy CLI Tool + +To run the Deploy CLI Tool, use the command-line interface to run: + +```bash +a0deploy export --config_file config.json --format yaml --output_folder +``` + +## Keep reading + +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Call Deploy CLI Tool Programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Import/Export Tenant Configuration to a Directory Structure](extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Troubleshooting the Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/index.md b/articles/extensions/deploy-cli/index.md new file mode 100644 index 0000000000..627f5ead21 --- /dev/null +++ b/articles/extensions/deploy-cli/index.md @@ -0,0 +1,91 @@ +--- +title: Deploy CLI Tool +description: Understand how the Auth0 Deploy CLI tool works. +topics: + - extensions + - deploy-cli +contentType: + - index +useCase: extensibility-extensions +--- +# Deploy CLI Tool + +Auth0 supports continuous integration and deployment (CI/CD) of Auth0 tenants through our [source control extensions](/extensions#deploy-hosted-pages-rules-and-database-connections-scripts-from-external-repositories) and integration into existing CI/CD pipelines using the Deploy CLI tool. + +The Deploy CLI tool (`auth0-deploy-cli`) supports two methods to import and export the following Auth0 tenant configuration objects: + +- Tenant settings +- Rules (including secrets/settings) +- Hooks +- Hook Secrets +- Connections +- Custom databases +- Clients/applications +- Resource servers (APIs) +- Pages +- Email templates and providers +- Guardian settings + +You can export the data to a predefined [directory structure](/extensions/deploy-cli/guides/import-export-directory-structure) or a [YAML configuration file](/extensions/deploy-cli/guides/import-export-yaml-file). You can call the tool [programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically). You can also use the tool to replace environment variables. + +::: warning +This tool can be destructive to your Auth0 tenant. Please ensure you have read the documentation and tested the tool on a development tenant before using it in production. +::: + +## Upgrade to latest version + +For version 5, the `auth0-deploy-cli` tool was updated to add support for Node.js v14 and drop support for Node.js versions earlier than v8. + +If you are upgrading `auth0-deploy-cli` from versions earlier than v4, please upgrade the **Auth0 Deploy CLI** extension by following the instructions for [Deploy CLI Tool v4](#deploy-cli-tool-v4) below. + +## Previous versions + +Features released in previous versions of the Deploy CLI Tool are listed below. For a complete list of changes, see the [changelog](https://github.com/auth0/auth0-deploy-cli/blob/master/CHANGELOG.md). + + +### Deploy CLI Tool v4 + +For version 4, the `auth0-deploy-cli` tool was updated to add support for Hooks and Hook Secrets. + +<%= include('./_includes/_upgrade-v4') %> + + +### Deploy CLI Tool v3 + +For version 3, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Added options to the config: + - INCLUDED_PROPS: Enables export of properties that are excluded by default (e.g., client_secret) + - EXCLUDED_PROPS: Provides ability to exclude any unwanted properties from exported objects +- Removed `--strip` option from `export` command. IDs will now be stripped by default; to override, use `--export_ids` or `AUTH0_EXPORT_IDENTIFIERS: true`. + +### Deploy CLI Tool v2 + +For version 2, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Added YAML support +- Added support for export (deprecation of separate auth0 dump tool) +- Delete support - The tool will, if configured via `AUTH0_ALLOW_DELETE`, delete objects if does not exist within the deploy configuration. +- Support for additional Auth0 objects + - Connections including Social, Enterprise and Passwordless configurations. + - Improved support for database connections and associated configuration. + - Email Templates + - Email Provider + - Client Grants + - Rule Configs (Import Only) + - Guardian config + - Better support for pages + - Tenant level settings +- Added support to be called programmatically +- Improved logging +- To simplify the tool the slack hook was removed. You can invoke the tool programmatically to support calling your own hooks +- Support referencing clients by their name vs client_id (automatic mapping during export/import) +- Simplified to support future Auth0 object types + +### Keep reading + +* [Install the Deploy CLI Tool](/extensions/deploy-cli/guides/install-deploy-cli) +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Deploy CLI Tool Options](/extensions/deploy-cli/references/deploy-cli-options) +* [Environment Variables and Keyword Mappings](/extensions/deploy-cli/references/environment-variables-keyword-mappings) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/references/deploy-cli-options.md b/articles/extensions/deploy-cli/references/deploy-cli-options.md new file mode 100644 index 0000000000..0e11c2e000 --- /dev/null +++ b/articles/extensions/deploy-cli/references/deploy-cli-options.md @@ -0,0 +1,43 @@ +--- +title: Deploy CLI Options +description: Describes the Auth0 Deploy CLI tool options. +topics: + - extensions + - deploy-cli +contentType: + - index + - concept +useCase: extensibility-extensions +--- +# Deploy CLI Options + +The following options are supported by the Deploy CLI tool `a0deploy`. + +## Commands + +- `a0deploy import` Deploy Configuration +- `a0deploy export` Export Auth0 Tenant Configuration + +## Options +- `--help` Show help `[boolean]` +- `--version` Show version number `[boolean]` +- `--debug, -d` Dump extra debug information. `[string] [default: false]` +- `--proxy_url, -p` A url for proxying requests, only set this if you are behind a proxy. `[string]` + +## Examples + +``` + a0deploy export --config_file config.json --strip --format yaml --output_folder path/to/export Dump Auth0 config to folder in YAML format + a0deploy export --config_file config.json --strip --format directory --output_folder path/to/export Dump Auth0 config to folder in directory format + a0deploy import --config_file config.json --input_file tenant.yaml Deploy Auth0 via YAML + a0deploy import --config_file config.json --input_file path/to/files Deploy Auth0 via Path +``` + +## Keep reading + +* [Install the Deploy CLI Tool](/extensions/deploy-cli/guides/install-deploy-cli) +* [Incorporate Deploy CLI into Build Environment](/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Call Deploy CLI Tool Programmatically](/extensions/deploy-cli/guides/call-deploy-cli-programmatically) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/deploy-cli/references/environment-variables-keyword-mappings.md b/articles/extensions/deploy-cli/references/environment-variables-keyword-mappings.md new file mode 100644 index 0000000000..6aba3d3e09 --- /dev/null +++ b/articles/extensions/deploy-cli/references/environment-variables-keyword-mappings.md @@ -0,0 +1,70 @@ +--- +title: Environment Variables and Keyword Mappings +description: Describes environmental variables and keyword mappings for exporting tenant configurations. +topics: + - extensions + - deploy-cli +contentType: + - reference +useCase: extensibility-extensions +--- +# Environment Variables and Keyword Mappings + +The mappings allow you to do the following: + +* Use the same configuration file for all of your environments (e.g. dev, uat, staging, and prod). + +* Replace certain values in your configuration repo with environment-specific values. There are two ways to use the keyword mappings: You can either wrap the key in `@@key@@` or `##key##`. + + - If you use the `@` symbols, it will do a `JSON.stringify` on your value before replacing it. So if it is a string, it will add quotes. and if it is an array or object, it will add braces. + + - If you use the `#` symbol instead, it will just do a literal replacement; it will not add quotes or brackets. + +::: note +By default the tool also merges your current environment variables and overrides the **AUTH0_KEYWORD_REPLACE_MAPPINGS** which have the same top key. You can disable this via the command line with the `--no-env` option. +::: + +For example, you could specify a different JWT timeout in your dev environment, and then use prod for testing and a different environment URL. + +See the examples below. + +## `Client.json` + +```json +{ + ... + "callbacks": [ + "##ENVIRONMENT_URL##/auth/callback" + ], + "jwt_configuration": { + "lifetime_in_seconds": ##JWT_TIMEOUT##, + "secret_encoded": true + } + ... +} +``` + +## Dev `Config.json` + +```json +"AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "ENVIRONMENT_URL": "http://dev.fabrikam.com", + "JWT_TIMEOUT": 120, + ... +} +``` + +## Prod `Config.json` + +```json +"AUTH0_KEYWORD_REPLACE_MAPPINGS": { + "ENVIRONMENT_URL": "http://fabrikam.com", + "JWT_TIMEOUT": 3600, + ... +} +``` + +## Keep reading + +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML file](/extensions/deploy-cli/guides/import-export-yaml-file) diff --git a/articles/extensions/deploy-cli/references/troubleshooting.md b/articles/extensions/deploy-cli/references/troubleshooting.md new file mode 100644 index 0000000000..935ad27372 --- /dev/null +++ b/articles/extensions/deploy-cli/references/troubleshooting.md @@ -0,0 +1,30 @@ +--- +title: Troubleshoot the Deploy CLI Tool +description: Describes troubleshooting information for the Auth0 Deploy Command Line Interface (CLI) tool. +topics: + - extensions + - deploy-cli +contentType: + - index + - concept +useCase: extensibility-extensions +--- +# Troubleshoot the Deploy CLI tool + +## Warning log entries after a Google Apps connection is recreated + +**Symptoms**: you see warnings in the logs with messages like `Unable to get extended attributes: unauthorized` or `Unable to get groups: unauthorized`. + +When you first create a Google Apps connection and enable one of the checkboxes to get extended information about the user, you'll need to go through a consent flow by having a Google Apps administrator follow the link under the "Setup instructions" button next to the connection. After completing this flow, some token information is stored on the connection's `options` object that is used to retrieve extended information when a user logs in. + +If you have a Google Apps connection, you'll need to ensure that the consent flow is completed before exporting the connection information using the CLI. By doing this, the necessary tokens will be included in the exported script and the administrator won't have to go through the consent flow every time the connection is recreated. + +::: warning +The tokens stored in the connection's `options` object is sensitive information that should be treated securely as any other system credential. +::: + +## Keep reading + +* [Deploy CLI Tool Overview](/extensions/deploy-cli) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) diff --git a/articles/extensions/deploy-cli/references/whats-new.md b/articles/extensions/deploy-cli/references/whats-new.md new file mode 100644 index 0000000000..d6126e729d --- /dev/null +++ b/articles/extensions/deploy-cli/references/whats-new.md @@ -0,0 +1,72 @@ +--- +title: What's New in Deploy CLI Tool +description: Learn about features released in new versions of the Auth0 Deploy Command Line Interface (CLI) tool. +public: false +topics: + - extensions + - deploy-cli +contentType: + - index + - concept +useCase: extensibility-extensions +--- +# What's New in Deploy CLI Tool + +Features released in each version of the Deploy CLI Tool are listed below. For a complete list of changes, see the [changelog](https://github.com/auth0/auth0-deploy-cli/blob/master/CHANGELOG.md). + +## Deploy CLI Tool v5 + +For version 5, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Updated dependencies and deprecated support for Node.js versions earlier than 8 + +- Allowed excluding default values for emailProvider with `AUTH0_EXCLUDED_DEFAULTS` + +- For pages, fixed error when dumping error_page without html property + +## Deploy CLI Tool v4 + +For version 4, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Added support for Hooks and Hook Secrets + +<%= include('../_includes/_upgrade-v4') %> + +## Deploy CLI Tool v3 + +For version 3, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Added options to the config: + - INCLUDED_PROPS: Enables export of properties that are excluded by default (e.g., client_secret) + - EXCLUDED_PROPS: Provides ability to exclude any unwanted properties from exported objects +- Removed `--strip` option from `export` command. IDs will now be stripped by default; to override, use `--export_ids` or `AUTH0_EXPORT_IDENTIFIERS: true`. + +## Deploy CLI Tool v2 + +For version 2, the `auth0-deploy-cli` tool was updated to include the following changes. + +- Added YAML support +- Added support for export (deprecation of separate auth0 dump tool) +- Delete support - The tool will, if configured via `AUTH0_ALLOW_DELETE`, delete objects if does not exist within the deploy configuration. +- Support for additional Auth0 objects + - Connections including Social, Enterprise and Passwordless configurations. + - Improved support for database connections and associated configuration. + - Email Templates + - Email Provider + - Client Grants + - Rule Configs (Import Only) + - Guardian config + - Better support for pages + - Tenant level settings +- Added support to be called programmatically +- Improved logging +- To simplify the tool the slack hook was removed. You can invoke the tool programmatically to support calling your own hooks +- Support referencing clients by their name vs client_id (automatic mapping during export/import) +- Simplified to support future Auth0 object types + +## Keep reading + +* [Deploy CLI Tool Overview](/extensions/deploy-cli) +* [Import/Export Tenant Configuration to a Directory Structure](/extensions/deploy-cli/guides/import-export-directory-structure) +* [Import/Export Tenant Configuration to a YAML File](/extensions/deploy-cli/guides/import-export-yaml-file) +* [Troubleshooting Deploy CLI Tool](/extensions/deploy-cli/references/troubleshooting) diff --git a/articles/extensions/github-deploy.md b/articles/extensions/github-deploy.md index 4ec8797d06..b12669f988 100644 --- a/articles/extensions/github-deploy.md +++ b/articles/extensions/github-deploy.md @@ -1,11 +1,21 @@ --- toc: true description: The GitHub Deployments extension allows you to deploy rules and database connection scripts from GitHub to Auth0. +topics: + - extensions + - github-deployments +contentType: + - how-to +useCase: extensibility-extensions --- -# Github Deployments +# GitHub Deployments -The **GitHub Deployments** extension allows you to deploy [rules](/rules) and database connection scripts from GitHub to Auth0. You can configure a GitHub repository, keep all your rules and database connection scripts there, and have them automatically deployed to Auth0 each time you push to your repository. +The **GitHub Deployments** extension allows you to deploy [rules](/rules), rules configs, connections, database connection scripts, clients, client grants, resource servers, hosted pages and email templates from GitHub to Auth0. You can configure a GitHub repository, keep all your rules and database connection scripts there, and have them automatically deployed to Auth0 each time you push to your repository. + +::: note +You can use the `auth0-deploy-cli` tool to export and import tenant configuration data to a directory structure or a YAML file. For more information, see [Deploy CLI Tool Overview](/extensions/deploy-cli). +::: ## Configure the extension @@ -15,13 +25,18 @@ To install and configure this extension, click on the __GitHub Deployments__ box Set the following configuration variables: -- **GITHUB_REPOSITORY**: The repository from which you want to deploy rules and database scripts. This can be either a public or private repository. -- **GITHUB_BRANCH**: The branch that the extension will monitor for commits. -- **GITHUB_TOKEN**: Your GitHub personal Access Token. Follow the instructions at [Creating an Access Token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/#creating-a-token) to create a token with `repo` scope. -- **GITHUB_HOST**: The public accessible GitHub Enterprise _(version 2.11.3 and later)_ host name, no value is required when using github.com (optional). -- **GITHUB_API_PATH**: GitHub Enterprise API path prefix, no value is required when using github.com (optional). -- **SLACK_INCOMING_WEBHOOK_URL**: The Webhook URL for Slack, used in order to receive Slack notifications for successful and failed deployments (optional). +* **REPOSITORY**: The repository from which you want to deploy rules and database scripts. This can be either a public or private repository. +* **BRANCH**: The branch that the extension will monitor for commits. +* **HOST**: The public accessible GitHub Enterprise _(version 2.11.3 and later)_ hostname, no value is required when using github.com (optional). +* **API_PATH**: GitHub Enterprise API path prefix, no value is required when using github.com (optional). +* **TOKEN**: Your GitHub Personal Access Token. Follow the instructions at [Creating an Access Token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/#creating-a-token) to create a token with `repo` scope. +* **BASE_DIR**: The base directory, where all your tenant settings are stored +* **AUTO_REDEPLOY**: If enabled, the extension redeploys the last successful configuration in the event of a deployment failure. Manual deployments and validation errors does not trigger auto-redeployment +* **SLACK_INCOMING_WEBHOOK_URL**: The Webhook URL for Slack, used to receive Slack notifications for successful and failed deployments (optional). +::: note +Some of the configuration variables were changed in version **2.6.0** of this extension. If you are updating the extension from a prior version, make sure that you update your configuration accordingly. +::: Once you have provided this information, click **Install**. @@ -47,19 +62,28 @@ You can find details on how to configure a webhook at [Creating Webhooks](https: ## Deployment -Once you have setup the webhook in GitHub using the provided information, you are ready to start committing to your repository. +Once you have set up the webhook in GitHub using the provided information, you are ready to start committing to your repository. -With each commit you push to your configured GitHub repository, if changes were made in the `rules` or `database-connection` folders, the webhook will call the extension to initiate a deployment. +With each commit you push to your configured GitHub repository, the webhook will call the extension to initiate a deployment if changes were made to one of these folders: +- `clients` +- `grants` +- `emails` +- `resource-servers` +- `connections` +- `database-connections` +- `rules-configs` +- `rules` +- `pages` -The __Deploy__ button on the **Deployments** tab of the extension allows you to manually deploy the rules and database connection scripts you already have in your GitHub repository. This is useful if you already have a repository filled with scripts that you want to deploy once you have setup the extension, or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your repository. +The __Deploy__ button on the **Deployments** tab of the extension allows you to manually deploy the rules and database connection scripts you already have in your GitHub repository. This is useful if you already have a repository filled with scripts that you want to deploy once you have set up the extension, or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your repository. ::: panel-warning Deleting Rules and Scripts from GitHub To maintain a consistent state, the extension will always do a full redeployment of the contents of these folders. Any rules or database connection scripts that exist in Auth0 but not in your GitHub repository will be __deleted__. ::: -### Deploy database connection scripts +### Deploy Database Connection scripts -In order to deploy database connection scripts, you must first create a directory under `database-connections`. The name of the directory must __exactly__ match the name of your [database connection](${manage_url}/#/connections/database) in Auth0. Of course, you can create as many directories as you have database connections. +To deploy database connection scripts, you must first create a directory under `database-connections`. The name of the directory must __exactly__ match the name of your [database connection](${manage_url}/#/connections/database) in Auth0. Of course, you can create as many directories as you have database connections. Under the created directory, create one file for every script you want to use. The allowed scripts are: @@ -76,22 +100,55 @@ If you enabled the migration feature, you will also need to provide the `get_use You can find an example in [this GitHub repository](https://github.com/auth0-samples/github-source-control-integration/tree/master/database-connections/my-custom-db). -### Deploy Hosted Pages +#### Deploy Database Connection settings + +To deploy Database Connection settings, you must create `database-connections/[connection-name]/database.json`. + +_This will work only for Auth0 connections (`strategy === auth0`); for non-Auth0 connections use `connections`._ + +_Support for using `settings.json` has been deprecated in favor of `database.json` since v3.1.1 of the extension and may be dropped in a future release._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/patch_connections_by_id) for more info on allowed attributes for Connections. + +### Deploy Connections + +To deploy a connection, you must create a JSON file under the `connections` directory of your GitHub repository. Example: + +__facebook.json__ +```json +{ + "name": "facebook", + "strategy": "facebook", + "enabled_clients": [ + "my-client" + ], + "options": {} +} +``` + +<%= include('./_includes/_embedded-clients-array') %> + +_This will work only for non-Auth0 connections (`strategy !== auth0`); for Auth0 connections, use `database-connections`._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/post_connections) for more info on allowed attributes for Connections. + +### Deploy Universal Login Pages + +The supported pages are: -The supported hosted pages are: - `error_page` - `guardian_multifactor` - `login` - `password_reset` -To deploy a page, you must create an HTML file under the `pages` directory of your GitHub repository. For each HTML page you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, in order to deploy an `error_page`, you would create two files: +To deploy a page, you must create an HTML file under the `pages` directory of your GitHub repository. For each HTML page, you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, to deploy a `password_reset`, you would create two files: ```text -your-github-repo/pages/error_page.html -your-github-repo/pages/error_page.json +your-github-repo/pages/password_reset.html +your-github-repo/pages/password_reset.json ``` -To enable the page the `error_page.json` would contain the following: +To enable the page, the `password_reset.json` would contain the following: ```json { @@ -99,9 +156,11 @@ To enable the page the `error_page.json` would contain the following: } ``` +<%= include('./_includes/_use-default-error') %> + ### Deploy rules -In order to deploy a rule, you must first create a JavaScript file under the `rules` directory of your GitHub repository. Each rule must be in its own `.js` file. +To deploy a rule, you must first create a JavaScript file under the `rules` directory of your GitHub repository. Each rule must be in its own JavaScript file. For example, if you create the file `rules/set-country.js`, then the extension will create a rule in Auth0 with the name `set-country`. @@ -109,10 +168,6 @@ For example, if you create the file `rules/set-country.js`, then the extension w If you plan to use Source Control integration for an existing account, first rename your rules in Auth0 to the same name of the files you will be deploying to this directory. ::: -You can mark rules as manual. In that case, the source control extension will not delete or update them. To mark a rule, navigate to the **Rules Configuration** tab of the GitHub Integration page. Toggle the **Manual Rule** switch for the rules you want to mark as manual. Click **Update Manual Rules** to save your changes. - -![Manual Rules](/media/articles/extensions/github-deploy/manual-rules.png) - You can control the rule order and status (`enabled`/`disabled`) by creating a JSON file with the same name as your JavaScript file. For this example, you would create a file named `rules/set-country.json`. __set-country.js__ @@ -126,7 +181,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -140,6 +195,157 @@ You can find examples in [this GitHub repository](https://github.com/auth0-sampl Multiple rules of the same order are not allowed. To avoid conflicts, you can create a JSON file for each rule and assign a value for `order`. If you leave enough space between these values, re-ordering them without conflicts will be easier. For example, if you have three rules, instead of setting their order to `1`, `2`, `3`, you can set them to `10`, `20`, `30`. This way, to move the `30` rule before the `20`, you can simply change its `order` to any value between `11` and `19`. +### Deploy Rules Configs + +To deploy a rule config, you must create a JSON file under the `rules-configs` directory of your GitHub repository. Example: + +__secret_number.json__ +```json +{ + "key": "secret_number", + "value": "42" +} +``` + +### Deploy Clients + +To deploy a client, you must create a JSON file under the `clients` directory of your GitHub repository. Example: + +__my-client.json__ +```json +{ + "name": "my-client" +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Clients/post_clients) for more info on allowed attributes for Clients and Client Grants. + +### Deploy Clients Grants + +You can specify the client grants for each client by creating a JSON file in the `grants` directory. + +__my-client-api.json__ +```json +{ + "client_id": "my-client", + "audience": "https://myapp.com/api/v1", + "scope": [ + "read:users" + ] +} +``` + +<%= include('./_includes/_deployment-extension') %> + +### Deploy Resource Servers + +To deploy a resource server, you must create a JSON file under the `resource-servers` directory of your GitHub repository. Example: + +__my-api.json__ +```json +{ + "name": "my-api", + "identifier": "https://myapp.com/api/v1", + "scopes": [ + { + "value": "read:users", + "description": "Allows getting user information" + } + ] +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Resource_Servers/post_resource_servers) for more info on allowed attributes for Resource Servers. + +### Deploy Email Provider + +To deploy an email provider, you must create `provider.json` file under the `emails` directory of your GitHub repository. Example: + +__provider.json__ +```json +{ + "name": "smtp", + "enabled": true, + "credentials": { + "smtp_host": "smtp.server.com", + "smtp_port": 25, + "smtp_user": "smtp_user", + "smtp_pass": "smtp_secret_password" + } +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Emails/patch_provider) for more info on allowed attributes for Email Provider. + +### Deploy Email Templates + +The supported email templates are: +- `verify_email` +- `reset_email` +- `welcome_email` +- `blocked_account` +- `stolen_credentials` +- `enrollment_email` +- `mfa_oob_code` + +To deploy an email template, you must create an HTML file under the `emails` directory of your GitHub repository. For each HTML file, you need to create a JSON file (with the same name) with additional options for that template. For example, to deploy a `blocked_account` template, you would create two files: + +```text +your-github-repo/emails/blocked_account.html +your-github-repo/emails/blocked_account.json +``` + +__blocked_account.json__ +```json +{ + "template": "blocked_account", + "from": "", + "subject": "", + "resultUrl": "", + "syntax": "liquid", + "body": "./blocked_account.html", + "urlLifetimeInSeconds": 432000, + "enabled": true +} +``` + +## Excluded records + +You can exclude the following records from the deployment process: `rules`, `clients`, `databases`, `connections` and `resourceServers`. If excluded, the records will not be modified by deployments. + +![](/media/articles/extensions/deploy-extensions/excluded-rules.png) + +## Keywords Mapping + +Beginning with version **3.0.0**, you can use keywords mapping to manage your secrets and tenant-based environment variables. + +There are two ways to use the keyword mappings. You can either wrap the key using `@` symbols (e.g., `@@key@@`), or you can wrap the key using `#` symbols (e.g., `##key##`). + + - If you use `@` symbols, your value will be converted from a JavaScript object or value to a JSON string. + + - If you use `#` symbols, Auth0 will perform a literal replacement. + +This is useful for something like specifying different variables across your environments. For example, you could specify different JWT timeouts for your Development, QA/Testing, and Production environments. + +Refer to the snippets below for sample implementations: + +__Client.json__ +```json +{ + ... + "callbacks": [ + "##ENVIRONMENT_URL##/auth/callback" + ], + "jwt_configuration": { + "lifetime_in_seconds": ##JWT_TIMEOUT##, + "secret_encoded": true + } + ... +} +``` + +![](/media/articles/extensions/deploy-extensions/mappings.png) + ## Track deployments To track your deployments, navigate to the [extensions](${manage_url}/#/extensions) page, click on the row for the __GitHub Deployments__ extension, and select the __Deployments__ tab. You will see a list of all deployments, both successful and failed. diff --git a/articles/extensions/gitlab-deploy.md b/articles/extensions/gitlab-deploy.md index 30512c819d..48909fdc18 100644 --- a/articles/extensions/gitlab-deploy.md +++ b/articles/extensions/gitlab-deploy.md @@ -1,63 +1,79 @@ --- toc: true description: The GitLab Deployments extension allows you to deploy Rules, Hosted Pages and Database Connection scripts from GitLab to Auth0. +topics: + - extensions + - gitlab-deployments +contentType: + - how-to +useCase: extensibility-extensions --- # GitLab Deployments -The **GitLab Deployments** extension allows you to deploy [Rules](/rules), Database Connection scripts and hosted pages from GitLab to Auth0. You can configure a GitLab repository, keep all of your scripts there, and have them automatically deployed to Auth0 whenever you push changes to your repository. +The **GitLab Deployments** extension allows you to deploy [rules](/rules), rules configs, connections, database connection scripts, clients, client grants, resource servers, hosted pages and email templates from GitLab to Auth0. You can configure a GitLab repository, keep all of your scripts there, and have them automatically deployed to Auth0 whenever you push changes to your repository. -## Configure the Auth0 Extension +## Configure the Auth0 extension -To install and configure this extension, click on the **GitLab Deployments** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the Auth0 Management Dashboard. The **Install Extension** window will open. +1. To install and configure this extension, click on the **GitLab Deployments** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the Auth0 Management Dashboard. The **Install Extension** window will open. ![Install extension popup window](/media/articles/extensions/gitlab-deploy/install-extension.png) -Set the following configuration variables: +2. Set the following configuration variables: -* **GITLAB_REPOSITORY**: The name of your GitLab repository. -* **GITLAB_BRANCH**: The branch of your GitLab repository your extension should monitor. -* **GITLAB_URL**: The url of your GitLab instance, in case of gitlab.com use `https://gitlab.com` -* **GITLAB_TOKEN**: The personal Access Token to your GitLab repository for this account. For details on how to configure one refer to [Configure a GitLab Token](configure-a-gitlab-token). +* **REPOSITORY**: The name of your GitLab repository. +* **BRANCH**: The branch of your GitLab repository your extension should monitor. +* **URL**: The URL of your GitLab instance, in case of gitlab.com use `https://gitlab.com` +* **TOKEN**: The personal Access Token to your GitLab repository for this account. To learn how to configure one, see [Configure a GitLab Token](#configure-a-gitlab-token). +* **BASE_DIR**: The base directory, where all your tenant settings are stored. If you want to keep your tenant settings under `org/repo/tenant/production`, `org/repo` goes to the `REPOSITORY` and `tenant/production` - to `BASE_DIR` +* **AUTO_REDEPLOY**: If enabled, the extension redeploys the last successful configuration in the event of a deployment failure. Manual deployments and validation errors does not trigger auto-redeployment * **SLACK_INCOMING_WEBHOOK**: The URL used to integrate with Slack to deliver notifications. -Once you have provided this information, click **Install**. +::: note +Some of the configuration variables were changed in version **2.7.0** of this extension. If you are updating the extension from a prior version, make sure that you update your configuration accordingly. +::: -### Configure a GitLab Token +3. Once you have provided this information, click **Install**. -Log in to your [GitLab](https://about.gitlab.com/) account and navigate to [Profile Settings > Access Tokens](https://gitlab.com/profile/personal_access_tokens). +### Configure a GitLab token -Create a new Access Token for Auth0. Make sure you copy the generated value and save it locally because you will not be able to access it again once you navigate away from this page. +1. Log in to your [GitLab](https://about.gitlab.com/) account and navigate to [Profile Settings > Access Tokens](https://gitlab.com/profile/personal_access_tokens). + +2. Create a new Access Token for Auth0. Make sure you copy the generated value and save it locally because you will not be able to access it again once you navigate away from this page. + +::: panel-warning API access +Make sure that you create the token with the `api` permission in Gitlab settings (this grants complete read/write access to the API). If your Gitlab token does not contain the necessary permissions, you may receive a "rejecting request of a tenant under quarantine" message because there was some uncaught error in the extension causing the Webtask context to be quarantined. +::: ![Generate a personal Access Token](/media/articles/extensions/gitlab-deploy/new-access-token.png) -Go back to the [Extensions](${manage_url}/#/extensions) page and set this value at the **Gitlab_Token** configuration variable. +3. Go back to the [Extensions](${manage_url}/#/extensions) page and set this value at the **Gitlab_Token** configuration variable. -## Authorize Access +## Authorize access -Navigate to the [Extensions](${manage_url}/#/extensions) page and click on the **Installed Extensions** tab. +1. Navigate to the [Extensions](${manage_url}/#/extensions) page and click on the **Installed Extensions** tab. ![](/media/articles/extensions/gitlab-deploy/installed-extensions-view.png) -Click on the row for the **GitLab Deployments** extension. The first time you click on your installed extension, you will be asked to grant it to access your GitLab account. +2. Click on the row for the **GitLab Deployments** extension. The first time you click on your installed extension, you will be asked to grant it to access your GitLab account. ![](/media/articles/extensions/gitlab-deploy/user-consent.png) -Once you agree, you will be directed to the **GitLab Integration** page. +3. Once you agree, you will be directed to the **GitLab Integration** page. ![](/media/articles/extensions/gitlab-deploy/gitlab-integration-page.png) -Copy the **Payload URL** and **Secret** values. You will use them in order to configure the GitLab Webhook in the next step. +4. Copy the **Payload URL** and **Secret** values. You will use them to configure the GitLab Webhook in the next step. ## Configure the GitLab Webhook Once you have configured your Auth0 Extension, you will need to configure the GitLab Webhook to complete the integration. -In your GitLab Repository, click on the gear icon near the top right of the page to open the menu. Click on **Webhooks**. +1. In your GitLab repository, click on the gear (Settings) icon. In the menu that appears, click on **Integrations**. This brings up the Webhook configuration area. ![](/media/articles/extensions/gitlab-deploy/gitlab-settings-menu.png) -Set the following configuration variables: +2. Set the following configuration variables: * **URL**: Set the value of the **Payload URL** from the previous step. * **Secret Token**: Set the value of the **Secret** from the previous step. @@ -66,30 +82,36 @@ Set the following configuration variables: ![](/media/articles/extensions/gitlab-deploy/gitlab-add-webhook.png) -Click **Add Webhook** to save your changes. +3. Scroll down, and click **Add Webhook** to save your changes. ## Deployment Once you have set up the webhook in GitLab using the provided information, you are ready to start committing to your repository. -Your repository should have a predefined structure: -- Rules are expected to be found under `rules` directory. -- Database connections are expected to be found under `database-connections` directory. -- Hosted pages are expected to be found under `pages` directory. - -With each commit you push to your configured GitLab repository, the webhook will call the extension to initiate a deployment if changes were made to these predefined directories. +With each commit you push to your configured GitLab repository, the webhook will call the extension to initiate a deployment if changes were made to one of these folders: +- `clients` +- `grants` +- `emails` +- `resource-servers` +- `connections` +- `database-connections` +- `rules-configs` +- `rules` +- `pages` -The **Deploy** button on the **Deployments** tab of the extension allows you to manually deploy the Rules, Pages and Database Connection scripts that you already have in your GitLab repository. This is useful if your repository already contains items that you want to deploy once you have set up the extension or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your repository. +The **Deploy** button on the **Deployments** tab of the extension allows you to manually deploy the Rules, Pages, and Database Connection scripts that you already have in your GitLab repository. This is useful if your repository already contains items that you want to deploy once you have set up the extension or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your repository. ::: panel-warning Full Deployment -To maintain a consistent state, the extension will always do a full deployment of the contents of these folders. **Any rules, pages or database connection scripts that exist in Auth0 but not in your GitHub repository will be deleted**. +To maintain a consistent state, the extension will always do a full deployment of the contents of these folders. **Any rules, pages, or database connection scripts that exist in Auth0 but not in your GitHub repository will be deleted**. + +To delete existing settings when AUTH0_ALLOW_DELETE is set to yes, corresponding folders must be present and contain configuration files; settings will not be deleted for missing folders or empty folders. We recommend setting up all configurations, since we are unable to provide data restores at this time. ::: -### Deploy Database Connection Scripts +### Deploy Database Connection scripts -To deploy Database Connection scripts, you must first create a directory under `database-connections`. The name of the directory must match **exactly** the name of your [database connection](${manage_url}/#/connections/database) in Auth0. You can create as many directories as you have Database Connections. +1. To deploy Database Connection scripts, you must first create a directory under `database-connections`. The name of the directory must match **exactly** the name of your [database connection](${manage_url}/#/connections/database) in Auth0. You can create as many directories as you have Database Connections. -Under the created directory, create one file for each script you want to use. The allowed scripts are: +2. Under the created directory, create one file for each script you want to use. The allowed scripts are: - `get_user.js` - `create.js` @@ -102,7 +124,41 @@ For a generic Custom Database Connection, only the `login.js` script is required You can find examples in [the Auth0 Samples repository](https://github.com/auth0-samples/github-source-control-integration/tree/master/database-connections/my-custom-db). While the samples were authored for GitHub, it will work for a GitLab integration as well. -### Deploy Hosted Pages +### Deploy Database Connection settings + +To deploy Database Connection settings, you must create `database-connections/[connection-name]/database.json`. + +_This will work only for Auth0 connections (`strategy === auth0`), for non-Auth0 connections use `connections`._ + +_Support for using `settings.json` has been deprecated in favor of `database.json` since v3.1.1 of the extension and may be dropped in a future release._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/patch_connections_by_id) for more info on allowed attributes for Connections. + + + +### Deploy Connections + +To deploy a connection, you must create a JSON file under the `connections` directory of your GitLab repository. Example: + +__facebook.json__ +```json +{ + "name": "facebook", + "strategy": "facebook", + "enabled_clients": [ + "my-client" + ], + "options": {} +} +``` + +<%= include('./_includes/_embedded-clients-array') %> + +_This will work only for non-Auth0 connections (`strategy !== auth0`); for Auth0 connections, use `database-connections`._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/post_connections) for more info on allowed attributes for Connections. + +### Deploy hosted pages The supported hosted pages are: - `error_page` @@ -110,14 +166,14 @@ The supported hosted pages are: - `login` - `password_reset` -To deploy a page, you must create an HTML file under the `pages` directory of your GitLab repository. For each HTML page you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, in order to deploy an `error_page`, you would create two files: +To deploy a page, you must create an HTML file under the `pages` directory of your GitLab repository. For each HTML page, you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, to deploy a `password_reset`, you would create two files: ```text -your-gitlab-repo/pages/error_page.html -your-gitlab-repo/pages/error_page.json +your-bitbucket-repo/pages/password_reset.html +your-bitbucket-repo/pages/password_reset.json ``` -To enable the page the `error_page.json` would contain the following: +To enable the page, the `password_reset.json` would contain the following: ```json { @@ -125,9 +181,11 @@ To enable the page the `error_page.json` would contain the following: } ``` -### Deploy Rules +<%= include('./_includes/_use-default-error') %> + +### Deploy rules -To deploy a rule, you must first create a JavaScript file under the `rules` directory of your GitLab repository. Each Rule must be in its own `.js` file. +To deploy a rule, you must first create a JavaScript file under the `rules` directory of your GitLab repository. Each Rule must be in its own JavaScript file. For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. @@ -135,10 +193,6 @@ For example, if you create the file `rules/set-country.js`, the extension will c If you plan to use source control integration for an existing account, first rename your Rules in Auth0 to match the name of the files you will be deploying to this directory. ::: -You can mark rules as manual. In that case, the source control extension will not delete or update them. To mark a rule navigate to the *Rules Configuration* tab of the **GitLab Integration** page. Toggle the **Manual Rule** switch for the rules you want to mark as manual. Click **Update Manual Rules** to save your changes. - -![Mark rules as manual](/media/articles/extensions/gitlab-deploy/manual-rule.png) - You can also control the Rule order and status (`enabled`/`disabled`) by creating a JSON file with the same name as your JavaScript file. For this example, you would create a file named `rules/set-country.json`. __set-country.js__ @@ -152,7 +206,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -162,19 +216,172 @@ __set-country.json__ You can find a `login_success` example in [the Auth0 Samples repository](https://github.com/auth0-samples/github-source-control-integration/tree/master/rules). While the sample was authored for GitHub, it will work for a GitLab integration as well. -#### Set Rule Order +#### Set rule order -To avoid conflicts, you are cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk for conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). +To avoid conflicts, you cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk of conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). -#### Set the Stage +#### Set the stage -After you deploy a Rule, you cannot change its stage, or the area where the Rule executes. +After you deploy a Rule, you cannot change its stage or the area where the Rule executes. If you need the rule to execute in a different stage, you must create a new Rule with the updated stage and delete the original Rule. -Please note that you may have only a single Rule for the `user_registration` and `login_failure` stages. +::: note +You may have only a single Rule for the `user_registration` and `login_failure` stages. +::: + +### Deploy Rules Configs + +To deploy a rule config, you must create a JSON file under the `rules-configs` directory of your GitLab repository. Example: + +__secret_number.json__ +```json +{ + "key": "secret_number", + "value": 42 +} +``` + +### Deploy Clients + +To deploy a client, you must create a JSON file under the `clients` directory of your GitLab repository. Example: + +__my-client.json__ +```json +{ + "name": "my-client" +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Clients/post_clients) for more info on allowed attributes for Clients and Client Grants. + +### Deploy Clients Grants + +You can specify the client grants for each client by creating a JSON file in the `grants` directory. + +__my-client-api.json__ +```json +{ + "client_id": "my-client", + "audience": "https://myapp.com/api/v1", + "scope": [ + "read:users" + ] +} +``` + +<%= include('./_includes/_deployment-extension') %> + +### Deploy Resource Servers + +To deploy a resource server, you must create a JSON file under the `resource-servers` directory of your GitLab repository. Example: + +__my-api.json__ +```json +{ + "name": "my-api", + "identifier": "https://myapp.com/api/v1", + "scopes": [ + { + "value": "read:users", + "description": "Allows getting user information" + } + ] +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Resource_Servers/post_resource_servers) for more info on allowed attributes for Resource Servers. + +### Deploy Email Provider + +To deploy an email provider, you must create `provider.json` file under the `emails` directory of your GitLab repository. Example: + +__provider.json__ +```json +{ + "name": "smtp", + "enabled": true, + "credentials": { + "smtp_host": "smtp.server.com", + "smtp_port": 25, + "smtp_user": "smtp_user", + "smtp_pass": "smtp_secret_password" + } +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Emails/patch_provider) for more info on allowed attributes for Email Provider. + +### Deploy Email Templates + +The supported email templates are: +- `verify_email` +- `reset_email` +- `welcome_email` +- `blocked_account` +- `stolen_credentials` +- `enrollment_email` +- `mfa_oob_code` + +To deploy an email template, you must create an HTML file under the `emails` directory of your GitLab repository. For each HTML file, you need to create a JSON file (with the same name) with additional options for that template. For example, to deploy a `blocked_account` template, you would create two files: + +```text +your-gitlab-repo/emails/blocked_account.html +your-gitlab-repo/emails/blocked_account.json +``` + +__blocked_account.json__ +```json +{ + "template": "blocked_account", + "from": "", + "subject": "", + "resultUrl": "", + "syntax": "liquid", + "body": "./blocked_account.html", + "urlLifetimeInSeconds": 432000, + "enabled": true +} +``` + +## Excluded records + +You can exclude the following records from the deployment process: `rules`, `clients`, `databases`, `connections` and `resourceServers`. If excluded, the records will not be modified by deployments. + +![](/media/articles/extensions/deploy-extensions/excluded-rules.png) + +## Keywords Mapping + +Beginning with version **3.0.0**, you can use keywords mapping to manage your secrets and tenant-based environment variables. + +There are two ways to use the keyword mappings. You can either wrap the key using `@` symbols (e.g., `@@key@@`), or you can wrap the key using `#` symbols (e.g., `##key##`). + + - If you use `@` symbols, your value will be converted from a JavaScript object or value to a JSON string. + + - If you use `#` symbols, Auth0 will perform a literal replacement. + +This is useful for something like specifying different variables across your environments. For example, you could specify different JWT timeouts for your Development, QA/Testing, and Production environments. + +Refer to the snippets below for sample implementations: + +__Client.json__ +```json +{ + ... + "callbacks": [ + "##ENVIRONMENT_URL##/auth/callback" + ], + "jwt_configuration": { + "lifetime_in_seconds": ##JWT_TIMEOUT##, + "secret_encoded": true + } + ... +} +``` + +![](/media/articles/extensions/deploy-extensions/mappings.png) -## Track Deployments +## Track deployments To track your deployments, navigate to the [Extensions](${manage_url}/#/extensions) page, click on the row for the **GitLab Deployments** extension, and select the **Deployments** tab. You will see a list of all deployments. diff --git a/articles/extensions/index.md b/articles/extensions/index.md index 1fe3f26f3d..fdfa06a1bd 100644 --- a/articles/extensions/index.md +++ b/articles/extensions/index.md @@ -1,62 +1,79 @@ --- description: Extensions enable you to install applications or run commands/scripts that extend the functionality of Auth0. toc: true +topics: + - extensions +contentType: + - index +useCase: extensibility-extensions --- # Auth0 Extensions -Auth0 Extensions enable you to install applications (such as [Webtasks](https://webtask.io/)) or run commands/scripts that extend the functionality of the Auth0 base product. +Auth0 Extensions enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. Each extension is separate from all other extensions. Auth0 defines extensions per tenant, so data is stored by the pair `tenant\extension`. -## Using an Extension +## Pre-defined extensions -Auth0 provides the following pre-defined extensions, and they are available for installation via the [Dashboard](${manage_url}). To use one or more of the following apps, you must provide the required configuration information and finish installing the extensions. +Auth0 provides a selection of pre-defined extensions, which you can install via the [Dashboard](${manage_url}/extensions). -![Auth0 Extensions](/media/articles/extensions/auth0-provided-extensions.png) +### Authorization -## What types of actions can I do with extensions? +- [Auth0 Authorization Extension](/extensions/authorization-extension): Manage authorizations for users with groups, roles, and permissions. We recommend that you use our [Authorization Core](/authorization/guides/how-to) feature set instead, which is being expanded to match the functionality of the Authorization Extension and improves performance and scalability. For a comparison, see [Authorization Core vs. Authorization Extension](/authorization/concepts/core-vs-extension). -### Manage the authorizations for Users using Groups, Roles and Permissions -- [Auth0 Authorization Extension](/extensions/authorization-extension) +- [Delegated Administration](/extensions/delegated-admin): Allow a select group of people to manage users without providing access to any other area of the Dashboard. -### Easily manage custom social connections -- [Custom Social Connections Extension](/extensions/custom-social-extensions) +### Connections + +- [Custom Social Connections Extension](/extensions/custom-social-extensions): Configure and manage custom social identity providers. + +- [Single Sign-on (SSO) Dashboard Extension](extensions/sso-dashboard): Create a Single Sign-on (SS0) dashboard that allows users to sign into any of multiple listed enterprise applications. + +### Manage users + +- [Users Import / Export](/extensions/user-import-export): Bulk import and export database users. + +### Extend and integrate + +Use your own custom webhooks in conjunction with Auth0 APIs: -### Go through the audit logs and call the appropriate webhook for specific API event triggers - [Auth0 Management API Webhooks](/extensions/management-api-webhooks) - [Auth0 Authentication API Webhooks](/extensions/authentication-api-webhooks) -### Test various endpoints of the Auth0 Authentication API +### Deployment and source control + +Keep history and deploy [rules](/rules), [database connection](/connections/database) scripts and other assets from external repositories: + +- [GitHub Deployments Extension](/extensions/github-deploy) +- [Bitbucket Deployments Extension](/extensions/bitbucket-deploy) +- [GitLab Deployments Extension](/extensions/gitlab-deploy) +- [Visual Studio Team Services Deployments Extension](/extensions/visual-studio-team-services-deploy) +- [Deploy CLI Tool Extension](/extensions/deploy-cli) + +### Troubleshoot + +Test Auth0 API endpoints: + - [Authentication API Debugger Extension](/extensions/authentication-api-debugger) -### Monitor your AD/LDAP connectors -- [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector) +### Monitor + +- [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector): Monitor your [AD/LDAP Connectors](/connector/overview). -### Import or Export existing users -- [Users Import / Export](/extensions/user-import-export) +- [Real-time Webtask Logs](/extensions/realtime-webtask-logs): Access real-time Webtask logs. + +### Logs export + +Export Auth0 logs to external services: -### Export Auth0 logs to an external service - [Auth0 Logs to Application Insights](/extensions/application-insight) +- [Auth0 Logs to AWS Cloudwatch](/extensions/cloudwatch) - [Auth0 Logs to Azure Blob Storage](/extensions/azure-blob-storage) +- [Auth0 Logs to Logentries](/extensions/logentries) - [Auth0 Logs to Loggly](/extensions/loggly) +- [Auth0 Logs to Logstash](/extensions/logstash) +- [Auth0 Logs to Mixpanel](/extensions/mixpanel) - [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) - -### Access to real-time webtask logs -- [Real-time Webtask Logs](/extensions/realtime-webtask-logs) - -### Expose the Users dashboard to a group of users without allowing them access to the dashboard -- [Delegated Administration](/extensions/delegated-admin) - -### Deploy hosted pages, rules, and database connections scripts from external repositories -- [GitHub Deployments Extension](/extensions/github-deploy) -- [Bitbucket Deployments Extension](/extensions/bitbucket-deploy) -- [GitLab Deployments Extension](/extensions/gitlab-deploy) -- [Visual Studio Team Services Deployments Extension](/extensions/visual-studio-team-services-deploy) -### Create a SSO dashboard with multiple enterprise applications -- [SSO Dashboard Extension](extensions/sso-dashboard) diff --git a/articles/extensions/logentries.md b/articles/extensions/logentries.md index 277e5be9eb..b7b7f7188a 100644 --- a/articles/extensions/logentries.md +++ b/articles/extensions/logentries.md @@ -1,5 +1,11 @@ --- description: How to enable and use the Logentries extension. +topics: + - extensions + - logentries +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Logentries @@ -14,13 +20,15 @@ To install and configure this extension, click on the _Auth0 Logs to Logentries_ At this point you should set the following configuration variables: - **Schedule**: The frequency with which logs should be exported. The schedule can be customized even further after creation. -- **BATCH_SIZE**: The ammount of logs to be read on each execution. Maximun is 100. +- **BATCH_SIZE**: The amount of logs to be read on each execution. Maximun is 100. - **LOGENTRIES_TOKEN**: The Logentries Token for your log set to which the Auth0 logs will be exported. - **LOG_LEVEL**: The minimal log level of events that you would like sent to Logentries. - **LOG_TYPES**: The events for which logs should be exported. If you want you can send only events with a specific type (for example, failed logins). Once you have provided this information, click the *Install* button to finish installing the extension. +<%= include('./_includes/_batch-size') %> + ## Retrieve the required information from Logentries In order to acquire the *LOGENTRIES_TOKEN* information, navigate to [Logentries](https://logentries.com) and login to your account or register for a new one. From the menu on the left select *Logs > Add New Log*. diff --git a/articles/extensions/loggly.md b/articles/extensions/loggly.md index fe5b0b24e2..d2d5f5d778 100644 --- a/articles/extensions/loggly.md +++ b/articles/extensions/loggly.md @@ -1,5 +1,11 @@ --- description: How to install and configure the Auth0 Logs to Loggly Extension. +topics: + - extensions + - loggly +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Loggly @@ -29,6 +35,8 @@ You can find the __Global Client ID__ and __Global Client Secret__ information a Once you have provided this information, click the *Install* button to finish installing the extension. +<%= include('./_includes/_batch-size') %> + ## Retrieve the required information from Loggly Let's see how we can retrieve the __Loggly_Customer_Token__ information. diff --git a/articles/extensions/logstash.md b/articles/extensions/logstash.md index ff1fa04426..ba02d1b161 100644 --- a/articles/extensions/logstash.md +++ b/articles/extensions/logstash.md @@ -1,5 +1,11 @@ --- description: How to install and configure the Auth0 Logs to Logstash extension. +topics: + - extensions + - logstash +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Logstash @@ -17,7 +23,7 @@ At this point you should set the following configuration variables: | Parameter | Description | |:-----------------|:------------| | **Schedule** | The frequency with which logs should be exported. The schedule can be customized even further after creation. | -| **BATCH_SIZE** | The ammount of logs to be read on each execution. Maximun, and default, is `100`. | +| **BATCH_SIZE** | The amount of logs to be read on each execution. Maximun, and default, is `100`. | | **LOGSTASH_URL**
      Required | Your Logstash URL as defined for use with `logstash-input-http` plugin. | | **LOGSTASH_INDEX**
      Required | Your Logstash Index to which the logs will be routed. | | **LOGSTASH_TOKEN** | The token required for your Logstash deployments that will be included in the querystring. | @@ -31,6 +37,12 @@ At this point you should set the following configuration variables: Once you have provided this information, click the _Install_ button to finish installing the extension. +<%= include('./_includes/_batch-size') %> + +### Using extension with ElasticSearch + +The extension is sending logs to the logstash instance as they are, including `_id`, which cannot be accepted by ElasticSearch. To fix that, you need rename `_id` to something else. You can do that by adding pipeline with `filter { mutate { rename => { "_id" => "log_id" } } }`. + ## Use the Extension To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}), click on the **Installed Extensions** link, and select the **Auth0 Logs to Logstash** line. @@ -45,7 +57,7 @@ You can view more details by clicking on the job you created. In this page you c ## Replay Logs -In the event of a Logstash failure or service interuption you can replay the logs starting from the failed log. +In the event of a Logstash failure or service interruption you can replay the logs starting from the failed log. To replay logs: diff --git a/articles/extensions/management-api-webhooks.md b/articles/extensions/management-api-webhooks.md index 88ed2f20b0..cb81a4d5e8 100644 --- a/articles/extensions/management-api-webhooks.md +++ b/articles/extensions/management-api-webhooks.md @@ -1,5 +1,11 @@ --- description: How to install and configure the Auth0 Management API Webhooks Extension. +topics: + - extensions + - management-api-webhooks +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Extension: Auth0 Management API Webhooks @@ -10,13 +16,16 @@ The Auth0 Management API Webhooks Extension allows you to use your own custom we To complete installation of this extension, click on the Auth0 Management API Webhooks box in the list of provided extensions on the Extensions page of the Management Portal. In the "Install Extension" window that then pops open, you will be asked to provide the following configuration variables: -- __Schedule__: The frequency with which the webhook runs; -- __Auth0_Domain__: The domain of your Auth0 app; -- __Auth0_Global_Client_ID__: The Auth0 Global Client ID; -- __Auth0_Global_Client_Secret__: The Auth0 Global Client Secret; -- __Auth0_API_Endpoints__: The specific Auth0 Management API endpoints you want to monitor/call; -- __Webhook URL__: The URL of your webhook; +- __Schedule__: The frequency with which the job runs +- __Batch_Size__: The amount of logs the extension will attempt to read and send on each execution. Extension could send multiple batches per run, depending on amount of time necessary to process. +- __Auth0_API_Endpoints__: The specific Auth0 Management API endpoints you want to monitor/call +- __Webhook_URL__: The URL of your webhook +- __Authorization__: String to be added as `Authorization` header. +- __Send_as_Batch__: If enabled, the extension will send the whole batch of logs to the webhook in a single request. Otherwise, extension sends logs one-by-one to webhook. Only disable if your webhook does not support batched messages. - __Webhook_Concurrent_Calls__: The maximum number of concurrent calls that will be made to your webhook. +- __Start_From__: Log Checkpoint to start from. +- __Slack_Incoming_Webhook_URL__: Extension can report statistics and possible failures to the Slack. +- __Slack_Send_Success__: If enabled, extension will be sending messages on each run. Otherwise - only on fails. Once you have provided the required pieces of information, click "Install" to finish installing the extension. @@ -74,4 +83,4 @@ Here is an example of the payload that will be sent: } ``` -<%= include('./_troubleshoot-webhooks') %> \ No newline at end of file +<%= include('./_troubleshoot-webhooks') %> diff --git a/articles/extensions/mixpanel.md b/articles/extensions/mixpanel.md index 3c5d4254b4..681af41310 100644 --- a/articles/extensions/mixpanel.md +++ b/articles/extensions/mixpanel.md @@ -1,42 +1,53 @@ --- description: How to configure and use the Auth0 Logs to Mixpanel extension. +topics: + - extensions + - mixpanel +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Mixpanel The Auth0 Logs to Mixpanel is a scheduled job that takes all of your Auth0 logs and exports them to [Mixpanel](https://mixpanel.com). -## Configuring the Extension +## Step 1: Get the required information from Mixpanel -To install and configure this extension, click on the **Auth0 Logs to Mixpanel** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [Auth0 Dashboard](${manage_url}). The **Install Extension** window pops open. +First you need to get some required information from Mixpanel: the Token and API Key that Auth0 will use to connect and push logs. -![](/media/articles/extensions/mixpanel/extension-mgmt-mixpanel.png) +1. Go to [Mixpanel](https://mixpanel.com) +1. Click on your [Account Settings](https://mixpanel.com/account/) +1. Click on the **Projects** tab +1. Copy the **Token** and **API Key** information. These map respectively to the **MIXPANEL_TOKEN** and **MIXPANEL_KEY** variables that you will set in the next step -At this point you should set the following configuration variables: +![Get keys from Mixpanel](/media/articles/extensions/mixpanel/mixpanel-project-info.png) + +## Step 2: Configure Auth0 + +Go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on the **Auth0 Logs to Mixpanel** box in the list of provided extensions. + +The **Install Extension** window pops open. + +![Install Auth0 Extension](/media/articles/extensions/mixpanel/extension-mgmt-mixpanel.png) + +Set the following configuration variables: - **Schedule**: The frequency with which logs should be exported. The schedule can be customized even further after creation. - **MIXPANEL_TOKEN**: The Mixpanel Token for your mixpanel project to which the Auth0 logs will be exported. - **MIXPANEL_KEY**: The Mixpanel API Key for your mixpanel project to which the Auth0 logs will be exported. -- **BATCH_SIZE**: The ammount of logs to be read on each execution. Maximun is 20. +- **BATCH_SIZE**: The amount of logs to be read on each execution. Maximum is 20. - **LOG_LEVEL**: The minimal log level of events that you would like sent to Mixpanel. - **LOG_TYPES**: The events for which logs should be exported. If you want you can send only events with a specific type (for example, failed logins). Once you have provided this information, click the **Install** button to finish installing the extension. -## Retrieve the required information from Mixpanel - -In order to acquire the **MIXPANEL_TOKEN** and **MIXPANEL_KEY** information, navigate to [Mixpanel](https://mixpanel.com) and click on your [Account Settings](https://mixpanel.com/account/). Click on the **Projects** tab. You now need to copy the **Token** and **API Key** information. These map respectively to the **MIXPANEL_TOKEN** and **MIXPANEL_KEY** variables. - -![](/media/articles/extensions/mixpanel/mixpanel-project-info.png) - -## Using Your Installed Extension - -To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Auth0 Dashboard](${manage_url}), click on the **Installed Extensions** link, and select the **Auth0 Logs to Mixpanel** line. There you can see the job you just created, modify its state by toggling the **State** switch, see when the next run is due and what was the result of the last execution. +<%= include('./_includes/_batch-size') %> -![](/media/articles/extensions/mixpanel/view-cron-jobs.png) +## Use your extension -You can view more details by clicking on the job you created. In this page you can view details for each execution, reschedule, access realtime logs, and more. +To view all jobs, navigate to [Dashboard > Extensions](${manage_url}/#/extensions), click on the **Installed Extensions** link, and select the **Auth0 Logs to Mixpanel** line. There you can see the alls job and failed jobs. You can also view the logs of these runs. -![](/media/articles/extensions/mixpanel/view-cron-details.png) +You can create a cron webtask (that will run every 10 minutes) or view more details around existing cron webtasks. In the terminal, you can view details for each execution, reschedule, access realtime logs, and more. That's it, you are done! You can now navigate to [Mixpanel](https://mixpanel.com) and view your [Auth0 Logs](${manage_url}/#/logs). diff --git a/articles/extensions/papertrail.md b/articles/extensions/papertrail.md index b38c4951d0..d8aef88e25 100644 --- a/articles/extensions/papertrail.md +++ b/articles/extensions/papertrail.md @@ -1,5 +1,11 @@ --- description: How to configure and retrieve information from the Auth0 Logs to Papertrail extension. +topics: + - extensions + - papertrail +contentType: + - how-to +useCase: extensibility-extensions --- # Auth0 Logs to Papertrail @@ -12,35 +18,33 @@ To install and configure this extension, click on the _Auth0 Logs to Papertrail_ ![](/media/articles/extensions/papertrail/extension-mgmt-papertrail.png) -At this point you should set the following configuration variables: +At this point, you should set the following configuration variables: - **Schedule**: The frequency with which logs should be exported. The schedule can be customized even further after creation. -- **BATCH_SIZE**: The ammount of logs to be read on each execution. Maximun is 100. +- **BATCH_SIZE**: The number of logs per batch (up to a maximum of 100). Note that logs are batched before sending, with multiple batches sent each time the extension runs. +- **START_FROM**: The Checkpoint ID of the log from which you want the extension to start sending. +- **SLACK_INCOMING_WEBHOOK_URL**: The Incoming Webhook URL used to report statistics and events to your Slack account/channel. +- **SLACK_SEND_SUCCESS**: If yes, enables verbose notifications to Slack. Useful for troubleshooting. +- **LOG_LEVEL**: The minimal log level of events that you would like sent to Papertrail. +- **LOG_TYPES**: The events for which logs should be exported. - **PAPERTRAIL_HOST**: The destination hostname for your logs. - **PAPERTRAIL_PORT**: The destination port for your logs. - **PAPERTRAIL_SYSTEM**: The destination system for your logs. -- **LOG_LEVEL**: The minimal log level of events that you would like sent to Papertrail; -- **LOG_TYPES**: The events for which logs should be exported. Once you have provided this information, click the *Install* button to finish installing the extension. -## Retrieve the required information from Papertrail - -In order to configure a new system for Auth0 logs and acquire the *PAPERTRAIL_HOST* and *PAPERTRAIL_PORT* information, follow the next steps: -1. Login to [Papertrail](https://papertrailapp.com) and navigate to your [Dashboard](https://papertrailapp.com/dashboard). -2. Click the *Add Systems* button. +<%= include('./_includes/_batch-size') %> -![](/media/articles/extensions/papertrail/papertrail-new-system-01.png) +## Retrieve the required information from Papertrail -3. Your log destination is created! Copy the URL and Port information displayed with the message *Your systems & apps will log to*. These map respectively to the *PAPERTRAIL_HOST* and *PAPERTRAIL_PORT* variables. +To configure a new system for Auth0 logs and acquire the *PAPERTRAIL_HOST* and *PAPERTRAIL_PORT* information: -![](/media/articles/extensions/papertrail/papertrail-new-system-02.png) +1. Login to [Papertrail](https://papertrailapp.com). You'll be directed to the **quick start and tour** page. +2. Click the *Add your first system* button. -If you already have a system you want to use, follow the next steps: -1. Login to [Papertrail](https://papertrailapp.com) and navigate to your [Settings > Log Destinations](https://papertrailapp.com/account/destinations). -2. Locate the system you want to use and copy the URL and Port information. These map respectively to the *PAPERTRAIL_HOST* and *PAPERTRAIL_PORT* variables. +You'll get redirected again, and at the top of the page, you will see a message that says something like **Your logs will go to logs4.papertrailapp.com:12345 and appear in Events.**. The log destination displayed is where your logs will go. The log and port information map to the *PAPERTRAIL_HOST* (i.e., `logs4.papertrailapp.com`) and *PAPERTRAIL_PORT* (i.e., `12345`) variables Auth0 asked for, respectively. -![](/media/articles/extensions/papertrail/papertrail-existing-system.png) +Per Papertrail, "no explicit configuration is required...just start sending logs. When Papertrail receives a message from a hostname that is not already present in your account, the system will be automatically added." ## Using Your Installed Extension @@ -48,16 +52,12 @@ If you already have a system you want to use, follow the next steps: ![](/media/articles/extensions/papertrail/view-cron-jobs.png) -You can view more details by clicking on the job you created. In this page you can view details for each execution, reschedule, access realtime logs, and more. +You can view more details by clicking on the job you created. In this page, you can view details for each execution, reschedule, access realtime logs, and more. ![](/media/articles/extensions/papertrail/view-cron-details.png) -That's it, you are done! You can now navigate to [Papertrail](https://papertrailapp.com) and view your [Auth0 Logs](${manage_url}/#/logs), by selecting the configured system. - -![](/media/articles/extensions/papertrail/auth0-logs-at-papertrail-01.png) +That's it, you are done! You can now navigate to [Papertrail](https://papertrailapp.com) and view your [Auth0 Logs](${manage_url}/#/logs) under **Events**. ::: note -You may have noticed that we didn't set a value for *PAPERTRAIL_SYSTEM*. This variable, when not set by the user, takes the default value of `auth0-logs`. As you can see in the previous screenshot, this is how our system will be displayed in the Papertrail dashboard. +You may have noticed that we didn't set a value for *PAPERTRAIL_SYSTEM*. This variable, when not set by the user, takes the default value of `auth0-logs`. This is how Auth0's logs will be displayed and referred to in the Papertrail dashboard. ::: - -![](/media/articles/extensions/papertrail/auth0-logs-at-papertrail-02.png) diff --git a/articles/extensions/realtime-webtask-logs.md b/articles/extensions/realtime-webtask-logs.md index 5cd0e514c2..7aa762f9c7 100644 --- a/articles/extensions/realtime-webtask-logs.md +++ b/articles/extensions/realtime-webtask-logs.md @@ -1,12 +1,18 @@ --- description: How to configure, use debug rules using the Real-time Webtask Logs extension. +topics: + - extensions + - realtime-webtask-logs +contentType: + - how-to +useCase: extensibility-extensions --- # Real-time Webtask Logs -_Real-time Webtask Logs_ is an extension that displays all logs in real-time for all custom code in your account. This includes all `console.log` output and exceptions. +_Real-time Webtask Logs_ is an extension that displays all logs in real-time for the custom code in your account. This includes all `console.log` output and exceptions. -## Configuring the Extension +## Configuring the extension To install and configure this extension, click on the _Real-time Webtask Logs_ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}). The _Install Extension_ window pops open. @@ -14,15 +20,23 @@ To install and configure this extension, click on the _Real-time Webtask Logs_ b Click the _Install_ button. -## Using Your Installed Extension +## Using your installed extension To view your installed extension, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}), click on the _Installed Extensions_ link, and select the _Real-time Webtask Logs_ line. You can view the logs in full screen by selecting the _FULL SCREEN MODE_ button. Press `Escape` to exit full screen mode. ![](/media/articles/extensions/realtime-webtask-logs/view-realtime-logs.png) -To clear the logs and start fresh select the the red _CLEAR CONSOLE_ button at the bottom right. +To clear the logs and start fresh select the red _CLEAR CONSOLE_ button at the bottom right. -## Debugging Rules +## Secure logging + +Because the Webtask Logs extension uses the users request, logging sensitive information is a concern of which you should be mindful. + +For example, your custom database scripts work with the `user` object extensively. The `user` object may contain sensitive information, and logging the complete object may lead to its disclosure to the Webtask Logs extension. + +Obviously, Auth0 strongly discourages such practices. These actions could lead to the disclosure of your users' sensitive information. **We caution you to be aware of the objects that you log and to ensure sensitive information is not logged** + +## Debugging rules The _Real-time Webtask Logs_ extension can be used to debug any [Rules](/rules) in your implementation. This includes all `console.log` output and exceptions. Let's follow a simple _hello world_ example. @@ -42,8 +56,6 @@ You are now ready to run this rule. Before you do so, open a new tab and navigat ![](/media/articles/extensions/realtime-webtask-logs/view-rules-example.png) -That's it, you are done! - ## Additional Information - [Rules debugging](/rules#debugging) - [Real-time Auth0 Webtask Logs GitHub repository](https://github.com/auth0/auth0-extension-realtime-logs) diff --git a/articles/extensions/segment.md b/articles/extensions/segment.md new file mode 100644 index 0000000000..3c47b20290 --- /dev/null +++ b/articles/extensions/segment.md @@ -0,0 +1,54 @@ +--- +description: How to install and configure the Auth0 Logs to Segment Extension. +topics: + - extensions + - segment +contentType: + - how-to +useCase: extensibility-extensions +--- +# Auth0 Logs to Segment + +The *Auth0 Logs to Segment* is a scheduled job that takes all of your Auth0 logs and exports them to [Segment](https://www.segment.com/). + +## Configure the Extension + +To install and configure this extension, click on the __Auth0 Logs to Segment__ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [dashboard](${manage_url}). The __Install Extension__ window pops open. + +At this point you should set the following configuration variables: + +| Parameter | Description | +|:-----------------|:------------| +| **Schedule** | The frequency with which logs should be exported. The schedule can be customized even further after creation. | +| **BATCH_SIZE** | The amount of logs to be read on each execution. Maximun, and default, is `100`. | +| **START_FROM** | The checkpoint ID of the log from where you want to start. | +| **SLACK_INCOMING_WEBHOOK** | The Slack incoming webhook URL used to send relevant updates. | +| **SLACK_SEND_SUCCESS** | Toggle for sending verbose notifications to Slack. | +| **SEGMENT_KEY** | Your segment key. | + +Once you have provided this information, click the _Install_ button to finish installing the extension. + +<%= include('./_includes/_batch-size') %> + +## Use the Extension + +You can monitor activity by logging into the extension. There you can find reports on most recent runs. Reports contains amount of logs processed and errors, if any. + +## Replay Logs + +In the event of a Segment failure or service interruption you can replay the logs starting from the failed log. + +To replay logs: + +1. Get the checkpoint ID of the failed log. +2. Go to the Auth0 Logs to Segment extension settings. +3. Enter the checkpoint in the **START_FROM** field. +4. Click the **Save** button to replay the failed logs. + +## Slack Integration + +To set up [Slack](https://slack.com/) integration, provide an [Incoming Webhook URL](https://api.slack.com/incoming-webhooks) to the **SLACK_INCOMING_WEBHOOK** field in the Auth0 Logs to Segment [extension settings](${manage_url}/#/extensions). + +The extension sends failed transaction notifications to Slack with the checkpoint code displayed in the message. You can also enable verbose notifications by turning on the `SLACK_SEND_SUCCESS` setting. + +![Slack Message](/media/articles/extensions/logstash/slack-message.png) diff --git a/articles/extensions/splunk.md b/articles/extensions/splunk.md index ddf68bbc81..62facb383e 100644 --- a/articles/extensions/splunk.md +++ b/articles/extensions/splunk.md @@ -1,8 +1,14 @@ --- -description: How to configure and retrieve information using the Auth0 Logs to Splunk extension. +description: Learn how to configure and retrieve information using the Auth0 Logs to Splunk extension. +topics: + - extensions + - splunk +contentType: + - how-to +useCase: extensibility-extensions --- -# Auth0 Logs to Splunk +# Export Logs to Splunk Using the Auth0 Extension The _Auth0 Logs to Splunk_ is a scheduled job that takes all of your Auth0 logs and exports them to [Splunk](http://www.splunk.com/). @@ -15,16 +21,19 @@ To install and configure this extension, click on the _Auth0 Logs to Splunk_ box At this point you should set the following configuration variables: - **Schedule**: How often the job will run. The schedule can be customized even further after creation. +- **START_FROM**: The checkpoint ID of the log from where you want to start. The value will be the log id (GUID). - **SPLUNK_URL**: Your Splunk Cloud URL. - **SPLUNK_TOKEN**: Your Splunk Token. - **SPLUNK_COLLECTOR_PORT**: The Port of your HTTP Collector Endpoint. - **SPLUNK_COLLECTOR_PATH**: The [HTTP Collector Endpoint](http://dev.splunk.com/view/event-collector/SP-CAAAE7H) to be used. If you use the `/raw` endpoint, make sure to append a channel as a querystring parameter, like this: `/services/collector/raw?channel=FE0ECFAD-13D5-401B-847D-77833BD77131`. More information can be found in the [Splunk documentation](http://dev.splunk.com/view/event-collector/SP-CAAAE8Y). -- **BATCH_SIZE**: The ammount of logs to be read on each execution. Maximun is 100. +- **BATCH_SIZE**: The amount of logs to be read on each execution. Maximum is 100. - **LOG_LEVEL**: The minimal log level of events that you would like sent to Splunk. - **LOG_TYPES**: The events for which logs should be exported. Once you have provided this information, click the *Install* button to finish installing the extension. +<%= include('./_includes/_batch-size') %> + ## Retrieve the required information from Splunk The HTTP Event Collector (HEC) is an endpoint that lets you send application events into Splunk Enterprise using the HTTP or Secure HTTP (HTTPS) protocols. In order to configure a new HTTP Event Collector for Auth0 logs and acquire the URL, Token and Port information, follow the next steps: @@ -65,7 +74,7 @@ curl -k https://:8088/services/collector -H 'Authorization: Splunk The `` value is based on your _Splunk Cloud URL_. When creating requests to Splunk Cloud, you must add a prefix to the URI of the hostname according to your subscription. For self-service Splunk Cloud plans, pre-pend the hostname with `input-`. For all other Splunk Cloud plans, pre-pend the hostname with `http-inputs-`. For this example we have subscribed for a self-service Splunk Cloud plan, so we will use the `input-` prefix. You can find more details [here](http://dev.splunk.com/view/event-collector/SP-CAAAE7F). ::: -As a response you should receive the followins JSON: +As a response you should receive the following JSON: ```json { diff --git a/articles/extensions/sso-dashboard.md b/articles/extensions/sso-dashboard.md index 3e61af5cdc..3d732fd70d 100644 --- a/articles/extensions/sso-dashboard.md +++ b/articles/extensions/sso-dashboard.md @@ -1,135 +1,45 @@ --- -title: "Auth0 Extension: Single Sign-On (SSO) Dashboard" -description: This page explains how to configure and utilize the SSO Dashboard Extension. -toc: true +description: Understand how the SSO Dashboard Extension enables you to manage SSO login for your users on multiple enterprise applications. +classes: topic-page +topics: + - extensions + - sso-dashboard + - sso +contentType: + - concept +useCase: + - extensibility-extensions + - setup-multiple-applications + - setup-sso-dashboard --- -# Auth0 Extension: Single Sign-On (SSO) Dashboard +# Auth0 Single Sign-On Dashboard Extension -The **SSO Dashboard** extension allows you to create a dashboard with multiple enterprise applications that can be enabled for single sign-on for your users for login. +The **Single Sign-on (SSO) Dashboard** is a web application designed to solve a problem familiar to many people. Organizations of all sizes maintain a variety of different applications to handle various business functions like accounting, HR, development, support, etc. Remembering usernames and passwords and login URLs for all of your applications can be cumbersome. With this extension, you can simplify the authentication experience by enabling SSO login for your users on multiple enterprise applications. It allows you to create a list of all the cloud services for which a user can authenticate with SSO logins. -The SSO dashboard supports two types of users: -**Users**- who will login to the dashboard to then select an application to sign into with SSO. -**Admins**- can login to configure the applications that are visible to the users. This guide is intended for Dashboard Admins. +::: note +A user should not be able to access, from the dashboard or otherwise, the service provider without having appropriate permissions (groups/roles) to do so. Ideally, these users would not see any service provider they are not granted access to on the dashboard. +::: -[View this Extension on GitHub](https://github.com/auth0-extensions/auth0-sso-dashboard-extension) +The SSO Dashboard supports two types of users: +- **Users** who can login to the dashboard to select an application to sign into with SSO. +- **Admins** who can configure applications visible to the users. -## Create an application +To setup and configure this extension, do the following steps: -Let's start with creating a new application. Navigate to [Applications](${manage_url}/#/applications) and click on the **+Create Application** button. Set a name and choose **Single Page Web Applications** application type. Click on **Create**. - -![](/media/articles/extensions/sso-dashboard/create-client.png) - -Click on the *Settings* tab and set the **Allowed Callback URLs**. This varies based on your location. - -The login URL for **Admins**: - -| Location | Allowed Callback URL | -| --- | --- | -| USA | `https://${account.tenant}.us.webtask.io/auth0-sso-dashboard/admins/login` | -| Europe | `https://${account.tenant}.eu.webtask.io/auth0-sso-dashboard/admins/login` | -| Australia | `https://${account.tenant}.au.webtask.io/auth0-sso-dashboard/admins/login` | - -The login URL for **Users**: - -| Location | Allowed Callback URL | -| --- | --- | -| USA | `https://${account.tenant}.us.webtask.io/auth0-sso-dashboard/login` | -| Europe | `https://${account.tenant}.eu.webtask.io/auth0-sso-dashboard/login` | -| Australia | `https://${account.tenant}.au.webtask.io/auth0-sso-dashboard/login` | - -Copy the **Client ID** value. - -Navigate to *Settings > Show Advanced Settings > OAuth* and paste the **Client ID** value to the **Allowed APPs / APIs** field. - -Set the **JsonWebToken Signature Algorithm** to *RS256*. - -![](/media/articles/extensions/delegated-admin/set-rs256.png) - -Save your changes. - -### Application connections - -By default all the connection types are enabled for users to be able to login into the SSO Dashbboard. If you would like to change this, navigate to the *Connections* tab for the Application. - -## Install the extension - -We are now ready to setup our new extension. But first, head back to your newly created Application and copy the **Client ID** value. - -To install and configure this extension, click on the **SSO Dashboard** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the dashboard. The **Install Extension** window will open. - -![Install SSO Dashboard Extension](/media/articles/extensions/sso-dashboard/install-extension.png) - -Set the following configuration variables: - -- **EXTENSION_CLIENT_ID**: This is the **Client ID** of the application you have created in the [Applications](${manage_url}/#/applications) that you wish to use this extension with. -- **TITLE**: This the custom title that will appear at the top of the SSO Dashboard page. -- **CUSTOM_CSS** *Optional*: This field that can contain a link to custom CSS you can use to style the look of your SSO Dashboard page. - -Once you have provided this information, click **INSTALL**. - -If you navigate back to the [Applications](${manage_url}/#/applications) view, you will see that there has been an additional application created. - -![New created Application](/media/articles/extensions/sso-dashboard/new-client.png) - -The `auth0-sso-dashboard` application is created automatically when you install the extension. It's an application authorized to access the [Management API](/api/management/v2) and you shouldn't modify it. - -## Use the extension - -Navigate to the [Extensions](${manage_url}/#/extensions) page and click on the **Installed Extensions** tab. - -Click on the row for the **SSO Dashboard** extension. The first time you click on your installed extension, you will be asked to grant it the required permissions. - -Once you agree, you will be directed to your custom **SSO Dashboard** page, which will have the **TITLE** you provided at the top of the page, and if you provided a custom CSS file that styling will be applied. - -![Your Custom SSO Dashboard](/media/articles/extensions/sso-dashboard/dashboard.png) - -To login into the dashboard: - -For **Admins** use `https://${account.tenant}..webtask.io/auth0-sso-dashboard/admins/login` or through the Dashboard. - -For **Users** use `https://${account.tenant}..webtask.io/auth0-sso-dashboard/login`. - -### Add a new application - -To add a new application to your dashboard to be used for single sign-on, go to the **Settings** page of the dashboard by clicking on the link on the upper right corner of the page and click **Settings** from the dropdown. - -Then click on the **CREATE APP** button to add a new application. - -![Dashboard Settings](/media/articles/extensions/sso-dashboard/settings.png) - -You will then need to enter the following fields for the new application: - -* **Type**: This field is a dropdown where you select the either SAML, OpenID-Connect, or WS-Federation depending on the type of application. -* **Application**: This is the application name of the application you have created that you wish to associate the login of users. -* **Name**: The name of the new application you are adding. -* **Logo**: Enter the url of the logo you wish to user as an icon for the application. -* **Callback**: This is one of the **Allowed Callback URLs** under your [Application Settings](${manage_url}/#/applications) of the application. -* **Connection** *Optional*: Select the connection type from the dropdown. You can add/edit your available connection types in the [Connections section of the Auth0 Management dashboard](${manage_url}/#/connections/database). If a connection is not set and the user is not logged, the user will see the Auth0 Login page. -* **Enabled**: Select this checkbox for this application to be visible (published) to your users. - -![Create a new application](/media/articles/extensions/sso-dashboard/new-app.png) - -Once completed click the **CREATE** button. - -Your new application will then appear on the **Applications** page of the SSO dashboard with any other applications that have been created. - -![SSO Dashboard Applications](/media/articles/extensions/sso-dashboard/dashboard-apps.png) - -You can click on an application here to test the connection. - -### Update an existing application - -To edit an existing application go to the **Settings** page of the dashboard by clicking on the link on the upper right corner of the page and click **Settings** from the dropdown. - -You can change whether users can see the application (if it is enabled) with the **Publish** or **Unpublish** buttons. - -You can delete an application with the **X** button, a confirmation box will popup to confirm the deletion. - -To update an application's settings, click the gear icon. - -![Change Application Settings](/media/articles/extensions/sso-dashboard/change-settings.png) - -Here you can change any of your application settings, or delete an application. +<%= include('../_includes/_topic-links', { links: [ + 'dashboard/guides/extensions/sso-dashboard-create-app', + 'dashboard/guides/extensions/sso-dashboard-install-extension', + 'dashboard/guides/extensions/sso-dashboard-add-apps', + 'dashboard/guides/extensions/sso-dashboard-update-apps', +] }) %> +## Keep reading +- [View this Extension on GitHub](https://github.com/auth0-extensions/auth0-sso-dashboard-extension) +- [Troubleshoot Extensions](/extensions/troubleshoot) +- [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) diff --git a/articles/extensions/sumologic.md b/articles/extensions/sumologic.md index 7d2037cf3d..5e6a1cef8e 100644 --- a/articles/extensions/sumologic.md +++ b/articles/extensions/sumologic.md @@ -1,75 +1,99 @@ --- description: How to configure and retrieve information using the Auth0 Logs to Sumo Logic extension. +topics: + - extensions + - sumologic +contentType: + - how-to +useCase: extensibility-extensions +toc: true --- # Auth0 Logs to Sumo Logic -The _Auth0 Logs to Sumo Logic_ is a scheduled job that takes all of your Auth0 logs and exports them to [Sumo Logic](https://www.sumologic.com/). +The Auth0 Logs to Sumo Logic is a scheduled job that takes all of your Auth0 logs and exports them to [Sumo Logic](https://www.sumologic.com/). This document will guide you through the process of setting up this integration. -## Configuring the Extension +## Step 1: Create a Sumo Logic HTTP endpoint -To install and configure this extension, click on the _Auth0 Logs to Sumo Logic_ box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}). The _Install Extension_ window pops open. +1. Login to [Sumo Logic](https://www.sumologic.com/) and from the top menu select **Manage > Setup Wizard**. -![](/media/articles/extensions/sumologic/extension-mgmt-sumologic.png) +![Start the Sumo Logic setup wizard](/media/articles/extensions/sumologic/sumologic-setup-wizard.png) -At this point you should set the following configuration variables: +2. On the next screen click **Set Up Streaming Data**. -- **Schedule**: The frequency with which logs should be exported. The schedule can be customized even further after creation. -- **BATCH_SIZE**: The ammount of logs to be read on each execution. Maximun is 100. -- **SUMOLOGIC_URL**: Your Sumo Logic HTTP Collector Endpoint. -- **LOG_LEVEL**: The minimal log level of events that you would like sent to Sumo Logic. -- **LOG_TYPES**: The events for which logs should be exported. +3. At the **Select Data Type** page, select **Your Custom App**. + +![Select data type](/media/articles/extensions/sumologic/sumologic-data-type.png) + +4. Select **HTTP Source** as the way to collect the logs. + +![Select HTTP source](/media/articles/extensions/sumologic/sumologic-setup-collection.png) + +5. Modify the **Source Category** and select a time zone for your log file. Click **Continue**. -Once you have provided this information, click the *Install* button to finish installing the extension. +6. You should now be provided with a URL. This is the **HTTP Source** that Sumo Logic configured for you. Copy the value and click **Continue**. Exit the setup wizard. -## Retrieve the required information from Sumo Logic +![Get the HTTP source](/media/articles/extensions/sumologic/sumologic-http-source.png) -In order to configure a new system for Auth0 logs and acquire the *SUMOLOGIC_URL* information, follow the next steps: -1. Login to [Sumo Logic](https://www.sumologic.com/) and from the top menu select _Manage > Setup Wizard_. +7. Now head back to the Auth0 Dashboard to set the value you copied as the value for **SUMOLOGIC_URL**. -![](/media/articles/extensions/sumologic/sumologic-setup-wizard.png) +## Step 2: Configure the Extension -2. On the next screen click _Set Up Streaming Data_. -3. At the _Select Data Type_ page, select _Your Custom App_. +To install and configure this extension, go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on the **Auth0 Logs to Sumo Logic** box. -![](/media/articles/extensions/sumologic/sumologic-data-type.png) +The **Install Extension** window pops open. + +![Install Auth0 extension](/media/articles/extensions/sumologic/extension-mgmt-sumologic.png) + +At this point you should set the following configuration parameters: + +- **Schedule**: The frequency with which logs should be exported. The schedule can be customized even further after creation. +- **BATCH_SIZE**: Logs are batched before sending. Multiple batches are sent each time the extension runs. Specify the number of logs per batch. Maximum is `100`. +- **SUMOLOGIC_URL**: Your Sumo Logic HTTP Collector Endpoint. Set the value you copied at the previous step. +- **LOG_LEVEL**: The minimal log level of events that you would like sent to Sumo Logic. +- **LOG_TYPES**: The events for which logs should be exported. +- **START_FROM**: The `log_id` of the log you would like to start sending from. Default is to start with the oldest available log. +- **SLACK_INCOMING_WEBHOOK_URL**: Send reports from the extension to the specific Slack webhook. +- **SLACK_SEND_SUCCESS**: Send even more stuff to Slack. Useful for troubleshooting. -4. Select _HTTP Source_ as the way to collect the logs. +Once you have provided this information, click the **Install** button to finish installing the extension. -![](/media/articles/extensions/sumologic/sumologic-setup-collection.png) +The integration between Auth0 and Sumo Logic is now in place! -5. Modify the _Source Category_ and select a time zone for your log file. Click Continue. -6. You should now be provided with a URL. This is the _HTTP Source_ that Sumo Logic configured for you. Copy the value and click _Continue_. Exit the setup wizard. +<%= include('./_includes/_batch-size') %> -![](/media/articles/extensions/sumologic/sumologic-http-source.png) +## How to view the results -7. Now head back to the Auth0 Dashboard and set the value you copied as the value for **SUMOLOGIC_URL**. +The integration you just setup, created a scheduled job that will be responsible to export the logs. -## Using Your Installed Extension +To view this scheduled job: +- Go to [Dashboard > Extensions](${manage_url}/#/extensions) +- Click on the **Installed Extensions** link +- Select the **Auth0 Logs to Sumo Logic** line. - To view all scheduled jobs, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}), click on the *Installed Extensions* link, and select the *Auth0 Logs to Sumo Logic* line. There you can see the job you just created, modify its state by toggling the *State* switch, see when the next run is due and what was the result of the last execution. +There you can see the job you just created, modify its state by toggling the **State** switch, see when the next run is due and what was the result of the last execution. -![](/media/articles/extensions/sumologic/view-cron-jobs.png) +![View scheduled job](/media/articles/extensions/sumologic/view-cron-jobs.png) You can view more details by clicking on the job you created. In this page you can view details for each execution, reschedule, access realtime logs, and more. -![](/media/articles/extensions/sumologic/view-cron-details.png) +![View job details](/media/articles/extensions/sumologic/view-cron-details.png) That's it, you are done! You can now navigate to [Sumo Logic](https://www.sumologic.com/) and view your [Auth0 Logs](${manage_url}/#/logs), by selecting the configured system. -![](/media/articles/extensions/sumologic/auth0-logs-at-sumologic.png) +![View Auth0 logs in Sumo Logic screen](/media/articles/extensions/sumologic/auth0-logs-at-sumologic.png) -## Auth0 Dashboard +## Use the Auth0 Dashboard Here, at Auth0, we have been using the Auth0 to Sumo Logic extension ourselves since it was first released, and it's proven to be very useful for staying on top of what's happening with our own Auth0 accounts and our internal users. Sumo Logic makes it easy to see the latest failed logins, find and alert on error messages, create charts to visualize trends, or even do complex statistical analysis on your data. To help us (and our customers) visualize these logs, we spent some time creating a dashboard. The Sumo Logic for Auth0 dashboard shows you the output of several saved searches all on one easy to read screen, and makes it easy to zoom in or drill down when something looks interesting. -![](/media/articles/extensions/sumologic/auth0-dashboard.png) +![Sumo Logic Dashboard](/media/articles/extensions/sumologic/auth0-dashboard.png) If you're a Sumo Logic customer and are interested in trying out this dashboard, you can find details on installing the Auth0 App for the Sumo Logic extension here: -[Install the Auth0 App](https://help.sumologic.com/Send_Data/Data_Types/Auth0/02Install_the_Auth0_App) +[Install the Auth0 App](https://help.sumologic.com/07Sumo-Logic-Apps/20SAML/Auth0/Auth0-App-Dashboards) Once it's available through your account, you're free to customize it, add to it, create alerts based on the searches, or really anything else that you find useful. diff --git a/articles/extensions/troubleshoot.md b/articles/extensions/troubleshoot.md new file mode 100644 index 0000000000..a42a424117 --- /dev/null +++ b/articles/extensions/troubleshoot.md @@ -0,0 +1,38 @@ +--- +description: General troubleshooting steps for extensions. +topics: + - extensions + - troubleshooting + - errors +contentType: + - how-to +useCase: + - extensibility-extensions + - troubleshooting +--- +# Troubleshoot Extensions + +If you see issues with your [extensions](/extensions), we recommend that you begin the troubleshooting process with the following two steps: + +1. Reinstall the extension. +2. Migrate to Node.js v12. + +## Reinstall the Extension + +One of the first things you can do when running into issues with an extension is to reinstall it: + +1. Go to [Dashboard > Extensions](${manage_url}/#/extensions). +2. On the **Installed Extensions** tab, delete the extension. +3. Log out of the Auth0 Dashboard. +4. Log back in to the Auth0 Dashboard. +5. Reinstall and reconfigure the extension. + +## Migrate to Node.js v12 + +We recommend changing your tenant's extensibility runtime from Node.js v8 to Node.js v12. Before updating, however, review the [migration guide](/migrations/guides/extensibility-node12) for full details on what will be affected by this change. + +You can change the Node.js runtime version by going to the **Extensibility** section in [Tenant Settings > Advanced](https://manage.auth0.com/#/tenant/advanced). + +## Contact Support + +If you are still experiencing issues with your extensions, and you need to [contact support](https://support.auth0.com/), please be sure to **include errors logs and/or [real-time Webtask logs](/extensions/realtime-webtask-logs) with your support ticket**. Errors and logs can help Auth0 support troubleshoot your issue faster. diff --git a/articles/extensions/user-import-export.md b/articles/extensions/user-import-export.md index 1b7bed87e5..45528fde69 100644 --- a/articles/extensions/user-import-export.md +++ b/articles/extensions/user-import-export.md @@ -2,18 +2,22 @@ title: User Import / Export Extension toc: true description: The User Import / Export is an extension that allows you to import / export users from or to any database you have configured in your account. +topics: + - extensions + - user-import-export +contentType: + - how-to +useCase: extensibility-extensions --- # User Import / Export -::: note -The User Import / Export extension is available in the PSaaS Appliance beginning with version `10755` when you have user search enabled. -::: - 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 +For a list of user profile fields that can be imported and exported, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes). + You must be a Dashboard Admin to use this extension. ## Install the Extension @@ -65,20 +69,20 @@ Once you've imported your users, you can manage them individually using the [Use ### Export Users +::: note +Auth0 uses the [ndjson](http://ndjson.org/) format due to the large size of export files. Before you can import users, you'll need to convert from **ndjson** to **json** using the library of your choice (such as [jq](https://stedolan.github.io/jq/)). When exporting users intended to later be imported, user field names should be left as their defaults and not mapped to a Column Name. +::: + To export your existing Auth0 users associated with database connections, select **Export** in the left-hand navigation bar. ![](/media/articles/extensions/user-import-export/export-users.png) -You can query the users that you want to export using [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) in the search bar. For example, to return all the users that have the `nickname` attribute you can use: `_exists_:nickname`. +Under **User Fields**, you can decide which user attributes or expressions should be included in the export. The user attribute can be a static value like `user.user_metadata.name`, or it can be a JavaScript expression like `user.user_metadata.name || user.name`. Expressions will be evaluated during the export runtime. The **column name** value is how the value will be represented in the export. -Under **Columns**, you can decide which user attributes or expressions should be included in the export. The user attribute can be a static value like `user.user_metadata.name`, or it can be a JavaScript expression like `user.user_metadata.name || user.name`. Expressions will be evaluated during the export runtime. The **column name** value is how the value will be represented in the export. - -You can use the **Add Default Columns** button to automatically select the default attributes and populate their column names (this is also a good way for you to visualize how parameters/expressions will appear). +You can click the **Add Default Fields** button to automatically select the default fields and populate their column names (this is also a good way for you to visualize how parameters/expressions will appear). You can remove extraneous attributes/expressions by clicking on its associated **trash can** icon. -![](/media/articles/extensions/user-import-export/default-columns.png) - Under **Settings**, you can: * Configure how your exported users are listed by providing a **User Attribute** by which users should be sorted (as well as whether the users should be sorted in ascending or descending order) diff --git a/articles/extensions/using-provided-extensions.md b/articles/extensions/using-provided-extensions.md index e15cadd277..6581cc99ab 100644 --- a/articles/extensions/using-provided-extensions.md +++ b/articles/extensions/using-provided-extensions.md @@ -1,5 +1,10 @@ --- description: Links and information on using Auth0's provided extensions. +topics: + - extensions +contentType: + - index +useCase: extensibility-extensions --- # Using Auth0's Provided Extensions diff --git a/articles/extensions/visual-studio-team-services-deploy.md b/articles/extensions/visual-studio-team-services-deploy.md index 7ebc668765..3c62c18309 100644 --- a/articles/extensions/visual-studio-team-services-deploy.md +++ b/articles/extensions/visual-studio-team-services-deploy.md @@ -1,10 +1,16 @@ --- -description: The Visual Studio Team Services Deployments extension allows you to deploy Rules, Hosted Pages and Database Connection scripts from Visual Studio Team Services to Auth0. +description: The Visual Studio Team Services Deployments extension allows you to deploy Rules, Universal Login pages and database connection scripts from Visual Studio Team Services to Auth0. +topics: + - extensions + - vs-team-services-deployments +contentType: + - how-to +useCase: extensibility-extensions --- # Visual Studio Team Services Deployments -The **Visual Studio Team Services Deployments** extension allows you to deploy [Rules](/rules), Database Connection scripts and hosted pages from Visual Studio Team Services to Auth0. You can configure a Visual Studio Team Services project, keep all of your scripts there, and have them automatically deployed to Auth0 whenever you push changes to your project. +The **Visual Studio Team Services Deployments** extension allows you to deploy [rules](/rules), rules configs, connections, database connection scripts, clients, client grants, resource servers, Universal Login pages and email templates from Visual Studio Team Services to Auth0. You can configure a Visual Studio Team Services project, keep all of your scripts there, and have them automatically deployed to Auth0 whenever you push changes to your project. ## Configure the Auth0 Extension @@ -14,15 +20,21 @@ To install and configure this extension, click on the **Visual Studio Team Servi Set the following configuration variables: -* **TFS_TYPE**: The type of repository, choose from TFVC or Git -* **TFS_PROJECT**: The project from which you want to deploy rules and database scripts. -* **TFS_BRANCH**: The branch we should monitor for commits. -* **TFS_INSTANCE**: Your Visual Studio Team Services instance name (without .visualstudio.com). -* **TFS_COLLECTION**: Your visualstudio collection -* **TFS_USERNAME**: Your Visual Studio Team Services username -* **TFS_TOKEN**: Your personal Access Token for Visual Studio Team Services, for details on how to configure one refer to [Configure a Personal Access Token](#configure-a-personal-access-token) below. +* **TYPE**: The type of repository, choose from TFVC or Git +* **REPOSITORY**: The project from which you want to deploy rules and database scripts. To use a specific repository within a project, format your input value as follows: `projectName/repoName`. +* **BRANCH**: The branch we should monitor for commits. +* **INSTANCE**: Your Visual Studio Team Services instance name (without .visualstudio.com). +* **COLLECTION**: Your Visual Studio collection (DefaultCollection for Azure DevOps). +* **USERNAME**: Your Visual Studio Team Services username +* **TOKEN**: Your personal Access Token for Visual Studio Team Services, for details on how to configure one refer to [Configure a Personal Access Token](#configure-a-personal-access-token) below. +* **BASE_DIR**: The base directory, where all your tenant settings are stored +* **AUTO_REDEPLOY**: If enabled, the extension redeploys the last successful configuration in the event of a deployment failure. Manual deployments and validation errors does not trigger auto-redeployment * **SLACK_INCOMING_WEBHOOK**: Webhook URL for Slack used to notify you of successful and failed deployments. +::: note +Some of the configuration variables were changed in version **2.5.0** of this extension. If you are updating the extension from a prior version, make sure that you update your configuration accordingly. +::: + Once you have provided this information, click **Install**. ## Configure a Personal Access Token @@ -41,7 +53,7 @@ Once you have provided this information, click **Install**. ![Creating the Access Token](/media/articles/extensions/visual-studio-ts/create-token.png) -5. Once the token is created, you will need to copy right away as it is not saved. Use this value as your **TFS_TOKEN**. +5. Once the token is created, you will need to save its value manually right away. Use this value as your **TFS_TOKEN**. ![Copy Access Token](/media/articles/extensions/visual-studio-ts/copy-token.png) @@ -59,11 +71,11 @@ Once you agree, you will be directed to the **Visual Studio Team Services Integr ![Visual Studio Team Services Integration Page](/media/articles/extensions/visual-studio-ts/vsts-integration.png) -Copy the **Payload URL** and **HTTP headers** values. You will use them in order to configure the Visual Studio Team Services Webhook in the next step. +Copy the **Payload URL** and **HTTP headers** values. You will use them to configure the Visual Studio Team Services Webhook in the next step. ## Configure the Visual Studio Team Services Webhook -Once you have configured your Auth0 Extension, you will need to configure the the Visual Studio Team Services Webhook to complete the integration. +Once you have configured your Auth0 Extension, you will need to configure the Visual Studio Team Services Webhook to complete the integration. In your Visual Studio Team Services account, go to **Overview** and click on the name the project being used for the integration, then click **Service Hooks**. @@ -73,7 +85,7 @@ Then click the link **Create the first subscription for this project**. Then sel ![Select Web Hooks](/media/articles/extensions/visual-studio-ts/web-hooks.png) -Then click the **Next** button, choose the trigger for the event and the filters are optional. Then click **Next**. +Then click the **Next** button, choose the trigger for the event, and the filters are optional. Then click **Next**. ![Configure Web Hook](/media/articles/extensions/visual-studio-ts/configure-web-hook.png) @@ -83,14 +95,18 @@ For the **URL** field, enter the **Payload URL** from the previous step along wi Once you have set up the webhook in Visual Studio Team Services using the provided information, you are ready to start committing to your project. -Your project should have a predefined structure: -- Rules are expected to be found under `rules` directory. -- Database connections are expected to be found under `database-connections` directory. -- Hosted pages are expected to be found under `pages` directory. +With each commit you push to your configured Visual Studio Team Services project, the webhook will call the extension to initiate a deployment if changes were made to one of these folders: +- `clients` +- `grants` +- `emails` +- `resource-servers` +- `connections` +- `database-connections` +- `rules-configs` +- `rules` +- `pages` -With each commit you push to your configured Visual Studio Team Services project, the webhook will call the extension to initiate a deployment if changes were made to these predefined directories. - -The **Deploy** button on the **Deployments** tab of the extension allows you to manually deploy the Rules, Pages and Database Connection scripts that you already have in your Visual Studio Team Services project. This is useful if your project already contains items that you want to deploy once you have set up the extension or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your project. +The **Deploy** button on the **Deployments** tab of the extension allows you to manually deploy the Rules, Pages, and Database Connection scripts that you already have in your Visual Studio Team Services project. This is useful if your project already contains items that you want to deploy once you have set up the extension or if you have accidentally deleted some scripts in Auth0 and need to redeploy the latest version of your project. ::: panel-warning Full Deployment To maintain a consistent state, the extension will always do a full deployment of the contents of these folders. **Any rules, pages or database connection scripts that exist in Auth0 but not in your Visual Studio Team Services project will be deleted**. @@ -113,31 +129,67 @@ For a generic Custom Database Connection, only the `login.js` script is required You can find examples in [the Auth0 Samples repository](https://github.com/auth0-samples/github-source-control-integration/tree/master/database-connections/my-custom-db). While the samples were authored for GitHub, it will work for a Visual Studio Team Services integration as well. -### Deploy Hosted Pages +#### Deploy Database Connection Settings + +To deploy Database Connection settings, you must create `database-connections/[connection-name]/database.json`. + +_This will work only for Auth0 connections (`strategy === auth0`), for non-Auth0 connections, use `connections`._ + +_Support for using `settings.json` has been deprecated in favor of `database.json` since v3.1.1 of the extension and may be dropped in a future release._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/patch_connections_by_id) for more info on allowed attributes for Connections. + +### Deploy Connections + +To deploy a connection, you must create a JSON file under the `connections` directory of your Visual Studio Team Services project. Example: + +__facebook.json__ +```json +{ + "name": "facebook", + "strategy": "facebook", + "enabled_clients": [ + "my-client" + ], + "options": {} +} +``` + +<%= include('./_includes/_embedded-clients-array') %> + +_This will work only for non-Auth0 connections (`strategy !== auth0`), for Auth0 connections, use `database-connections`._ + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Connections/post_connections) for more info on allowed attributes for Connections. + +### Deploy Universal Login Pages + +The supported pages are: -The supported hosted pages are: - `error_page` - `guardian_multifactor` - `login` - `password_reset` -To deploy a page, you must create an HTML file under the `pages` directory of your Visual Studio Team Services project. For each HTML page you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, in order to deploy an `error_page`, you would create two files: +To deploy a page, you must create an HTML file under the `pages` directory of your Visual Studio Team Services project. For each HTML page, you need to create a JSON file (with the same name) that will be used to mark the page as enabled or disabled. For example, to deploy a `password_reset`, you would create two files: ```text -your-project/pages/error_page.html -your-project/pages/error_page.json +your-bitbucket-repo/pages/password_reset.html +your-bitbucket-repo/pages/password_reset.json ``` -To enable the page the `error_page.json` would contain the following: +To enable the page, the `password_reset.json` would contain the following: ```json { "enabled": true } ``` + +<%= include('./_includes/_use-default-error') %> + ### Deploy Rules -To deploy a rule, you must first create a JavaScript file under the `rules` directory of your Visual Studio Team Services project. Each Rule must be in its own `.js` file. +To deploy a rule, you must first create a JavaScript file under the `rules` directory of your Visual Studio Team Services project. Each Rule must be in its own JavaScript file. For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. @@ -145,10 +197,6 @@ For example, if you create the file `rules/set-country.js`, the extension will c If you plan to use source control integration for an existing account, first rename your Rules in Auth0 to match the name of the files you will be deploying to this directory. ::: -You can mark rules as manual. In that case, the source control extension will not delete or update them. To mark a rule navigate to the **Rules Configuration** tab of the **Visual Studio Team Services Integration** page. Toggle the **Manual Rule** switch for the rules you want to mark as manual. Click **Update Manual Rules** to save your changes. - -![Mark rules as manual](/media/articles/extensions/visual-studio-ts/manual-rule.png) - You can also control the Rule order and status (`enabled`/`disabled`) by creating a JSON file with the same name as your JavaScript file. For this example, you would create a file named `rules/set-country.json`. __set-country.js__ @@ -162,7 +210,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -174,16 +222,167 @@ You can find a `login_success` example in [the Auth0 Samples repository](https:/ #### Set Rule Order -To avoid conflicts, you are cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk for conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). +To avoid conflicts, you cannot set multiple Rules of the same order. However, you can create a JSON file for each rule, and within each file, assign a value for `order`. We suggest using number values that allow for reordering with less risk of conflict. For example, assign a value of `10` to the first Rule and `20` to the second Rule, rather than using values of `1` and `2`, respectively). #### Set the Stage -After you deploy a Rule, you cannot change its stage, or the area where the Rule executes. +After you deploy a Rule, you cannot change its stage or the area where the Rule executes. If you need the rule to execute in a different stage, you must create a new Rule with the updated stage and delete the original Rule. Please note that you may have only a single Rule for the `user_registration` and `login_failure` stages. +### Deploy Rules Configs + +To deploy a rule config, you must create a JSON file under the `rules-configs` directory of your Visual Studio Team Services project. Example: + +__secret_number.json__ +```json +{ + "key": "secret_number", + "value": 42 +} +``` + +### Deploy Clients + +To deploy a client, you must create a JSON file under the `clients` directory of your Visual Studio Team Services project. Example: + +__my-client.json__ +```json +{ + "name": "my-client" +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Clients/post_clients) for more info on allowed attributes for Clients and Client Grants. + +### Deploy Clients Grants + +You can specify the client grants for each client by creating a JSON file in the `grants` directory. + +__my-client-api.json__ +```json +{ + "client_id": "my-client", + "audience": "https://myapp.com/api/v1", + "scope": [ + "read:users" + ] +} +``` + +<%= include('./_includes/_deployment-extension') %> + +### Deploy Resource Servers + +To deploy a resource server, you must create a JSON file under the `resource-servers` directory of your Visual Studio Team Services project. Example: + +__my-api.json__ +```json +{ + "name": "my-api", + "identifier": "https://myapp.com/api/v1", + "scopes": [ + { + "value": "read:users", + "description": "Allows getting user information" + } + ] +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Resource_Servers/post_resource_servers) for more info on allowed attributes for Resource Servers. + +### Deploy Email Provider + +To deploy an email provider, you must create `provider.json` file under the `emails` directory of your Visual Studio Team Services project. Example: + +__provider.json__ +```json +{ + "name": "smtp", + "enabled": true, + "credentials": { + "smtp_host": "smtp.server.com", + "smtp_port": 25, + "smtp_user": "smtp_user", + "smtp_pass": "smtp_secret_password" + } +} +``` + +See [Management API v2 Docs](https://auth0.com/docs/api/management/v2#!/Emails/patch_provider) for more info on allowed attributes for Email Provider. + +### Deploy Email Templates + +The supported email templates are: +- `verify_email` +- `reset_email` +- `welcome_email` +- `blocked_account` +- `stolen_credentials` +- `enrollment_email` +- `mfa_oob_code` + +To deploy an email template, you must create an HTML file under the `emails` directory of your Visual Studio Team Services project. For each HTML file, you need to create a JSON file (with the same name) with additional options for that template. For example, to deploy a `blocked_account` template, you would create two files: + +```text +your-project/emails/blocked_account.html +your-project/emails/blocked_account.json +``` + +__blocked_account.json__ +```json +{ + "template": "blocked_account", + "from": "", + "subject": "", + "resultUrl": "", + "syntax": "liquid", + "body": "./blocked_account.html", + "urlLifetimeInSeconds": 432000, + "enabled": true +} +``` + +## Excluded records + +You can exclude the following records from the deployment process: `rules`, `clients`, `databases`, `connections` and `resourceServers`. If excluded, the records will not be modified by deployments. + +![](/media/articles/extensions/deploy-extensions/excluded-rules.png) + +## Keywords Mapping + +Beginning with version **3.0.0**, you can use keywords mapping to manage your secrets and tenant-based environment variables. + +There are two ways to use the keyword mappings. You can either wrap the key using `@` symbols (e.g., `@@key@@`), or you can wrap the key using `#` symbols (e.g., `##key##`). + + - If you use `@` symbols, your value will be converted from a JavaScript object or value to a JSON string. + + - If you use `#` symbols, Auth0 will perform a literal replacement. + +This is useful for something like specifying different variables across your environments. For example, you could specify different JWT timeouts for your Development, QA/Testing, and Production environments. + +Refer to the snippets below for sample implementations: + +__Client.json__ +```json +{ + ... + "callbacks": [ + "##ENVIRONMENT_URL##/auth/callback" + ], + "jwt_configuration": { + "lifetime_in_seconds": ##JWT_TIMEOUT##, + "secret_encoded": true + } + ... +} +``` + +![](/media/articles/extensions/deploy-extensions/mappings.png) + ## Track Deployments To track your deployments, navigate to the [Extensions](${manage_url}/#/extensions) page, then **Installed Extensions** and click on the row for the **Visual Studio Team Services Deployments** extension, and select the **Deployments** tab. You will see a list of all deployments. diff --git a/articles/flows/concepts/auth-code-pkce.md b/articles/flows/concepts/auth-code-pkce.md new file mode 100644 index 0000000000..5b0677b14e --- /dev/null +++ b/articles/flows/concepts/auth-code-pkce.md @@ -0,0 +1,79 @@ +--- +title: Authorization Code Flow with Proof Key for Code Exchange (PKCE) +description: Learn how the Authorization Code flow with Proof Key for Code Exchange (PKCE) works and why you should use it for native and mobile apps. +topics: + - authorization-code + - pkce + - api-authorization + - grants + - authentication + - native-apps + - mobile-apps +contentType: concept +useCase: + - secure-api + - call-api + - add-login +--- +# Authorization Code Flow with Proof Key for Code Exchange (PKCE) + +When public clients (e.g., native and single-page applications) request Access Tokens, some additional security concerns are posed that are not mitigated by the Authorization Code Flow alone. This is because: + +**Native apps** + +* Cannot securely store a Client Secret. Decompiling the app will reveal the Client Secret, which is bound to the app and is the same for all users and devices. +* May make use of a custom URL scheme to capture redirects (e.g., MyApp://) potentially allowing malicious applications to receive an Authorization Code from your Authorization Server. + +**Single-page apps** + +* Cannot securely store a Client Secret because their entire source is available to the browser. + +To mitigate this, OAuth 2.0 provides a version of the Authorization Code Flow which makes use of a Proof Key for Code Exchange (PKCE) (defined in [OAuth 2.0 RFC 7636](https://tools.ietf.org/html/rfc7636)). + +The PKCE-enhanced Authorization Code Flow introduces a secret created by the calling application that can be verified by the authorization server; this secret is called the Code Verifier. Additionally, the calling app creates a transform value of the Code Verifier called the Code Challenge and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier. + +## How it works + +Because the PKCE-enhanced Authorization Code Flow builds upon the [standard Authorization Code Flow](/flows/concepts/auth-code), the steps are very similar. + +![Authorization Code Flow with PKCE Authentication Sequence](/media/articles/flows/concepts/auth-sequence-auth-code-pkce.png) + +1. The user clicks **Login** within the application. +2. Auth0's SDK creates a cryptographically-random `code_verifier` and from this generates a `code_challenge`. +3. Auth0's SDK redirects the user to the Auth0 Authorization Server ([**/authorize** endpoint](/api/authentication#authorization-code-grant-pkce-)) along with the `code_challenge`. +4. Your Auth0 Authorization Server redirects the user to the login and authorization prompt. +5. The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the application. +6. Your Auth0 Authorization Server stores the `code_challenge` and redirects the user back to the application with an authorization `code`, which is good for one use. +7. Auth0's SDK sends this `code` and the `code_verifier` (created in step 2) to the Auth0 Authorization Server ([**/oauth/token** endpoint](/api/authentication?http#authorization-code-flow-with-pkce44)). +8. Your Auth0 Authorization Server verifies the `code_challenge` and `code_verifier`. +9. Your Auth0 Authorization Server responds with an ID Token and Access Token (and optionally, a Refresh Token). +10. Your application can use the Access Token to call an API to access information about the user. +11. The API responds with requested data. + +<%= include('../../_includes/_refresh_token_rotation_panel.md') %> + +## How to implement it + +The easiest way to implement the Authorization Code Flow with PKCE is to follow our [Native Quickstarts](/quickstart/native) or [Single-Page Quickstarts](/quickstart/spa). + +Depending on your application type, you can also use our mobile or single-page app SDKs: + +**Mobile** + +* [Auth0 Swift SDK](/libraries/auth0-swift) +* [Auth0 Android SDK](/libraries/auth0-android) + +**Single-page** + +* [Auth0 Single-Page App SDK](/libraries/auth0-spa-js) +* [Auth0 React SDK](/libraries/auth0-react) + +<%= include('../../_includes/_refresh_token_rotation_recommended.md') %> + +You can follow our tutorials to use our API endpoints to [Add Login Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce) or [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce). + +## Keep reading + +- Learn how to personalize your user's login experience using [rules](/rules) and [hooks](/hooks) +- Learn more about [tokens](/tokens) and [token storage](/tokens/concepts/token-storage) +- Explore [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) diff --git a/articles/flows/concepts/auth-code.md b/articles/flows/concepts/auth-code.md new file mode 100644 index 0000000000..a01f39b566 --- /dev/null +++ b/articles/flows/concepts/auth-code.md @@ -0,0 +1,46 @@ +--- +title: Authorization Code Flow +description: Learn how the Authorization Code flow works and why you should use it for regular web apps. +topics: + - authorization-code + - api-authorization + - grants + - authentication + - regular-web-apps +contentType: concept +useCase: + - secure-api + - call-api + - add-login +--- +# Authorization Code Flow + +Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow (defined in [OAuth 2.0 RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.1)), which exchanges an Authorization Code for a token. Your app must be server-side because during this exchange, you must also pass along your application's Client Secret, which must always be kept secure, and you will have to store it in your client. + +## How it works + +![Authorization Code Flow Authentication Sequence](/media/articles/flows/concepts/auth-sequence-auth-code.png) + + +1. The user clicks **Login** within the regular web application. +2. Auth0's SDK redirects the user to the Auth0 Authorization Server ([**/authorize** endpoint](/api/authentication#authorization-code-grant)). +3. Your Auth0 Authorization Server redirects the user to the login and authorization prompt. +4. The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the regular web application. +5. Your Auth0 Authorization Server redirects the user back to the application with an authorization `code`, which is good for one use. +6. Auth0's SDK sends this `code` to the Auth0 Authorization Server ([**/oauth/token** endpoint](/api/authentication?http#authorization-code-flow43)) along with the application's Client ID and Client Secret. +7. Your Auth0 Authorization Server verifies the code, Client ID, and Client Secret. +8. Your Auth0 Authorization Server responds with an ID Token and Access Token (and optionally, a Refresh Token). +9. Your application can use the Access Token to call an API to access information about the user. +10. The API responds with requested data. + +## How to implement it + +The easiest way to implement the Authorization Code Flow is to follow our [Regular Web App Quickstarts](/quickstart/webapp). + +Finally, you can follow our tutorials to use our API endpoints to [Add Login Using the Authorization Code Flow](/flows/guides/auth-code/add-login-auth-code) or [Call Your API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code). + +## Keep reading + +- Learn how to personalize your user's login experience using [rules](/rules) and [hooks](/hooks) +- Learn more about [tokens](/tokens) and [token storage](/tokens/concepts/token-storage) +- Explore [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) \ No newline at end of file diff --git a/articles/flows/concepts/client-credentials.md b/articles/flows/concepts/client-credentials.md new file mode 100644 index 0000000000..eebe4ee5c4 --- /dev/null +++ b/articles/flows/concepts/client-credentials.md @@ -0,0 +1,42 @@ +--- +title: Client Credentials Flow +description: Learn how the Client Credentials flow works and why you should use it for machine-to-machine (M2M) apps. +topics: + - M2M + - client-credentials + - api-authorization + - grants + - authentication + - m2m-apps +contentType: concept +useCase: + - secure-api + - call-api +--- +# Client Credentials Flow + +With machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on your back-end, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow (defined in [OAuth 2.0 RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)), in which they pass along their Client ID and Client Secret to authenticate themselves and get a token. + +## How it works + +![Client Credentials Flow Authentication Sequence](/media/articles/flows/concepts/auth-sequence-client-credentials.png) + + +1. Your app authenticates with the Auth0 Authorization Server using its Client ID and Client Secret ([**/oauth/token** endpoint](/api/authentication?http#client-credentials-flow)). +2. Your Auth0 Authorization Server validates the Client ID and Client Secret. +3. Your Auth0 Authorization Server responds with an Access Token. +4. Your application can use the Access Token to call an API on behalf of itself. +5. The API responds with requested data. + + +## How to implement it + +The easiest way to implement the Client Credentials Flow is to follow our [Backend Quickstarts](/quickstart/backend). + +You can also follow our tutorial to use our API endpoints to [Call Your API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials). + +## Keep reading + +- Learn how to personalize your user's login experience using [rules](/rules) and [hooks](/hooks) +- Learn more about [tokens](/tokens) and [token storage](/tokens/concepts/token-storage) +- Explore [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) \ No newline at end of file diff --git a/articles/flows/concepts/device-auth.md b/articles/flows/concepts/device-auth.md new file mode 100644 index 0000000000..99eddae8b6 --- /dev/null +++ b/articles/flows/concepts/device-auth.md @@ -0,0 +1,63 @@ +--- +title: Device Authorization Flow +description: Learn how the Device Authorization flow works and why you should use it for input-constrained devices, such as smart TVs and media consoles. For use with native apps. +topics: + - input-constrained-devices + - device-flow + - api-authorization + - grants + - flows + - authorization + - mobile-apps + - desktop-apps + - native-apps +contentType: concept +useCase: + - add-login + - secure-api + - call-api +--- +# 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 (ratified in [OAuth 2.0](https://tools.ietf.org/html/rfc8628)), in which they pass along their Client ID to initiate the authorization process and get a token. + +## How it works + +The Device Authorization Flow contains two different paths; one occurs on the device requesting authorization and the other occurs in a browser. The browser flow path, wherein a device code is bound to the session in the browser, occurs in parallel to part of the device flow path. + +![Device Authorization Sequence](/media/articles/flows/concepts/auth-sequence-device-auth.png) + +### Device Flow + +1. The user starts the app on the device. +2. The device app requests authorization from the Auth0 Authorization Server using its Client ID (**/oauth/device/code** endpoint). +3. The Auth0 Authorization Server responds with a `device_code`, `user_code`, `verification_uri`, `verification_uri_complete` `expires_in` (lifetime in seconds for `device_code` and `user_code`), and polling `interval`. +4. The device app asks the user to activate using their computer or smartphone. The app may accomplish this by: + - asking the user to visit the `verification_uri` and enter the `user_code` after displaying these values on-screen + - asking the user to interact with either a QR Code or shortened URL with embedded user code generated from the `verification_uri_complete` + - directly navigating to the verification page with embedded user code using `verification_uri_complete`, if running natively on a browser-based device +5. The device app begins polling your Auth0 Authorization Server for an Access Token (**/oauth/token** endpoint) using the time period specified by `interval` and counting from receipt of the last polling request's response. The device app continues polling until either the user completes the browser flow path or the user code expires. +6. When the user successfully completes the browser flow path, your Auth0 Authorization Server responds with an Access Token (and optionally, a Refresh Token). The device app should now forget its `device_code` because it will expire. +7. Your device app can use the Access Token to call an API to access information about the user. +8. The API responds with requested data. + +### Browser Flow + +1. The user visits the `verification_uri` on their computer, enters the `user_code` and confirms that the device that is being activated is displaying the `user_code`. If the user visits the `verification_uri_complete` by any other mechanism (such as by scanning a QR code), only the device confirmation will be needed. +2. Your Auth0 Authorization Server redirects the user to the login and consent prompt, if needed. +3. The user authenticates using one of the configured login options and may see a consent page asking to authorize the device app. +4. Your device app is authorized to access the API. + +## How to implement it + +The easiest way to implement the Device Authorization Flow is to follow our tutorial: [Call API Using Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth). + +## Force device reauthorization + +To force the user to reauthorize a device, you must revoke the [Refresh Token](/tokens/guides/revoke-refresh-tokens) 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. + +## Keep reading + +- Learn how to personalize your user's login experience using [rules](/rules) and [hooks](/hooks) +- Learn more about [tokens](/tokens) and [token storage](/tokens/concepts/token-storage) +- Explore [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) \ No newline at end of file diff --git a/articles/flows/concepts/implicit.md b/articles/flows/concepts/implicit.md new file mode 100644 index 0000000000..fd8a3d2f8f --- /dev/null +++ b/articles/flows/concepts/implicit.md @@ -0,0 +1,59 @@ +--- +title: Implicit Flow with Form Post +description: Learn how the Implicit flow with Form Post works and why you should use it for single-page apps (SPAs) that need only an ID Token to perform user authentication. +topics: + - authorization-code + - implicit + - hybrid + - api-authorization + - grants + - authentication + - SPA + - single-page apps +contentType: concept +useCase: + - secure-api + - call-api + - add-login +--- +# Implicit Flow with Form Post + +::: warning +The [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2) states that you **should not** use the Implicit Flow to request [Access Tokens](/tokens/access-tokens) from the Authorization Server. For this reason, we recommend that you use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) if your single-page app (SPA) requires Access Tokens for [Cross-Origin Resource Sharing (CORS)](/cross-origin-authentication#what-is-cross-origin-authentication) requests (along with [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) if your SPA needs to maintain session). +::: + +As an alternative to the [Authorization Code Flow](/flows/concepts/auth-code), the OAuth 2.0 spec includes the Implicit Flow intended for Public Clients, or applications which are unable to securely store Client Secrets. As part of the authorization response, the Implicit Flow returns an Access Token rather than an Authorization Code that must be exchanged at the token endpoint. + +While this is no longer considered a best practice for requesting Access Tokens, it does offer a streamlined workflow if the application needs only an ID Token to perform user authentication. + +## How it works + +In the Implicit Flow, issued tokens are short-lived, and Refresh Tokens are not available. + +::: warning +You should use this flow for login-only use cases; if you need to request Access Tokens while logging the user in so you can call your API, use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). +::: + +![Implicit Flow with Form Post Authentication Sequence](/media/articles/flows/concepts/auth-sequence-implicit-form-post.png) + +1. The user clicks **Login** in the app. +2. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint) passing along a `response_type` parameter of `id_token` that indicates the type of requested credential. It also passes along a `response_mode` parameter of `form_post` to ensure security. +3. Your Auth0 Authorization Server redirects the user to the login and authorization prompt. +4. The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the app. +5. Your Auth0 Authorization Server redirects the user back to the app with an ID Token. + +## How to implement it + +You can use our [Express OpenID Connect SDK](https://www.npmjs.com/package/express-openid-connect) to securely implement the Implicit Flow. If you use our [Javascript SDKs](/libraries), please ensure you are implementing mitigations that are appropriate for your architecture. + +::: note +The [Auth0 Single-Page App SDK](/libraries/auth0-spa-js) and [Single-Page Quickstarts](/quickstart/spa) adhere to the new recommendations and use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). +::: + +Finally, you can follow our tutorials to use our API endpoints to [Add Login Using the Implicit Flow with Form Post](/flows/guides/implicit/add-login-implicit). + +## Keep reading + +- Learn how to personalize your user's login experience using [rules](/rules) and [hooks](/hooks) +- Learn more about [tokens](/tokens) and [token storage](/tokens/concepts/token-storage) +- Explore [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) \ No newline at end of file diff --git a/articles/flows/guides/auth-code-pkce/add-login-auth-code-pkce.md b/articles/flows/guides/auth-code-pkce/add-login-auth-code-pkce.md new file mode 100644 index 0000000000..03e57d2ac3 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/add-login-auth-code-pkce.md @@ -0,0 +1,68 @@ +--- +title: Add Login Using the Authorization Code Flow with PKCE +description: Learn how to add login to your native, mobile, or single-page application using the Authorization Code Flow with Proof Key for Code Exchange (PKCE). +toc: true +topics: + - api-authentication + - oidc + - authorization-code + - pkce + - native-apps + - mobile-apps + - single-page-apps +contentType: tutorial +useCase: + - add-login +--- +# Add Login Using the Authorization Code Flow with PKCE + +::: note +This tutorial will help you add login to your native, mobile, or single-page app using the Authorization Code Flow with PKCE. If you want to learn how the flow works and why you should use it, see [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). If you want to learn to call your API from a native, mobile, or single-page app, see [Call Your API Using Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce). +::: + +Auth0 makes it easy for your app to implement the Authorization Code Flow with Proof Key for Code Exchange (PKCE) using: + +* [Auth0 Mobile SDKs](/libraries#auth0-sdks) and [Auth0 Single-Page App SDK](/libraries/auth0-spa-js): The easiest way to implement the flow, which will do most of the heavy-lifting for you. Our [Mobile Quickstarts](/quickstart/native) and [Single-Page App Quickstarts](/quickstart/spa) will walk you through the process. +* Authentication API: If you prefer to roll your own, keep reading to learn how to call our API directly. + +Following successful login, your application will have access to the user's [ID Token](/tokens/concepts/id-tokens) and [Access Token](/tokens/concepts/access-tokens). The ID Token will contain basic user profile information, and the Access Token can be used to call the Auth0 /userinfo endpoint or your own protected APIs. + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register your Application with Auth0](/dashboard/guides/applications/register-app-native). + * Select an **Application Type** of **Native** or **Single-Page App**, depending on your application type. + * Add an **Allowed Callback URL** of **`YOUR_CALLBACK_URL`**. Your callback URL format will vary depending on your application type and platform. For details about the format for your application type and platform, see our [Native/Mobile Quickstarts](/quickstart/native) and [Single-Page App Quickstarts](/quickstart/spa). + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Authorization Code**. + +## Steps + +Each time your user chooses to authenticate you will need to: + +1. [Create a code verifier](#create-a-code-verifier): +Generate a `code_verifier` that will be sent to Auth0 to request tokens. +2. [Create a code challenge](#create-a-code-challenge): +Generate a `code_challenge` from the `code_verifier` that will be sent to Auth0 to request an `authorization_code`. +3. [Authorize the user](#authorize-the-user): +Request the user's authorization and redirect back to your app with an `authorization_code`. +4. [Request Tokens](#request-tokens): +Exchange your `authorization_code` and `code_verifier` for tokens. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + +<%= include('./includes/create-code-verifier') %> + +<%= include('./includes/create-code-challenge') %> + +<%= include('./includes/authorize-user-add-login') %> + +<%= include('./includes/request-tokens') %> + +<%= include('./includes/sample-use-cases-add-login') %> + +## Keep reading + +- [OAuth 2.0 framework](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/auth-code-pkce/call-api-auth-code-pkce.md b/articles/flows/guides/auth-code-pkce/call-api-auth-code-pkce.md new file mode 100644 index 0000000000..8f737d50b0 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/call-api-auth-code-pkce.md @@ -0,0 +1,79 @@ +--- +title: Call API Using Authorization Code Flow with PKCE +description: Learn how to call your API from a native, mobile, or single-page application using the Authorization Code flow using Proof Key for Code Exchange (PKCE). +toc: true +topics: + - api-authentication + - oidc + - authorization-code + - pkce + - native-apps + - mobile-apps + - single-page-apps +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Call Your API Using the Authorization Code Flow with PKCE + +::: note +This tutorial will help you call your own API from a native, mobile, or single-page app using the Authorization Code Flow with PKCE. If you want to learn how the flow works and why you should use it, see [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). If you want to learn to add login to your native, mobile, or single-page app, see [Add Login Using Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce). +::: + +Auth0 makes it easy for your app to implement the Authorization Code Flow with Proof Key for Code Exchange (PKCE) using: + +* [Auth0 Mobile SDKs](/libraries#auth0-sdks) and [Auth0 Single-Page App SDK](/libraries/auth0-spa-js): The easiest way to implement the flow, which will do most of the heavy-lifting for you. Our [Mobile Quickstarts](/quickstart/native) and [Single-Page App Quickstarts](/quickstart/spa) will walk you through the process. +* Authentication API: If you prefer to roll your own, keep reading to learn how to call our API directly. + + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register the Application with Auth0](/dashboard/guides/applications/register-app-native). + * Select an **Application Type** of **Native** or **Single-Page App**, depending on your application type. + * Add an **Allowed Callback URL** of **`YOUR_CALLBACK_URL`**. Your callback URL format will vary depending on your application type and platform. For details about the format for your application type and platform, see our [Native/Mobile Quickstarts](/quickstart/native) and [Single-Page App Quickstarts](/quickstart/spa). + * Make sure the Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Authorization Code**. + * If you want your Application to be able to use [Refresh Tokens](/tokens/concepts/refresh-tokens), make sure the Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Refresh Token**. + +* [Register your API with Auth0](/architecture-scenarios/mobile-api/part-2#create-the-api) + * If you want your API to receive Refresh Tokens to allow it to obtain new tokens when the previous ones expire, enable **Allow Offline Access**. + +## Steps + +1. [Create a code verifier](#create-a-code-verifier): +Generate a `code_verifier` that will be sent to Auth0 to request tokens. +2. [Create a code challenge](#create-a-code-challenge): +Generate a `code_challenge` from the `code_verifier` that will be sent to Auth0 to request an `authorization_code`. +3. [Authorize the user](#authorize-the-user): +Request the user's authorization and redirect back to your app with an `authorization_code`. +4. [Request Tokens](#request-tokens): +Exchange your `authorization_code` and `code_verifier` for tokens. +5. [Call your API](#call-your-api): +Use the retrieved Access Token to call your API. +6. [Refresh Tokens](#refresh-tokens): +Use a Refresh Token to request new tokens when the existing ones expire. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + + +<%= include('./includes/create-code-verifier') %> + +<%= include('./includes/create-code-challenge') %> + +<%= include('./includes/authorize-user-call-api') %> + +<%= include('./includes/request-tokens') %> + +<%= include('./includes/call-api') %> + +<%= include('./includes/refresh-tokens') %> + +<%= include('./includes/sample-use-cases-call-api') %> + +## Keep reading + +- [OAuth 2.0 framework](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/auth-code-pkce/includes/authorize-user-add-login.md b/articles/flows/guides/auth-code-pkce/includes/authorize-user-add-login.md new file mode 100644 index 0000000000..31591db0b8 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/authorize-user-add-login.md @@ -0,0 +1,63 @@ +## 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; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-), including the `code_challenge` you generated in the previous step and the method you used to generate the `code_challenge`. + + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=code& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + client_id=${account.clientId}& + redirect_uri=YOUR_CALLBACK_URL& + scope=SCOPE& + state=STATE +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `response_type` | Denotes the kind of credential that Auth0 will return (`code` or `token`). For this flow, the value must be `code`. | +| `code_challenge` | Generated challenge from the `code_verifier`. | +| `code_challenge_method` | Method used to generate the challenge (e.g., S256). 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. | +| `client_id` |Your application's Client ID. You can find this value in your [Application 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. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | Specifies the [scopes](/scopes) for which you want to request authorization, which dictate which claims (or user attributes) you want returned. These must be separated by a space. To get an ID Token in the response, you need to specify a scope of at least `openid`. If you want to return the user's full profile, you can request `openid profile`. 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 `email`, or [custom claims](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [Application Settings](${manage_url}/#/applications)). | +| `state` | (recommended) An opaque arbitrary alphanumeric string your app adds to the initial request that Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | +| `connection` | (optional) Forces the user to sign in with a specific connection. For example, you can pass a value of `github` to send the user directly to GitHub to log in with their GitHub account. When not specified, the user sees the Auth0 Lock screen with all configured connections. You can see a list of your configured connections on the **Connections** tab of your application. | + + +As an example, your HTML snippet for your authorization URL when adding login to your app might look like: + +```html + + Sign In + +``` + + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The authorization code is included at the end of the URL: + +```text +HTTP/1.1 302 Found +Location: YOUR_CALLBACK_URL?code=AUTHORIZATION_CODE&state=xyzABC123 +``` diff --git a/articles/flows/guides/auth-code-pkce/includes/authorize-user-call-api.md b/articles/flows/guides/auth-code-pkce/includes/authorize-user-call-api.md new file mode 100644 index 0000000000..cbb11d6cfc --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/authorize-user-call-api.md @@ -0,0 +1,71 @@ +## 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; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-), including the `code_challenge` you generated in the previous step and the method you used to generate the `code_challenge`. + + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=code& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + client_id=${account.clientId}& + redirect_uri=YOUR_CALLBACK_URL& + scope=SCOPE& + audience=API_AUDIENCE& + state=STATE +``` + +#### Parameters + +Note that for authorizing a user when calling a custom API, you: + +- must include an audience parameter +- can include additional scopes supported by the target API + + +| Parameter Name | Description | +|-----------------|-------------| +| `response_type` | Denotes the kind of credential that Auth0 will return (`code` or `token`). For this flow, the value must be `code`. | +| `code_challenge` | Generated challenge from the `code_verifier`. | +| `code_challenge_method` | Method used to generate the challenge (e.g., S256). 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. | +| `client_id` |Your application's Client ID. You can find this value in your [Application 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. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | The [scopes](/scopes) for which you want to request authorization. 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](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (e.g., `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [Application Settings](${manage_url}/#/apis)). | +|`audience` | The unique identifier of the API your mobile 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. | +| `state` | (recommended) An opaque arbitrary alphanumeric string your app adds to the initial request that Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | + + +As an example, your HTML snippet for your authorization URL when calling an API might look like: + +```html + + Sign In + +``` + + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The authorization code is included at the end of the URL: + +```text +HTTP/1.1 302 Found +Location: YOUR_CALLBACK_URL?code=AUTHORIZATION_CODE&state=xyzABC123 +``` diff --git a/articles/flows/guides/auth-code-pkce/includes/call-api.md b/articles/flows/guides/auth-code-pkce/includes/call-api.md new file mode 100644 index 0000000000..95c675e3c9 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/call-api.md @@ -0,0 +1,15 @@ +## Call your API + +To call your API from a native/mobile application, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request. + + + ```har +{ + "method": "GET", + "url": "https://myapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` diff --git a/articles/flows/guides/auth-code-pkce/includes/create-code-challenge.md b/articles/flows/guides/auth-code-pkce/includes/create-code-challenge.md new file mode 100644 index 0000000000..8bd378a10c --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/create-code-challenge.md @@ -0,0 +1,70 @@ +## Create a Code Challenge + +Generate a `code_challenge` from the `code_verifier` that will be sent to Auth0 to request an `authorization_code`. + + +
      +
      + +
      +
      +
      + 
      +// Dependency: Node.js crypto module
+// https://nodejs.org/api/crypto.html#crypto_crypto
+function sha256(buffer) {
+    return crypto.createHash('sha256').update(buffer).digest();
+}
+var challenge = base64URLEncode(sha256(verifier));
+
+
      +
      +
      + 
      +// Dependency: Apache Commons Codec
+// https://commons.apache.org/proper/commons-codec/
+// Import the Base64 class.
+// import org.apache.commons.codec.binary.Base64;
+byte[] bytes = verifier.getBytes("US-ASCII");
+MessageDigest md = MessageDigest.getInstance("SHA-256");
+md.update(bytes, 0, bytes.length);
+byte[] digest = md.digest();
+String challenge = Base64.encodeBase64URLSafeString(digest);
      +
      +
      + 
      +// Dependency: Apple Common Crypto library
+// http://opensource.apple.com//source/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)
      +
      +
      + 
      +// Dependency: Apple Common Crypto library
+// http://opensource.apple.com//source/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:@"="]];
      +
      +
      +
      diff --git a/articles/flows/guides/auth-code-pkce/includes/create-code-verifier.md b/articles/flows/guides/auth-code-pkce/includes/create-code-verifier.md new file mode 100644 index 0000000000..a05a231f8b --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/create-code-verifier.md @@ -0,0 +1,60 @@ +## Create a Code Verifier + +Create a `code_verifier`, which is a cryptographically-random key that will eventually be sent to Auth0 to request tokens. + +
      + +
      + +
      +
      +
      + 
      +// Dependency: Node.js crypto module
+// https://nodejs.org/api/crypto.html#crypto_crypto
+function base64URLEncode(str) {
+    return str.toString('base64')
+        .replace(/\+/g, '-')
+        .replace(/\//g, '_')
+        .replace(/=/g, '');
+}
+var verifier = base64URLEncode(crypto.randomBytes(32));
      +
      +
      + 
      +// Dependency: Apache Commons Codec
+// https://commons.apache.org/proper/commons-codec/
+// Import the Base64 class.
+// import org.apache.commons.codec.binary.Base64;
+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:@"="]];
      +
      +
      +
      + diff --git a/articles/flows/guides/auth-code-pkce/includes/refresh-tokens.md b/articles/flows/guides/auth-code-pkce/includes/refresh-tokens.md new file mode 100644 index 0000000000..0946684b81 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/refresh-tokens.md @@ -0,0 +1,66 @@ +## Refresh Tokens + +You have already received a Refresh Token if you've been following this tutorial and completed the following: + +* configured your API to allow offline access +* included the `offline_access` scope when you initiated the authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint + +You can use the Refresh Token to get a new Access Token. Usually, a user will need a new Access Token only after the previous one expires or when gaining access to a new resource for the first time. It's bad practice to call the endpoint to get a new Access Token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. + +To refresh your token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`. + +### Example POST to token URL + +```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": "refresh_token", + "value": "YOUR_REFRESH_TOKEN" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "refresh_token". | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `refresh_token` | The Refresh Token to use. | +| `scope` | (Optional) 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. | + +### Response + +If all goes well, you'll receive an `HTTP 200` response with a payload containing a new `access_token`, its lifetime in seconds (`expires_in`), granted `scope` values, and `token_type`. If the scope of the initial token included `openid`, then the response will also include a new `id_token`: + +```json +{ + "access_token": "eyJ...MoQ", + "expires_in": 86400, + "scope": "openid offline_access", + "id_token": "eyJ...0NE", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: diff --git a/articles/flows/guides/auth-code-pkce/includes/request-tokens.md b/articles/flows/guides/auth-code-pkce/includes/request-tokens.md new file mode 100644 index 0000000000..71ee43fb40 --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/request-tokens.md @@ -0,0 +1,78 @@ +## Request Tokens + +Now that you have an Authorization Code, you must exchange it for tokens. Using the extracted Authorization Code (`code`) from the previous step, you will need to `POST` to the [token URL](/api/authentication#authorization-code-pkce-) sending along the `code_verifier`. + +### Example POST to token URL + +```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}" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "authorization_code". | +| `code_verifier` | The cryptographically-random key that was generated in the first step of this tutorial. | +| `code` | The `authorization_code` retrieved in the previous step of this tutorial. | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `redirect_uri` | The valid callback URL set in your Application settings. This must exactly match the `redirect_uri` passed to the authorization URL in the previous step of this tutorial. Note that this must be URL encoded. | + + +### Response + +If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `refresh_token`, `id_token`, and `token_type` values: + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/id-tokens#id-token-payload). + +[Access Tokens](/tokens/concepts/access-token) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). + +[Refresh Tokens](/tokens/concepts/refresh-tokens) are used to obtain a new Access Token or ID Token after the previous one has expired. The `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. + +::: warning +Refresh Tokens must be stored securely since they allow a user to remain authenticated essentially forever. +::: diff --git a/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-add-login.md b/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-add-login.md new file mode 100644 index 0000000000..e72b60344a --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-add-login.md @@ -0,0 +1,94 @@ +## Sample Use Cases + +### Basic Authentication Request + +This example shows the most basic request you can make when authorizing the user in step 1. It displays the Auth0 login screen and allows the user to sign in with any of your configured connections: + +```text +https://${account.namespace}/authorize? + response_type=code& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + client_id=${account.clientId}& + redirect_uri=YOUR_CALLBACK_URL& + scope=openid +``` + +Now, when you [request tokens](/flows/guides/auth-code-pkce/add-login-auth-code-pkce#request-tokens), your ID Token will contain the most basic claims. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the User's Name and Profile Picture + +In addition to the usual user authentication, this example shows how to request additional user details, such as name and picture. + +To request the user's name and picture, you need to add the appropriate scopes when authorizing the user in step 3: + +```text +https://${account.namespace}/authorize? + response_type=code& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + client_id=${account.clientId}& + redirect_uri=YOUR_CALLBACK_URL& + scope=openid%20name%20picture& + state=STATE +``` + +Now, when you [request tokens](/flows/guides/auth-code-pkce/add-login-auth-code-pkce#request-tokens), your ID Token will contain the requested name and picture claims. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 + +In addition to the usual user authentication, this example shows how to send users directly to a social identity provider, such as GitHub. For this example to work, you will first need to [configure the appropriate connection in the Auth0 Dashboard](${manage_url}/#/connections/social) and get the connection name from the **Settings** tab. + +To send users directly to the GitHub login screen, you need to pass the `connection` parameter and set its value to the connection name (in this case, `github`) when authorizing the user in step 3: + +```text +https://${account.namespace}/authorize? + response_type=code& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + client_id=${account.clientId}& + redirect_uri=YOUR_CALLBACK_URL& + scope=openid%20name%20picture& + state=STATE& + connection=github +``` + +Now, when you [request tokens](/flows/guides/auth-code-pkce/add-login-auth-code-pkce#request-tokens), your ID Token will contain a `sub` claim with the user's unique ID returned from GitHub. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 +} +``` + +For a list of possible connections, see [Identity Providers Supported by Auth0](/identityproviders). diff --git a/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-call-api.md b/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-call-api.md new file mode 100644 index 0000000000..7cfe4d986a --- /dev/null +++ b/articles/flows/guides/auth-code-pkce/includes/sample-use-cases-call-api.md @@ -0,0 +1,29 @@ +## Sample Use Cases + +### Customize Tokens + +You can use [Rules](/rules) to change the returned scopes of Access Tokens and/or add claims to Access and ID Tokens. To do so, add the following rule, which will run after the user authenticates: + +```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); +} +``` + +Scopes will be available in the token after all rules have run. + +::: 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 custom claims added to ID Tokens or Access Tokens must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. +::: + +### View Sample Application: Mobile App + API + +For an sample implementation, see the [Mobile + API](/architecture-scenarios/application/mobile-api) architecture scenario. This series of tutorials is accompanied by a code sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets). diff --git a/articles/flows/guides/auth-code/add-login-auth-code.md b/articles/flows/guides/auth-code/add-login-auth-code.md new file mode 100644 index 0000000000..e3824d399e --- /dev/null +++ b/articles/flows/guides/auth-code/add-login-auth-code.md @@ -0,0 +1,58 @@ +--- +title: Add Login Using the Authorization Code Flow +description: Learn how to add login to your regular web application using the Authorization Code Flow. +toc: true +topics: + - api-authentication + - oidc + - authorization-code + - regular-web-apps +contentType: tutorial +useCase: + - add-login +--- +# Add Login Using the Authorization Code Flow + +::: note +This tutorial will help you add login to your regular web application using the Authorization Code Flow. If you want to learn how the flow works and why you should use it, see [Authorization Code Flow](/flows/concepts/auth-code). If you want to learn to call your API from a regular web app, see [Call Your API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code). +::: + +Auth0 makes it easy for your app to implement the Authorization Code Flow using: + +* [Regular Web App Quickstarts](/quickstart/webapp): The easiest way to implement the flow. +* Authentication API: If you prefer to roll your own, keep reading to learn how to call our API directly. + +Following successful login, your application will have access to the user's [ID Token](/tokens/concepts/id-tokens) and [Access Token](/tokens/concepts/access-tokens). The ID Token will contain basic user profile information, and the Access Token can be used to call the Auth0 /userinfo endpoint or your own protected APIs. + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register your Application with Auth0](/dashboard/guides/applications/register-app-regular-web). + * Select an **Application Type** of **Regular Web Apps**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Authorization Code**. + + +## Steps + +1. [Authorize the user](#authorize-the-user): +Request the user's authorization and redirect back to your app with an `authorization_code`. +2. [Request Tokens](#request-tokens): +Exchange your `authorization_code` for tokens. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + + +<%= include('./includes/authorize-user-add-login') %> + +<%= include('./includes/request-tokens') %> + +<%= include('./includes/sample-use-cases-add-login') %> + +## Keep reading + +- [OAuth 2.0 framework](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) + diff --git a/articles/flows/guides/auth-code/call-api-auth-code.md b/articles/flows/guides/auth-code/call-api-auth-code.md new file mode 100644 index 0000000000..51e879faa7 --- /dev/null +++ b/articles/flows/guides/auth-code/call-api-auth-code.md @@ -0,0 +1,68 @@ +--- +title: Call API Using the Authorization Code Flow +description: Learn how to call your own API from regular web apps using the Authorization Code Flow. +toc: true +topics: + - api-authentication + - oidc + - authorization-code + - regular-web-apps +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Call Your API Using the Authorization Code Flow + +::: note +This tutorial will help you call your own API using the Authorization Code Flow. If you want to learn how the flow works and why you should use it, see [Authorization Code Flow](/flows/concepts/auth-code). If you want to learn to add login to your regular web app, see [Add Login Using the Authorization Code Flow](/flows/guides/auth-code/add-login-auth-code). +::: + +Auth0 makes it easy for your app to implement the Authorization Code Flow using: + +* [Regular Web App Quickstarts](/quickstart/webapp): The easiest way to implement the flow. +* Authentication API: If you prefer to roll your own, keep reading to learn how to call our API directly. + + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register your Application with Auth0](/dashboard/guides/applications/register-app-regular-web). + * Select an **Application Type** of **Regular Web Apps**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Authorization Code**. + * If you want your Application to be able to use [Refresh Tokens](/tokens/concepts/refresh-tokens), make sure the Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Refresh Token**. + +* [Register your API with Auth0](/architecture-scenarios/mobile-api/part-2#create-the-api) + * If you want your API to receive Refresh Tokens to allow it to obtain new tokens when the previous ones expire, enable **Allow Offline Access**. + +## Steps + +1. [Authorize the user](#authorize-the-user): +Request the user's authorization and redirect back to your app with an authorization code. +2. [Request Tokens](#request-tokens): +Exchange your authorization code for tokens. +3. [Call your API](#call-your-api): +Use the retrieved Access Token to call your API. +4. [Refresh Tokens](#refresh-tokens): +Use a Refresh Token to request new tokens when the existing ones expire. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + + +<%= include('./includes/authorize-user-call-api') %> + +<%= include('./includes/request-tokens') %> + +<%= include('./includes/call-api') %> + +<%= include('./includes/refresh-tokens') %> + +<%= include('./includes/sample-use-cases-call-api') %> + +## Keep reading + +- [OAuth 2.0 framework](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/auth-code/includes/authorize-user-add-login.md b/articles/flows/guides/auth-code/includes/authorize-user-add-login.md new file mode 100644 index 0000000000..2d9c1a18ff --- /dev/null +++ b/articles/flows/guides/auth-code/includes/authorize-user-add-login.md @@ -0,0 +1,53 @@ +## Authorize the User + +To begin the flow, you'll need to get the user's authorization. This step may include one or more of the following processes: + +* Authenticating the user; +* Redirecting the user to an Identity Provider to handle authentication; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the [authorization URL](/api/authentication#authorization-code-flow). + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=SCOPE& + state=STATE +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `response_type` | Denotes the kind of credential that Auth0 will return (`code` or `token`). For this flow, the value must be `code`. | +| `client_id` | Your application's Client ID. You can find this value in your [Application 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. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | Specifies the [scopes](/scopes) for which you want to request authorization, which dictate which claims (or user attributes) you want returned. These must be separated by a space. To get an ID Token in the response, you need to specify a scope of at least `openid`. If you want to return the user's full profile, you can request `openid profile`. 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 `email`, or [custom claims](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [Application Settings](${manage_url}/#/applications)). | +| `state` | (recommended) An opaque arbitrary alphanumeric string your app adds to the initial request that Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | +| `connection` | (optional) Forces the user to sign in with a specific connection. For example, you can pass a value of `github` to send the user directly to GitHub to log in with their GitHub account. When not specified, the user sees the Auth0 Lock screen with all configured connections. You can see a list of your configured connections on the **Connections** tab of your application. | + +As an example, your HTML snippet for your authorization URL when adding login to your app might look like: + +```html + + Sign In + +``` + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The authorization code is included at the end of the URL: + +```text +HTTP/1.1 302 Found +Location: ${account.callback}?code=AUTHORIZATION_CODE&state=xyzABC123 +``` diff --git a/articles/flows/guides/auth-code/includes/authorize-user-call-api.md b/articles/flows/guides/auth-code/includes/authorize-user-call-api.md new file mode 100644 index 0000000000..69a5106534 --- /dev/null +++ b/articles/flows/guides/auth-code/includes/authorize-user-call-api.md @@ -0,0 +1,63 @@ +## Authorize the User + +To begin the flow, you'll need to get the user's authorization. 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; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the [authorization URL](/api/authentication#authorization-code-grant). + + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=SCOPE& + audience=API_AUDIENCE& + state=STATE +``` + +#### Parameters + +Note that for authorizing a user when calling a custom API, you: + +- must include an audience parameter +- can include additional scopes supported by the target API + + +| Parameter Name | Description | +|-----------------|-------------| +| `response_type` | Denotes the kind of credential that Auth0 will return (`code` or `token`). For this flow, the value must be `code`. | +| `client_id` | Your application's Client ID. You can find this value in your [Application 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. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | Specifies the [scopes](/scopes) for which you want to request authorization, which dictate which claims (or user attributes) you want returned. 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` or `email`, [custom claims](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (e.g., `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [Application Settings](${manage_url}/#/applications)). | +| `audience` | The unique identifier of the API your 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. | +| `state` | (recommended) An opaque arbitrary alphanumeric string your app adds to the initial request that Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | + +As an example, your HTML snippet for your authorization URL when calling an API might look like: + +```html + + Sign In + +``` + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The authorization code is included at the end of the URL: + +```text +HTTP/1.1 302 Found +Location: ${account.callback}?code=AUTHORIZATION_CODE&state=xyzABC123 +``` diff --git a/articles/flows/guides/auth-code/includes/call-api.md b/articles/flows/guides/auth-code/includes/call-api.md new file mode 100644 index 0000000000..c621fb6d86 --- /dev/null +++ b/articles/flows/guides/auth-code/includes/call-api.md @@ -0,0 +1,15 @@ +## Call your API + +To call your API from a regular web application, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request. + + + ```har +{ + "method": "GET", + "url": "https://myapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` diff --git a/articles/flows/guides/auth-code/includes/refresh-tokens.md b/articles/flows/guides/auth-code/includes/refresh-tokens.md new file mode 100644 index 0000000000..4ebc667073 --- /dev/null +++ b/articles/flows/guides/auth-code/includes/refresh-tokens.md @@ -0,0 +1,66 @@ +## Refresh Tokens + +You have already received a Refresh Token if you've been following this tutorial and completed the following: + +* configured your API to allow offline access +* included the `offline_access` scope when you initiated the authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint + +You can use the Refresh Token to get a new Access Token. Usually, a user will need a new Access Token only after the previous one expires or when gaining access to a new resource for the first time. It's bad practice to call the endpoint to get a new Access Token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. + +To refresh your token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`. + +### Example POST to token URL + +```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": "refresh_token", + "value": "YOUR_REFRESH_TOKEN" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "refresh_token". | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `refresh_token` | The Refresh Token to use. | +| `scope` | (optional) 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. | + +### Response + +If all goes well, you'll receive an `HTTP 200` response with a payload containing a new `access_token`, its lifetime in seconds (`expires_in`), granted `scope` values, and `token_type`. If the scope of the initial token included `openid`, then the response will also include a new `id_token`: + +```json +{ + "access_token": "eyJ...MoQ", + "expires_in": 86400, + "scope": "openid offline_access", + "id_token": "eyJ...0NE", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: diff --git a/articles/flows/guides/auth-code/includes/request-tokens.md b/articles/flows/guides/auth-code/includes/request-tokens.md new file mode 100644 index 0000000000..6a468fe06c --- /dev/null +++ b/articles/flows/guides/auth-code/includes/request-tokens.md @@ -0,0 +1,78 @@ +## Request Tokens + +Now that you have an Authorization Code, you must exchange it for tokens. Using the extracted Authorization Code (`code`) from the previous step, you will need to `POST` to the [token URL](/api/authentication#authorization-code). + +### Example POST to token URL + +```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}" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "authorization_code". | +| `code` | The `authorization_code` retrieved in the previous step of this tutorial. | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `client_secret` | Your application's Client Secret. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `redirect_uri` | The valid callback URL set in your Application settings. This must exactly match the `redirect_uri` passed to the authorization URL in the previous step of this tutorial. Note that this must be URL encoded. | + + +### Response + +If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `refresh_token`, `id_token`, and `token_type` values: + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "refresh_token": "GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Token](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/id-tokens#id-token-payload). + +[Access Tokens](/tokens/concepts/access-tokens) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). + +[Refresh Tokens](/tokens/concepts/refresh-tokens) are used to obtain a new Access Token or ID Token after the previous one has expired. The `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. + +::: warning +Refresh Tokens must be stored securely since they allow a user to remain authenticated essentially forever. +::: diff --git a/articles/flows/guides/auth-code/includes/sample-use-cases-add-login.md b/articles/flows/guides/auth-code/includes/sample-use-cases-add-login.md new file mode 100644 index 0000000000..f0a6478f24 --- /dev/null +++ b/articles/flows/guides/auth-code/includes/sample-use-cases-add-login.md @@ -0,0 +1,87 @@ +## Sample Use Cases + +### Basic Authentication Request + +This example shows the most basic request you can make when authorizing the user in step 1. It displays the Auth0 login screen and allows the user to sign in with any of your configured connections: + +```text +https://${account.namespace}/authorize? + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=openid +``` + +Now, when you [request tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens), your ID Token will contain the most basic claims. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the User's Name and Profile Picture + +In addition to the usual user authentication, this example shows how to request additional user details, such as name and picture. + +To request the user's name and picture, you need to add the appropriate scopes when authorizing the user in step 1: + +```text +https://${account.namespace}/authorize? + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=openid%20name%20picture& + state=STATE +``` + +Now, when you [request tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens), your ID Token will contain the requested name and picture claims. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 + +In addition to the usual user authentication, this example shows how to send users directly to a social identity provider, such as GitHub. For this example to work, you will first need to [configure the appropriate connection in the Auth0 Dashboard](${manage_url}/#/connections/social) and get the connection name from the **Settings** tab. + +To send users directly to the GitHub login screen, you need to pass the `connection` parameter and set its value to the connection name (in this case, `github`) when authorizing the user in step 1: + +```text +https://${account.namespace}/authorize? + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=openid%20name%20picture& + state=STATE& + connection=github +``` + +Now, when you [request tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens), your ID Token will contain a `sub` claim with the user's unique ID returned from GitHub. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 +} +``` + +For a list of possible connections, see [Identity Providers Supported by Auth0](/identityproviders). diff --git a/articles/flows/guides/auth-code/includes/sample-use-cases-call-api.md b/articles/flows/guides/auth-code/includes/sample-use-cases-call-api.md new file mode 100644 index 0000000000..3987b1496b --- /dev/null +++ b/articles/flows/guides/auth-code/includes/sample-use-cases-call-api.md @@ -0,0 +1,25 @@ +## Sample Use Cases + +### Customize Tokens + +You can use [Rules](/rules) to change the returned scopes of Access Tokens and/or add claims to Access and ID Tokens. To do so, add the following rule, which will run after the user authenticates: + +```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); +} +``` + +Scopes will be available in the token after all rules have run. + +::: 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 custom claims added to ID Tokens or Access Tokens must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. +::: diff --git a/articles/flows/guides/client-credentials/call-api-client-credentials.md b/articles/flows/guides/client-credentials/call-api-client-credentials.md new file mode 100644 index 0000000000..320ac08210 --- /dev/null +++ b/articles/flows/guides/client-credentials/call-api-client-credentials.md @@ -0,0 +1,56 @@ +--- +title: Call API Using the Client Credentials Flow +description: Learn how to call your API from a machine-to-machine (M2M) application using the Client Credentials Flow. +toc: true +topics: + - api-authentication + - oidc + - client-credentials + - M2M + - machine-to-machine apps +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Call Your API Using the Client Credentials Flow + +::: note +This tutorial will help you call your API from a machine-to-machine (M2M) application using the Client Credentials Flow. If you want to learn how the flow works and why you should use it, see [Client Credentials Flow](/flows/concepts/client-credentials). +::: + +Auth0 makes it easy for your app to implement the Client Credentials Flow. Following successful authentication, the calling application will have access to an [Access Token](/tokens/concepts/access-tokens), which can be used to call your protected APIs. + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register your API with Auth0](/architecture-scenarios/server-api/part-2#configure-the-api) + +* [Register the M2M Application with Auth0](/dashboard/guides/applications/register-app-m2m). + * Select an **Application Type** of **Machine to Machine Applications**. + * Choose your previously-registered API. + * Authorize the M2M Application to call your API. + +## Steps + +1. [Request a token](#request-token): +From the authorized application, request an Access Token for your API. +2. [Call your API](#call-your-api): +Use the retrieved Access Token to call your API. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + +<%= include('./includes/request-token') %> + +<%= include('./includes/call-api') %> + +<%= include('./includes/sample-use-cases') %> + +Once your API receives a request with an Access Token, it will need to validate the token. For details, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Keep reading + +- [How to change scopes and add custom claims to tokens using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/client-credentials/includes/call-api.md b/articles/flows/guides/client-credentials/includes/call-api.md new file mode 100644 index 0000000000..20650469e4 --- /dev/null +++ b/articles/flows/guides/client-credentials/includes/call-api.md @@ -0,0 +1,15 @@ +## Call your API + +To call your API from the M2M application, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request. + + + ```har +{ + "method": "GET", + "url": "https://myapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` diff --git a/articles/flows/guides/client-credentials/includes/request-token.md b/articles/flows/guides/client-credentials/includes/request-token.md new file mode 100644 index 0000000000..2e62b59a20 --- /dev/null +++ b/articles/flows/guides/client-credentials/includes/request-token.md @@ -0,0 +1,64 @@ +## Request Token + + To access your API, you must request an Access Token for it. To do so, you will need to `POST` to the [token URL](https://auth0.com/docs/api/authentication#client-credentials). + +### Example POST to token URL + +```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": "YOUR_CLIENT_ID" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "client_credentials". | +| `client_id` | Your application's Client ID. You can find this value on the [application's settings tab](${manage_url}/#/applications). | +| `client_secret` | Your application's Client Secret. You can find this value on the [application's settings tab](${manage_url}/#/applications). | +| `audience` | The audience for the token, which is your API. You can find this in the **Identifier** field on your [API's settings tab](${manage_url}/#/apis). | + + +### Response + + If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `token_type`, and `expires_in` values: + + ```json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + + +::: warning +You should validate your token before saving it. To learn how, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + diff --git a/articles/flows/guides/client-credentials/includes/sample-use-cases.md b/articles/flows/guides/client-credentials/includes/sample-use-cases.md new file mode 100644 index 0000000000..a7a969f962 --- /dev/null +++ b/articles/flows/guides/client-credentials/includes/sample-use-cases.md @@ -0,0 +1,12 @@ +## Sample Use Cases + +### Customize Tokens + +You can use [Hooks](/hooks) to change the returned scopes of Access Tokens and/or add claims to them. Auth0 invokes Hooks attached to the client credentials grant at runtime to execute your custom logic. + +For more information, see our tutorial on [Using Hooks with the Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks). + + +### View Sample Application: Server Client + API + +For a sample implementation, see the [Server Client + API](/architecture-scenarios/application/server-api) architecture scenario. This series of tutorials is accompanied by a code sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets). diff --git a/articles/flows/guides/device-auth/call-api-device-auth.md b/articles/flows/guides/device-auth/call-api-device-auth.md new file mode 100644 index 0000000000..b0f3fd4c6b --- /dev/null +++ b/articles/flows/guides/device-auth/call-api-device-auth.md @@ -0,0 +1,20 @@ +--- +title: Call API Using Device Authorization Flow +description: Learn how to call your API from an input-constrained device using the Device Authorization flow. +toc: true +topics: + - api-authentication + - oidc + - device-flow + - native-apps + - desktop-apps + - mobile-apps + - devices +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Call Your API Using the Device Authorization Flow + +<%= include('./includes/index.md') %> diff --git a/articles/flows/guides/device-auth/includes/call-api.md b/articles/flows/guides/device-auth/includes/call-api.md new file mode 100644 index 0000000000..20be11679e --- /dev/null +++ b/articles/flows/guides/device-auth/includes/call-api.md @@ -0,0 +1,15 @@ +## Call your API + +To call your API, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request. + + + ```har +{ + "method": "GET", + "url": "https://myapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` diff --git a/articles/flows/guides/device-auth/includes/index.md b/articles/flows/guides/device-auth/includes/index.md new file mode 100644 index 0000000000..a7fdf8b8f3 --- /dev/null +++ b/articles/flows/guides/device-auth/includes/index.md @@ -0,0 +1,66 @@ +::: note +This tutorial will help you call your own API from an input-constrained device using the Device Authorization Flow. If you want to learn how the flow works and why you should use it, see Device Authorization Flow. +::: + +Auth0 makes it easy for your app to implement the Device Authorization flow using: + +* Authentication API: Keep reading to learn how to call our API directly. For an interactive experience, see our Device Flow Playground. + +## Prerequisites + +**Before beginning this tutorial:** + +* Check [limitations](#limitations) to be sure the Device Authorization flow is suitable for your implementation. + +* Register the Application with Auth0. + * Select an **Application Type** of **Native**. + * If necessary, set **Allowed Web Origins**. You can use this to allow localhost as an origin for local development, or to set an allowed origin for specific TV software with architecture subject to CORS (eg: HTML5 + JS). Most applications will not use this setting. + * Ensure that the **OIDC Conformant** toggle is enabled. This setting is in the Dashboard under **Application Settings > Advanced > OAuth**. + * Make sure the Application's **Grant Types** include **Device Code**. This is also in the Dashboard, under **Application Settings > Advanced > Grant Types**. + * If you want your Application to be able to use Refresh Tokens, make sure the Application's **Grant Types** include **Refresh Token**. + +* Set up and enable at least one connection for the Application: Database connections, Social connections + +* Register your API with Auth0 + * If you want your API to receive Refresh Tokens to allow it to obtain new tokens when the previous ones expire, enable **Allow Offline Access**. + +* Configure Device User Code Settings to define the character set, format, and length of your randomly-generated user code. + +## Steps + +1. [Request device code](#request-device-code) (Device Flow): Request a device code that the user can use to authorize the device. +2. [Request device activation](#request-device-activation) (Device Flow): Request that the user authorize the device using their laptop or smartphone. +3. [Request Tokens](#request-tokens) (Device Flow): Poll the token endpoint to request a token. +4. [User authorization](#user-authorization) (Browser Flow): The user authorizes the device, so the device can receive tokens. +5. [Receive Tokens](#receive-tokens) (Device Flow): After the user successfully authorizes the device, receive tokens. +6. [Call your API](#call-your-api) (Device Flow): Use the retrieved Access Token to call your API. +7. [Refresh Tokens](#refresh-tokens) (Device Flow): Use a Refresh Token to request new tokens when the existing ones expire. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + +Optional: [Troubleshooting](#troubleshooting) + +<%= include('./request-device-code') %> + +<%= include('./request-device-activation') %> + +<%= include('./request-tokens') %> + +<%= include('./user-authorization') %> + +<%= include('./receive-tokens') %> + +<%= include('./call-api') %> + +<%= include('./refresh-tokens') %> + +<%= include('./sample-use-cases-call-api') %> + +<%= include('./troubleshooting') %> + +## Keep reading + +- The OAuth 2.0 protocol +- The OpenID Connect protocol +- Tokens +- Tenant Logs for Devices diff --git a/articles/flows/guides/device-auth/includes/receive-tokens.md b/articles/flows/guides/device-auth/includes/receive-tokens.md new file mode 100644 index 0000000000..a2350b94ad --- /dev/null +++ b/articles/flows/guides/device-auth/includes/receive-tokens.md @@ -0,0 +1,29 @@ + +## Receive Tokens + +While the user has been authenticating and authorizing the device, the device app has continued to poll the token URL to request an Access Token. + +Once the user has successfully authorized the device, you'll receive an `HTTP 200` response with a payload containing `access_token`, `refresh_token` (optionally), `id_token` (optionally), `token_type`, and `expires_in` values: + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` +::: warning +You should validate your tokens before saving them. To learn how, see [Validate Access Tokens](/tokens/guides/validate-access-tokens) and [Validate ID Tokens](/tokens/guides/validate-id-tokens). +::: + +[Access Tokens](/tokens/concepts/access-token) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. You will be able to use the Access Token to call `/userinfo` only if you included the `openid` scope. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/id-tokens#id-token-payload). The `id_token` will only be present in the response if you included the `openid` scope. + +[Refresh Tokens](/tokens/concepts/refresh-tokens) are used to obtain a new Access Token or ID Token after the previous one has expired. The `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. + +::: warning +Refresh Tokens must be stored securely since they allow a user to remain authenticated essentially forever. +::: diff --git a/articles/flows/guides/device-auth/includes/refresh-tokens.md b/articles/flows/guides/device-auth/includes/refresh-tokens.md new file mode 100644 index 0000000000..9bea311641 --- /dev/null +++ b/articles/flows/guides/device-auth/includes/refresh-tokens.md @@ -0,0 +1,71 @@ +## Refresh Tokens + +You have already received a [Refresh Token](/tokens/concepts/refresh-tokens) if you've been following this tutorial and completed the following: + +* configured your API to allow offline access +* included the `offline_access` scope when you initiated the authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint + +You can use the Refresh Token to get a new Access Token. Usually, a user will need a new Access Token only after the previous one expires or when gaining access to a new resource for the first time. It's bad practice to call the endpoint to get a new Access Token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. + +To refresh your token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`. + +### Example refresh token POST to token URL + +```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": "${account.clientSecret}" + }, + { + "name": "refresh_token", + "value": "YOUR_REFRESH_TOKEN" + } + ] + } +} +``` + +#### Refresh Token Request Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "refresh_token". | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `client_secret` | Your application's Client Secret. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientSecret}/settings). | +| `refresh_token` | The Refresh Token to use. | +| `scope` | (Optional) 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. | + +### Refresh Token Response + +If all goes well, you'll receive an `HTTP 200` response with a payload containing a new `access_token`, `id_token` (optionally), token lifetime in seconds (`expires_in`), granted `scope` values, and `token_type`: + +```json +{ + "access_token": "eyJ...MoQ", + "expires_in": 86400, + "scope": "openid offline_access", + "id_token": "eyJ...0NE", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate Access Tokens](/tokens/guides/validate-access-tokens) and [Validate ID Tokens](/tokens/guides/validate-id-tokens). +::: diff --git a/articles/flows/guides/device-auth/includes/request-device-activation.md b/articles/flows/guides/device-auth/includes/request-device-activation.md new file mode 100644 index 0000000000..b6429b9025 --- /dev/null +++ b/articles/flows/guides/device-auth/includes/request-device-activation.md @@ -0,0 +1,11 @@ +## Request Device Activation + +Once you have received a `device_code` and `user_code`, you must ask the user to go to the `verification_uri` on their laptop or smartphone and enter the `user_code`: + +![Request Device Activation](/media/articles/flows/guides/device-auth/request-device-activation.png) + +The `device_code` is not intended for the user directly and should not be displayed during the interaction to avoid confusing the user. + +::: note +When building a CLI, you could skip this step and immediately open the browser with `verification_uri_complete`. +::: diff --git a/articles/flows/guides/device-auth/includes/request-device-code.md b/articles/flows/guides/device-auth/includes/request-device-code.md new file mode 100644 index 0000000000..4aca46bb7a --- /dev/null +++ b/articles/flows/guides/device-auth/includes/request-device-code.md @@ -0,0 +1,89 @@ +## Request Device Code + +Once the user has started their device app and wants to authorize the device, you'll need to get a device code. When the user begins their session in their browser-based device, this code will be bound to that session. + +To get the device code, your app must request a code from the [device code URL](/api/authentication#get-device-code), including the Client ID. + +### Example POST to device code URL + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/device/code", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData" : { + "mimeType": "application/x-www-form-urlencoded", + "params" : [ + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "scope", + "value": "SCOPE" + }, + { + "name": "audience", + "value": "AUDIENCE" + } + ] + } +} +``` + +#### Device Code Parameters + +Note that when requesting a device code to call a custom API, you: + +- must include an audience parameter +- can include additional scopes supported by the target API + +::: note + If your app wants an Access Token only to retrieve info about the authenticated user, then no audience parameter is required. +::: + +| Parameter Name | Description | +|-----------------|-------------| +| `client_id` |Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `scope` | The [scopes](/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](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims), or any [scopes supported by the target API](/scopes/current/api-scopes) (e.g., `read:contacts`). Include `openid` to get an ID Token or to be able to use the [/userinfo endpoint](/api/authentication#user-profile) to retrieve profile information for the user. 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)). Note that this must be URL encoded. | +|`audience` | The unique identifier of the API your 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. Note that this must be URL encoded. | + +### Device Code Response + +If all goes well, you'll receive an HTTP 200 response with a payload containing `device_code`, `user_code`, `verification_uri`, and `expires_in`, `interval`, and `verification_uri_complete` values: + +```json +{ + "device_code": "Ag_EE...ko1p", + "user_code": "QTZL-MCBW", + "verification_uri": "https://accounts.acmetest.org/activate", + "verification_uri_complete": "https://accounts.acmetest.org/activate?user_code=QTZL-MCBW", + "expires_in": 900, + "interval": 5 +} +``` + +* `device_code` is the unique code for the device. When the user goes to the `verification_uri` in their browser-based device, this code will be bound to their session. +* `user_code` contains the code that should be input at the `verification_uri` to authorize the device. +* `verification_uri` contains the URL the user should visit to authorize the device. +* `verification_uri_complete` contains the complete URL the user should visit to authorize the device. This allows your app to embed the `user_code` in the URL, if you so choose. +* `expires_in` indicates the lifetime (in seconds) of the `device_code` and `user_code`. +* `interval` indicates the interval (in seconds) at which the app should poll the token URL to request a token. + +::: note +You can [configure the character set, format, and length of your randomly-generated user code](/dashboard/guides/tenants/configure-device-user-code-settings) in your tenant settings. + +To prevent brute force attacks, we enforce the following limits on `user_code`: + +**Minimum length**: +* BASE20 Letters: 8 characters +* Numbers: 9 characters + +**Maximum length**: +* 20 characters (including hyphens and spaces, which may be added as separators for readability) + +**Expiration time**: +* 15 minutes +::: diff --git a/articles/flows/guides/device-auth/includes/request-tokens.md b/articles/flows/guides/device-auth/includes/request-tokens.md new file mode 100644 index 0000000000..d2b1de6a53 --- /dev/null +++ b/articles/flows/guides/device-auth/includes/request-tokens.md @@ -0,0 +1,107 @@ +## Request Tokens + +While you are waiting for the user to activate the device, begin polling the token URL to request an Access Token. Using the extracted polling interval (`interval`) from the previous step, you will need to `POST` to the [token URL](/api/authentication#device-auth) sending along the `device_code`. + +To avoid errors due to network latency, you should start counting each interval after receipt of the last polling request's response. + +### Example request token POST to token URL + +```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": "urn:ietf:params:oauth:grant-type:device_code" + }, + { + "name": "device_code", + "value": "YOUR_DEVICE_CODE" + }, + { + "name": "client_id", + "value": "${account.clientId}" + } + ] + } +} +``` + +#### Token Request Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "urn:ietf:params:oauth:grant-type:device_code". This is an extension grant type (as defined by Section 4.5 of [RFC6749](https://tools.ietf.org/html/rfc6749#section-4.5)). Note that this must be URL encoded. | +| `device_code` | The `device_code` retrieved in the previous step of this tutorial. | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | + +### Token Responses + +While you wait for the user to authorize the device, you may receive a few different `HTTP 4xx` responses: + +#### Authorization pending + +You will see this error while waiting for the user to take action. Continue polling using the suggested interval retrieved in the previous step of this tutorial. + +```json +`HTTP 403` + +{ + "error": "authorization_pending", + "error_description": "..." +} +``` + +#### Slow down + +You are polling too fast. Slow down and use the suggested interval retrieved in the previous step of this tutorial. To avoid receiving this error due to network latency, you should start counting each interval after receipt of the last polling request's response. + +```json +`HTTP 429` + +{ + "error": "slow_down", + "error_description": "..." +} +``` + +#### Expired Token + +The user has not authorized the device quickly enough, so the `device_code` has expired. Your application should notify the user that the flow has expired and prompt them to reinitiate the flow. + +::: note +Then `expired_token` error will be returned exactly once; after that, the dreaded `invalid_grant` will be returned. Your device *must* stop polling. +::: + +```json +`HTTP 403` + +{ + "error": "expired_token", + "error_description": "..." +} +``` + +#### Access Denied + +Finally, if access is denied, you will receive: + +```json +`HTTP 403` + +{ + "error": "access_denied", + "error_description": "..." +} +``` +This can occur for a variety of reasons, including: + +* the user refused to authorize the device +* the authorization server denied the transaction +* a configured [Rule](/rules) denied access diff --git a/articles/flows/guides/device-auth/includes/sample-use-cases-call-api.md b/articles/flows/guides/device-auth/includes/sample-use-cases-call-api.md new file mode 100644 index 0000000000..8b5955b216 --- /dev/null +++ b/articles/flows/guides/device-auth/includes/sample-use-cases-call-api.md @@ -0,0 +1,21 @@ +## Sample Use Cases + +### Detect Device Authorization Flow Use + +You can use [Rules](/rules) to detect whether the current transaction is using the Device Authorization Flow. To do so, check the `context` object's `protocol` property: + +```javascript +function (user, context, callback) { + if (context.protocol === 'oauth2-device-code') { + ... + } + + callback(null, user, context); +} +``` + +### Sample Implementations + +* [Device Authorization Playground](https://auth0.github.io/device-flow-playground/) +* [AppleTV (Swift)](https://github.com/pushpabrol/auth0-device-flow-appletv): Simple application that shows how Auth0 can be used with the Device Authorization Flow from an AppleTV. +* [CLI (Node.js)](https://gist.github.com/panva/652c61e7d847e0ed99926c324fa91b36): Sample implementation of a CLI that uses the Device Authorization Flow instead of the Authorization Code Flow. The major difference is that your CLI does not need to host a webserver and listen on a port. \ No newline at end of file diff --git a/articles/flows/guides/device-auth/includes/troubleshooting.md b/articles/flows/guides/device-auth/includes/troubleshooting.md new file mode 100644 index 0000000000..7815d9016d --- /dev/null +++ b/articles/flows/guides/device-auth/includes/troubleshooting.md @@ -0,0 +1,29 @@ +# Troubleshooting + +[Tenant logs](/logs) are created for any interaction that takes place and can be used to troubleshoot issues. + +## Error codes + +| Code | Name | Description | +|------------|------|-------------| +| `fdeaz` | Failed device authorization request | | +| `fdeac` | Failed device activation | | +| `fdecc` | User canceled the device confirmation | | +| `fede` | Failed Exchange | Device Code for Access Token | +| `sede` | Success Exchange | Device Code for Access Token | + +## Limitations + +To use the Device Authorization Flow, devices must: + +* Support Server Name Indication (SNI) +* Have an [Auth0 application type](/applications) of **Native** +* Have the [**Token Endpoint Authentication Method**](/dashboard/reference/settings-application) set to **None** +* Be [OIDC-conformant](/dashboard/reference/settings-application#oauth) +* Not be created through [Dynamic Client Registration](/api-auth/dynamic-client-registration) + +In addition, the Device Authorization Flow does not allow: +* [Social Connections](/connections) using [Auth0 developer keys](/connections/social/devkeys) unless you are using new [New Universal Login Experience](/universal-login/new). +* Query string parameters to be accessed from hosted login page or rules + +We support the full [Draft 15](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15), except for confidential Clients. diff --git a/articles/flows/guides/device-auth/includes/user-authorization.md b/articles/flows/guides/device-auth/includes/user-authorization.md new file mode 100644 index 0000000000..360a4bb7cf --- /dev/null +++ b/articles/flows/guides/device-auth/includes/user-authorization.md @@ -0,0 +1,24 @@ +## User Authorization + +The user will either scan the QR code, or else will open the activation page and enter the user code: + +![Enter User Code](/media/articles/flows/guides/device-auth/enter-user-code.png) + +A confirmation page will be shown to have the user confirm that this is the right device: + +![Confirm Device](/media/articles/flows/guides/device-auth/confirm-device.png) + +The user will complete the transaction by signing in. 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 SSO sessions; +* Obtaining user consent for the device, unless consent has been previously given. + +![Authenticate User](/media/articles/flows/guides/device-auth/user-auth.png) + +Upon successful authentication and consent, the confirmation prompt will be shown: + +![User Confirmation](/media/articles/flows/guides/device-auth/user-confirmation.png) + +At this point, the user has authenticated, and the device has been authorized. \ No newline at end of file diff --git a/articles/flows/guides/implicit/add-login-implicit.md b/articles/flows/guides/implicit/add-login-implicit.md new file mode 100644 index 0000000000..36373a31b2 --- /dev/null +++ b/articles/flows/guides/implicit/add-login-implicit.md @@ -0,0 +1,54 @@ +--- +title: Add Login Using the Implicit Flow with Form Post +description: Learn how to add login to your single-page application (SPA) using the Implicit Flow with Form Post. +toc: true +topics: + - api-authentication + - oidc + - hybrid-flow + - implicit-flow + - SPA + - single-page apps +contentType: tutorial +useCase: + - add-login +--- +# Add Login Using the Implicit Flow with Form Post + +::: note +This tutorial will help you add login to your single-page application (SPA) using the Implicit Flow with Form Post. If you want to learn how the flow works and why you should use it, see [Implicit Flow with Form Post](/flows/concepts/implicit). + +You can use the Implicit Flow with Form Post for login-only use cases; if you need to request Access Tokens while logging the user in so you can call your API, use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). +::: + +Auth0 makes it easy to implement the Implicit Flow with Form Post by using: + +* [Express OpenID Connect SDK](https://www.npmjs.com/package/express-openid-connect): The easiest way to implement the flow, which will do most of the heavy-lifting for you. If you use our [Javascript SDK](/libraries/auth0js), please ensure you are implementing mitigations that are appropriate for your architecture. +* Authentication API: If you prefer to roll your own solution, keep reading to learn how to call our API directly. + +Following successful login, your application will have access to the user's [ID Token](/tokens/id-tokens). The ID Token will contain basic user profile information. + +## Prerequisites + +**Before beginning this tutorial:** + +* [Register your Application with Auth0](applications/spa) + * Select an **Application Type** of **Single-Page App**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Implicit**. + +## Steps + +1. [Authorize the user](#authorize-the-user): Request the user's authorization and redirect back to your app. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + +<%= include('./includes/authorize-user-add-login') %> + +<%= include('./includes/sample-use-cases-add-login') %> + +## Keep reading + +- [The OAuth 2.0 protocol](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/implicit/call-api-implicit.md b/articles/flows/guides/implicit/call-api-implicit.md new file mode 100644 index 0000000000..c524badcde --- /dev/null +++ b/articles/flows/guides/implicit/call-api-implicit.md @@ -0,0 +1,57 @@ +--- +title: Call API Using the Implicit Flow +description: Learn how to call your API from single-page apps (SPA) using the Implicit Flow. +toc: true +topics: + - api-authentication + - oidc + - implicit-flow + - single-page apps + - SPA +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Call Your API Using the Implicit Flow + +::: note +This tutorial will help you call your own API from a single-page application (SPA) using the Implicit Flow. If you want to learn how the flow works and why you should use it, see [Implicit Flow](/flows/concepts/implicit). If you want to learn to add login to your single-page application (SPA), see [Add Login Using the Implicit Flow](/flows/guides/implicit/add-login-implicit). +::: + +Auth0 makes it easy for your app to implement the Implicit Flow using: + +* [Auth0.js](/libraries/auth0js): The easiest way to implement the flow, which will do most of the heavy-lifting for you. Our [Single-Page App Quickstarts](/quickstart/spa) will walk you through the process. +* Authentication API: If you prefer to roll your own, keep reading to learn how to call our API directly. + +## 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 an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include **Implicit**. + +* [Register your API with Auth0](/architecture-scenarios/spa-api/part-2#create-the-api) + +## Steps + +1. [Authorize the user](#authorize-the-user): +Request the user's authorization and redirect back to your app with the requested credentials. +2. [Call Your API](#call-your-api): +Use the retrieved Access Token to call your API. + +Optional: [Explore Sample Use Cases](#sample-use-cases) + +<%= include('./includes/authorize-user-call-api') %> + +<%= include('./includes/call-api') %> + +<%= include('./includes/sample-use-cases-call-api') %> + +## Keep reading + +- [OAuth 2.0 framework](/protocols/oauth2) +- [OpenID Connect (OIDC) protocol](/protocols/oidc) +- [Tokens](/tokens) diff --git a/articles/flows/guides/implicit/includes/authorize-user-add-login.md b/articles/flows/guides/implicit/includes/authorize-user-add-login.md new file mode 100644 index 0000000000..8f057fee2e --- /dev/null +++ b/articles/flows/guides/implicit/includes/authorize-user-add-login.md @@ -0,0 +1,80 @@ +## Authorize the user + +To begin the flow, you'll need to get the user's authorization. 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; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the authorization URL. + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=YOUR_RESPONSE_TYPE& + response_mode=form_post& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=STATE& + nonce=NONCE +``` + +#### Parameters + +| Parameter Name | Description | +| -------------- | ----------- | +| `response_type` | Denotes the kind of credential that Auth0 will return (code or token). For the Implicit Flow, the value can be `id_token`, `token`, or `id_token token`. Specifically, `id_token` returns an ID Token, and `token` returns an Access Token. | +| `response_mode` | Specifies the method with which response parameters should be returned. For security purposes, the value should be `form_post`. In this mode, response parameters will be encoded as HTML form values that are transmitted via the HTTP POST method and encoded in the body using the `application/x-www-form-urlencoded` format. | +| `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. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | Specifies the [scopes](/scopes) for which you want to request authorization, which dictate which claims (or user attributes) you want returned. 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](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). | +| `state` | (recommended) An opaque arbitrary alphanumeric string that your app adds to the initial request and Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | +| `nonce` | (required for `response_type` containing `id_token token`, otherwise recommended) A cryptographically random string that your app adds to the initial request and Auth0 includes inside the ID Token, [used to prevent token replay attacks](/api-auth/tutorials/nonce). | +| `connection` | (optional) Forces the user to sign in with a specific connection. For example, you can pass a value of `github` to send the user directly to GitHub to log in with their GitHub account. When not specified, the user sees the Auth0 Lock screen with all configured connections. You can see a list of your configured connections on the **Connections** tab of your application. | + +As an example, your HTML snippet for your authorization URL when adding login to your app might look like: + +```html + + Sign In + +``` + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The requested credentials are encoded in the body: + +```text +HTTP/1.1 302 Found +Content-Type: application/x-www-form-urlencoded + +id_token=eyJ...acA& +state=xyzABC123 +``` + +Note that the returned values depend on what you requested as a `response_type`. + +| Response Type | Components | +| ------------------- | ---------- | +| id_token | ID Token | +| token | Access Token (plus `expires_in` and `token_type` values) | +| id_token token | ID Token, Access Token (plus `expires_in` and `token_type` values) | + +Auth0 will also return any state value you included in your call to the authorization URL. + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/concepts/id-tokens#id-token-payload). + +[Access Tokens](/tokens/concepts/access-tokens) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). \ No newline at end of file diff --git a/articles/flows/guides/implicit/includes/authorize-user-call-api.md b/articles/flows/guides/implicit/includes/authorize-user-call-api.md new file mode 100644 index 0000000000..08d668c77e --- /dev/null +++ b/articles/flows/guides/implicit/includes/authorize-user-call-api.md @@ -0,0 +1,78 @@ +## Authorize the user + +To begin the flow, you'll need to get the user's authorization. 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; +* Obtaining user consent for the requested permission level, unless consent has been previously given. + +To authorize the user, your app must send the user to the authorization URL. + +### Example authorization URL + +```text +https://${account.namespace}/authorize? + response_type=YOUR_RESPONSE_TYPE& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=YOUR_SCOPE& + audience=YOUR_API_AUDIENCE& + state=STATE& + nonce=NONCE +``` + +#### Parameters + +| Parameter Name | Description | +| -------------- | ----------- | +| `response_type` | Denotes the kind of credential that Auth0 will return (code or token). For the Implicit Flow, the value can be `id_token`, `token`, or `id_token token`. Specifically, `id_token` returns an ID Token, and `token` returns 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 Auth0 will redirect the browser after authorization has been granted by the user. You must specify this URL as a valid callback URL in your [Application 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. | +| `scope` | Specifies the [scopes](/scopes) for which you want to request authorization, which dictate which claims (or user attributes) you want returned. 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](/tokens/concepts/jwt-claims#custom-claims) conforming to a [namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). | +| `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. | +| `state` | (recommended) An opaque arbitrary alphanumeric string that your app adds to the initial request and Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). | +| `nonce` | (required for `response_type` containing `id_token token`, otherwise recommended) A cryptographically random string that your app adds to the initial request and Auth0 includes inside the ID Token, [used to prevent token replay attacks](/api-auth/tutorials/nonce). | + +As an example, your HTML snippet for your authorization URL when adding login to your app might look like: + +```html + + Sign In + +``` + + +### Response + +If all goes well, you'll receive an `HTTP 302` response. The requested credentials are included in a hash fragment at the end of the URL: + +```text +HTTP/1.1 302 Found +Location: ${account.callback}#access_token=ey...MhPw&expires_in=7200&token_type=Bearer&id_token=ey...Fyqk&state=xyzABC123 +``` + +Note that the returned values depend on what you requested as a `response_type`. + +| Response Type | Components | +| ------------------- | ---------- | +| id_token | ID Token | +| token | Access Token (plus `expires_in` and `token_type` values) | +| id_token token | ID Token, Access Token (plus `expires_in` and `token_type` values) | + +Auth0 will also return any state value you included in your call to the authorization URL. + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/concepts/id-tokens#id-token-payload). + +[Access Tokens](/tokens/concepts/access-tokens) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). diff --git a/articles/flows/guides/implicit/includes/call-api.md b/articles/flows/guides/implicit/includes/call-api.md new file mode 100644 index 0000000000..61d453a2c1 --- /dev/null +++ b/articles/flows/guides/implicit/includes/call-api.md @@ -0,0 +1,15 @@ +## Call your API + +To call your API from a SPA, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request. + + + ```har +{ + "method": "GET", + "url": "https://myapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` diff --git a/articles/flows/guides/implicit/includes/refresh-tokens.md b/articles/flows/guides/implicit/includes/refresh-tokens.md new file mode 100644 index 0000000000..4ebc667073 --- /dev/null +++ b/articles/flows/guides/implicit/includes/refresh-tokens.md @@ -0,0 +1,66 @@ +## Refresh Tokens + +You have already received a Refresh Token if you've been following this tutorial and completed the following: + +* configured your API to allow offline access +* included the `offline_access` scope when you initiated the authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint + +You can use the Refresh Token to get a new Access Token. Usually, a user will need a new Access Token only after the previous one expires or when gaining access to a new resource for the first time. It's bad practice to call the endpoint to get a new Access Token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. + +To refresh your token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`. + +### Example POST to token URL + +```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": "refresh_token", + "value": "YOUR_REFRESH_TOKEN" + } + ] + } +} +``` + +#### Parameters + +| Parameter Name | Description | +|-----------------|-------------| +| `grant_type` | Set this to "refresh_token". | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `refresh_token` | The Refresh Token to use. | +| `scope` | (optional) 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. | + +### Response + +If all goes well, you'll receive an `HTTP 200` response with a payload containing a new `access_token`, its lifetime in seconds (`expires_in`), granted `scope` values, and `token_type`. If the scope of the initial token included `openid`, then the response will also include a new `id_token`: + +```json +{ + "access_token": "eyJ...MoQ", + "expires_in": 86400, + "scope": "openid offline_access", + "id_token": "eyJ...0NE", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: diff --git a/articles/flows/guides/implicit/includes/request-tokens.md b/articles/flows/guides/implicit/includes/request-tokens.md new file mode 100644 index 0000000000..406e1564ad --- /dev/null +++ b/articles/flows/guides/implicit/includes/request-tokens.md @@ -0,0 +1,78 @@ +## Request Tokens + +Now that you have an authorization code, you can exchange it for tokens. The Access Token you receive will allow you to call the API specified when you authorized the user. Using the extracted Authorization Code (`code`) from the first step, you will need to `POST` to the [Token URL](/api/authentication?http#authorization-code). + +### Example POST to token URL + +```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": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "redirect_uri", + "value": "${account.callback}" + } + ] + } +} +``` + +#### Parameters + +| Parameter | Description | +| --------- | ----------- | +| `grant_type` | Set this to "authorization_code". | +| `code` | The `authorization_code` retrieved in the previous step of this tutorial. | +| `client_id` | Your application's Client ID. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `client_secret` | Your application's Client Secret. You can find this value in your [Application Settings](${manage_url}/#/Applications/${account.clientId}/settings). | +| `redirect_uri` | The valid callback URL set in your Application settings. This must exactly match the `redirect_uri` passed to the authorization URL in the previous step of this tutorial. Note that this must be URL encoded. | + + +### Response + +If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `refresh_token`, `id_token`, and `token_type` values: + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "refresh_token": "GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type": "Bearer" +} +``` + +::: warning +You should validate your tokens before saving them. To learn how, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) and [Validate Access Tokens](/tokens/guides/validate-access-tokens). +::: + +[ID Tokens](/tokens/concepts/id-tokens) contain user information that must be [decoded and extracted](/tokens/concepts/id-tokens#id-token-payload). + +[Access Tokens](/tokens/concepts/access-token) are used to call the [Auth0 Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or another API. If you are calling your own API, the first thing your API will need to do is [verify the Access Token](/tokens/guides/validate-access-tokens). + +[Refresh Tokens](/tokens/concepts/refresh-tokens) are used to obtain a new Access Token or ID Token after the previous one has expired. The `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. + +::: warning +Refresh Tokens must be stored securely since they allow a user to remain authenticated essentially forever. +::: diff --git a/articles/flows/guides/implicit/includes/sample-use-cases-add-login.md b/articles/flows/guides/implicit/includes/sample-use-cases-add-login.md new file mode 100644 index 0000000000..410a8637a1 --- /dev/null +++ b/articles/flows/guides/implicit/includes/sample-use-cases-add-login.md @@ -0,0 +1,83 @@ +## Sample Use Cases + +### Basic Authentication Request + +This example shows the most basic request you can make when authorizing the user in step 1. It displays the Auth0 login screen and allows the user to sign in with any of your configured connections: + +```text +https://${account.namespace}/authorize? + response_type=id_token& + response_mode=form_post& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + nonce=NONCE +``` + +This will return an ID Token, which you can parse from your redirect URL. + + +### Request the User's Name and Profile Picture + +In addition to the usual user authentication, this example shows how to request additional user details, such as name and picture. + +To request the user's name and picture, you need to add the appropriate scopes when authorizing the user in step 1: + +```text +https://${account.namespace}/authorize? + response_type=id_token token& + response_mode=form_post& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=openid%20name%20picture& + state=STATE& + nonce=NONCE +``` + +Now, your ID Token will contain the requested name and picture claims. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 + +In addition to the usual user authentication, this example shows how to send users directly to a social identity provider, such as GitHub. For this example to work, you will first need to [configure the appropriate connection in the Auth0 Dashboard](${manage_url}/#/connections/social) and get the connection name from the **Settings** tab. + +To send users directly to the GitHub login screen, you need to pass the `connection` parameter and set its value to the connection name (in this case, `github`) when authorizing the user in step 1: + +```text +https://${account.namespace}/authorize? + response_type=id_token token& + response_mode=form_post& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + scope=openid%20name%20picture& + state=STATE& + nonce=NONCE& + connection=github +``` + +Now, your ID Token will contain a `sub` claim with the user's unique ID returned from GitHub. When you [decode the ID Token](/tokens/id-tokens#id-token-payload), it will look similar to: + +```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 +} +``` + +For a list of possible connections, see [Identity Providers Supported by Auth0](/identityproviders). diff --git a/articles/flows/guides/implicit/includes/sample-use-cases-call-api.md b/articles/flows/guides/implicit/includes/sample-use-cases-call-api.md new file mode 100644 index 0000000000..3987b1496b --- /dev/null +++ b/articles/flows/guides/implicit/includes/sample-use-cases-call-api.md @@ -0,0 +1,25 @@ +## Sample Use Cases + +### Customize Tokens + +You can use [Rules](/rules) to change the returned scopes of Access Tokens and/or add claims to Access and ID Tokens. To do so, add the following rule, which will run after the user authenticates: + +```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); +} +``` + +Scopes will be available in the token after all rules have run. + +::: 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 custom claims added to ID Tokens or Access Tokens must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. +::: diff --git a/articles/flows/index.md b/articles/flows/index.md new file mode 100644 index 0000000000..424e69d796 --- /dev/null +++ b/articles/flows/index.md @@ -0,0 +1,90 @@ +--- +url: /flows +section: articles +classes: topic-page +title: Authentication and Authorization Flows +description: Introduction to the various flows used for authentication and authorization of applications and APIs. +topics: + - api-authentication + - api-authorization + - oidc +contentType: index +useCase: + - secure-api + - call-api + - add-login +--- + +
      +
      +

      Authentication and Authorization Flows

      +

      Introduction to the various flows used for authentication and authorization of applications and APIs.

      +
      + +Auth0 uses [OpenID Connect (OIDC)](/protocols/oidc) and [OAuth 2.0](/protocols/oauth2) to authenticate users and get their authorization to access protected resources. With Auth0, you can easily support different flows in your own applications and APIs without worrying about the OAuth 2.0/OIDC specification or the other technical aspects of authentication and authorization. + +We support scenarios for server-side, mobile, desktop, client-side, machine-to-machine, and device applications. + + diff --git a/articles/getting-started/_list-processes.md b/articles/getting-started/_list-processes.md index 7b9dc2fa64..b8d018dc5a 100644 --- a/articles/getting-started/_list-processes.md +++ b/articles/getting-started/_list-processes.md @@ -1,31 +1,33 @@ <% if (screen === "dashboard") { %> This is the dashboard home page. Here you can view statistics about your apps: the login activity for the past year, the logins and new signups for the past week, a list of the latest signups, and more. [More docs on the dashboard](/dashboard). -<% } else if (screen === "clients") { %> +<% } else if (screen === "applications") { %> Use this page to manage your applications. For every app of yours that you want to use Auth0, you should register an application here. You can create new applications, view your existing ones, review settings, enable connections, and more. - [More info on applications](/clients). + [More info on applications](/applications). <% } else if (screen === "apis") { %> Use this page to manage your APIs. Here you can register a new API of yours, that you want to secure with Auth0, and manage your existing ones. - [More info on APIs](/apis). + [More info on APIs](/api-auth). <% } else if (screen === "sso") { %> - Single Sign On (SSO) Integrations enable the use of external services for single sign-on. In this page you can see a list of the available external services that you can use, such as Office 365, Salesforce, and others. Here you can create a new SSO integration, find tutorials on how to configure it, and review and update the settings of a particular integration. - [More info on SSO Integrations](/sso/integrations). + Single Sign-on (SSO) Integrations enable the use of external services for SSO. In this page you can see a list of the available external services that you can use, such as Office 365, Salesforce, and others. Here you can create a new SSO integration, find tutorials on how to configure it, and review and update the settings of a particular integration. + [More info on SSO Integrations](/integrations/sso). <% } else if (screen === "connections") { %> Use this page to manage the identity providers that you use to login to your apps. There are four types: - - [Database](${manage_url}/#/connections/database): securely store and manage username / password credentials either in an Auth0 Database or in your own. To connect to an existing database you can use JavaScript scripts (we provide the templates) that run on Auth0's server on every authentication. Furthermore, you can migrate an existing legacy credentials database to Auth0 gradually as users authenticate (no password reset required). [More info on Database Connections](/connections/database). - - [Social](${manage_url}/#/connections/social): configure social connections like Facebook, Twitter, Github and others, so that you can let your users login with them. [More info on individual social providers](/identityproviders#social). - - [Enterprise](${manage_url}/#/connections/enterprise): configure Enterprise Connections like Active Directory, SAML, Office 365 and others so that you can let your users login with them. This way your users can use their enterprise credentials to login to your app. [More info on individual enterprise providers](/identityproviders#enterprise). - - [Passwordless](${manage_url}/#/connections/passwordless): let your users signup and login using one-time codes (delivered by email or SMS) or one-click links, instead of passwords. [More info on Passwordless](/connections/passwordless). -<% } else if (screen === "users") { %> - This is where you manage your user's identities. In this page you can view your user's profiles, create new ones, perform password resets, block and delete users, and many more. You can also use this page to log in as any of your users in order to reproduce any issues that they report and debug your application. [More info on User Management](/users). + - [Database](${manage_url}/#/connections/database): Securely store and manage username / password credentials either in an Auth0 Database or in your own. To connect to an existing database you can use JavaScript scripts (we provide the templates) that run on Auth0's server on every authentication. Furthermore, you can migrate an existing legacy credentials database to Auth0 gradually as users authenticate (no password reset required). [More info on Database Connections](/connections/database). + - [Social](${manage_url}/#/connections/social): Configure social connections like Facebook, Twitter, Github and others, so that you can let your users login with them. [More info on individual social providers](/connections/identity-providers-social). + - [Enterprise](${manage_url}/#/connections/enterprise): Configure Enterprise Connections like Active Directory, SAML, Office 365 and others so that you can let your users login with them. This way your users can use their enterprise credentials to login to your app. [More info on individual enterprise providers](/connections/identity-providers-enterprise). + - [Passwordless](${manage_url}/#/connections/passwordless): Let your users signup and login using one-time codes (delivered by email or SMS) or one-click links, instead of passwords. [More info on Passwordless](/connections/passwordless). + <% } else if (screen === "universal-login") { %> + This is where you can create a beautiful universal login page where you can redirect to authenticate your users, customize the look and feel of your login page with CSS and HTML, and implement SSO in your applications with the flip of a switch. [More info on Universal Login](/universal-login). +<% } else if (screen === "users-roles") { %> + This is where you manage your user's identities and permissions. + - [Users](${manage_url}/#/users): View your user's profiles, create new ones, perform password resets, block and delete users, and many more. [More info on Users](/users). + - [Roles](${manage_url}/#/roles): Create and manage roles for your applications. Roles contain collection of permissions and can be assigned to users. [More info on Roles](/authorization/guides/manage-roles). <% } else if (screen === "rules") { %> Here you can configure custom JavaScript snippets that are executed in Auth0 as part of the transaction every time a user authenticates to your application. You can call external APIs, filter which users can login to your application, use a whitelist, geolocated access or anything. [More information on Rules](/rules). <% } else if (screen === "hooks") { %> Here you can configure Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). This way you can customize the behavior of Auth0 when you use Database Connections. [More info on Hooks](/hooks). <% } else if (screen === "mfa") { %> - Use this page to configure Multifactor Authentication (MFA) for your apps. This way you can add an additional factor to conventional logins to prevent unauthorized access. You can use Push Notifications, SMS or both. [More info on MFA](/multifactor-authentication). -<% } else if (screen === "hlp") { %> - Here you can create a login page where you can redirect to authenticate your users. The page can be customized with HTML and CSS and will be hosted by Auth0. By using centralized authentication, your app will be more secure and you will be able to implement SSO very easily. Except for the login, you can also add pages for the Password Reset process, MFA, and error pages. [More info on Hosted Pages](/hosted-pages). + Use this page to configure multi-factor authentication (MFA) for your apps. This way you can add an additional factor to conventional logins to prevent unauthorized access. You can use Push Notifications, SMS, Voice, etc. [More info on MFA](/mfa). <% } else if (screen === "emails") { %> Here you can configure the email templates for verification emails, welcome emails, change password emails, and more. You can also configure a custom SMTP email provider which is a requirement for production purposes. Auth0 does offer a built-in email infrastructure but it should be used for testing purposes only. [More info on emails](/email). <% } else if (screen === "logs") { %> @@ -35,5 +37,5 @@ <% } else if (screen === "extensions") { %> In this page you can see a list of pre-built addons that we have created for you. You can use them to extend the functionality of the Auth0 base product. You can enable extensions in order to import or export users, export logs to external services, expose the Users dashboard to a group of users (without allowing them access to the rest of the dashboard), manage user authorization, and more. [More info on extensions](/extensions). <% } else { %> - The last screeen navigates you to our [Support Center](${env.DOMAIN_URL_SUPPORT}). The alternative to users that do not have access to support services is the [Auth0 Community](https://community.auth0.com/). [More info on support options](/support). -<% } %> \ No newline at end of file + The last screen navigates you to our [Support Center](${env.DOMAIN_URL_SUPPORT}). The alternative to users that do not have access to support services is the [Auth0 Community](https://community.auth0.com/). [More info on support options](/support). +<% } %> diff --git a/articles/getting-started/create-tenant.md b/articles/getting-started/create-tenant.md new file mode 100644 index 0000000000..ecc9e1c324 --- /dev/null +++ b/articles/getting-started/create-tenant.md @@ -0,0 +1,36 @@ +--- +title: Create a Tenant +description: Learn how to create a tenant in the Auth0 Dashboard. +topics: + - tenants +contentType: how-to +useCase: + - create-tenant + - get-started +--- +# Create a Tenant + +Once you create your account, you will be asked to create a **tenant**. No tenant can access the data of another tenant, even though multiple tenants might be running on the same machine. + +Tenant characteristics include: + +- The tenant name has to be unique. It will be used to create your personal domain. +- The tenant name can contain only lowercase alphanumeric characters and hyphens ("-"). It cannot begin or end with a hyphen. +- The tenant name must be a minimum of 3 characters and maximum of 64 characters. +- The tenant name cannot be changed after creation. +- You can create more than one tenant; in fact you are encouraged to do so for each environment you may have, such as development, staging, or production. For details, see [Set Up Multiple Environments](/dev-lifecycle/setting-up-env). + +When you name your tenant, that name becomes your Auth0 domain. (Or you can create a custom domain.) This domain is the base URL that you will use to access our API and the URL where your users are redirected to authenticate. + +Auth0 supports three regional subdomains: +- `us.auth0.com` for US +- `eu.auth0.com` for Europe +- `au.auth0.com` for Australia + +When you you are asked for the region you want to use, your choice affects which regional subdomain will be assigned to you and where your data will be hosted. If you pick US, then the name format will be `YOUR-TENANT-NAME.us.auth0.com`; for Europe, it will be `YOUR-TENANT-NAME.eu.auth0.com`; and so forth. + +In our example, Example-Co chose the name `example-co` and **Americas** as their region. So their domain is `example-co.us.auth0.com`. + +## Keep reading + +* [Set Up Multiple Environments](/dev-lifecycle/setting-up-env) diff --git a/articles/getting-started/dashboard-overview.md b/articles/getting-started/dashboard-overview.md index d951a1d079..3528b0a344 100644 --- a/articles/getting-started/dashboard-overview.md +++ b/articles/getting-started/dashboard-overview.md @@ -2,6 +2,14 @@ title: Dashboard Overview description: Learn the basics of the Auth0 Dashboard toc: true +topics: + - auth0-101 + - dashboard +contentType: + - how-to +useCase: + - manage-accounts + - get-started --- # Dashboard Overview @@ -13,7 +21,7 @@ It consists of several sections which you can navigate using the sidebar menu on ## Configure your implementation -The matrix that follows offers a brief overview of the different dashboard screens and what you can do on each. +The following table contains a brief overview of the different dashboard pages and what you can do on each. @@ -29,7 +37,7 @@ The matrix that follows offers a brief overview of the different dashboard scree - + @@ -44,8 +52,12 @@ The matrix that follows offers a brief overview of the different dashboard scree - - + + + + + + @@ -56,13 +68,9 @@ The matrix that follows offers a brief overview of the different dashboard scree - + - - - - @@ -90,10 +98,10 @@ The matrix that follows offers a brief overview of the different dashboard scree On the top right you can see your tenant's name and icon, and a little arrow. This arrow displays a drop-down menu that you can use to configure different aspects of your account: +- **Settings**: Here you can configure several aspects of your tenant. For more info see [Tenant Settings in the Auth0 Dashboard](/dashboard/reference/settings-tenant). +- **Invite an admin**: Use this option to add another person as admin to your tenant configuration. For more info see [Manage Admins in the Dashboard](/dashboard/manage-dashboard-admins). +- **Create tenant**: Use this to [create a new tenant](/getting-started/create-tenant). - **Switch tenant**: If you have multiple [tenants](/getting-started/the-basics#account-and-tenants) you can use this option to switch between them. All configuration described in the previous section is per tenant. If you create an application for `tenant-A`, you will not see it listed for `tenant-B`. If you have more than one tenant, you will find this switching option handy. -- **Settings**: Here you can configure several aspects of your tenant. For more info see [Tenant Settings in the Auth0 Dashboard](/dashboard/dashboard-tenant-settings). -- **Invite users to this tenant**: Use this option to add another person as admin to your tenant configuration. For more info see [Manage Admins in the Dashboard](/dashboard/manage-dashboard-admins). -- **Create tenant**: Use this to [create a new tenant](/getting-started/the-basics#account-and-tenants). - **View profile**: Use this to view information about your [account profile](${manage_url}/#/profile). -- **Subscription overview**: This option navigates you to our [Account Center](${env.DOMAIN_URL_SUPPORT}/tenants/public) where you can see information about your subscription and your tenants. -- **Log out**: Log out from your account. \ No newline at end of file +- **Account usage**: This option navigates you to our [Account Center](${env.DOMAIN_URL_SUPPORT}/tenants/public) where you can see information about your subscription and your tenants. +- **Logout**: Log out from your account. \ No newline at end of file diff --git a/articles/getting-started/deployment-models.md b/articles/getting-started/deployment-models.md index a6bef722b4..3f9a81a6cf 100644 --- a/articles/getting-started/deployment-models.md +++ b/articles/getting-started/deployment-models.md @@ -2,19 +2,43 @@ title: Auth0 Deployment Models description: Read about the four different deployment models that Auth0 offers and the differences between them toc: true +topics: + - auth0-101 + - deployment-models +contentType: + - concept +useCase: + - development + - get-started --- # Auth0 Deployment Models -Auth0 is offered in four deployment models: +Auth0 is offered in the following deployment models: -- As a **multi-tenant cloud service** running on Auth0's cloud -- As a **dedicated cloud service** running on Auth0's cloud -- As a **dedicated cloud service** running on Customer's cloud infrastructure -- As an **on-premises virtual Private SaaS (PSaaS) Appliance** running on Customer's data centers +
       Applications<%= include('./_list-processes', {"screen": "clients"}) %><%= include('./_list-processes', {"screen": "applications"}) %>
       APIs<%= include('./_list-processes', {"screen": "connections"}) %>
       Users<%= include('./_list-processes', {"screen": "users"}) %> Universal Login<%= include('./_list-processes', {"screen": "universal-login"}) %>
       Users & Roles<%= include('./_list-processes', {"screen": "users-roles"}) %>
       Rules<%= include('./_list-processes', {"screen": "hooks"}) %>
       Multifactor Auth Multi-factor Auth <%= include('./_list-processes', {"screen": "mfa"}) %>
       Hosted Pages<%= include('./_list-processes', {"screen": "hlp"}) %>
       Emails <%= include('./_list-processes', {"screen": "emails"}) %>
      + + + + + + + + + + + + + + + + +
      DeploymentDescription
      Public CloudA multi-tenant cloud service running on Auth0's cloud
      Standard Private CloudA dedicated cloud service running on Auth0's cloud
      Managed Private CloudA dedicated cloud service running on either Auth0's cloud or the customer's AWS cloud infrastructure
      -::: note -PSaaS Appliance is a managed service that you can use if your organization's requirements prevent you from using a multi-tenant cloud service. To learn more refer to [Private SaaS (PSaaS) Appliance](/appliance). -::: +The [Standard and the Managed Private Cloud](/private-cloud) options are managed services that you can use if: + +* Your organization's requirements prevent you from using the multi-tenant public cloud service +* You require an SLA guaranteeing higher uptimes +* You require a guaranteed level of requests per second The following tables describe operational and feature differences between these models. @@ -24,15 +48,15 @@ The following tables describe operational and feature differences between these Where It Runs - Auth0's Infrastructure - Customer's Infrastructure + Auth0's Infrastructure + Auth0's Infrastructure + Auth0's Infrastructure or Customer's AWS Cloud How It Runs - Multi-Tenant - Dedicated - Cloud - On-Premises + Public Cloud (Multi-Tenant) + Standard Private Cloud + Managed Private Cloud @@ -40,172 +64,138 @@ The following tables describe operational and feature differences between these Public Facing Yes Yes - Configurable - Configurable + Auth0's Cloud: Yes
      Customer's AWS Cloud: Configurable* Updates - Unscheduled.
      Multiple times per day.

      Staged in two zones. - Cumulative. Deployed post multi-tenant update after coordination with Customer. - Scheduled with Customer.

      Minimum 1/month, except critical updates (such as vulnerabilities, security updates) - Scheduled with Customer.

      Minimum 1/month, except critical updates (such as vulnerabilities, security updates) + Automatic Updates + Automatic Monthly Updates + Monthly, bi-monthly, or quarterly as coordinated with Auth0. Excludes critical updates (e.g., security patches), which will be applied as soon as possible Deployment Configurations N/A - High Availability (HA);
      Geo HA;
      High Capacity;
      Geo HA and High Capacity - High Availability (HA);
      Geo HA;
      High Capacity;
      Geo HA and High Capacity + High Availability (HA);
      High Capacity High Availability (HA);
      Geo HA;
      High Capacity;
      Geo HA and High Capacity + + Isolated Non-Production Environment + No + Yes + Yes + Service & Uptime Reporting - http://status.auth0.com
      http://uptime.auth0.com + https://status.auth0.com
      http://uptime.auth0.com Monitored by Auth0 - Monitored by Auth0 and Customer's tools - Monitored by Auth0 and Customer's tools + Auth0's Cloud: Auth0
      Customer's AWS Cloud: Customer + + + Infrastructure and Backup Responsibility + Auth0 + Auth0 + Auth0's Cloud: Auth0
      Customer's AWS Cloud: Customer Uptime SLA Provided - Yes - Yes - No + 99.90%
      No upgrade option available + 99.95% SLA with optional upgrade to 99.99%** + 99.95% SLA with optional upgrade to 99.99%** + + + Requests per Second + See Rate Limit Policy for Auth0 APIs + 500 requests per second with optional upgrade to 1500 requests per second + 500 requests per second with optional upgrade to 1500 requests per second + + + Data Residency + Not applicable + Region of Choice*** **** + Region of Choice*** + + + PCI Compliance No + Add-on available + Add-on available for Auth0-Hosted Private Cloud Support Channels & Levels - Same across all models + Same across all models + Same across all models + Same across all models +*Access to the Managed Private Cloud can be restricted to customer's private subnets. + +**See the **PSaaS Appliance** section the Auth0 [Service Level Description](https://auth0.com/legal) (located under **Support Program and Service Levels**). + +***Deployments to China are currently unavailable. + +****If you need to meet 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 (excepting China). + ## Feature Differences - - - - - - - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - + + + - - - + + - - - - - - - - - - - - - - - - - + + - - + - - - - + + - - - - - - - - - - - - - - - - - - + +
      Where It RunsAuth0's InfrastructureCustomer's Infrastructure
      How It RunsMulti-TenantDedicatedCloudOn-PremisesPublic Cloud (Multi-Tenant)Standard Private CloudManaged Private Cloud
      SSO LifetimeDefault SettingsConfigurableConfigurableConfigurable
      User SearchLucene queriesSimple attribute search or Lucene queriesSimple attribute search or Lucene queriesSimple attribute search or Lucene queries
      Tenant Log SearchLucene queriesSimple attribute searchSimple attribute searchSimple attribute search
      Log RetentionUp to 30 days (depends on subscription plan)Limited to 30 daysLimited to 30 daysLimited to 30 daysv3v3
      Code SandboxWebtask (Javascript and C#)Webtask or in-processWebtask or in-processWebtask or in-processWebtask (Node.js version 8 and C#)Webtask (Node.js version 8)Webtask (Node.js version 8)
      Webtask Multi-TenantDedicated (Fixed NPM modules)Dedicated (Fixed NPM modules)On-Premises (Fixed NPM modules)DedicatedDedicated
      Anomaly Detection Brute Force and Breached PasswordsBrute ForceBrute ForceBrute Force
      ExtensionsYesYes *Yes *Yes *
      GeolocationYesYesYesYesBrute Force and Breached PasswordsBrute Force and Breached Passwords
      Connecting IP Address Filtering Restrictions No NoYesYesAuth0's Cloud: No
      Customer's AWS Cloud: Yes
      Custom Domains YesYes**Yes**Yes**
      Yes*Yes*
      Shared Resources Among Multiple Customers Yes No NoNo
      MFA YesAvailable using SMS, Google Authenticator, Duo over TOTP/HOTP, and Push Notification with Guardian SDK.Available using SMS, Google Authenticator, Duo over TOTP/HOTP, and Push Notification with Guardian SDK.Available using SMS, Google Authenticator, Duo over TOTP/HOTP, and Push Notification with Guardian SDK.
      LockYesYesYesYes ***
      Internet RestrictedNoNoNoOptional ***Available using SMS, Voice, Google Authenticator or similar apps, Duo over TOTP/HOTP, Email, and Push Notification with Guardian Available using SMS, Voice, Google Authenticator or similar apps, Duo over TOTP/HOTP, Email, and Push Notification with Guardian
      -*See the [PSaaS Appliance: Extensions page](/appliance/extensions) to learn more about configuring extensions with the PSaaS Appliance. - -**See [PSaaS Appliance Custom Domains](/appliance/custom-domains) for details. If your PSaaS Appliance is hosted in the Auth0 Private Cloud, see [Private Cloud Requirements](/appliance/private-cloud-requirements). - -***You may choose to [operate the PSaaS Appliance in an Internet-restricted environment](/appliance/infrastructure/internet-restricted-deployment) (except during [update periods](/appliance/infrastructure/ip-domain-port-list#external-connectivity)). \ No newline at end of file +*See [Custom Domains](/appliance/custom-domains) and [Private Cloud Requirements](/appliance/private-cloud-requirements) for details. diff --git a/articles/getting-started/faq.md b/articles/getting-started/faq.md index b0cd2722cb..82bc9567db 100644 --- a/articles/getting-started/faq.md +++ b/articles/getting-started/faq.md @@ -2,5 +2,11 @@ description: FAQ for Auth0 beginners toc: true public: false +topics: + - auth0-101 +contentType: concept +useCase: + - strategize + - get-started --- # Frequently Asked Questions - UNDER CONSTRUCTION diff --git a/articles/getting-started/hello-world.md b/articles/getting-started/hello-world.md index 47162e0187..28e11867a5 100644 --- a/articles/getting-started/hello-world.md +++ b/articles/getting-started/hello-world.md @@ -2,5 +2,11 @@ description: How to add authentication to a simple Hello World app using Auth0 toc: true public: false +topics: + - auth0-101 +contentType: tutorial +useCase: + - strategize + - get-started --- # Hello World - UNDER CONSTRUCTION diff --git a/articles/getting-started/index.md b/articles/getting-started/index.md index 46ab091b2d..a033710ec9 100644 --- a/articles/getting-started/index.md +++ b/articles/getting-started/index.md @@ -1,29 +1,25 @@ --- description: If you are new to Auth0 start here for a list of resources that can get you started -title: Getting Started +title: Get Started classes: topic-page +topics: + - auth0-101 +contentType: + - concept + - index +useCase: + - strategize + - get-started ---
      -

      Getting Started

      +

      Get Started

      Learn the basics of Auth0.

      -Welcome! If you are new to Auth0, you are in the right place. - -This is an introduction to Auth0, and covers things like: - -* What is it we do -* How we can help you -* The basic terminology we use -* The process of implementing Auth0 -* The Auth0 ecosystem -* ... and many more - -Let's get started! - +Welcome! If you are new to Auth0, you are in the right place. Here we will cover how to get started using Auth0.
      • @@ -36,10 +32,22 @@ Let's get started!
      • Dashboard Overview -

        The Dashboard is where you configure and manage all things Auth0. This article offers a brief overview of the sections it contains and what you can do in each section.

        +

        Learn the basics of using the Auth0 Dashboard.

        +
        • +
      • + Create a Tenant +

        Learn how to create an Auth0 tenant.

        +
        • +
      • + Set Up an App +

        Learn how to configure your application.

        +
        • +
      • + Set Up an API +

        Learn how to configure an API.

      • Deployment Models -

        Read about the four different deployment models that Auth0 offers.

        +

        Read about the four deployment models that Auth0 offers.

      diff --git a/articles/getting-started/overview.md b/articles/getting-started/overview.md index 72eb99f382..738d3bbd98 100644 --- a/articles/getting-started/overview.md +++ b/articles/getting-started/overview.md @@ -1,56 +1,59 @@ --- title: Auth0 Overview -description: Learn what Auth0 is and how you can use it +description: Learn what Auth0 is and how you can use it. toc: true +topics: + - auth0-101 + - auth0-overview +contentType: concept +useCase: + - strategize + - get-started --- # Auth0 Overview -Auth0 provides authentication and authorization as a service. - -We are here to give developers and companies the building blocks they need in order to secure their applications, without having to become security experts. +Auth0 is a flexible, drop-in solution to add authentication and authorization services to your applications. Your team and organization can avoid the cost, time, and risk that comes with building your own solution to authenticate and authorize users. You can connect any application (written in any language or on any stack) to Auth0 and define the identity providers you want to use (how you want your users to log in). -Based on your app's technology, choose one of our SDKs (or call our API) and hook it up to your app. Now each time a user tries to authenticate, Auth0 will verify their identity and send the required information back to your app. - -![Auth0 Overview](/media/articles/getting-started/overview.png) +Based on your app's technology, choose one of our SDKs (or call our API), and hook it up to your app. Now each time a user tries to authenticate, Auth0 will verify their identity and send the required information back to your app. ## Why use Auth0? -Take a look at just a few of the use cases for which you can use Auth0: +Take a look at just a few of Auth0's use cases: -- You built an awesome app and you want to add user authentication and authorization. Your users should be able to log in either with username/password or with their social accounts (Facebook, Twitter, and so on). You want to retrieve the user's profile after the login so you can customize the UI and apply your authorization policies. +- You built an awesome app and you want to add user authentication and authorization. Your users should be able to log in either with username/password or with their social accounts (such as Facebook or Twitter). You want to retrieve the user's profile after the login so you can customize the UI and apply your authorization policies. - You built an API and you want to secure it with [OAuth 2.0](/protocols/oauth2). -- You have more than one app and you want to implement [Single Sign On](/sso). -- You built a JavaScript front-end app and a mobile app and you want them both to securely access your API. -- You have a web app which needs to authenticate users using SAML. +- You have more than one app, and you want to implement Single Sign-on (SSO). +- You built a JavaScript front-end app and a mobile app, and you want them both to securely access your API. +- You have a web app which needs to authenticate users using Security Assertion Markup Language (SAML). - You believe passwords are broken and you want your users to log in with one-time codes delivered by email or SMS. -- If one of your user's email addresses is compromised in some site's public data breach, you want to be notified, and also notify the users and/or block them from logging in to your app until they reset their password. -- You want to act proactively and block suspicious IP addresses if they make consecutive failed login attempts, in order to avoid DDoS attacks. +- If one of your user's email addresses is compromised in some site's public data breach, you want to be notified, and you want to notify the users and/or block them from logging in to your app until they reset their password. +- You want to act proactively to block suspicious IP addresses if they make consecutive failed login attempts, in order to avoid DDoS attacks. - You are part of a large organization who wants to federate their existing enterprise directory service to allow employees to log in to the various internal and third-party applications using their existing enterprise credentials. - You don't want (or you don't know how) to implement your own user management solution. Password resets, creating, provisioning, blocking, and deleting users, and the UI to manage all these. You just want to focus on your app. -- You want to enforce [multifactor authentication](/multifactor-authentication) when your users want to access sensitive data. -- You are looking for an identity solution that will help you stay on top of the constantly growing compliance requirements of SOC2, GDPR, OpenID Connect and others. -- You want to use analytics to track users on your site or application. You plan on using this data to create funnels, measure user retention, and improve your sign up flow. +- You want to enforce multi-factor authentication (MFA) when your users want to access sensitive data. +- You are looking for an identity solution that will help you stay on top of the constantly growing compliance requirements of SOC2, GDPR, PCI DSS, HIPAA, and others. +- You want to use analytics to track users on your site or application. You plan on using this data to create funnels, measure user retention, and improve your sign-up flow. ## Which industry standards does Auth0 use? -Once upon a time, when computers were standalone systems, all the authentication and user data lived in a single machine. Times have changed, and now you can use the same login information across multiple apps and sites. This was achieved due to the identity industry standards that were widely adopted across the web. +Once upon a time, when computers were standalone systems, all the authentication and user data lived in a single machine. Times have changed, and now you can use the same login information across multiple apps and sites. This has been achieved through widespread adoption of identity industry standards across the web. These are a set of open specifications and protocols that specify how to design an authentication and authorization system. They specify how you should manage identity, move personal data securely, and decide who can access applications and data. The identity industry standards that we use here in Auth0 are: -- **OAuth 1**: the original standard for access delegation. Used as a way for a user to grant websites access to their information on other websites or apps, but without giving them the credentials. -- **OAuth 2**: an authorization standard that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials. You use this standard every time you log in to a site using your Google account and you are asked if you agree with sharing your email address and your contacts list with that site. -- **Open ID Connect**: an identity layer that sits on top of OAuth 2 and allows for easy verification of the user's identity, as well the ability to get basic profile information from the identity provider. -- **JSON Web Tokens**: an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. +- **Open Authorization (OAuth) 1**: the original standard for access delegation. Used as a way for a user to grant websites access to their information on other websites or apps, but without giving them the credentials. +- **Open Authorization (OAuth) 2**: an authorization standard that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials. You use this standard every time you log in to a site using your Google account and you are asked if you agree with sharing your email address and your contacts list with that site. +- **OpenID Connect (OIDC)**: an identity layer that sits on top of OAuth 2 and allows for easy verification of the user's identity, as well the ability to get basic profile information from the identity provider. +- **JSON Web Tokens (JWT)**: an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. - **Security Assertion Markup Language (SAML)**: an open-standard, XML-based data format that allows businesses to communicate user authentication and authorization information to partner companies and enterprise applications their employees may use. -- **WS-Federation**: a standard developed by Microsoft, and used extensively in their applications. It defines the way security tokens can be transported between different entities to exchange identity and authorization information. +- **WS-Federation (WS-Fed)**: a standard developed by Microsoft, and used extensively in their applications. It defines the way security tokens can be transported between different entities to exchange identity and authorization information. ## Keep reading ::: next-steps -- [Learn the basics and familiarize yourself with the identity terminology](/getting-started/the-basics) -- [Read about the four different deployment models that Auth0 offers](/getting-started/deployment-models) +- [Learn the basics and familiarize yourself with identity terminology](/getting-started/the-basics) +- [Read about different deployment models offered by Auth0](/getting-started/deployment-models) ::: diff --git a/articles/getting-started/set-up-api.md b/articles/getting-started/set-up-api.md new file mode 100644 index 0000000000..cb5c67c61f --- /dev/null +++ b/articles/getting-started/set-up-api.md @@ -0,0 +1,101 @@ +--- +title: Set Up an API +description: Learn how to set up an API in Auth0 Dashboard. +topics: + - apis +contentType: how-to +useCase: + - set-up-api + - get-started +--- +# Set Up an API + +1. In the Dashboard, 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). + ::: + +2. 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](/tokens/concepts/signing-algorithms). + +3. 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. For more details on the signing algorithms see the [Signing Algorithms paragraph](#signing-algorithms) below. + +## 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 see [JSON Web Tokens (JWTs) in Auth0](/jwt#what-is-the-json-web-token-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 secret key is compromised (e.g. by the application) 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. + +::: panel Verify an RS256 signed token +Go to [Dashboard > Applications](${manage_url}/#/applications). Open the **Settings** of your applications, scroll down and open **Advanced Settings**. Open the **Certificates** tab and you will find the Public Key in the **Signing Certificate** field. + +If you want to use the Public Key to verify a JWT signature on [JWT.io](https://jwt.io/), you can copy the Public Key and paste it in the **Public Key or Certificate** field under the **Verify Signature** section on the [JWT.io](https://jwt.io/) website. + +If you want to verify the signature of a token from one of your applications, we recommend that you get the Public Key from your tenant's [JSON Web Key Set (JWKS)](/tokens/concepts/jwks). Your tenant's JWKS is `https://${account.namespace}/.well-known/jwks.json`. +::: + +# Keep reading + +- [API Authorization Overview](/api-auth) +- [Which OAuth Flow to Use](/api-auth/which-oauth-flow-to-use) +- [Tokens](/tokens) diff --git a/articles/getting-started/set-up-app/index.md b/articles/getting-started/set-up-app/index.md new file mode 100644 index 0000000000..c289ac8edc --- /dev/null +++ b/articles/getting-started/set-up-app/index.md @@ -0,0 +1,21 @@ +--- +title: Set Up an App +description: Learn how to set up an app in Auth0 Dashboard. +classes: topic-page +topics: + - apps +contentType: how-to +useCase: + - set-up-app + - get-started +--- +# Set Up an App + +Learn how to set up an app in the Auth0 Dashboard. You can set up the following app types: + +<%= include('../../_includes/_topic-links', { links: [ + 'dashboard/guides/applications/register-app-regular-web', + 'dashboard/guides/applications/register-app-native', + 'dashboard/guides/applications/register-app-spa', + 'dashboard/guides/applications/register-app-m2m', +] }) %> diff --git a/articles/getting-started/the-authentication-flow.md b/articles/getting-started/the-authentication-flow.md index 26238ad8b6..b91140b4c8 100644 --- a/articles/getting-started/the-authentication-flow.md +++ b/articles/getting-started/the-authentication-flow.md @@ -2,5 +2,12 @@ description: Learn how the Auth0 authentication flow works toc: true public: false +topics: + - auth0-101 + - authentication +contentType: concept +useCase: + - development + - get-started --- # The Authentication Flow - UNDER CONSTRUCTION diff --git a/articles/getting-started/the-basics.md b/articles/getting-started/the-basics.md index fb1d91c58e..ed84b63202 100644 --- a/articles/getting-started/the-basics.md +++ b/articles/getting-started/the-basics.md @@ -1,46 +1,70 @@ --- title: Learn the Basics -description: Learn the basics of Auth0 and familiarize yourself with the terminology +description: Learn the basics of Auth0 and familiarize yourself with the terminology. toc: true +topics: + - auth0-101 + - auth0-basics +contentType: concept +useCase: + - development + - strategize + - get-started --- # Learn the Basics -Often, the biggest barrier to learning new things, especially in the tech industry, is terminology. The words that are used to describe things can cause problems when you try to understand new concepts. This document explains some of the basic terminology we use here at Auth0, and maps these terms to concepts you are already familiar with. +Often, the biggest barrier to learning new things, especially in the tech industry, is terminology. The words that are used to describe things can cause problems when you try to understand new concepts. This document explains some of the basic terminology we use here at Auth0, and maps these terms to concepts you are already familiar with. We also have a handy [glossary](/glossary). ::: panel TL;DR -This article uses an example to introduce some core concepts of Auth0: **accounts**, **tenants**, **domains**, **applications**, and **connections**. If you already know what these are (in the context of Auth0) you can safely skip reading it. +This article uses an example to introduce some core concepts of Auth0: **accounts**, **tenants**, **domains**, **applications**, and **connections**. If you already know what these are in the context of Auth0, you can safely skip reading it. -We will use a very simple example: A company named `Example-Co` wants to use Auth0 for authentication. They have a web app and a mobile app, and they want their users to be able to login with username/password, Google, or GitHub. +We will use a very simple example: A company named `Example-Co` wants to use Auth0 for authentication. They have a web app and a mobile app, and they want their users to be able to log in with username/password, Google, or GitHub. ::: ## Account and tenants -If you haven't already signed up for an Auth0 **account**, do so (it's free). You can either use username/password or log in with a social provider (GitHub, Google, or Microsoft). +If you haven't already [signed up](https://auth0.com/signup) for an Auth0 **account**, do so (it's free). You can either use username and password or log in with a social provider (such as Facebook, Google, or Apple). -Once you create your account you will be asked to create a **Tenant**. This is a **logical isolation unit**. +Once you create your account you will be asked to create a tenant. *Tenant* is a term borrowed from [software multitenancy](https://en.wikipedia.org/wiki/Multitenancy). It refers to an architecture where a single software instance serves multiple tenants. In Auth0, a tenant is logically isolated. No tenant can access the data of another tenant, even though multiple tenants might be running on the same machine. -The term is borrowed from "software multitenancy". This 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). +Tenant characteristics: -Some characteristics: - -- The tenant name has to be unique (we will see in the next paragraph that it is used to create your own personal domain). +- The tenant name has to be unique. It will be used to create your personal domain. +- The tenant name can contain only lowercase alphanumeric characters and hyphens ("-"). It cannot begin or end with a hyphen. +- The tenant name must be a minimum of three characters and maximum of 64 characters. - The tenant name cannot be changed after creation. - You can create more than one tenant; in fact, you are encouraged to do so for each environment you have (such as Development, Staging, or Production). -- If you chose to host your data in Europe or Australia, then your tenant will have a suffix (`eu` or `au`). In our example, if `Example-Co` picked the name `example-co`, then depending on where the data is stored, the tenant name would be `example-co-eu` or `example-co-au`. -## Domain +You can create additional tenants at any time. To do so, go to the upper-right corner of the Dashboard and click on your tenant name to display the pulldown menu. Click **Create Tenant**. -As discussed in the previous section, when you create a new account with Auth0, you are asked to pick a name for your **Tenant**. This name, appended with `auth0.com`, will be your Auth0 **Domain**. It's the base URL you will be using when you want to access our API (for example, to authenticate a user). The name format is `TENANT-NAME.auth0.com` (you get to pick the `TENANT-NAME` part). +## Domains -In our example, `Example-Co` picked the name `example-co`; hence their domain is `example-co.auth0.com`. +As discussed in the previous section, when you create a new account with Auth0, you are asked to pick a name for your tenant. This name, appended with `auth0.com`, will be your Auth0 *domain*. (You can also use [custom domains](#custom-domains).) It's the base URL you will use to access our API and the URL where your users are redirected in order to authenticate. -::: panel Custom Domains -You can use a custom domain, such as `example-co.com`. This comes with an additional cost. This feature is in beta for **public-cloud tenants** (see the [Custom Domains](/custom-domains) documentation for details). If you have a **single-tenant** implementation, you can deploy your custom domain in one of three locations: -- The cloud managed by Auth0 -- A cloud managed by you -- An [on-premise installation](/appliance) +Auth0 supports three regional subdomains: +- `us.auth0.com` for US +- `eu.auth0.com` for Europe +- `au.auth0.com` for Australia + +When you create your tenant, you are asked for the region you want to use. This choice affects which regional subdomain will be assigned to you and where your data will be hosted. So if you pick US then the name format will be `YOUR-TENANT-NAME.auth0.com`, for Europe it will be `YOUR-TENANT-NAME.eu.auth0.com`, and so forth. + +In our example, `Example-Co` picked the name `example-co` and Americas as their region. Therefore their domain is `example-co.auth0.com`. + +::: note +Tenants created on or after 10 June 2020 in the US region will be appended with `us.auth0.com` (instead of `auth0.com`) to create the domain URL that you use to access Auth0 services. ::: +### Custom domains + +We recommend the use of custom domains, such as `example-co.com`, in your production environments to provide your users with the most secure and seamless experience. This comes with an additional cost. + +If you have a [**single-tenant** implementation](/private-cloud), you can deploy your custom domain in: + +- The cloud managed by Auth0 +- An AWS cloud managed by you + +For more information, see [Custom Domains](/custom-domains). + ## Application Now that you have an account, we need to know about your app(s) that will be using our services. To that end, you must register each application. We use the term **application** to refer to an application (like [OAuth 2.0 does](https://tools.ietf.org/html/rfc6749#page-6)). @@ -70,9 +94,9 @@ This relationship between Auth0 and the identity provider is referred to as a ** Connections are sources of users and they can be of the following types: - [Database connections](/connections/database): Users log in with username and passwords, stored either in the Auth0 cloud or your own database -- [Social logins](/identityproviders#social): Google, Facebook, Twitter, and more -- [Enterprise directories](/identityproviders#enterprise): LDAP, Google Apps, Office 365, ADFS, AD, SAML-P, WS-Federation, and more -- [Passwordless systems](/connections/passwordless): Users log in with one-time codes, sent via SMS or email +- [Social logins](/connections/identity-providers-social): Google, Facebook, Twitter, and more +- [Enterprise directories](/connections/identity-providers-enterprise): LDAP, G Suite, Office 365, ADFS, AD, SAML-P, WS-Federation, and more +- [Passwordless systems](/connections/passwordless): Users log in with one-time codes, sent via SMS or email Each connection can be shared among multiple applications. You can configure any number of connections, and then choose which of them to enable for each application. @@ -84,7 +108,7 @@ In our example, `ExampleCo` wants their users to be able to login with username/ 1. Enable all three connections for the mobile app ::: note -For more information on the supported identity providers, refer to [Identity Providers Supported by Auth0](/identityproviders). For details on how to enable a connection for an application, refer to [Application Connections](/applications/connections). +For more information on the supported identity providers, refer to [Identity Providers Supported by Auth0](/identityproviders). For details on how to enable a connection for an application, refer to [Connections](/connections). ::: ## Where to go from here @@ -95,13 +119,11 @@ If you wish to learn more about the next steps in setting up Auth0, you can read - **Hook Auth0 up to your app**: Assuming that your app has a login and a logout button, you need to add some code in order to invoke Auth0 APIs each time one of these buttons is clicked. For details you can refer to one of our [quickstarts](/quickstarts). Alternatively, you can directly call our API to [log in](/api/authentication#login) or [log out](/api/authentication#logout) a user, or implement one of Auth0's [libraries and SDKs](/libraries). -- **Migrate your users to Auth0**: If you already have a user store, you need to migrate these users to Auth0 before you go live. For more information refer to [User Migration](/users/migrations). Alternatively, you can [connect your app to your own user database](/connections/database/custom-db) and access it via Auth0. +- **Migrate your users to Auth0**: If you already have a user store, you need to migrate these users to Auth0 before you go live. For more information refer to [User Migration](/users/concepts/overview-user-migration). Alternatively, you can [connect your app to your own user database](/connections/database/custom-db) and access it via Auth0. ## Keep reading -::: next-steps -- [Learn how you can configure, secure, and access your own API with Auth0](/apis) -- [Learn more about Auth0 APIs](/api/info) -- [Learn about our libraries](/libraries) -- [Learn about working with users and user profiles in Auth0](/users) -::: \ No newline at end of file +- [Auth0 APIs](/api/info) - Learn about Auth0 APIs. +- [Set Up an API](/getting-started/set-up-api) - Learn how to configure your own API with Auth0. +- [Auth0 Libraries & SDKs](/libraries) - Learn about our libraries and SDKs. +- [Manage Users](/users) - Learn about working with users and user profiles in Auth0. diff --git a/articles/getting-started/the-implementation-process.md b/articles/getting-started/the-implementation-process.md index 2470d48cbb..832eefbc0f 100644 --- a/articles/getting-started/the-implementation-process.md +++ b/articles/getting-started/the-implementation-process.md @@ -2,21 +2,27 @@ description: Roadmap of what you need to do to add authentication to your app and secure your APIs with Auth0 toc: true public: false +topics: + - auth0-101 + - auth0-basics +contentType: concept +useCase: + - strategize + - development + - get-started --- # The Implementation Process - UNDER CONSTRUCTION ## Integrate Auth0 with your Application -The default [protocol](/protocols) between your application and Auth0 is [OpenID Connect](/protocols/oidc), a modern, lightweight, simple to use, and simple to integrate protocol. - -<%= include('../_includes/_pipeline2') %> +The default [protocol](/protocols) between your application and Auth0 is [OpenID Connect (OIDC)](/protocols/oidc), a modern, lightweight, simple to use, and simple to integrate protocol. Auth0 ships [SDKs for all major platforms](/support/matrix#sdks) (.NET, Java, PHP, Python, node, iOS, and many more), but the use of Auth0 SDKs is not required. Virtually anything able to send HTTP requests can integrate with Auth0. -Auth0 also supports other common identity protocols, such as [WS-Federation](/protocols/ws-fed) and [SAML](/protocols/saml). Applications that are already "claims enabled" can easily connect to Auth0. +Auth0 also supports other common identity protocols, such as [WS-Federation](/protocols/ws-fed) and [SAML](/protocols/saml). Applications that are already "claims enabled" can easily connect to Auth0. -The **best** solution for integrating Auth0 with your application is to use Auth0's [universal login](/hosted-pages/login). Using universal login is a much less complicated process, and circumvents the dangers of cross-origin authentication. Universal login uses the [Lock](/libraries/lock) widget to allow your users to authenticate by default, but has other starting templates as well. You can customize the login page in the [Dashboard](${manage_url}/#/login_page). +The **best** solution for integrating Auth0 with your application is to use Auth0's Universal Login. Using Universal Login is a much less complicated process, and circumvents the dangers of cross-origin authentication. Universal Login uses the [Lock](/libraries/lock) widget to allow your users to authenticate by default, but has other starting templates as well. You can customize the login page in the [Dashboard](${manage_url}/#/login_page). ## Access your APIs -Auth0's [API authorization](/api-auth) features allow you to manage the authorization requirements for server-to-server and client-to-server applications, using the [OAuth 2.0 protocol](/protocols/oauth2). Using Auth0, you can easily support [different flows](/api-auth/which-oauth-flow-to-use) in your own APIs without worrying about the OAuth 2.0/OpenID Connect specification, or the many other technical aspects of API authorization. \ No newline at end of file +Auth0's [API authorization](/api-auth) features allow you to manage the authorization requirements for server-to-server and client-to-server applications, using the [OAuth 2.0 protocol](/protocols/oauth2). Using Auth0, you can easily support [different flows](/api-auth/which-oauth-flow-to-use) in your own APIs without worrying about the OAuth 2.0/OpenID Connect specification, or the many other technical aspects of API authorization. diff --git a/articles/getting-started/whats-next.md b/articles/getting-started/whats-next.md index 699e378d16..a2ed17b47d 100644 --- a/articles/getting-started/whats-next.md +++ b/articles/getting-started/whats-next.md @@ -2,6 +2,14 @@ description: Learn about Auth0 advanced features toc: true public: false +topics: + - auth0-101 + - auth0-basics +contentType: concept +useCase: + - strategize + - development + - get-started --- # What's Next? - UNDER CONSTRUCTION @@ -9,8 +17,8 @@ public: false Auth0 offers several ways to extend the platform's functionality: -- **Rules**: [Rules](/rules) are functions written in JavaScript or C#, that are executed in Auth0 just after successful authentication and before control returns to your app. Rules can be chained together for modular coding and can be turned on and off individually. They can be used for Access Control, Webhooks, Profile Enrichment, Multi-factor Authentication, and many other things. +- **Rules**: [Rules](/rules) are functions written in JavaScript or C#, that are executed in Auth0 just after successful authentication and before control returns to your app. Rules can be chained together for modular coding and can be turned on and off individually. They can be used for Access Control, Webhooks, Profile Enrichment, Multi-factor Authentication (MFA), and many other things. -- **Hooks**: [Hooks](/hooks) allow you to customize the behavior of Auth0 using Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). They are [Webtasks](https://webtask.io) associated with specific [extensibility points](/hooks/extensibility-points) of the Auth0 platform. Auth0 invokes the Hooks at runtime to execute your custom logic. Hooks will eventually replace Rules, the current Auth0 extensibility method. Currently, you can use both Hooks and Rules, but Auth0 will implement new functionality in Hooks. +- **Hooks**: [Hooks](/hooks) allow you to customize the behavior of Auth0 using Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). They are secure, self-contained functions associated with specific [extensibility points](/hooks/extensibility-points) of the Auth0 platform. Auth0 invokes the Hooks at runtime to execute your custom logic. Hooks will eventually replace Rules, the current Auth0 extensibility method. Currently, you can use both Hooks and Rules, but Auth0 will implement new functionality in Hooks. -- **Extensions**: [Auth0 Extensions](/extensions) enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. You can either use one of the [pre-defined extensions](/extensions#using-an-auth0-provided-extension), provided by Auth0, or [create your own](/extensions#creating-your-own-extension). Some of the actions you can do with extensions are manage the authorizations for users (using groups, roles and permissions), import/export users, export logs to other services, deploy scripts from external repositories, and more. \ No newline at end of file +- **Extensions**: [Auth0 Extensions](/extensions) enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. You can either use one of the [pre-defined extensions](/extensions#using-an-auth0-provided-extension), provided by Auth0, or [create your own](/extensions#creating-your-own-extension). Some of the actions you can do with extensions are manage the authorizations for users (using groups, roles, and permissions), import/export users, export logs to other services, deploy scripts from external repositories, and more. \ No newline at end of file diff --git a/articles/guides/ip-whitelist.md b/articles/guides/ip-whitelist.md new file mode 100644 index 0000000000..093624e73e --- /dev/null +++ b/articles/guides/ip-whitelist.md @@ -0,0 +1,55 @@ +--- +title: Whitelist IP Addresses +description: Identify Auth0 IP addresses to whitelist if you are behind a firewall. +topics: + - connections + - custom-database + - scripts +contentType: + - reference + - how-to +useCase: + - customize-connections +--- + +# Whitelist IP Addresses + +If you are behind a firewall, the following features may require whitelisting of the appropriate Auth0 IP addresses to ensure proper functionality: + +* [Custom Database Connections](/connections/database/custom-db) +* [Hooks](/hooks) +* [Rules](/rules) + +## Outbound Calls + +::: warning +Please note that IP addresses are subject to change. In the event of a change, Auth0 will send notifications several months before any IP address changes take place. The lists provided are up-to-date at the time of writing, but check the [Dashboard](${manage_url}) for the latest list. +::: + +When Auth0 makes outbound calls, the IP addresses are static. Auth0 translates internal IP addresses to one of the displayed options when reaching out using NAT. + +Please be sure to **allow** inbound connections from the region-specific set of IP addresses listed in the [Dashboard](${manage_url}). The specific set of IP addresses you should use is provided when you create your new [Custom Database Connection](${manage_url}/#/connections/database), [Hook](${manage_url}/#/hooks), or [Rule](${manage_url}/#/rules/create). + +The IP addresses are region-specific. + +### United States + +```text +35.167.74.121, 35.166.202.113, 35.160.3.103, 54.183.64.135, 54.67.77.38, 54.67.15.170, 54.183.204.205, 35.171.156.124, 18.233.90.226, 3.211.189.167, 18.232.225.224, 34.233.19.82, 52.204.128.250, 3.132.201.78, 3.19.44.88, 3.20.244.231 +``` + +### Europe + +```text +52.28.56.226, 52.28.45.240, 52.16.224.164, 52.16.193.66, 34.253.4.94, 52.50.106.250, 52.211.56.181, 52.213.38.246, 52.213.74.69, 52.213.216.142, 35.156.51.163, 35.157.221.52, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.57.230.214, 54.76.184.103, 52.210.122.50, 52.208.95.174 +``` + +### Australia + +```text +52.64.84.177, 52.64.111.197, 54.153.131.0, 13.210.52.131, 13.55.232.24, 13.54.254.182, 52.62.91.160, 52.63.36.78, 52.64.120.184, 54.66.205.24, 54.79.46.4 +``` + +## Inbound Calls + +IP addresses related to inbound calls to Auth0 may be variable due to the lack of fixed IP addresses on the load balancers. In this case firewall rules should operate on the name of the service (e.g. `.auth0.com`). diff --git a/articles/guides/login/_includes/_centralized_webapp.md b/articles/guides/login/_includes/_centralized_webapp.md index 3c1d2056fd..beb5e5dd35 100644 --- a/articles/guides/login/_includes/_centralized_webapp.md +++ b/articles/guides/login/_includes/_centralized_webapp.md @@ -9,7 +9,7 @@ router.get('/callback', ``` ## Convert your Code to use Universal Login -In web applications, you don't need any client-side code to integrate universal login. Your application should perform these steps: +In web applications, you don't need any client-side code to integrate Universal Login. Your application should perform these steps: 1. When the application needs to authenticate, navigate to a `/login` route in your website. If you were using plain HTML to code the web views, it would be: @@ -35,6 +35,6 @@ After authentication is done, it will redirect to the `/callback` url as in the 3. Review if you are using any [legacy authentication flow in your application](guides/migration-legacy-flows), and adjust your code accordingly. -You can find complete examples of implementing universal login in web applications for different technologies in our [Quickstarts](/quickstart/webapp). +You can find complete examples of implementing Universal Login in web applications for different technologies in our [Quickstarts](/quickstart/webapp). <%= include('_customizing-login-page') %> diff --git a/articles/guides/login/_includes/_customizing-login-page.md b/articles/guides/login/_includes/_customizing-login-page.md index 9980122d8f..92d0bd121b 100644 --- a/articles/guides/login/_includes/_customizing-login-page.md +++ b/articles/guides/login/_includes/_customizing-login-page.md @@ -1,16 +1,16 @@ ## Customizing the Login Page -When you integrate universal login in your application, you redirect the user to the `/authorize` endpoint of your Auth0 tenant. If Auth0 needs to authenticate the user, it will show the default login page. +When you integrate Universal Login in your application, you redirect the user to the `/authorize` endpoint of your Auth0 tenant. If Auth0 needs to authenticate the user, it will show the default login page. -You can customize the login page in your [Dashboard](${manage_url}/#/login_page) under Hosted Pages, by enabling the **Customize Login Page** toggle. +You can customize the login page in your [Dashboard](${manage_url}/#/login_settings) under Universal Login, by enabling the **Customize Login Page** toggle. ![Login Page](/media/articles/hosted-pages/login.png) ## Customize Lock in the Login Page -The default login page for universal login with your tenant is a template that will use [Lock](/libraries/lock) to provide your users with an attractive interface and smooth authentication process. You can look over that template and use it as a starting point if you choose to customize it in any way. +The default login page for Universal Login with your tenant is a template that will use [Lock](/libraries/lock) to provide your users with an attractive interface and smooth authentication process. You can look over that template and use it as a starting point if you choose to customize it in any way. -If you want to change any of Lock's [configurable options](/libraries/lock/configuration), you can do so using the editor [Dashboard](${manage_url}/#/login_page) under Hosted Pages. These options can alter the behavior of Lock itself, or the look and feel of the widget using the theming options. See the [configuration documentation](/libraries/lock/configuration) for details on how to customize Lock. +If you want to change any of Lock's [configurable options](/libraries/lock/configuration), you can do so using the editor [Dashboard](${manage_url}/#/login_settings) under Universal Login. These options can alter the behavior of Lock itself, or the look and feel of the widget using the theming options. See the [configuration documentation](/libraries/lock/configuration) for details on how to customize Lock. When you're done making changes to the code, click **Save** to persist the changes. diff --git a/articles/guides/login/migrating-lock-v10-spa.md b/articles/guides/login/migrating-lock-v10-spa.md index 8d66b3dbef..f24d3acc12 100644 --- a/articles/guides/login/migrating-lock-v10-spa.md +++ b/articles/guides/login/migrating-lock-v10-spa.md @@ -1,12 +1,20 @@ --- title: Moving SPAs using Lock to Universal Login -description: Learn how to migrate from Single Page Applications using Lock to Universal Login +description: Learn how to migrate from Single-Page Applications using Lock to Universal Login toc: true +topics: + - lock + - migrations + - spa + - universal-login +contentType: + - how-to +useCase: migrate --- # Migrate SPAs using Lock 10+ to Universal Login -This document explains how to migrate Single Page Applications using [Lock](/libraries/lock) to universal login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). +This document explains how to migrate Single-Page Applications using [Lock](/libraries/lock) to Universal Login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). When you use Lock, your code does basically this: @@ -54,7 +62,7 @@ function login() { } ``` -To use **universal login**, you need to use [auth0.js](/libraries/auth0js) to perform the same tasks: +To use **Universal Login**, you need to use [auth0.js](/libraries/auth0js) to perform the same tasks: 1. Initialize auth0.js, using the same parameters as when initializing Lock: @@ -99,6 +107,6 @@ function login() { 5. Review if you are using any [legacy authentication flow in your application](guides/migration-legacy-flows), and adjust your code accordingly. -You can find complete examples of implementing universal login in Single Page Applications for different technologies in our [Quickstarts](/quickstart/spa). +You can find complete examples of implementing Universal Login in Single-Page Applications for different technologies in our [Quickstarts](/quickstart/spa). <%= include('_includes/_customizing-login-page') %> diff --git a/articles/guides/login/migrating-lock-v10-webapp.md b/articles/guides/login/migrating-lock-v10-webapp.md index 0861c719ee..b2378e8a08 100644 --- a/articles/guides/login/migrating-lock-v10-webapp.md +++ b/articles/guides/login/migrating-lock-v10-webapp.md @@ -2,10 +2,18 @@ title: Moving Web Applications using Lock to Universal Login description: Learn how to migrate from Web Applications using Lock to Universal Login toc: true +topics: + - lock + - migrations + - web-apps + - universal-login +contentType: + - how-to +useCase: migrate --- # Migrate Web Applications using Lock 10+ to Universal Login -This document explains how to migrate Web Applications using [Lock 10+](/libraries/lock) to universal login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). +This document explains how to migrate Web Applications using [Lock 10+](/libraries/lock) to Universal Login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). When you use Lock in a Web Application, your code does basically this: diff --git a/articles/guides/login/migrating-lock-v8.md b/articles/guides/login/migrating-lock-v8.md index dfefdf1e11..62c9674b41 100644 --- a/articles/guides/login/migrating-lock-v8.md +++ b/articles/guides/login/migrating-lock-v8.md @@ -2,10 +2,16 @@ title: Moving Applications using Lock 8 to Universal Login description: Learn how to migrate from Applications using Lock 8 to Universal Login toc: true +topics: + - lock + - migrations + - universal-login +contentType: index +useCase: migrate --- # Migrating Applications using Lock 8 to Universal Login -Lock v8 is very similar to Lock v9 from an API standpoints, so the guides for v9 give you all the information you need to migrate to universal login: +Lock v8 is very similar to Lock v9 from an API standpoints, so the guides for v9 give you all the information you need to migrate to Universal Login: - [Migrating Web Applications using Lock 9](/guides/login/migrating-lock-v9-webapp) diff --git a/articles/guides/login/migrating-lock-v9-spa-popup.md b/articles/guides/login/migrating-lock-v9-spa-popup.md index cabfc6a8d4..0e4fdeac6d 100644 --- a/articles/guides/login/migrating-lock-v9-spa-popup.md +++ b/articles/guides/login/migrating-lock-v9-spa-popup.md @@ -2,12 +2,20 @@ title: Migrate SPAs Using Lock 9 Popup Mode to Universal Login description: Learn how to Migrate SPAs Using Lock 9 Popup Mode to Universal Login toc: true +topics: + - lock + - migrations + - spa + - universal-login +contentType: + - how-to +useCase: migrate --- # Migrate SPAs Using Lock 9 Popup Mode to Universal Login -This document explains how to migrate Web Applications using [Lock](/libraries/lock) to universal login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). +This document explains how to migrate Web Applications using [Lock](/libraries/lock) to Universal Login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). -When you use 'popup mode' in Lock 9 applications, the entire authentication flow happens in a web page, without any kind of redirection. That will change when you use universal login. +When you use 'popup mode' in Lock 9 applications, the entire authentication flow happens in a web page, without any kind of redirection. That will change when you use Universal Login. 1. Initialize Lock: @@ -40,7 +48,7 @@ function login() } ``` -To use **universal login**, you need to use [auth0.js](/libraries/auth0js) to manage the authentication flow: +To use **Universal Login**, you need to use [auth0.js](/libraries/auth0js) to manage the authentication flow: 1. Initialize auth0.js, using the same parameters as when initializing Lock and also including the ones you use when you call lock.show(). @@ -76,6 +84,6 @@ webAuth.parseHash(function(err, authResult) { 4. Review if you are using any [legacy authentication flow in your application](guides/migration-legacy-flows), and adjust your code accordingly. -You can find complete examples of implementing universal login in Single Page Applications for different technologies in our [Quickstarts](/quickstart/spa). +You can find complete examples of implementing Universal Login in Single-Page Applications for different technologies in our [Quickstarts](/quickstart/spa). <%= include('_includes/_customizing-login-page') %> diff --git a/articles/guides/login/migrating-lock-v9-spa.md b/articles/guides/login/migrating-lock-v9-spa.md index fa0c8a26a5..ced825aa61 100644 --- a/articles/guides/login/migrating-lock-v9-spa.md +++ b/articles/guides/login/migrating-lock-v9-spa.md @@ -2,10 +2,18 @@ title: Moving Web Applications using Lock to Universal Login description: Learn how to migrate from Web Applications using Lock to Universal Login toc: true +topics: + - lock + - migrations + - spa + - universal-login +contentType: + - how-to +useCase: migrate --- -# Migrate Single Page Applications using Lock 9 to Universal Login +# Migrate Single-Page Applications using Lock 9 to Universal Login -This document explains how to migrate Web Applications using [Lock](/libraries/lock) to universal login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). +This document explains how to migrate Web Applications using [Lock](/libraries/lock) to Universal Login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). When you use Lock v9 in a Web Application, your code does basically this: @@ -47,7 +55,7 @@ function login() { } ``` -To use **universal login**, you need to use [auth0.js](/libraries/auth0js) to manage the authentication flow: +To use **Universal Login**, you need to use [auth0.js](/libraries/auth0js) to manage the authentication flow: 1. Initialize auth0.js, using the same parameters as when initializing Lock and also including the ones you use when you call lock.show(): @@ -83,6 +91,6 @@ function login() { 4. Review if you are using any [legacy authentication flow in your application](guides/migration-legacy-flows), and adjust your code accordingly. -You can find complete examples of implementing universal login in Single Page Applications for different technologies in our [Quickstarts](/quickstart/spa). +You can find complete examples of implementing Universal Login in Single-Page Applications for different technologies in our [Quickstarts](/quickstart/spa). <%= include('_includes/_customizing-login-page') %> diff --git a/articles/guides/login/migrating-lock-v9-webapp.md b/articles/guides/login/migrating-lock-v9-webapp.md index 7b97086a39..1df0f0a1e4 100644 --- a/articles/guides/login/migrating-lock-v9-webapp.md +++ b/articles/guides/login/migrating-lock-v9-webapp.md @@ -2,10 +2,18 @@ title: Moving Web Applications using Lock to Universal Login description: Learn how to migrate from Web Applications using Lock to Universal Login toc: true +topics: + - lock + - migrations + - web-apps + - universal-login +contentType: + - how-to +useCase: migrate --- # Migrate Web Applications using Lock 9 to Universal Login -This document explains how to migrate Web Applications using Lock to universal login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). +This document explains how to migrate Web Applications using Lock to Universal Login. For other migration scenarios see [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal). When you use Lock v9 in a Web Application, your code does basically this: diff --git a/articles/guides/login/migration-embedded-universal.md b/articles/guides/login/migration-embedded-universal.md index fb5bd75a5e..6bd0804496 100644 --- a/articles/guides/login/migration-embedded-universal.md +++ b/articles/guides/login/migration-embedded-universal.md @@ -1,20 +1,28 @@ --- title: Migrating from Embedded to Universal Login description: Learn how to migrate from Embedded Login using Lock to Universal Login +topics: + - lock + - migrations + - universal-login + - embedded-login +contentType: + - index +useCase: migrate --- # Migrating to Universal Login -When you integrate Auth0 in our applications, you have to decide whether you will use embedded or universal login. +When you integrate Auth0 in our applications, you have to decide whether you will use embedded or Universal Login. - With embedded login the login dialog is hosted in your application. You can use [Lock](/libraries/lock) or create your own UI and use [auth0.js](/libraries/auth0js). -- With universal login, you redirect to an Auth0-hosted [login page](/hosted-pages/login) where the authentication flow is performed. +- With Universal Login, you redirect to an Auth0-hosted [login page](/universal-login) where the authentication flow is performed. -Universal login has several advantages over embedded login. For a detailed analysis refer to [Centralized vs Embedded Login](/guides/login/universal-vs-embedded). +Universal Login has several advantages over embedded login. For a detailed analysis refer to [Centralized vs Embedded Login](/guides/login/universal-vs-embedded). -We put together a set of articles to help you migrate to universal login in different scenarios. +We put together a set of articles to help you migrate to Universal Login in different scenarios. -You can also find how to implement universal login in multiple technology stacks using [our Quickstarts](/quickstart). +You can also find how to implement Universal Login in multiple technology stacks using [our Quickstarts](/quickstart). ## Migration Guides per Application Type diff --git a/articles/guides/login/migration-sso.md b/articles/guides/login/migration-sso.md index d9b23551a1..b309d94aa7 100644 --- a/articles/guides/login/migration-sso.md +++ b/articles/guides/login/migration-sso.md @@ -1,19 +1,28 @@ --- -title: Migration in Embedded Login Scenarios with SSO -description: Learn how to migrate from old versions of Lock/Auth0.js when your application uses embedded login and requires SSO. +title: Migration in Embedded Login Scenarios with Single Sign-On +description: Learn how to migrate from old versions of Lock/Auth0.js when your application uses embedded login and requires Single Sign-on (SSO). +topics: + - lock + - migrations + - sso + - embedded-login +contentType: + - concept + - index +useCase: migrate --- -# Migration in Embedded Login Scenarios with SSO +# Migration in Embedded Login Scenarios with Single Sign-On -Migration from legacy versions of Lock and Auth0.js is required. For Single Sign On (SSO) scenarios, it will imply moving to [Universal Login](/hosted-pages/login) in most cases. +Migration from legacy versions of Lock and Auth0.js is required. For Single Sign-on (SSO) scenarios, it will imply moving to [Universal Login](/universal-login) in most cases. -## Single Page Apps +## Single-Page Apps -Single Page Applications (SPAs) with embedded login can only achieve SSO if they are on the same top-level domain. If SPAs with embedded login which are on different domains require SSO, the websites will need to [migrate to Universal Login](/guides/login/migration-embedded-universal). +Single-Page Applications (SPAs) with embedded login can only achieve SSO if they are on the same top-level domain. If SPAs with embedded login which are on different domains require SSO, the websites will need to [migrate to Universal Login](/guides/login/migration-embedded-universal). SSO works by having Auth0 set a cookie that identifies the session in the Auth0 server for a specific domain. -In order to make embedded login work properly, you need to set up a [custom domain](/custom-domains) that matches your website's top level domain, so as to avoid [cross-origin authentication issues](/cross-origin-authentication#limitations-of-cross-origin-authentication). +In order to make embedded login work properly, you need to set up a [custom domain](/custom-domains) that matches your website's top level domain, so as to avoid [cross-origin authentication issues](/cross-origin-authentication#limitations). If two applications using embedded login are sitting on different top-level domains, they would need to point to two different custom domains in order implement embedded login properly. If they are on different domains, those domains cannot share the same SSO cookie, so you can’t implement SSO across those sites. @@ -23,4 +32,4 @@ Web Applications using embedded login that require SSO need to [migrate to Unive The proper way of implementing embedded login for web applications is by creating a custom form that POSTs credentials to the web application. The web application then validates them with Auth0 using the [/oauth/token endpoint](/api-auth/tutorials/password-grant). -This approach does not allow for the creation of an SSO session, as the Auth0 server cannot set a cookie in the end-user’s browser. It also prevents Auth0 from performing [Anomaly Detection](/anomaly-detection#restrictions-regarding-brute-force-protection). +This approach does not allow for the creation of an SSO session, as the Auth0 server cannot set a cookie in the end-user’s browser. It also prevents Auth0 from performing [Anomaly Detection](/anomaly-detection). diff --git a/articles/guides/login/universal-vs-embedded.md b/articles/guides/login/universal-vs-embedded.md index c37a39ec4f..73fe301b7c 100644 --- a/articles/guides/login/universal-vs-embedded.md +++ b/articles/guides/login/universal-vs-embedded.md @@ -2,12 +2,21 @@ title: Universal vs Embedded Login description: Read about the differences between Universal and Embedded login toc: true +topics: + - universal-login + - embedded-login + - migrations +contentType: + - concept +useCase: + - strategize + - development --- # Universal vs Embedded Login When you design the authentication experience for your application, you have to choose whether the login flow will use **universal** or **embedded** login. -With universal login, when the users try to log in they are redirected to a central domain, through which authentication is performed, and then they are redirected back to the app. An example is Google Apps. No matter which service you are trying to access (gmail, google calendar, google docs, etc) if you are not logged in you are redirected to `https://accounts.google.com` and once you successfully log in you are redirected back to the calling app. +With Universal Login, when the users try to log in they are redirected to a central domain, through which authentication is performed, and then they are redirected back to the app. An example is G Suite. No matter which service you are trying to access (gmail, google calendar, google docs, etc) if you are not logged in you are redirected to `https://accounts.google.com` and once you successfully log in you are redirected back to the calling app. ![Google Universal Login](/media/articles/guides/login/google-login.jpg) @@ -19,23 +28,23 @@ In this article, we will evaluate the pros and cons of these two options and see ## Pros and cons -- **Single Sign-On (SSO)**: If you are working with mobile apps you cannot have SSO unless you use universal login. With web apps you can, although the most secure way is to use a central service so the cookies are from the same origin. With embedded login, you'd have to collect the user credentials in an application served from one origin and then send them to another origin, which can present certain security vulnerabilities, including the possibility of a phishing attack (see [Embedded Login with Auth0 > Security risks](#security-risks) for more info). There are workarounds you could use, like third-party cookies, but the most secure option for SSO, and logins in general, is using a central service. +- **Single Sign-on (SSO)**: If you are working with mobile apps you cannot have SSO unless you use Universal Login. With web apps you can, although the most secure way is to use a central service so the cookies are from the same origin. With embedded login, you'd have to collect the user credentials in an application served from one origin and then send them to another origin, which can present certain security vulnerabilities, including the possibility of a phishing attack (see [Embedded Login with Auth0 > Security risks](#security-risks) for more info). There are workarounds you could use, like third-party cookies, but the most secure option for SSO, and logins in general, is using a central service. -- **Consistency and Maintenance**: With embedded login, if you have more than one app, you will have to implement more than one login page. You will also have to maintain and manage these pages. Besides the extra effort it can also introduce inconsistencies which results in bad UX. Furthermore, with embedded login you would have to manage the dangers of cross-origin attack vectors. On the other hand, if you are using universal login, then your Authorization Server (the domain that logs the users in) owns all the login pages which makes the management easier and the pages more consistent and secure. You could also use a single login page among your apps, a process that creates an impression that users are logging into a centralized system, rather than an individual app. In the following diagram you can see an example of how the universal and embedded logins look. The reason why the universal login offers a more consistent and thus superior use experience is evident. +- **Consistency and Maintenance**: With embedded login, if you have more than one app, you will have to implement more than one login page. You will also have to maintain and manage these pages. Besides the extra effort it can also introduce inconsistencies which results in bad UX. Furthermore, with embedded login you would have to manage the dangers of cross-origin attack vectors. On the other hand, if you are using Universal Login, then your Authorization Server (the domain that logs the users in) owns all the login pages which makes the management easier and the pages more consistent and secure. You could also use a single login page among your apps, a process that creates an impression that users are logging into a centralized system, rather than an individual app. In the following diagram you can see an example of how the universal and embedded logins look. The reason why the Universal Login offers a more consistent and thus superior use experience is evident. ![Universal vs Embedded login UX](/media/articles/guides/login/centralized-embedded-ux.jpg) -- **Central Features Management**: When you use universal login with Auth0, you can turn on and off features across all your apps, using the Dashboard. An example is [Multifactor Authentication](/multifactor-authentication) which you can enable using the toggles located at the [Dashboard > Multifactor Auth](${manage_url}/#/guardian) page. These changes will be automatically available to all your registered apps. +- **Central Features Management**: When you use Universal Login with Auth0, you can turn on and off features across all your apps, using the Dashboard. An example is [Multi-factor Authentication](/mfa) which you can enable using the toggles located at the [Dashboard > Multi-factor Auth](${manage_url}/#/mfa) page. These changes will be automatically available to all your registered apps. - **User Experience**: In the past, an argument could be made that the user experience with embedded login was better because it did not require redirecting users to another subdomain. However, users are getting increasingly familiar with the process of being redirected to another subdomain to log in. As a result, they don't find the process disruptive to their experience. Think about this, when you try to access your Gmail, if you are not logged in, you get redirected to the Google Accounts subdomain in order to log in. Do you get frustrated with that? You probably don't even notice it. -- **Mobile Apps & Security**: According to the [Best Current Practice for OAuth 2.0 for Native Apps Request For Comments](https://www.rfc-editor.org/rfc/rfc8252.txt), only external user agents (such as the browser) should be used by native applications for authentication flows. Using the browser to make native app authorization requests results in better security and it gives users the confidence that they are entering credentials in the right domain. It also enables use of the user's current authentication state, making single sign-on possible. Embedded user agents are deemed unsafe for third parties and should not be implemented (see [Embedded Login with Auth0 > Security risks](#security-risks) for more info). With native login a malicious app could try and phish users for username/password or tokens. Also, if your mobile apps use native login, then your users have to enter their credentials for each of your apps, hence SSO is not possible. +- **Mobile Apps & Security**: According to the [Best Current Practice for OAuth 2.0 for Native Apps Request For Comments](https://www.rfc-editor.org/rfc/rfc8252.txt), only external user agents (such as the browser) should be used by native applications for authentication flows. Using the browser to make native app authorization requests results in better security and it gives users the confidence that they are entering credentials in the right domain. It also enables use of the user's current authentication state, making Single Sign-on (SSO) possible. Embedded user agents are deemed unsafe for third parties and should not be implemented (see [Embedded Login with Auth0 > Security risks](#security-risks) for more info). With native login a malicious app could try and phish users for username/password or tokens. Also, if your mobile apps use native login, then your users have to enter their credentials for each of your apps, hence SSO is not possible. -## Universal login with Auth0 +## Universal Login with Auth0 -For most situations, we recommend using a a universal login strategy, where Auth0 will show a [login page](/hosted-pages/login) if authentication is required. You can customize your login page using the [Dashboard](${manage_url}/#/login_page). +For most situations, we recommend using a Universal Login strategy, where Auth0 will show a [login page](/universal-login) if authentication is required. You can customize your login page using the [Dashboard](${manage_url}/#/login_page). -You can use **Auth0's Custom Domains** in order to persist the same domain across the login page and the app. This way the redirect to the login page will be transparent to your users since the domain will not change. For more details refer to [Custom Domains Overview](/custom-domains). +You can use **Auth0's Custom Domains** in order to persist the same domain across the login page and the app. This way the redirect to the login page will be transparent to your users since the domain will not change. For more details, see [Custom Domains](/custom-domains). Whenever your app triggers an authentication request, the user will be redirected to the login page in order to authenticate. This will create a cookie. In future authentication requests, Auth0 will check for this cookie, and if it is present the user will not be redirected to the login page. They will see the page only when they need to actually log in. This is the easiest way to implement SSO. @@ -45,36 +54,35 @@ Note that if the incoming authentication request uses an external identity provi You can deploy your custom login page from an external repository, like [GitHub](/extensions/github-deploy#deploy-hosted-pages), [Bitbucket](/extensions/bitbucket-deploy#deploy-hosted-pages), [GitLab](/extensions/gitlab-deploy#deploy-hosted-pages), or [Visual Studio Team Services](/extensions/visual-studio-team-services-deploy#deployment). ::: -Our recommendation is to use universal login when you use Auth0. The first and foremost reason is security. Using Auth0 hosted pages instead of hosting them externally provides seamless CSRF protection. This helps prevent third-party impersonation or the hijacking of sessions. +Our recommendation is to use Universal Login when you use Auth0. The first and foremost reason is security. Using Auth0 Universal Login instead of embedding login in your application provides seamless CSRF protection. This helps prevent third-party impersonation or the hijacking of sessions. ## Embedded login with Auth0 Embedded logins in web apps with Auth0 use [Cross-Origin Authentication](/cross-origin-authentication). This uses [third-party cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Third-party_cookies) to allow for secure authentication transactions across different origins. This does not apply to native applications since they use the standard OAuth 2.0 token endpoint. ::: note -Cross-origin authentication is only necessary when authenticating against a directory using a username and password. Social identity providers and enterprise federation use a different mechanism, redirecting via standard protocols like OpenID Connect and SAML. +Cross-origin authentication is not recommended and is only necessary when authenticating against a directory using a username and password. Social IdPs and enterprise federation use a different mechanism, redirecting via standard protocols like OpenID Connect (OIDC) and SAML. Additionally, cross-origin authentication is only applicable to embedded login on the web (using Lock or auth0.js). Native applications using embedded login make use of the standard OAuth 2.0 token endpoint. ::: -In addition, if you have not enabled [Custom Domain Names](/custom-domains) the end user must have a browser that supports third-party cookies, otherwise, in some browsers, cross-origin authentication will fail. For more information refer to [Limitations of Cross-Origin Authentication](/cross-origin-authentication). +In addition, if you have not enabled [custom domains](/custom-domains), the end user must have a browser that supports third-party cookies. Otherwise, in some browsers, cross-origin authentication will fail. For more information, see [Cross-Origin Authentication](/cross-origin-authentication#limitations). This limitation applies to both traditional username/password database connections as well as to passwordless database connections. + ### Security risks -Universal login is more secure than embedded login. Authentication takes place over the same domain, eliminating cross-origin requests. Cross-origin authentication is inherently more dangerous. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities. [Phishing attacks](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) are more likely, as are [man-in-the-middle attacks](/security/common-threats#man-in-the-middle-mitm-attacks). Universal login does not send information between origins, thereby negating cross-origin concerns. +Universal Login is more secure than embedded login. Authentication takes place over the same domain, eliminating cross-origin requests. Cross-origin authentication is inherently more dangerous. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities. Phishing attacks are more likely, as are [man-in-the-middle attacks](/security/common-threats#man-in-the-middle-mitm-attacks). Universal Login does not send information between origins, thereby negating cross-origin concerns. Embedded user agents are unsafe for third parties, including the authorization server itself. If an embedded login is used, the app has access to both the authorization grant and the user's authentication credentials. As a consequence, this data is left vulnerable to recording or malicious use. Even if the app is trusted, allowing it to access the authorization grant as well as the user's **full credentials** is unnecessary. This violates the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and increases the potential for attack. :::note -As a matter of fact, Google no longer supports an embedded approach when implementing OAuth. For more information on this, refer to [Google Blocks OAuth Requests Made via embedded browsers](https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/). +Google no longer supports an embedded approach when implementing OAuth. ::: -Furthermore, according to the [Internet Engineering Task Force (IETF)](https://www.ietf.org/), authorization requests from native apps should only be made through external user agents, primarily the user's browser. Using the browser to make native app authorization requests results in better security. When embedded agents are used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. For more info refer to [OAuth 2.0 Best Practices for Native Apps](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/). +Furthermore, according to the [Internet Engineering Task Force (IETF)](https://www.ietf.org/), authorization requests from native apps should only be made through external user agents, primarily the user's browser. Using the browser to make native app authorization requests results in better security. When embedded agents are used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. ## Keep reading :::next-steps - [Migrating from Embedded to Universal Login](/guides/login/migration-embedded-universal) - [Browser-Based vs. Native Login Flows on Mobile Devices](/design/browser-based-vs-native-experience-on-mobile) -- [Authentication Provider Best Practices: Universal Login](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) -- [OAuth 2.0 Best Practices for Native Apps](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/) - [Modernizing OAuth interactions in Native Apps for Better Usability and Security](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html) ::: diff --git a/articles/guides/migration-legacy-flows.md b/articles/guides/migration-legacy-flows.md index c95b872489..ba6f220bab 100644 --- a/articles/guides/migration-legacy-flows.md +++ b/articles/guides/migration-legacy-flows.md @@ -3,6 +3,16 @@ section: libraries title: Migrating from Legacy Authentication Flows description: How to migrate from Legacy Authentication Flows toc: true +topics: + - migrations + - lock + - auth0js + - tokens + - user-profiles +contentType: + - how-to + - concept +useCase: migrate --- # Migrating from Legacy Authentication Flows @@ -10,11 +20,11 @@ When using Lock versions below 11 and Auth0.js version below 9, you could use le ## Renewing Tokens -Legacy applications used [Refresh Tokens](/tokens/refresh-token) and the `refreshToken()` function as a way to get new tokens upon expiration (an example of this is below). +Legacy applications used Refresh Tokens and the `refreshToken()` function as a way to get new tokens upon expiration (an example of this is below). ```js function renewToken() { - // Assumes the refresh_token is stored in localStorage + // Assumes the Refresh Token is stored in localStorage refresh_token = localStorage.getItem('refresh_token'); auth0.refreshToken(refresh_token, function (err, delegationResult) { if (!err) @@ -22,9 +32,9 @@ function renewToken() { var expires_at = JSON.stringify( delegationResult.expires_in* 1000 + new Date().getTime()) ; - // Assumes you want to keep the time the token will expire - // and the id_token in localStorage - localStorage.setItem('expires_at', expires_at); + // Assumes you want to keep the time the token will expire + // and the ID Token in localStorage + localStorage.setItem('expires_at', expires_at); localStorage.setItem('id_token', delegationResult.id_token); } ); @@ -52,14 +62,14 @@ Check the [Silent Authentication documentation](/api-auth/tutorials/silent-authe ## Calling APIs -Legacy applications used an [ID Token](/tokens/id-token) to invoke APIs. This [is a bad practice](/api-auth/why-use-access-tokens-to-secure-apis) and we recommend you to start using [Access Tokens](/tokens/access-token). +Legacy applications used an [ID Token](/tokens/concepts/id-tokens) to invoke APIs. This is a bad practice, and we recommend that you only use [Access Tokens](/tokens/concepts/access-tokens). To call an API, you will need to specify the API identifier as the `audience` parameter when initializing auth0.js or Lock. ```js var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { auth: { - audience: 'https::/mydomain.com/api', + audience: 'https://mydomain.com/api', } }); ``` @@ -68,7 +78,9 @@ If you specify an audience, then the OIDC flow will be triggered and the user pr You can check the **Calling an API** section of our [SPA Quickstarts](/quickstart/backend) for more information on how to call APIs from SPAs. You will also need to migrate your backend API implementation to use Access Tokens. You can look at our [API Quickstarts](/quickstart/backend) for instructions on how to do this. -## User Profiles +## User Profiles + +The legacy authentication flows that allow ID Tokens and the `/userinfo` endpoint to include the complete user profile are being deprecated. Make sure the `Legacy User Profile` toggle is turned off after completing the migration to the new OIDC-conformant APIs. When using the legacy authentication flows, the entire user profile is returned in ID Tokens and from `/userinfo`, as demonstrated below. @@ -114,21 +126,21 @@ The new user profile conforms to the OIDC specification, which allows for certai } ``` -The contents will vary depending on which [scopes](/scopes) are requested. You will need to adjust the scopes you request when configuring Auth0.js or Lock so all the claims you need are available in your application. Note that you can add custom claims to return whatever data you want (for example, user metadata), as described in [this example](/scopes/current#example-add-custom-claims). +The contents will vary depending on which [scopes](/scopes) are requested. You will need to adjust the scopes you request when configuring Auth0.js or Lock so all the claims you need are available in your application. Note that you can add custom claims to return whatever data you want (for example, user metadata), as described in [this example](/scopes/current/sample-use-cases#add-custom-claims-to-a-token). Another approach to get the full user profile is to use the [Management API](/api/management/v2) (instead of getting the profile through the authentication flow) as described in the next section. ## User Profile with Management API -In the legacy flows, the [Management API](/api/management/v2) supported authentication with an `id_token`. This approach has been deprecated, and now you need to call it with an `access_token`. +In the legacy flows, the [Management API](/api/management/v2) supported authentication with an ID Token. This approach has been deprecated, and now you need to call it with an Access Token. -To get an `access_token`, you need to ask Auth0 for one using the `https://${account.namespace}/api/v2/` audience. Auth0 does not currently support specifying two audiences when authenticating, so you will need to still use your application's API audience when initializing Lock or auth0.js. Once the user is authenticated, you can use `checkSession` to retrieve a Management API `access_token`, and then call the [getUser() endpoint](/api/management/v2#!/Users/get_users_by_id). +To get an Access Token, you need to ask Auth0 for one using the `https://${account.namespace}/api/v2/` audience. Auth0 does not currently support specifying two audiences when authenticating, so you will need to still use your application's API audience when initializing Lock or auth0.js. Once the user is authenticated, you can use `checkSession` to retrieve a Management API `access_token`, and then call the [getUser() endpoint](/api/management/v2#!/Users/get_users_by_id). ```js function getUserUsingManagementApi() { webAuth.checkSession( { - audience: `https://${account.namespace}/api/v2/˜`, + audience: `https://${account.namespace}/api/v2/`, scope: 'read:current_user' }, function(err, result) { diff --git a/articles/hooks/_includes/_access_hook_secrets.md b/articles/hooks/_includes/_access_hook_secrets.md new file mode 100644 index 0000000000..f97a1aa5fb --- /dev/null +++ b/articles/hooks/_includes/_access_hook_secrets.md @@ -0,0 +1,3 @@ +::: note +To access a configured Hook Secret from within a Hook, use `context.webtask.secrets.SECRET_NAME`. +::: \ No newline at end of file diff --git a/articles/hooks/_includes/_default_hook_enable_behavior.md b/articles/hooks/_includes/_default_hook_enable_behavior.md new file mode 100644 index 0000000000..fd1cac9b99 --- /dev/null +++ b/articles/hooks/_includes/_default_hook_enable_behavior.md @@ -0,0 +1,3 @@ +::: warning +When creating new Hooks, Auth0 automatically enables the first Hook you create for an extensibility point. Any subsequent Hooks you create for that extensibility point are automatically disabled, so you must explicitly enable them. +::: \ No newline at end of file diff --git a/articles/hooks/_includes/_handle_rate_limits.md b/articles/hooks/_includes/_handle_rate_limits.md new file mode 100644 index 0000000000..ec53a8e291 --- /dev/null +++ b/articles/hooks/_includes/_handle_rate_limits.md @@ -0,0 +1,5 @@ +::: panel Handle Rate Limits when calling Auth0 APIs from within Hooks +If you call Auth0 APIs from within a Hook's script, you will need to handle rate limits. To do so, check the `X-RateLimit-Remaining` header and act appropriately when the number returned nears 0. + +Additionally, add logic to handle cases in which you exceed the provided rate limits and receive the `429` HTTP Status Code (`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. To learn more about rate limits, see [Rate Limit Policy For Auth0 APIs](/policies/rate-limits). +::: \ No newline at end of file diff --git a/articles/hooks/_includes/_hook_enabled_limit.md b/articles/hooks/_includes/_hook_enabled_limit.md new file mode 100644 index 0000000000..f88e9902b3 --- /dev/null +++ b/articles/hooks/_includes/_hook_enabled_limit.md @@ -0,0 +1,3 @@ +::: warning +Although you may create multiple Hooks for any given extensibility point, each extensibility point may have only **one** **enabled** Hook at a time. +::: \ No newline at end of file diff --git a/articles/hooks/_includes/_hook_secrets_limit.md b/articles/hooks/_includes/_hook_secrets_limit.md new file mode 100644 index 0000000000..67d2753477 --- /dev/null +++ b/articles/hooks/_includes/_hook_secrets_limit.md @@ -0,0 +1,3 @@ +::: note +You may create up to 20 secrets for any given Hook. +::: \ No newline at end of file diff --git a/articles/hooks/_includes/_test_runner_save_warning.md b/articles/hooks/_includes/_test_runner_save_warning.md new file mode 100644 index 0000000000..101c626f77 --- /dev/null +++ b/articles/hooks/_includes/_test_runner_save_warning.md @@ -0,0 +1,3 @@ +::: warning +Executing the code using the Runner requires a save, which means that the original code will be overwritten. +::: \ No newline at end of file diff --git a/articles/hooks/cli/create-delete.md b/articles/hooks/cli/create-delete.md deleted file mode 100644 index 31d2111d15..0000000000 --- a/articles/hooks/cli/create-delete.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -description: How to create/delete Hooks using the Auth0 Command-Line Interfance -beta: true ---- - -# Create/Delete Hooks Using the Auth0 Command-Line Interface - -::: note -The Auth0 CLI examples use `auth0-profile` as the name of the profile. This is the same profile name used when installing `wt-cli`, and you can obtain it from *Step 2* of the instructions set located on [Auth0 Management Dashboard's Webtask page](${manage_url}/#/account/webtasks). -::: - -Using the Auth0 CLI, you can create new Hooks, as well as manage or delete existing Hooks. You can also gather real-time data about your Hooks. - -## Create a New Hook - -Rather than beginning from scratch, you can scaffold the sample code for an Auth0 hook. - -`auth0 scaffold -t pre-user-registration > file.js` - -Create the hook: - -`auth0 create -t pre-user-registration --name my-extension-1 -p auth0-default file.js` - -### Provision Secrets to New Hooks - -Optionally, you can add provision secrets (such as Twilio Keys or database connection strings) to your new Hook by adding `--secret KEY=VALUE` to your *Create* command. The information you attach will be encrypted, and it can only be decrypted by the Webtask server. - -At this point, you have created a new, disabled Hook using the `pre-user-registration` [extensibility point](/hooks/extensibility-points). You can repeat this process and create Hooks for any of the other extensibility points. - -## Delete an Existing Hook - -If you need to delete an existing Hook, you can do so using the following command: - -`auth0 rm my-extension-1 -p auth0-default` \ No newline at end of file diff --git a/articles/hooks/cli/edit.md b/articles/hooks/cli/edit.md deleted file mode 100644 index 5ed62216c7..0000000000 --- a/articles/hooks/cli/edit.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -description: How to edit Hooks using the Auth0 Command-Line Interfance -beta: true ---- - -# Edit Existing Hooks Using the Auth0 Command-Line Interface - -::: note -All of the examples on this page use `auth0-profile` as the name of the profile. This is the same profile name used when installing `wt-cli` and can be obtained from *Step 2* of the instructions set located on [Auth0 Management Dashboard's Webtask page](${manage_url}/#/account/webtasks). -::: - -You can edit the code of your Hook using the [Webtask Editor](https://webtask.io/docs/editor). The following command will open up the code for your Hook in the Webtask Editor window: - - `auth0 edit my-extension-1` - - ![Webtask Editor](/media/articles/hooks/webtask-editor.png) - -If the CLI cannot open the Editor window automatically, you can copy and paste the provided link into your web browser. - -::: note -Please see the [Webtask docs](https://webtask.io/docs/editor) for detailed information on using the Webtask Editor. -::: - -## Test Your Hook - -The Webtask Editor allows you to test your Hook using the Runner. By default, the Runner is hidden until you choose to display it by clicking its icon in the top left of the Editor. - -![](/media/articles/hooks/webtask-runner.png) - -The Runner allows you to simulate an Auth0 call to your Hook and provides the basic parameters needed to complete the call. You can edit the provided schema as necessary. - -![](/media/articles/hooks/webtask-runner2.png) - -When you're ready, click **Run** to proceed. You will be presented with the results of the call. - -![](/media/articles/hooks/webtask-runner3.png) - -If you run multiple tests, the Runner keeps track of the calls you've made in its *History* section. For each result, you can see specific details about the call by clicking **>** to the right of the call result. - -![](/media/articles/hooks/webtask-runner4.png) - -:::panel Test Runner Schema -If you created your Hook early on during the beta testing period, your Webtask Editor/Test Runner window might not populate with the schema required to successfully use the Test Runner. If that is the case, you'll need to save the Hook's code, delete the Hook, and create a new Hook using your existing code. -::: - -## Manipulate Secrets - -If you [provisioned a secret to your Hook](/hooks/cli/create-delete#provision-secrets-to-new-hooks) during creation, you can manipulate it by clicking on the **wrench** at the top left of the Webtask Editor window and selecting **Secrets** from the dropdown menu. - - ![Webtask Editor Secrets pane](/media/articles/hooks/webtask-editor-secrets.png) \ No newline at end of file diff --git a/articles/hooks/cli/enable-disable.md b/articles/hooks/cli/enable-disable.md deleted file mode 100644 index 2229fb58a6..0000000000 --- a/articles/hooks/cli/enable-disable.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -description: How to enable/disable Hooks using the Auth0 Command-Line Interfance -beta: true ---- - -# Enable or Disable Existing Hooks Using the Auth0 Command-Line Interface - -::: note -All of the examples on this page use `auth0-profile` as the name of the profile. This is the same profile name used when installing `wt-cli` and can be obtained from *Step 2* of the instructions set located on [Auth0 Management Dashboard's Webtask page](${manage_url}/#/account/webtasks). -::: - -For each extensibility point, you may have either no associated Hooks enabled or **one** associated Hook enabled. - -By default, the Auth0 CLI creates new Hooks in a disabled state. - -## Enable Your Hook - -The following command enables your Hook: - - `auth0 enable my-extension-1 -p auth0-default` - -By enabling a given Hook, the Auth0 CLI disables all other Hooks associated with the same extensibility point. - -## Disable Your Hook - -The following command disables your Hook: - - `auth0 disable my-extension-1 -p auth0-default` \ No newline at end of file diff --git a/articles/hooks/cli/index.md b/articles/hooks/cli/index.md deleted file mode 100644 index 65968957b6..0000000000 --- a/articles/hooks/cli/index.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: How to use the Command-Line Interface with Hooks -url: /hooks/cli -beta: true ---- - -# Auth0 Command-Line Interface - -The Auth0 Command-Line Interface (CLI) allows you to create, edit, enable/disable, and delete Hooks associated with specific extensibility points within the Auth0 platform. You can also use the CLI to identify Hooks and gather real-time logging information. - -## Set Up the CLI - -You can find instructions for installing and configuring the Webtask CLI in the [Dashboard > Webtask page](${manage_url}/#/account/webtasks). - -The `wt-cli` package also includes the `auth0` binary, allowing you to use the Auth0 CLI. - -![Install Webtasks Instructions](/media/articles/hooks/mgmt-dashboard-webtasks.png) - -## Work with Hooks - -Once you have installed and set up the CLI, you can use it to create new Hooks and manage/delete existing Hooks. You can also use it to gather real-time log data on your Hooks. - -::: note -The Auth0 CLI examples use `auth0-profile` as the name of the profile. This is the same profile name used when installing `wt-cli`, and you can obtain it from *Step 2* of the instructions set located on [Dashboard > Webtask](${manage_url}/#/account/webtasks). -::: - -* [Create/Delete Hooks](/hooks/cli/create-delete) -* [Edit Existing Hooks](/hooks/cli/edit) -* [Enable/Disable Existing Hooks](/hooks/cli/enable-disable) -* [Identify and Get Log Data from Your Hooks](/hooks/cli/logs) \ No newline at end of file diff --git a/articles/hooks/cli/logs.md b/articles/hooks/cli/logs.md deleted file mode 100644 index 82b6a88c5e..0000000000 --- a/articles/hooks/cli/logs.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: How to get Hooks logs using the Auth0 Command-Line Interface -beta: true ---- - -# Get Log Information About Hooks Using the Auth0 Command-Line Interface - -::: note -All of the examples on this page use `auth0-profile` as the name of the profile. This is the same profile name used when installing `wt-cli` and can be obtained from *Step 2* of the instructions set located on [Auth0 Management Dashboard's Webtask page](${manage_url}/#/account/webtasks). -::: - -You can use the Auth0 CLI to gather information about your Hooks: - -* To get a list of Hooks for a specific extensibility point: - `auth0 ls -t pre-user-registration -p auth0-default` -* To get a list of Hooks associated with your Auth0 account: - `auth0 ls -p auth0-default` -* To access logs containing real-time data on your Hooks: - `auth0 logs -p auth0-default` \ No newline at end of file diff --git a/articles/hooks/create.md b/articles/hooks/create.md new file mode 100644 index 0000000000..40d1be3940 --- /dev/null +++ b/articles/hooks/create.md @@ -0,0 +1,90 @@ +--- +title: Create Hooks +description: Learn how to create Hooks using the Dashboard and Management API. Hooks may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - dashboard + - mgmt-api +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# Create Hooks + +You can create multiple Hooks for any given [extensibility point](/hooks/extensibility-points) using the Dashboard or Management API. + +Hooks may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +<%= include('./_includes/_hook_enabled_limit') %> + +
      +
      + +
      +
      +
      + +## Create Hooks using the Dashboard + +<%= include('./_includes/_default_hook_enable_behavior') %> + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click **Create a Hook**. +2. Enter a descriptive name for your Hook, select the extensibility point for which the Hook should execute, and click **Create**. +3. Locate the section for the extensibility point you selected, and click the pencil icon next to the hook you created. +4. Update the Hook using the Hook Editor, and click the disk icon to save. + +
      +
      + +## Create Hooks using the Management API + +<%= include('./_includes/_default_hook_enable_behavior') %> + +1. Make a `POST` call to the [Create a Hook endpoint](/api/management/v2/#!/Hooks/post_hooks). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `HOOK_NAME`, `HOOK_SCRIPT`, and `EXTENSIBILITY_POINT_NAME` placeholder values with your Management API Access Token, Hook name, Hook script, and extensibility point name, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/hooks", + "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\": \"HOOK_NAME\", \"script\": \"HOOK_SCRIPT\", \"triggerId\": \"EXTENSIBILITY_POINT_NAME\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:hooks`. | +| `HOOK_NAME` | Name of the hook you would like to create. | +| `HOOK_SCRIPT` | Script that contains the code for the hook. Should match what you would enter if you were creating a new hook using the Dashboard. | +| `EXTENSIBILITY_POINT_NAME` | Name of the extensibility point for which the hook should execute. Options include: `credentials-exchange`, `pre-user-registration`, `post-user-registration`, `post-change-password`. To learn more about extensibility points, see [Extensibiity Points](/hooks/extensibility-points). | + +
      +
      +
      + +<%= include('./_includes/_handle_rate_limits') %> + +::: note +Optionally, you can add secrets (such as Twilio Keys or database connection strings) to Hooks. To learn more, see [Hook Secrets](/hooks/secrets). +::: + +### Explore starter code and sample Hook scripts + +To explore starter code and sample Hook scripts, see the documentation for your chosen [extensibility point](/hooks/extensibility-points): + +* [Client Credentials Exchange](/hooks/extensibility-points/client-credentials-exchange) +* [Post Change Password](/hooks/extensibility-points/post-change-password) +* [Post User Registration](/hooks/extensibility-points/post-user-registration) +* [Pre User Registration](/hooks/extensibility-points/pre-user-registration) +* [Send Phone Message](/hooks/extensibility-points/send-phone-message) diff --git a/articles/hooks/dashboard/create-delete.md b/articles/hooks/dashboard/create-delete.md deleted file mode 100644 index b3106a1c70..0000000000 --- a/articles/hooks/dashboard/create-delete.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -description: How to create new Hooks using the Management Dashboard -beta: true ---- - -# Create a New Hook Using the Dashboard - -You can create new Hooks using the Auth0 Management Dashboard. - -![Management Dashboard Hooks Page](/media/articles/hooks/hooks-dashboard.png) - -## Create a New Hook - -1. Navigate to [the Hooks page of the Dashboard](${manage_url}/#/hooks). You can create new Hooks in one of two ways: - - * Clicking on the **+ Create New Hook** button at the top right of the Hooks page. - * Finding the extensibility hook you want to work with and then clicking the **Create New Hook** link below. - -2. On the *New Hook* pop-up window, provide the requested information: - - ![Create Hook Dialog](/media/articles/hooks/create-new-hook.png) - - * **Name**: The name for your new Hook - * **Hook**: The extensibility point associated with your Hook - - Click **Create** to create your Hook. - - At this point, you will see your newly-created Hook listed under its associated extensibility point. - -:::panel New Hooks -For any given extensibility point, you may create multiple Hooks. However, you may only have **one** Hook enabled per extensibility point at any given time. - -Auth0 automatically enables the first Hook you create for an extensibility point, and any subsequent Hooks for that point are created in a disabled state. As such, you must explicitly activate subsequent Hooks. -::: - -![List of Hooks](/media/articles/hooks/hooks-list.png) - -## Delete an Existing Hook - -1. In the Hooks page of the Management Dashboard, find the Hook you want to edit. -2. Click the **Gear** icon next to your Hook. -3. Click **Delete**. -4. Confirm that you want to delete your Hook by clicking **YES, DELETE HOOK**. - -![Delete Hook Confirmation](/media/articles/hooks/delete-hook.png) \ No newline at end of file diff --git a/articles/hooks/dashboard/edit.md b/articles/hooks/dashboard/edit.md deleted file mode 100644 index b965191d05..0000000000 --- a/articles/hooks/dashboard/edit.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -description: How to edit Hooks using the Management Dashboard -beta: true ---- - -# Edit Existing Hooks Using the Dashboard - -You can edit the code for your existing Hook using the [Webtask Editor](https://webtask.io/docs/editor). To open up the Webtask Editor: - -1. Navigate to [the Hooks page of the Dashboard](${manage_url}/#/hooks) and find the Hook you want to edit. -2. Click the **Pencil and Paper** icon to the right of the Hook to open the Webtask Editor. - - ![List of Hooks](/media/articles/hooks/hooks-list.png) - -3. Edit your Hook using the Webtask Editor. - - ![Webtask Editor](/media/articles/hooks/webtask-editor.png) - - ::: note - Please see the [Webtask docs](https://webtask.io/docs/editor) for detailed information on using the Webtask Editor. - ::: - -## Test Your Hook - -The Webtask Editor allows you to test your Hook using the Runner. By default, the Runner is hidden until you choose to display it by clicking its icon in the top left of the Editor. - -![](/media/articles/hooks/webtask-runner.png) - -The Runner allows you to simulate an Auth0 call to your Hook and provides the basic parameters needed to complete the call. You can edit the provided schema as necessary. - -![](/media/articles/hooks/webtask-runner2.png) - -When you're ready, click **Run** to proceed. You will be presented with the results of the call. - -![](/media/articles/hooks/webtask-runner3.png) - -If you run multiple tests, the Runner keeps track of the calls you've made in its *History* section. For each result, you can see specific details about the call by clicking **>** to the right of the call result. - -![](/media/articles/hooks/webtask-runner4.png) - -:::panel Test Runner Schema -If you created your Hook early on during the beta testing period, your Webtask Editor/Test Runner window might not populate with the schema required to successfully use the Test Runner. If that is the case, you'll need to save the Hook's code, delete the Hook, and create a new Hook using your existing code. -::: - -## Rename Your Hook - -You can rename your Hook using the Management Dashboard. - -1. In [the Hooks page of the Dashboard](${manage_url}/#/hooks), find the Hook you want to edit. -2. Click the **Gear** icon next to your Hook. -3. Click **Rename**. You will see a dialog pop up, asking you for the **Current Name** of the Hook, as well as the **New Name** you want to use. Click **Rename** when you have populated both values. - -![Rename Hooks prompt](/media/articles/hooks/rename-hook.png) \ No newline at end of file diff --git a/articles/hooks/dashboard/enable-disable.md b/articles/hooks/dashboard/enable-disable.md deleted file mode 100644 index 45bcb33496..0000000000 --- a/articles/hooks/dashboard/enable-disable.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -description: How to enable or disable Hooks using the Management Dashboard -beta: true ---- - -# Enable or Disable Existing Hooks Using the Dashboard - -You can use the Management Dashboard to enable/disable Hooks. Each extensibility point may be associated with **zero** or **one** active Hook. - -::: note -When creating new Hooks, Auth0 enables your Hook for that extensibility point if there are no other Hooks associated with that point. In any other circumstance, Auth0 does *not* enable your new Hook. -::: - -## Enable a Hook - -1. Navigate to [the Hooks page of the Dashboard](${manage_url}/#/hooks) and find the extensibility point for which you want an enabled Hook. -2. Immediately under the name and description of the extensibility point, click on the dropdown box that lists all of the point's associated Hooks. - - ![List of Hooks for a Point](/media/articles/hooks/select-hook-to-enable.png) - -3. Select the Hook you want to enable. -4. Confirm your selection by clicking **YES, ENABLE HOOK**. - - ![Confirm Hook to Enable](/media/articles/hooks/confirm-enable-hook.png) - -You will now see a green dot next to the name of the Hook, indicating that it's enabled. - -## Disable a Hook - -1. Navigate to [the Hooks page of the Dashboard](${manage_url}/#/hooks) and find the extensibility point for which you want an enabled Hook. -2. Immediately under the name and description of the extensibility point, click on the dropdown box that lists all of the point's associated Hooks. - - ![List of Hooks for a Point](/media/articles/hooks/select-hook-to-enable.png) - -3. Select **None**. -4. Confirm your selection by clicking **YES, DISABLE HOOK**. - - ![Confirm Hook to Disable](/media/articles/hooks/disable-hook.png) \ No newline at end of file diff --git a/articles/hooks/dashboard/index.md b/articles/hooks/dashboard/index.md deleted file mode 100644 index 18fed1500a..0000000000 --- a/articles/hooks/dashboard/index.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -description: How to create new Hooks using the Management Dashboard -url: /hooks/dashboard -beta: true ---- - -# Work with Hooks in the Dashboard - -![Management Dashboard Hooks Page](/media/articles/hooks/hooks-dashboard.png) - -The Auth0 Management Dashboard provides a visual interface for working with Hooks. With the Dashboard, you can: - -* [Create/Delete New Hooks](/hooks/dashboard/create-delete) -* [Enable/Disable Existing Hooks](/hooks/dashboard/enable-disable) -* [Edit Existing Hooks](/hooks/dashboard/edit) \ No newline at end of file diff --git a/articles/hooks/delete.md b/articles/hooks/delete.md new file mode 100644 index 0000000000..cdc18884aa --- /dev/null +++ b/articles/hooks/delete.md @@ -0,0 +1,56 @@ +--- +title: Delete Hooks +description: Learn how to delete Hooks using the Dashboard and Management API. Hooks may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - mgmt-api + - dashboard +contentType: how-to +useCase: extensibility-hooks +v2: true +--- +# Delete Hooks + +When you no longer need Hooks, you can delete them using either the Dashboard or Management API. + +Hooks may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +
      +
      + +
      +
      +
      + +## Delete Hooks using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the gear icon next to the Hook you want to delete. +2. Select **Delete**, and confirm. +
      +
      + +## Delete Hooks using the Management API + +1. Make a `DELETE` call to the [Delete a Hook endpoint](/api/management/v2/#!/Hooks/delete_hooks_by_id). Be sure to replace `HOOK_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your hook ID and Management API Access Token, respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_ID", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| Value | Description | +| - | - | +| `HOOK_ID` | ID of the Hook you would like to delete. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `delete:hooks`. | + +
      +
      +
      diff --git a/articles/hooks/enable-disable.md b/articles/hooks/enable-disable.md new file mode 100644 index 0000000000..29db93e2a5 --- /dev/null +++ b/articles/hooks/enable-disable.md @@ -0,0 +1,76 @@ +--- +title: Enable/Disable Hooks +description: Learn how to enable and disable Hooks using the Dashboard and Management API. +topics: + - hooks + - dashboard + - mgmt-api +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# Enable/Disable Hooks + +You can enable or disable Hooks that have been configured for any given [extensibility point](/hooks/extensibility-points) using the Dashboard or Management API. + +<%= include('./_includes/_hook_enabled_limit') %> + +<%= include('./_includes/_default_hook_enable_behavior') %> + +
      +
      + +
      +
      +
      + +## Enable/Disable Hooks using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and locate the extensibility point for which you want to enable or disable a Hook. + +2. Click on the dropdown box located immediately under the extensibility point's name and description. + + ![View Avalilable Hooks for an Extensibility Point](/media/articles/hooks/select-hook-to-enable.png) + +3. Select the Hook you want to enable, and confirm. If you want to disable all Hooks, select `None`. + +A green dot will appear next to the name of any enabled Hooks. +
      +
      + +## Enable/Disable Hooks using the Management API + +1. Make a `PATCH` call to the [Update a Hook endpoint](/api/management/v2/#!/Hooks/patch_hooks_by_id). Be sure to replace `HOOK_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your hook ID and Management API Access Token, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_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" : "{ \"enabled\": \"true\" }" + } +} +``` + +| Value | Description | +| - | - | +| `HOOK_ID` | ID of the hook to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:hooks`. | + +::: note +The `enabled` property represents whether the rule is enabled (`true`) or disabled (`false`). | +::: + +
      +
      +
      diff --git a/articles/hooks/extensibility-points/client-credentials-exchange.md b/articles/hooks/extensibility-points/client-credentials-exchange.md new file mode 100644 index 0000000000..1d447b40f7 --- /dev/null +++ b/articles/hooks/extensibility-points/client-credentials-exchange.md @@ -0,0 +1,263 @@ +--- +title: Client Credentials Exchange +description: Learn how hooks can be used with the Client Credentials Exchange extensibility point, which is available for database connections and passwordless connections. +toc: true +topics: + - hooks + - extensibility-points + - client-credentials-exchange + - credentials-exchange +contentType: + - how-to +useCase: extensibility-hooks +v2: true +--- + +# Client Credentials Exchange + +At the Client Credentials Exchange extensibility point, Hooks allow custom actions to be executed when an Access Token is issued through the Authentication API [`POST /oauth/token` endpoint](/api/authentication#client-credentials-flow) using the [Client Credentials Flow](/flows/concepts/client-credentials). For example, you may deny the token from being issued, add custom claims to the Access Token, or modify its scopes. + +Hooks at this extensibility point are blocking (synchronous), which means they execute as part of the trigger's process and will prevent the rest of the Auth0 pipeline from running until the Hook is complete. + +::: note +The `triggerId` for the Client Credentials Exchange extensibility point is `credentials-exchange`. To learn how to create Hooks for this extensibility point, see [Create New Hooks](/hooks/create). +::: + +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). + +## Starter code and parameters + +When creating a Hook executed at the Client Credentials Exchange extensibility point, you may find the following starter code helpful. Parameters that can be passed into and used by the Hook function are listed at the top of the code sample. + +```js +/** +@param {object} client - client information +@param {string} client.name - client name +@param {string} client.id - client ID +@param {string} client.tenant - Auth0 tenant name +@param {object} client.metadata - client metadata +@param {array|undefined} scope - either an array of strings representing the token's scope claim, or undefined +@param {string} audience - token's audience claim +@param {object} context - Auth0 context info +@param {object} context.webtask - Hook (webtask) context +@param {function} cb - function (error, accessTokenClaims) +*/ + +module.exports = function(client, scope, audience, context, cb) { + var access_token = {}; + access_token.scope = scope; // do not remove this line + + // Modify scopes or add extra claims + // access_token['https://example.com/claim'] = 'bar'; + // access_token.scope.push('extra'); + + // Deny the token and respond with an OAuth2 error response + // if (denyExchange) { + // // To return an HTTP 400 with { "error": "invalid_scope", "error_description": "Not authorized for this scope." } + // return cb(new InvalidScopeError('Not authorized for this scope.')); + // + // // To return an HTTP 400 with { "error": "invalid_request", "error_description": "Not a valid request." } + // return cb(new InvalidRequestError('Not a valid request.')); + // + // // To return an HTTP 500 with { "error": "server_error", "error_description": "A server error occurred." } + // return cb(new ServerError('A server error occurred.')); + // } + + cb(null, access_token); +}; +``` + +Please note: + +* The callback function (`cb`) at the end of the sample code signals completion and *must* be included. +- The line `access_token.scope = scope` ensures that all granted scopes will be present in the Access Token. Removing it will reset all scopes, and the token will include only any scopes you might add with the script. + +### Default response + +When you run a Hook executed at the Client Credentials Exchange extensibility point, the default response object is: + +```json +{ + "scope": "array of strings" +} +``` + +### Starter code response + +Once you've customized the starter code with your scopes and additional claims, you can test the Hook using the Runner embedded in the Hook Editor. The Runner simulates a call to the Hook with the same body and response that you would get with a Client Credentials Exchange. + +<%= include('../_includes/_test_runner_save_warning') %> + +When you run a Hook based on the starter code, the response object is: + +```json +{ + "audience": "https://my-tenant.auth0.com/api/v2/", + "client": { + "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", + "name": "client-name", + "tenant": "my-tenant", + "metadata": { + "plan": "full" + } + }, + "scope": [ + "read:connections" + ] +} +``` + +## Sample script: Add an additional scope to the Access Token + +In this example, we use a Hook to add an additional [scope](/scopes) to those already existing for the Access Token. + +```js +module.exports = function(client, scope, audience, context, cb) { + // Scopes to be added + var access_token = {}; + + // Get the scope that's currently on the Access Token + // and add it to the object we're working with + // Do not remove this line! + access_token.scope = scope; + + // Append the `read:resource` scope + access_token.scope.push('read:resource'); + + // Callback to indicate completion and to return new + // array of scopes + cb(null, access_token); +}; +``` + +### Response + +When we run this Hook, the response object is: + +```json +{ + "scope": [ + "read:connections", + "read:resource" + ] +} +``` + +## Sample script: Add a claim to the Access Token + +In this example, we add a [namespaced](/tokens/guides/create-namespaced-custom-claims) custom claim and its value to the Access Token. + +You can add the following as claims to the issued token: + +* The `scope` property of the response object +* Any properties with [namespaced](/tokens/concepts/claims-namespacing) property names + +The extensibility point will ignore all other response object properties. + +<%= include('../_includes/_access_hook_secrets') %> + +```js +module.exports = function(client, scope, audience, context, cb) { + // Claims to be added + var access_token = {}; + + // New claim to add to the token + access_token['https://example.com/foo'] = 'bar'; + + // Callback to indicate completion and to return new claim + cb(null, access_token); + }; +``` + +### Response + +When we run this Hook, the response object is: + +```json +{ + "https://example.com/foo": "bar" +} +``` + +## Sample script: Raise an Error or Deny an Access Token + +In this example, we use custom Error objects to generate OAuth2 Error Responses. ([See OAuth2 RFC - Section 5.2](https://tools.ietf.org/html/rfc6749#section-5.2)) + +If a plain JavaScript error is returned in the callback, such as: + +```js +module.exports = function(client, scope, audience, context, cb) { + // Callback to indicate completion and to return new claim + cb(new Error("Unknown error occurred."); + }; +``` + +Then when you request a `client_credentials` grant from the `/oauth/token` endpoint, Auth0 will respond with: + +``` +HTTP 500 +{ "error": "server_error", "error_description": "Unknown error occurred." } +``` + +However, if you like additional control over the OAuth2 Error Response, three custom Error objects are available to use instead. They are: + +### InvalidScopeError + +```js +module.exports = function(client, scope, audience, context, cb) { + const invalidScope = ...; // determine if scope is valid + + if(invalidScope) { + cb(new InvalidScopeError("Scope is not permitted.")); + } + }; +``` + +Then when you request a `client_credentials` grant is from the `/oauth/token` endpoint, Auth0 will respond with: + +``` +HTTP 400 +{ "error": "invalid_scope", "error_description": "Scope is not permitted." } +``` + +### InvalidRequestError + +```js +module.exports = function(client, scope, audience, context, cb) { + const invalidRequest = ...; // determine if request is valid + + if(invalidRequest) { + cb(new InvalidRequestError("Bad request.")); + } + }; +``` + +Then when you request a `client_credentials` grant from the `/oauth/token` endpoint, Auth0 will respond with: + +``` +HTTP 400 +{ "error": "invalid_request", "error_description": "Bad request." } +``` + +### ServerError + +```js +module.exports = function(client, scope, audience, context, cb) { + callOtherService(function(err, response) { + if(err) { + return cb(new ServerError("Error calling remote system: " + err.message)); + } + }); + }; +``` + +Then when you request a `client_credentials` grant from the `/oauth/token` endpoint, Auth0 will respond with: + +``` +HTTP 400 +{ "error": "server_error", "error_description": "Error calling remote system: ..." } +``` + +::: note +Currently, the behavior of the built-in JavaScript `Error` class and `ServerError` is identical, but the `ServerError` class allows you to be explicit about the OAuth2 error that will be returned. +::: diff --git a/articles/hooks/extensibility-points/credentials-exchange.md b/articles/hooks/extensibility-points/credentials-exchange.md deleted file mode 100644 index 4117d61609..0000000000 --- a/articles/hooks/extensibility-points/credentials-exchange.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: Using the Credentials Exchange Extensibility Point -description: The credentials-exchange extensibility point for use with Hooks -toc: true -beta: true ---- - -# Extensibility Point: Credentials Exchange - -The `credentials-exchange` extensibility point allows you to change the scopes and add custom claims to the [Access Tokens](/tokens/access-token) issued by the [Auth0 API's `POST /oauth/token` endpoint](/api/authentication#authorization-code) during runtime. - -::: note -Please see [Calling APIs from a Service](/api-auth/grant/client-credentials) for more information on the Client Credentials Grant. -::: - -## Types of Claims Available - -You can add the following as claims to the issued token: - -* The `scope` property of the response object; -* Any properties with namespaced property names: - - * URLs with HTTP or HTTPS schemes - * URLs with hostnames that *aren't* auth0.com, webtask.io, webtask.run, or the associated subdomain names - -The extensibility point will ignore all other response object properties. - -::: note -If you need to configure client secrets and access them within your Hook, you can do so using `context.webtask.secrets.SECRET_NAME`. -::: - -## How to Implement This - -You can implement a [Hook](/hooks#work-with-hooks) using this extensibility point with either the [Dashboard](/hooks/dashboard) or the [Command Line Interface](/hooks/cli). - -For detailed steps on implementing the grant, please refer to [Using Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks). - -### Starter Code and Parameters - -After you've created a new Hook that uses the Credentials Exchange extensibility point, you can open up the Hook and edit it using the Webtask Editor embedded in the Dashboard. - -The parameters listed in the comment at the top of the code indicate the Auth0 objects (and the parameters within the objects) that can be passed into and used by the Hook's function. For example, the `client` object comes with the following parameters: client name, client ID, the Auth0 tenant name with which the client is associated, and client metadata. - -```js -/** -@param {object} client - information about the client -@param {string} client.name - name of client -@param {string} client.id - client id -@param {string} client.tenant - Auth0 tenant name -@param {object} client.metadata - client metadata -@param {array|undefined} scope - array of strings representing the scope claim or undefined -@param {string} audience - token's audience claim -@param {object} context - additional authorization context -@param {object} context.webtask - webtask context -@param {function} cb - function (error, accessTokenClaims) -*/ -module.exports = function(client, scope, audience, context, cb) { - var access_token = {}; - access_token.scope = scope; - - // Modify scopes or add extra claims - // access_token['https://example.com/claim'] = 'bar'; - // access_token.scope.push('extra'); - - cb(null, access_token); -}; -``` - -The callback function `cb` at the end of the sample code is used to signal completion and must not be omitted. - -#### Response - -The default response object every time you run this Hook is as follows: - -```json -{ - "scope": "array of strings" -} -``` - -### Testing Your Hook - -::: note -Executing the code using the Runner requires a save, which means that your original code will be overwritten. -::: - -Once you've modified the sample code with the specific scopes of additional claims you'd like added to your Access Tokens, you can test your Hook using the Runner. The runner simulates a call to the Hook with the same body/payload that you would get with a Credentials Exchange. The following is the sample body that populates the Runner by default (these are the same objects/parameters detailed in the comment at the top of the sample Hook code): - -```json -{ - "audience": "https://my-tenant.auth0.com/api/v2/", - "client": { - "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", - "name": "client-name", - "tenant": "my-tenant", - "metadata": { - "plan": "full" - } - }, - "scope": [ - "read:connections" - ] -} -``` - -## Example: Add Scope to the Access Token - -This example shows you how to use the Hook to add an additional scope to the scopes already existing on the Access Token. - -```js -module.exports = function(client, scope, audience, context, cb) { - // Scopes to be added - var access_token = {}; - - // Get the scope that's currently on the Access Token - // and add it to the object we're working with - access_token.scope = scope; - - // Append the `read:resource` scope - access_token.scope.push('read:resource'); - - // Callback to indicate completion and to return new - // array of scopes - cb(null, access_token); -}; -``` - -Using the [test runner](https://webtask.io/docs/editor/runner), we see that the response is as follows: - -```json -{ - "scope": [ - "read:connections", - "read:resource" - ] -} -``` - -## Example: Add a Claim to the Access Token - -This example show you have to add a namespaced claim and its value to the Access Token. - -```js -module.exports = function(client, scope, audience, context, cb) { - // Claims to be added - var access_token = {}; - - // New claim to add to the token - access_token['https://example.com/foo'] = 'bar'; - - // Callback to indicate completion and to return new claim - cb(null, access_token); - }; -``` - -Using the [test runner](https://webtask.io/docs/editor/runner), we see that the response is as follows: - -```json -{ - "https://example.com/foo": "bar" -} -``` \ No newline at end of file diff --git a/articles/hooks/extensibility-points/index.md b/articles/hooks/extensibility-points/index.md index 85b2a78920..c39ebc9aa5 100644 --- a/articles/hooks/extensibility-points/index.md +++ b/articles/hooks/extensibility-points/index.md @@ -1,13 +1,27 @@ --- -description: The extensibility points for use with Hooks -url: /hooks/extensibility-points -beta: true +description: Learn about extensibility points of the Auth0 platform that are available to use with Hooks. +topics: + - hooks + - extensibility-points +contentType: + - reference +useCase: extensibility-hooks --- # Extensibility Points -Hooks allow you to customize the behavior of Auth0 with Node.js code. They are essentially [Webtask](https://webtask.io), but [Hooks](/hooks#work-with-hooks) are executed only against selected extensibility points, which are the serverless option that's analagous to the webhooks that come with a server. The following is a list of currently available extensibility points: +Extensibility points are places in the Auth0 platform where [Hooks](/hooks) can be executed. -- [Credentials Exchange](/hooks/extensibility-points/credentials-exchange): change the scopes and add custom claims to the tokens issued by the Auth0 API's `POST /oauth/token` endpoint -- [Pre-User Registration](/hooks/extensibility-points/pre-user-registration): prevent user registration and add custom metadata to a newly-created user -- [Post-User Registration](/hooks/extensibility-points/post-user-registration): implement custom actions that execute asynchronously from the Auth0 authentication process after a new user registers and is added to the database \ No newline at end of file +Whether Hooks can be used with connections varies according to extensibility point. Hooks that can be used with connections only work with [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). + +Extensibility points may also block processes from executing. Synchronous extensibility points are blocking, which means they execute the Hook as part of the trigger's process and will prevent that process from executing until the Hook is complete. Aynchronous extensibility points will not wait for the Hook to finish its execution before proceeding. + +The following extensibility points are available: + +| Extensibility Point | Trigger ID | Connection Type(s) | Blocking? | Description | +|---------------------|-----------|-----------------|-------------|-------------------| +| [Client Credentials Exchange](/hooks/extensibility-points/client-credentials-exchange) | `credentials-exchange` | N/A | Yes | Extend machine-to-machine token exchanges. Prevent a token exchange or change the scopes and add custom claims to access tokens issued by the Auth0 API's `POST /oauth/token` endpoint. | +| [Pre-User Registration](/hooks/extensibility-points/pre-user-registration) | `pre-user-registration` | Database, Passwordless | Yes | Prevent user creation or registration, or add custom metadata to a newly-created user. | +| [Post-User Registration](/hooks/extensibility-points/post-user-registration) | `post-user-registration` | Database, Passwordless | No | Implement custom actions from the Auth0 authentication process after a new user is created or registers and is added to the database. | +| [Post-Change Password](/hooks/extensibility-points/post-change-password) | `post-change-password` | Database | No | Implement custom actions to be executed after a successful user password change. | +| [Send Phone Message](/hooks/extensibility-points/send-phone-message) | `send-phone-message` | N/A | Yes | Implement a custom phone messaging provider to deliver MFA one-time-use codes. | diff --git a/articles/hooks/extensibility-points/post-change-password.md b/articles/hooks/extensibility-points/post-change-password.md new file mode 100644 index 0000000000..4a26db63aa --- /dev/null +++ b/articles/hooks/extensibility-points/post-change-password.md @@ -0,0 +1,128 @@ +--- +title: Post-Change Password +description: Learn how hooks can be used with the Post Change Password extensibility point, which is available for database connections. +toc: true +topics: + - hooks + - extensibility-points + - post-change-password +contentType: + - how-to +useCase: extensibility-hooks +v2: true +--- + +# Post-Change Password + +At the Post-Change Password extensibility point, Hooks allow custom actions to be executed after a successful user password change, whether initiated by a user for their own password or by a tenant administrator for another user's password. For example, you may send an email to a user to notify them that their password has been changed. + +Hooks at this extensibility point are non-blocking (asynchronous), which means the Auth0 pipeline will continue to run without waiting for a Hook to finish its execution. Thus, the Hook's outcome does not affect the Auth0 transaction. + +The Post-Change Password extensibility point is available for [Database Connections](/connections/database). + +::: note +The `triggerId` for the Post-Change Password extensibility point is `post-change-password`. To learn how to create Hooks for this extensibility point, see [Create New Hooks](/hooks/create). +::: + +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). + +## Starter code and parameters + +When creating a Hook executed at the Post-Change Password extensibility point, you may find the following starter code helpful. Parameters that can be passed into and used by the Hook function are listed at the top of the code sample. + +```js +/** +@param {object} user - affected user +@param {string} user.id - user's ID +@param {string} user.username - user's username +@param {string} user.email - user's email +@param {string} user.last_password_reset - date/time the user's password was last changed +@param {object} context - Auth0 context info, such as connection +@param {object} context.connection - connection info +@param {object} context.connection.id - connection ID +@param {object} context.connection.name - connection name +@param {object} context.connection.tenant - connection tenant +@param {object} context.webtask - Hook (webtask) context +@param {function} cb - function (error) +**/ + +module.exports = function (user, context, cb) { + // Perform any asynchronous actions, e.g. send notification to Slack. + cb(); +}; +``` + +Please note: + +* The callback function (`cb`) at the end of the sample code signals completion and *must* be included. + +### Default response + +Hooks executed at the Post-Change Password extensibility point ignore any response object. If an error is returned, a tenant log entry is created, but this does not affect the Auth0 transaction. + +### Starter code response + +Once you've customized the starter code, you can test the Hook using the Runner embedded in the Hook Editor. The Runner simulates a call to the Hook with the appropriate body and response. + +<%= include('../_includes/_test_runner_save_warning') %> + +When you run a Hook based on the starter code, the response object is: + +```json +{ + "user": { + "id": "abc123", + "username": "user1", + "email": "user1@foo.com", + "last_password_reset": "2019-02-27T14:14:29.206Z" + }, + "context": { + "connection": { + "id": "con_xxxxxxxxxxxxxxxx", + "name": "Username-Password-Authentication", + "tenant": "my-tenant" + } + } +} +``` + +## Sample script: Send a notification email upon password change + +In this example, we use a Hook to have SendGrid send a notification email to the user upon password change. The example requires a valid SendGrid API key to be stored in [Hook Secrets](/hooks/secrets) as `SENDGRID_API_KEY`. + +```js +module.exports = function (user, context, cb) { + + const request = require('request'); + const sendgridApiKey = context.webtask.secrets.SENDGRID_API_KEY; + + // https://sendgrid.api-docs.io/v3.0/mail-send + request.post({ + url: 'https://api.sendgrid.com/v3/mail/send', + headers: { + 'Authorization': 'Bearer ' + sendgridApiKey + }, + json: { + personalizations: [{ + to: [{ + email: user.email + }] + }], + from: { + email: 'admin@example.com' + }, + subject: 'Your password was changed', + content: [{ + type: 'text/plain', + value: 'The password for your ' + context.connection.name + ' account ' + user.email + ' was recently changed.' + }] + } + }, function (err, resp, body) { + if (err || resp.statusCode !== 202) { + return cb(err || new Error(body.errors[0].message)); + } + + cb(); + }); +}; +``` diff --git a/articles/hooks/extensibility-points/post-user-registration.md b/articles/hooks/extensibility-points/post-user-registration.md index 1e785ee835..694ee52253 100644 --- a/articles/hooks/extensibility-points/post-user-registration.md +++ b/articles/hooks/extensibility-points/post-user-registration.md @@ -1,69 +1,78 @@ --- -title: Using the Post-User Registration Extensibility Point -description: The post-user-registration extensibility point for use with Hooks -beta: true +title: Post-User Registration +description: Learn how hooks can be used with the Post-User Registration extensibility point, which is available for database connections and passwordless connections. toc: true +topics: + - hooks + - extensibility-points + - post-user-registration +contentType: + - how-to +useCase: extensibility-hooks +v2: true --- -# Extensibility Point: Post-User Registration +# Post-User Registration -For [Database Connections](/connections/database), the `post-user-registration` extensibility point allows you to implement custom actions that execute after a new user registers and is added to the database. [Hooks](/hooks#work-with-hooks) associated with the `post-user-registration` extensibility point execute asynchronously from the actions that are a part of the Auth0 authentication process. +At the Post-User Registration extensibility point, Hooks allow custom actions to be executed after a new user registers an account and is added to the database. For example, you may send a message to Slack or create a record in your customer relationship management (CRM) system. -This allows you to implement scenarios including (but not limited to): +Hooks at this extensibility point are non-blocking (asynchronous), which means the Auth0 pipeline will continue to run without waiting for a Hook to finish its execution. Thus, the Hook's outcome does not affect the Auth0 transaction. -* Sending notifications to Slack or via e-mail about the user's new account; -* Creating a new user record in a CRM system. +The Post-User Registration extensibility point is available for [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). -## How to Implement This - -You can implement a [Hook](/hooks#work-with-hooks) using this extensibility point with either the [Dashboard](/hooks/dashboard) or the [Command Line Interface](/hooks/cli). +::: note +The `triggerId` for the Post-User Registration extensibility point is `post-user-registration`. To learn how to create Hooks for this extensibility point, see [Create New Hooks](/hooks/create). +::: -### Starter Code and Parameters +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). -After you've created a new Hook that uses the Post-User Registration extensibility point, you can open up the Hook and edit it using the Webtask Editor embedded in the Dashboard. +## Starter code and parameters -The parameters listed in the comment at the top of the code indicate the Auth0 objects (and the parameters within the objects) that can be passed into and used by the Hook's function. For example, the `client` object comes with the following parameters: application name, client ID, the Auth0 tenant name with which the application is associated, and application metadata. +When creating a Hook executed at the Post-User Registration extensibility point, you may find the following starter code helpful. Parameters that can be passed into and used by the Hook function are listed at the top of the code sample. ```js /** -@param {object} user - The user being created -@param {string} user.id - user id +@param {object} user - user being created +@param {string} user.id - user's ID (user GUID without "auth0|" database prefix) @param {string} user.tenant - Auth0 tenant name -@param {string} user.username - user name -@param {string} user.email - email -@param {boolean} user.emailVerified - is e-mail verified? -@param {string} user.phoneNumber - phone number -@param {boolean} user.phoneNumberVerified - is phone number verified? -@param {object} user.user_metadata - user metadata -@param {object} user.app_metadata - application metadata -@param {object} context - Auth0 connection and other context info +@param {string} user.username - user's username +@param {string} user.email - user's email +@param {boolean} user.emailVerified - indicates whether email is verified +@param {string} user.phoneNumber - user's phone number +@param {boolean} user.phoneNumberVerified - indicates whether phone number is verified +@param {object} user.user_metadata - user's user metadata +@param {object} user.app_metadata - user's application metadata +@param {object} context - Auth0 context info, such as connection @param {string} context.requestLanguage - language of the application agent -@param {object} context.connection - information about the Auth0 connection -@param {object} context.connection.id - connection id +@param {object} context.connection - connection info +@param {object} context.connection.id - connection ID @param {object} context.connection.name - connection name @param {object} context.connection.tenant - connection tenant -@param {object} context.webtask - webtask context +@param {object} context.webtask - Hook (webtask) context @param {function} cb - function (error, response) */ + module.exports = function (user, context, cb) { // Perform any asynchronous actions, such as send notification to Slack. cb(); }; ``` -The callback function `cb` at the end of the sample code is used to signal completion and must not be omitted (even though the extensibility point ignores response objects). +Please note: -#### Response +* The callback function (`cb`) at the end of the sample code signals completion and *must* be included. -The Post-User Registration extensibility point ignores any response object. +### Default response -### Testing Your Hook +Hooks executed at the Post-User Registration extensibility point ignore any response object. -::: note -Executing the code using the Runner requires a save, which means that your original code will be overwritten. -::: +### Starter code response + +Once you've customized the starter code, you can test the Hook using the Runner embedded in the Hook Editor. The Runner simulates a call to the Hook with the appropriate body and response. + +<%= include('../_includes/_test_runner_save_warning') %> -Once you've modified the sample code with the specific scopes of additional claims you'd like added to your Access Tokens, you can test your Hook using the Runner. The runner simulates a call to the Hook with the appropriate user information body/payload. The following is the sample body that populates the Runner by default (these are the same objects/parameters detailed in the comment at the top of the sample Hook code): +When you run a Hook based on the starter code, the response object is: ```json { @@ -92,7 +101,9 @@ Once you've modified the sample code with the specific scopes of additional clai } ``` -## Example: Integrate with Slack +## Sample script: Integrate with Slack + +In this example, we use a Hook to have Slack post a new user's username and email address to a specified channel upon user registration. ```js module.exports = function (user, context, cb) { @@ -102,7 +113,7 @@ module.exports = function (user, context, cb) { // Post the new user's name and email address to the selected channel var slack = require('slack-notify')(SLACK_HOOK); - var message = 'New User: ' + (user.name || user.email) + ' (' + user.email + ')'; + var message = 'New User: ' + (user.username || user.email) + ' (' + user.email + ')'; var channel = '#some_channel'; slack.success({ @@ -113,4 +124,4 @@ module.exports = function (user, context, cb) { // Return immediately; the request to the Slack API will continue on the sandbox cb(); }; -``` \ No newline at end of file +``` diff --git a/articles/hooks/extensibility-points/pre-user-registration.md b/articles/hooks/extensibility-points/pre-user-registration.md index 572f317734..6291fd715e 100644 --- a/articles/hooks/extensibility-points/pre-user-registration.md +++ b/articles/hooks/extensibility-points/pre-user-registration.md @@ -1,49 +1,61 @@ --- -title: Using the Pre-User Registration Extensibility Point -description: The pre-user-registration extensibility point for use with Hooks +title: Pre-User Registration +description: Learn how hooks can be used with the Pre-User Registration extensibility point, which is available for database connections and passwordless connections. toc: true -beta: true +topics: + - hooks + - extensibility-points + - pre-user-registration +contentType: + - how-to +useCase: extensibility-hooks +v2: true --- -# Extensibility Point: Pre-User Registration +# Pre-User Registration -For [Database Connections](/connections/database), the `pre-user-registration` extensibility point allows you to add custom `app_metadata` or `user_metadata` to a newly-created user. +At the Pre-User Registration extensibility point, Hooks allow custom actions to be executed when a new user is created. For example, you may add custom `app_metadata` or `user_metadata` to the newly-created user, or even prevent the creation of the user in the database. -This allows you to implement scenarios such as setting conditional [metadata](/metadata) on users that do not exist yet. +Hooks at this extensibility point are blocking (synchronous), which means they execute as part of the trigger's process and will prevent the rest of the Auth0 pipeline from running until the Hook is complete. -## How to Implement This +The Pre-User Registration extensibility point is available for [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). -You can implement a [Hook](/hooks#work-with-hooks) using this extensibility point with either the [Dashboard](/hooks/dashboard) or the [Command Line Interface](/hooks/cli). +::: note +The `triggerId` for the Pre-User Registration extensibility point is `pre-user-registration`. To learn how to create Hooks for this extensibility point, see [Create New Hooks](/hooks/create). +::: -## Starter Code and Parameters +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). -After you've created a new Hook that uses the Pre-User Registration extensibility point, you can open up the Hook and edit it using the Webtask Editor embedded in the Dashboard. +## Starter code and parameters -The parameters listed in the comment at the top of the code indicate the Auth0 objects (and the parameters within the objects) that can be passed into and used by the Hook's function. For example, the `client` object comes with the following parameters: application name, client ID, the Auth0 tenant name with which the application is associated, and application metadata. +When creating a Hook executed at the Pre-User Registration extensibility point, you may find the following starter code helpful. Parameters that can be passed into and used by the Hook function are listed at the top of the code sample. ```js /** -@param {object} user - The user being created +@param {object} user - user being created @param {string} user.tenant - Auth0 tenant name -@param {string} user.username - user name +@param {string} user.username - user's username @param {string} user.password - user's password -@param {string} user.email - email -@param {boolean} user.emailVerified - is e-mail verified? -@param {string} user.phoneNumber - phone number -@param {boolean} user.phoneNumberVerified - is phone number verified? -@param {object} context - Auth0 connection and other context info -@param {string} context.requestLanguage - language of the application agent -@param {object} context.connection - information about the Auth0 connection -@param {object} context.connection.id - connection id +@param {string} user.email - user's email +@param {boolean} user.emailVerified - indicates whether email is verified +@param {string} user.phoneNumber - user's phone number +@param {boolean} user.phoneNumberVerified - indicates whether phone number is verified +@param {object} context - Auth0 context info, such as connection +@param {string} context.renderLanguage - language of the signup flow +@param {string} context.request.ip - ip address +@param {string} context.request.language - language of the application agent +@param {object} context.connection - connection info +@param {object} context.connection.id - connection ID @param {object} context.connection.name - connection name @param {object} context.connection.tenant - connection tenant -@param {object} context.webtask - webtask context -@param {function} cb - function (error, response) +@param {object} context.webtask - Hook (webtask) context +@param {function} cb - Function (error, response) */ + module.exports = function (user, context, cb) { var response = {}; - // Add user or app metadata to the newly created user + // Add user or app metadata to the newly-created user // response.user = { // user_metadata: { foo: 'bar' }, // app_metadata: { vip: true, score: 7 } @@ -55,11 +67,13 @@ module.exports = function (user, context, cb) { }; ``` -The callback function `cb` at the end of the sample code is used to signal completion and must not be omitted. +Please note: -### Response +* The callback function (`cb`) at the end of the sample code signals completion and *must* be included. + +### Default response -The default response object every time the Hook runs is similar to the following: +When you run a Hook executed at the Pre-User Registration extensibility point, the default response object is: ```json { @@ -87,13 +101,17 @@ If you specify `app_metadata` and `user_metadata` in the response object, Auth0 Metadata property names must not start with the `$` character or contain the `.` character. ::: -## Testing Your Hook - ::: note -Executing the code using the Runner requires a save, which means that your original code will be overwritten. +Hooks executed at the Pre-User Registration extensibility point do not pass error messages to any Auth0 APIs. ::: -Once you've modified the sample code with the specific scopes of additional claims you'd like added to your Access Tokens, you can test your Hook using the Runner. The runner simulates a call to the Hook with the appropriate user information body/payload. The following is the sample body that populates the Runner by default (these are the same objects/parameters detailed in the comment at the top of the sample Hook code): +### Starter code response + +Once you've customized the starter code, you can test the Hook using the Runner embedded in the Hook Editor. The Runner simulates a call to the Hook with the appropriate body and response. + +<%= include('../_includes/_test_runner_save_warning') %> + +When you run a Hook based on the starter code, the response object is: ```json { @@ -113,7 +131,10 @@ Once you've modified the sample code with the specific scopes of additional clai } }, "context": { - "requestLanguage": "en-us", + "request": { + "language": "en-us", + "ip": "123.123.123.123" + }, "connection": { "id": "con_xxxxxxxxxxxxxxxx", "name": "Username-Password-Authentication", @@ -123,7 +144,9 @@ Once you've modified the sample code with the specific scopes of additional clai } ``` -## Example: Add Metadata to New Users +## Sample script: Add metadata to new users + +In this example, we use a Hook to add metadata to new users upon creation. ```js module.exports = function (user, context, cb) { @@ -138,7 +161,9 @@ module.exports = function (user, context, cb) { }; ``` -Using the [test runner](https://webtask.io/docs/editor/runner), we see that the response, reflecting the updated metadata, is as follows: +### Response + +When we run this Hook, the response object is: ```json { @@ -154,6 +179,27 @@ Using the [test runner](https://webtask.io/docs/editor/runner), we see that the } ``` -::: note -The Pre-Registration Hook does not currently pass error messages to any Auth0 APIs. -::: \ No newline at end of file +## Sample script: Customize the error message and language for user messages + +In this example, we use a Hook to prevent a user from registering, then return a custom error message in our tenant logs and show a custom, translated error message to the user when they are denied. To return the user message and use the translation functionality, your tenant must be configured to use the [Universal Login - New Experience](/universal-login/new). + +```js +module.exports = function (user, context, cb) { + const isUserDenied = ...; // determine if a user should be allowed to register + + if (isUserDenied) { + const LOCALIZED_MESSAGES = { + en: 'You are not allowed to register.', + es: 'No tienes permitido registrarte.' + }; + + const localizedMessage = LOCALIZED_MESSAGES[context.renderLanguage] || LOCALIZED_MESSAGES['en']; + return cb(new PreUserRegistrationError('Denied user registration in Pre-User Registration Hook', localizedMessage)); + } +}; +``` + +Please note: +* The custom `PreUserRegistrationError` class allows you to control the message seen by the user who is attempting to register. +* The first parameter passed to `PreUserRegistrationError` controls the error message that appears in your tenant logs. +* The second parameter controls the error message seen by the user who is attempting to register. In this example, the `context.renderLanguage` parameter generates a user-facing message in the appropriate language for the user. You can use these parameters only if your tenant is configured to use the [Universal Login - New Experience](/universal-login/new). diff --git a/articles/hooks/extensibility-points/send-phone-message.md b/articles/hooks/extensibility-points/send-phone-message.md new file mode 100644 index 0000000000..89ec90acf3 --- /dev/null +++ b/articles/hooks/extensibility-points/send-phone-message.md @@ -0,0 +1,138 @@ +--- +title: Send Phone Message +description: Learn how to provide your own code to send phone messages for MFA +toc: true +topics: + - hooks + - extensibility-points + - send-phone-message + - custom-messaging-gateway + - sms + - voice +contentType: + - how-to +useCase: extensibility-hooks +v2: true +--- +# Send Phone Message + +If you decide to use SMS or Voice as a factor for Multi-factor Authentication (MFA), you can configure how you want Auth0 to send the messages in the [MFA Phone configuration dialog](/mfa/guides/configure-phone#administrative-setup). + +If you select the 'Custom' delivery method, you must create a **Send Phone Message Hook** that will let you write your own code to send the message. This allows you to use whatever messaging provider you want. + +Hooks at this extensibility point are blocking (synchronous), which means they execute as part of the trigger's process and will prevent the rest of the Auth0 pipeline from running until the Hook is complete. + +::: note +The `triggerId` for the Send Phone Message extensibility point is `send-phone-message`. To learn how to create Hooks for this extensibility point, see [Create New Hooks](/hooks/create). +::: + +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). + +## Starter code and parameters + +When creating a Hook executed at the Send Phone Message extensibility point, you may find the following starter code helpful. Parameters that can be passed into and used by the Hook function are listed at the top of the code sample. + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'second-factor-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 {object} context.client - object with details about the Auth0 application +@param {string} context.client.client_id - Auth0 application ID +@param {string} context.client.name - Auth0 application name +@param {object} context.client.client_metadata - metadata from client +@param {object} context.user - object representing the user +@param {string} context.user.user_id - Auth0 user's ID +@param {string} context.user.name - user's name +@param {string} context.user.email - user 'semail +@param {object} context.user.app_metadata - metadata specific to user and application +@param {object} context.user.user_metadata - metadata specific to user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + // TODO: Add your code here + cb(null, {}); +}; +``` + +::: note +The callback function (`cb`) at the end of the sample code signals completion and **must** be included. +::: + +## Example parameters + +This is an example of the parameters: + +```js +{ + "recipient": "1-808-555-5555", + "text": "Here is your one time password: 999111", + "context": { + "message_type": "sms", + "action": "enrollment", + "language": "en", + "code": "123456", + "ip": "127.0.0.1", + "user_agent": "Mozilla/5.0", + "client": { + "client_id": "1235", + "name": "Test Application", + "client_metadata": { } + }, + "user": { + "user_id": "auth0|test12345", + "name": "Billie Magnusson", + "email": "billie@email.com", + "app_metadata": { }, + "user_metadata": { } + } + } +} +``` + +## Starter code response + +Once you have customized the Hook code, you can test it using the Runner embedded in the Editor. The Runner simulates a call to the Hook with the appropriate body and response. + +<%= include('../_includes/_test_runner_save_warning') %> + +When you run a Hook based on the starter code, the response object is: + +``` +{ + "MessageID": "998a9ad1-c9b9-4b85-97b1-ac0305aa5532" +} +``` + +## Localization + +The `context.language` parameter will always have one of the [languages configured in the Tenant Settings](/universal-login/i18n). Depending on how you trigger the MFA flow, we will calculate which language to use in the following different ways: + +- If you use the [MFA API](/mfa/concepts/mfa-api), we will use the Accept-Language header from the request and map it to a tenant language. If the language is not available, we will set the parameter to the tenant default language. + +- If you use the New Universal Login Experience, we will use a combination of the Accept-Language header and the `ui_locales` parameter, as described in [Universal Login Internationalization](/universal-login/i18n#language-selection). + +- If you use the Classic Universal Login Experience, we will set the language to 'N/A'. This is a limitation that will be fixed in upcoming releases. + +## Examples + +Learn how to integrate different messaging providers with the examples 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) + +## Keep Reading + +- [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone) +- [Extensibility Points](/hooks/extensibility-points) diff --git a/articles/hooks/index.md b/articles/hooks/index.md index 2c14134ba2..ee230d7323 100644 --- a/articles/hooks/index.md +++ b/articles/hooks/index.md @@ -1,51 +1,46 @@ --- -url: /hooks -classes: topic-page title: Hooks -description: Working with Hooks -beta: true +description: Learn about Auth0 Hooks for Database Connections and Passwordless Connections. +topics: + - hooks + - extensibility-points +contentType: + - index + - concept +useCase: extensibility-hooks --- +# Hooks -
      -
      -

      Hooks

      -

      - Hooks allow you to extend the Auth0 platform with custom code. -

      -
      - -## What are Hooks? - -When using [Database Connections](/connections/database), Hooks allow you to customize the behavior of Auth0 using Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). Hooks allow you modularity when configuring your Auth0 implementation, and extend the functionality of base Auth0 features. - -## Work with Hooks - - - -## Use the Webtask Editor - -You can edit Hooks directly using the Webtask Editor. Please see the [Webtask documentation](https://webtask.io/docs/editor) for detailed information. +<%= include('../_includes/_ip_whitelist') %> + +Hooks are secure, self-contained functions that allow you to customize the behavior of Auth0 when executed for selected [extensibility points](/hooks/extensibility-points) of the Auth0 platform. Auth0 invokes Hooks during runtime to execute your custom Node.js code. + +Whether Hooks can be used with connections varies according to extensibility point. Hooks that can be used with connections only work with [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). + +## Manage Hooks + +You can create, update, delete, enable/disable, and view Hooks from the Dashboard or Management API. To learn more, see: + +- [Create Hooks](/hooks/create) +- [Update Hooks](/hooks/update) +- [Delete Hooks](/hooks/delete) +- [Enable/Disable Hooks](/hooks/enable-disable) +- [View Hooks](/hooks/view) + +Hooks may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +<%= include('./_includes/_handle_rate_limits') %> + +## Manage Hook Secrets + +Hooks feature integrated secret management to securely store secrets while making them conveniently available in code. To learn more, see [Hook Secrets](/hooks/secrets). + +## Test Hooks + +The Hooks editor in the Dashboard has an integrated Runner, which allows you to test your code without leaving the editor. + +<%= include('./_includes/_test_runner_save_warning') %> + +## View Logs + +You can view real-time logging information for specific configured Hooks using the Dashboard. To learn more, see [View Logs for Hooks](/hooks/view-logs). diff --git a/articles/hooks/overview.md b/articles/hooks/overview.md deleted file mode 100644 index bc135c0bc6..0000000000 --- a/articles/hooks/overview.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -description: >- - Hooks are JavaScript functions executed as part of the user - authentication flow. They allow you to customize and extend Auth0's - capabilities, and you can chain them together for modular coding. -beta: true ---- - -# Hooks: Overview - -Hooks, which will eventually replace [Rules](/rules), allow you to extend the Auth0 platform with custom code. - -Hooks are Webtasks associated with specific extensibility points of the Auth0 platform. When using [Database Connections](/connections/database), Auth0 invokes the Hooks at runtime to execute your custom logic. - -You can manage your Hooks using: - -* [The Auth0 Management Dashboard](/hooks/dashboard) -* [The Auth0 Command-Line Interface (CLI)](/hooks/cli). - -## Supported Extensibility Points - -You can create Hooks for the following [extensibility points](/hooks/extensibility-points): - -- [Credentials Exchange](/hooks/extensibility-points/credentials-exchange) -- [Pre-User Registration](/hooks/extensibility-points/pre-user-registration) -- [Post-User Registration](/hooks/extensibility-points/post-user-registration) \ No newline at end of file diff --git a/articles/hooks/secrets/create.md b/articles/hooks/secrets/create.md new file mode 100644 index 0000000000..071f5318d8 --- /dev/null +++ b/articles/hooks/secrets/create.md @@ -0,0 +1,71 @@ +--- +title: Create Hook Secrets +description: Learn how to create Hook Secrets using the Dashboard and Management API. Hook Secrets may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - secrets + - dashboard + - mgmt-api +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# Create Hook Secrets + +You can create multiple Hook Secrets for any [Hook](/hooks) using the Dashboard or Management API. + +Hook Secrets may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +<%= include('../_includes/_hook_secrets_limit') %> + +
      +
      + +
      +
      +
      + +## Create Hook Secrets using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook you want to edit. +2. In the Hook editor, click the wrench icon, and click **Secrets**. +3. Click **Add Secret**. +4. Enter a descriptive name and value for your secret, and click **Save**. + +
      +
      + +## Create Hook Secrets using the Management API + +1. Make a `POST` call to the [Add Hook Secrets endpoint](/api/management/v2/#!/Hooks/post_secrets). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `HOOK_ID`, `HOOK_SECRET_KEY`, and `HOOK_SECRET_VALUE` placeholder values with your Management API Access Token, Hook ID, and Hook key-value pair(s), respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_ID/secrets", + "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": "{ [ \"HOOK_SECRET_KEY\", \"HOOK_SECRET_VALUE\" ], [ \"HOOK_SECRET_KEY\", \"HOOK_SECRET_VALUE\" ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:hooks`. | +| `HOOK_ID` | ID of the hook for which you would like to add secrets. | +| `HOOK_SECRET_KEY` | Name of the secret that you would like to add to the specified hook. This endpoint accepts an object of key-value pairs. | +| `HOOK_SECRET_VALUE` | Value of the secret that you would like to add to the specified hook. This endpoint accepts an object of key-value pairs. | + +
      +
      +
      diff --git a/articles/hooks/secrets/delete.md b/articles/hooks/secrets/delete.md new file mode 100644 index 0000000000..128a697d81 --- /dev/null +++ b/articles/hooks/secrets/delete.md @@ -0,0 +1,64 @@ +--- +title: Delete Hook Secrets +description: Learn how to delete Hook Secrets using the Dashboard and Management API. Hook Secrets may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - secrets + - mgmt-api + - dashboard +contentType: how-to +useCase: extensibility-hooks +v2: true +--- +# Delete Hook Secrets + +When you no longer need Hook Secrets for a given [Hook](/hooks), you can delete them using either the Dashboard or Management API. + +Hook Secrets may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +
      +
      + +
      +
      +
      + +## Delete Hook Secrets using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook you want to edit. +2. In the Hook editor, click the wrench icon, and click **Secrets**. +3. Locate the Hook Secret you want to delete, click the trash can icon, and confirm. + +
      +
      + +## Delete Hook Secrets using the Management API + +1. Make a `DELETE` call to the [Delete Hook Secrets endpoint](/api/management/v2/#!/Hooks/delete_secrets). Be sure to replace `HOOK_ID`, `HOOK_SECRET_NAME`, and `MGMT_API_ACCESS_TOKEN` placeholder values with your hook ID, your hook secret name(s), and Management API Access Token, respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_ID/secrets", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ [ \"HOOK_SECRET_NAME\", \"HOOK_SECRET_NAME\" ] }" + } +} +``` + +| Value | Description | +| - | - | +| `HOOK_ID` | ID of the Hook for which you want to delete secrets. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `delete:hooks`. | +| `HOOK_SECRET_NAME` | Name(s) of the secret(s) you would like to delete from the specified Hook. This endpoint accepts an array of secret names to delete. | + +
      +
      +
      diff --git a/articles/hooks/secrets/index.md b/articles/hooks/secrets/index.md new file mode 100644 index 0000000000..aab126f146 --- /dev/null +++ b/articles/hooks/secrets/index.md @@ -0,0 +1,26 @@ +--- +title: Hook Secrets +description: Learn about integrated secret management used with Auth0 Hooks. +topics: + - hooks + - secrets +contentType: + - concept +useCase: extensibility-hooks +--- +# Hook Secrets + +[Hooks](/hooks) feature integrated secret management to securely store secrets while making them conveniently available in code. + +<%= include('../_includes/_access_hook_secrets') %> + +## Manage Hook Secrets + +You can create, update, delete, and view Hook Secrets from the Dashboard or Management API. To learn more, see: + +- [Create Hook Secrets](/hooks/secrets/create) +- [Update Hook Secrets](/hooks/secrets/update) +- [Delete Hook Secrets](/hooks/secrets/delete) +- [View Hook Secrets](/hooks/secrets/view) + + Hook Secrets may also be imported or exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). diff --git a/articles/hooks/secrets/update.md b/articles/hooks/secrets/update.md new file mode 100644 index 0000000000..4ee4c59e79 --- /dev/null +++ b/articles/hooks/secrets/update.md @@ -0,0 +1,73 @@ +--- +title: Update Hook Secrets +description: Learn how to update Hook Secrets using the Dashboard or Management API. Hook Secrets may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - secrets + - dashboard + - mgmt-api +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# Update Hook Secrets + +You can update Hook Secrets added to any given [Hook](/hooks) using the Dashboard or Management API. + +Hook Secrets may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +
      +
      + +
      +
      +
      + +## Update Hook Secrets using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook you want to edit. +2. In the Hook editor, click the wrench icon, and click **Secrets**. +3. Click the pencil and paper icon next to the value of the secret you want to edit. +4. Make your changes to the name and/or value of the selected secret, and click **Save**. + +
      +
      + +## Update Hook Secrets using the Management API + +1. Make a `PATCH` call to the [Update Hook Secrets endpoint](/api/management/v2/#!/Hooks/patch_secrets). Be sure to replace `HOOK_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your hook ID and Management API Access Token, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_ID/secrets", + "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": "{ [ \"HOOK_SECRET_KEY\", \"HOOK_SECRET_VALUE\" ], [ \"HOOK_SECRET_KEY\", \"HOOK_SECRET_VALUE\" ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:hooks`. | +| `HOOK_ID` | ID of the hook for which you would like to update secrets. | +| `HOOK_SECRET_KEY` | Name of the secret that you would like to update for the specified hook. This endpoint accepts an object of key-value pairs. | +| `HOOK_SECRET_VALUE` | Value of the secret that you would like to update for the specified hook. This endpoint accepts an object of key-value pairs. | + +::: warning +When retrieving secrets configured for a specified hook, values will contain the placeholder text: `_VALUE_NOT_SHOWN`. Be careful not to return this placeholder text during an update, or the secret's actual value will be overwritten. +::: + +
      +
      +
      diff --git a/articles/hooks/secrets/view.md b/articles/hooks/secrets/view.md new file mode 100644 index 0000000000..0760ba1468 --- /dev/null +++ b/articles/hooks/secrets/view.md @@ -0,0 +1,63 @@ +--- +title: View Hook Secrets +description: Learn how to view Hook Secrets using the Dashboard and Management API. +topics: + - hooks + - secrets + - mgmt-api + - dashboard +contentType: how-to +useCase: extensibility-hooks +v2: true +--- +# View Hook Secrets + +To see configured secrets for a [Hook](/hooks), you can view them using the Dashboard or retrieve a list of them using the Management API. + +
      +
      + +
      +
      +
      + +## View Hook Secrets using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook for which you want to view secrets. + +2. In the Hook editor, click the wrench icon, and click **Secrets**. + +All configured secrets for the selected Hook will be listed. + +
      +
      + +## Get Hook Secrets using the Management API + +1. Make a `GET` call to the [Get Hook Secrets endpoint](/api/management/v2/#!/Hooks/get_secrets). Be sure to replace `HOOK_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your Hook's ID and the Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_ID/secrets", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `HOOK_ID` | ID of the Hook for which you want to retrieve secrets. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:hooks`. | + +::: warning +Secrets are write-only. When retrieving secrets configured for a specified hook, values will contain the placeholder text: `_VALUE_NOT_SHOWN`. +::: + +
      +
      +
      diff --git a/articles/hooks/update.md b/articles/hooks/update.md new file mode 100644 index 0000000000..06a288e13a --- /dev/null +++ b/articles/hooks/update.md @@ -0,0 +1,92 @@ +--- +title: Update Hooks +description: Learn how to update Hooks using the Dashboard or Management API. Hooks may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - dashboard + - mgmt-api +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# Update Hooks + +You can update Hooks configured for any given [extensibility point](/hooks/extensibility-points) using the Dashboard or Management API. + +Hooks may also be imported and exported using the [Deploy Command-Line Interface (CLI) Extension](/extensions/deploy-cli). + +::: note +If you added a [Hook Secret](/hooks/secrets) and want to update it, see [Update Hook Secrets](/hooks/secrets/update). +::: + +
      +
      + +
      +
      +
      + +## Rename Hooks using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the gear icon next to the Hook you want to rename. +2. Select **Rename**. +3. Enter the current name and new name of the hook, then click **Rename**. + +![Rename Hooks prompt](/media/articles/hooks/rename-hook.png) + +## Update Hook scripts using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook you want to update. + + ![List of Hooks](/media/articles/hooks/hooks-list.png) + +2. Update the Hook using the Hook Editor, and click the disk icon to save. + + ![Update a Hook in the Hook Editor](/media/articles/hooks/webtask-editor.png) +
      +
      + +## Update Hooks using the Management API + +1. Make a `PATCH` call to the [Update a Hook endpoint](/api/management/v2/#!/Hooks/patch_hooks_by_id). Be sure to replace `HOOK_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your hook ID and Management API Access Token, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/hooks/HOOK_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\": \"HOOK_NAME\", \"script\": \"HOOK_SCRIPT\", \"enabled\": \"true\" }" + } +} +``` + +| Value | Description | +| - | - | +| `HOOK_ID` | ID of the hook to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:hooks`. | +| `HOOK_NAME` | Name of the hook you would like to create. | +| `HOOK_SCRIPT` | Script that contains the code for the hook. Should match what you would enter if you were creating a new hook using the Dashboard. | + +::: note +The `enabled` property represents whether the rule is enabled (`true`) or disabled (`false`). | +::: + +
      +
      +
      + +<%= include('./_includes/_handle_rate_limits') %> + +::: note +Optionally, you can add secrets (such as Twilio Keys or database connection strings) to Hooks. To learn how to update secrets, see [Update Hook Secrets](/hooks/secrets/update). +::: diff --git a/articles/hooks/view-logs.md b/articles/hooks/view-logs.md new file mode 100644 index 0000000000..af51d1f9b5 --- /dev/null +++ b/articles/hooks/view-logs.md @@ -0,0 +1,21 @@ +--- +title: View Logs for Hooks +description: Learn how to view logs for Hooks using the Auth0 Dashboard. +topics: + - hooks + - logs + - dashboard +contentType: how-to +useCase: extensibility-hooks +v2: true +--- + +# View Logs for Hooks + +You can view real-time logging information for specific configured Hooks using the Dashboard. + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/), and click the pencil icon next to the Hook you want to update. + + ![List of Hooks](/media/articles/hooks/hooks-list.png) + +2. In the Hooks Editor, click the logs icon. diff --git a/articles/hooks/view.md b/articles/hooks/view.md new file mode 100644 index 0000000000..498e623194 --- /dev/null +++ b/articles/hooks/view.md @@ -0,0 +1,55 @@ +--- +title: View Hooks +description: Learn how to view Hooks using the Dashboard and Management API. Hooks may also be imported and exported using the Auth0 Deploy Command-Line Interface (CLI) tool. +topics: + - hooks + - mgmt-api + - dashboard +contentType: how-to +useCase: extensibility-hooks +v2: true +--- +# View Hooks + +To see configured Hooks, you can view them using the Dashboard or retrieve a list of them using the Management API. + +
      +
      + +
      +
      +
      + +## View Hooks using the Dashboard + +1. Navigate to the [Hooks](${manage_url}/#/hooks) page in the [Auth0 Dashboard](${manage_url}/). + +All configured Hooks will be listed by the extensibility point at which they are executed. A green dot next to a Hook indicates that it is enabled. + +
      +
      + +## Get Hooks using the Management API + +1. Make a `GET` call to the [Get Hooks endpoint](/api/management/v2/#!/Hooks/get_hooks). Be sure to replace `MGMT_API_ACCESS_TOKEN` placeholder value with your Management API Access Token. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/hooks", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:hooks`. | + +
      +
      +
      diff --git a/articles/hosted-pages/custom-error-pages.md b/articles/hosted-pages/custom-error-pages.md deleted file mode 100644 index 7ce87d71ad..0000000000 --- a/articles/hosted-pages/custom-error-pages.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Custom Error Pages -description: How to setup a custom error page for authorization error events. -toc: true -crews: crew-2 ---- -# Custom Error Pages - -In the event of an authorization error, you may choose to display to your users either [the default Auth0 error page](/hosted-pages/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](/hosted-pages/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. - -![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" : "" -} -``` - -### Render a custom error page - -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\": \"

      Hello {{name}}. This error was generated {{'now' | date: '%Y %h'}}.<\\h1>\", \"show_log_link\": false, \"url\": \"\"}}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` diff --git a/articles/hosted-pages/error-pages.md b/articles/hosted-pages/error-pages.md deleted file mode 100644 index df02ed9daa..0000000000 --- a/articles/hosted-pages/error-pages.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -description: Guide on how to use the hosted error pages for authorization error events -crews: crew-2 ---- - -# 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. - -![Hosted Error Page](/media/articles/hosted-pages/error-pages.png) - -By going into the [Tenant Settings](${manage_url}/#/tenant/) page of the Management Dashboard, you may customize your Auth0 error page with the following fields: - -* **Friendly Name**: the name of your company; -* **Logo URL**: the URL to your company logo; -* **Support Email**: the email address of your company's support team; -* **Support URL**: the URL to your company's support page. - -In addition to these fields, the error page returns the follow information to assist you in troubleshooting the error: - -* **Client ID**: the identifier for the client; -* **Connection**: the Connection used at the time of error; -* **Language**: the language set to be used at the time of error; -* **Error**: the code corresponding to the error that occurred; -* **Error Description**: a description of the error that occurred; -* **Show Log URL**: the link to the error logs, if available; -* **Title**: the friendly name of the tenant; -* **Tenant**: the tenant information (the friendly name, logo URL, support email, and support URL fields that you may customize). - -## 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. - -The [custom error pages](/hosted-pages/custom-error-pages) page details how you can configure your own custom error page for use with Auth0. diff --git a/articles/hosted-pages/guardian.md b/articles/hosted-pages/guardian.md deleted file mode 100644 index 67e6d096f8..0000000000 --- a/articles/hosted-pages/guardian.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: Guide on how to use the hosted Guardian MFA page ---- -# Guardian Multifactor Login Page - -In the [Auth0 Dashboard](${manage_url}/#/guardian_mfa_page), you can enable 2nd factor authentication, using Guardian Multifactor. You can customize the page that Auth0 displays to your users, allowing you to require MFA on logins which meet certain criteria, or just across the board. For more information on Guardian, refer to [Guardian MFA](/multifactor-authentication/guardian). - -![Hosted Guardian MFA Page](/media/articles/hosted-pages/guardian.png) - -## Guardian Login Page HTML Editor - -To enable the Guardian Login page, go to [Dashboard > Hosted Pages > Guardian Multifactor](${manage_url}/#/guardian_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**. diff --git a/articles/hosted-pages/index.md b/articles/hosted-pages/index.md deleted file mode 100644 index 95513db8e1..0000000000 --- a/articles/hosted-pages/index.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -description: Overview of hosted pages with Auth0, and how to use them ---- - -# Auth0 Hosted Pages - -Auth0 offers you the ability to display customized pages containing Auth0-related functionality and to which Auth0 redirects your users during the authorization process. You can create the following types of hosted pages: - -* [Login](/hosted-pages/login) -* [Password Reset](/hosted-pages/password-reset) -* [Guardian Multifactor](/hosted-pages/guardian) -* [Error pages](/hosted-pages/error-pages) - -While Auth0 hosts your custom pages, you can still [manage your pages using the version control system of your choice](/hosted-pages/version-control). - -## Why Use Hosted Pages - -Hosted pages are easy to implement and secure. For example, using Auth0 hosted pages instead of hosting them externally provides seamless CSRF protection. This helps prevent third party impersonation or the hijacking of sessions. - -## How to Enable and Customize Hosted Pages - -To enable a particular type of hosted page, navigate to the [Hosted Pages section of the Auth0 Dashboard](${manage_url}/#/login_page) (note that Error Page settings are located under [Tenant Settings](${manage_url}/#/tenant)). Click on the slider to enable the page. - -## Customize Your Hosted Page - -In the Auth0 Dashboard, you'll see an HTML editor, as well as a **Preview** tab, for each of the hosted page types. You can either use the editor to create your HTML or paste in the HTML you've created elsewhere. - -For detailed instructions on how to customize each type of hosted page, please see the following docs: - -* [Login Page](/hosted-pages/login) -* [Password Reset Page](/hosted-pages/password-reset) -* [Guardian Multifactor Authentication Page](/hosted-pages/guardian) -* [Error Pages](/error-pages) diff --git a/articles/hosted-pages/login/auth0js.md b/articles/hosted-pages/login/auth0js.md deleted file mode 100644 index 0dd64f2da4..0000000000 --- a/articles/hosted-pages/login/auth0js.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -description: How to Use the Auth0.js with the Hosted Login Page ---- -# Using Auth0.js in the Hosted Login Page - -Within the login page, you can use the the [Auth0.js SDK](/libraries/auth0js), instead of [Lock](/libraries/lock), to perform authentication using a custom UI. - -## Auth0.js Template for the Login Page - -You can start out with a basic template that will provide you with a working, ready-to-use example of a custom UI using Auth0.js v8 in your universal login page. - -In the [dashboard](${manage_url}), go to **Hosted Pages**, and then to the **Login** page section. - -At the top of the code editor for the page contents, you'll see a dropdown, titled **Default Templates**. Here you can choose from `Lock`, `Lock Passwordless`, or `Custom UI`. - -Choose `Custom UI` to get started. - -![Login Page](/media/articles/hosted-pages/hlp-customui.png) - -The template showcases using Auth0.js to allow users to sign up, log in with a database connection, or login with a social provider (Google, in this example). - -Additionally, you can take a look at the following example scenario using Auth0.js as well. - -### Passwordless example - -With [passwordless authentication](/connections/passwordless), the user is prompted to enter an email or an SMS number, at which they will receive a one-time code to enter, or a "magic link" to click, which will authenticate them. In this example, the user will enter an email, and receive a one-time code. - -For this example, replace the code in the login page editor with the following template: - -```html - - - - - - Sign In with Auth0 - - - - - - - - - - - - - - - - - -``` - -This should allow you to prompt your users to enter their email address, receive a code, and enter it to verify. Once the transaction is complete and they're redirected to your application, you'll want to [parse the URL hash](/libraries/auth0js#extract-the-authresult-and-get-user-info) to acquire their token and finish your authentication process. - -## Next Steps - -Are you looking for more information about the SDK used here, or about Passwordless authentication? Or are you ready to get started implementing universal login? - -::: next-steps -* [Read more About the Auth0.js SDK](/libraries/auth0js) -* [Get Started with Universal Login](${manage_url}/#/login_page) -::: diff --git a/articles/hosted-pages/login/index.md b/articles/hosted-pages/login/index.md index 8da2c2a94e..91c88f8d46 100644 --- a/articles/hosted-pages/login/index.md +++ b/articles/hosted-pages/login/index.md @@ -8,15 +8,17 @@ crews: crew-2 ## About Universal Login -Auth0's universal login is the most secure way to easily authenticate users for your applications. The login page appearance and behavior is easily customizable right from the [Dashboard](${manage_url}). By default, the login page uses Auth0's [Lock Widget](/libraries/lock) to authenticate your users, but the code of the login page can be customized to replace Lock with the Lock Passwordless widget, or an entirely custom UI can be built in its place, using the [Auth0.js SDK](/libraries/auth0js) for authentication. +Auth0's universal login is the most secure way to easily authenticate users for your applications. The login page appearance and behavior is easily customizable right from the [Dashboard](${manage_url}). By default, the login page uses Auth0's [Lock Widget](/libraries/lock) to authenticate your users, but the code of the login page can be customized to replace Lock with the Lock Passwordless widget, or an entirely custom UI can be built in its place, using the [Auth0.js SDK](/libraries/auth0js) for authentication. If you cannot use universal login, you can embed the Lock widget or a custom login form in your application using [cross-origin authentication](/cross-origin-authentication), but be sure to read about its limitations before choosing to do so. ![Login Page](/media/articles/hosted-pages/hlp-lock.png) +To find the default page name for the login page, see [How to Use Version Control to Manage Your Universal Login Pages](/universal-login/version-control). + ### How Does Universal Login Work -Auth0 shows the login page whenever something (or someone) triggers an authentication request, such as calling the `/authorize` endpoint (OIDC/OAuth) or sending a SAML login request. +Auth0 shows the login page whenever something (or someone) triggers an authentication request, such as calling the `/authorize` endpoint (OIDC/OAuth) or sending a SAML login request. Users will see the login page, typically with either the Lock widget or with your custom UI. Once they login, they will be redirected back to your application. @@ -24,16 +26,16 @@ Users will see the login page, typically with either the Lock widget or with you If the incoming authentication request includes a `connection` parameter that uses an external identity provider (such as a social provider), the login page will not display. Instead, Auth0 will direct the user to the [identity provider's](/identityproviders) login page. ::: -#### Single Sign-On (SSO) +#### Single Sign-on (SSO) -If you want to use single sign on, you should use universal login rather than an embedded login solution. When a user logs in via the login page, a cookie will be created and stored. On future calls to the `authorize` endpoint, the cookie will be checked, and if SSO is achieved, the user will not ever be redirected to the login page. They will see the page only when they need to actually login. +If you want to use Single Sign-on (SSO), you should use universal login rather than an embedded login solution. When a user logs in via the login page, a cookie will be created and stored. On future calls to the `authorize` endpoint, the cookie will be checked, and if SSO is achieved, the user will not ever be redirected to the login page. They will see the page only when they need to actually login. This behavior occurs without the need for any modification to the login page itself. This is a simple two step process: -1. Enable SSO for the application in the [Dashboard](${manage_url}) (Go to the Application's Settings, then scroll down to the **Use Auth0 instead of the IdP to do Single Sign On** setting and toggle it on. +1. Enable SSO for the application in the [Dashboard](${manage_url}) (Go to the Application's Settings, then scroll down to the **Use Auth0 instead of the IdP to do Single Sign-on** setting (legacy tenants only) and toggle it on. 1. Use the [authorize endpoint](/api/authentication#authorization-code-grant) with `?prompt=none` for [silent SSO](/api-auth/tutorials/silent-authentication). -::: note +::: note For more details about how SSO works, see the [SSO documentation](/sso). ::: @@ -57,7 +59,7 @@ Currently, universal login is the **only** way to use [Passwordless](/connection ### 1. Enable Customization on the Login Page -In the [Dashboard](${manage_url}), you can enable a custom login page by navigating to [Hosted Pages](${manage_url}/#/login_page) and enabling the **Customize Login Page** toggle. +In the [Dashboard](${manage_url}), you can enable a custom login page by navigating to [Universal Login](${manage_url}/#/login_settings) and enabling the **Customize Login Page** toggle. ![Login Page](/media/articles/hosted-pages/login.png) @@ -67,7 +69,7 @@ In order to get started customizing the login page, you'll first want to choose - [Lock](/hosted-pages/login/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)](/hosted-pages/login/lock-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](/hosted-pages/login/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. +- [Auth0.js](/hosted-pages/login/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. ### 3. Customization @@ -77,7 +79,7 @@ All changes to the page's appearance and/or behavior will apply to **all** users #### Parameters for the Authorize Endpoint -If you initiate universal login via the `authorize` endpoint, whether by an SDK like auth0.js or by calling the endpoint directly, you may also pass some customization parameters to the login page. However, parameters passed to the `authorize` endpoint must be [OIDC specification](http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) compliant parameters. +If you initiate universal login via the `authorize` endpoint, whether by an SDK like auth0.js or by calling the endpoint directly, you may also pass some customization parameters to the login page. However, parameters passed to the `authorize` endpoint must be [OpenID Connect (OIDC) specification](http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) compliant parameters. The `config` object contains the set of configuration values that adjusts the behavior of the login page at runtime. Set the `config` object up in the login page editor so that you can access the config parameters to use in your page: @@ -85,7 +87,7 @@ The `config` object contains the set of configuration values that adjusts the be var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@')))); ``` -The below examples assume that you are using [Auth0.js](/libraries/auth0js) within your application to call the `authorize` endpoint and show the login page. +The below examples assume that you are using [Auth0.js](/libraries/auth0js) within your application to call the `authorize` endpoint and show the login page. ##### Callback URL @@ -103,19 +105,19 @@ webAuth.authorize({ ## Configure Multiple Pages by Using Separate Tenants -In some cases, you might have multiple apps and want to configure separate login pages for each. Since the hosted pages are configured in the [Dashboard](${manage_url}) at the tenant level (every app you have set up on a single tenant would use the same login page), you would have to create a new tenant for each application that requires a different hosted page. +In some cases, you might have multiple apps and want to configure separate login pages for each. Since the Universal Login pages are configured in the [Dashboard](${manage_url}) at the tenant level (every app you have set up on a single tenant would use the same login page), you would have to create a new tenant for each application that requires a different login page. In most cases, it would be preferable to use a single login page, which unifies your brand and the authentication experience for your users across the various areas in which they might encounter it. Additionally, using the same pages, and the same tenant, will allow you to share the resources that would otherwise need to be separated across multiple tenants. -Creating a separate tenant is only really a viable option for an organization that needs two or more separate sets of custom pages, such as for branding reasons. If an example corporation has multiple branded subsidiaries or products, and separate APIs for all of them, it might make sense for them to create several separate Auth0 tenants, each with their own hosted pages set up for that brand or product's specific needs. +Creating a separate tenant is only really a viable option for an organization that needs two or more separate sets of custom pages, such as for branding reasons. If an example corporation has multiple branded subsidiaries or products, and separate APIs for all of them, it might make sense for them to create several separate Auth0 tenants, each with their own Universal Login pages set up for that brand or product's specific needs. -Bear in mind that separating tenants with the goal of having separate hosted pages will also mean that those separate tenants will have two distinct sets of applications, users, settings, and so on as these things are not shared between tenants. +Bear in mind that separating tenants with the goal of having separate Universal Login pages will also mean that those separate tenants will have two distinct sets of applications, users, settings, and so on as these things are not shared between tenants. ### Creating New Tenants If your use case requires separate sets of custom pages, let's see how you would go about creating them. -If you have five different applications, with three of them (`app1`, `app2`, `app3`) using the same set of hosted pages and the other two (`app4`, `app5`) using different ones, you would do the following: +If you have five different applications, with three of them (`app1`, `app2`, `app3`) using the same set of Universal Login pages and the other two (`app4`, `app5`) using different ones, you would do the following: - If you already have an account, you have a tenant configured. Configure three applications under this tenant, one to represent each app (`app1`, `app2`, `app3`), and one login page which these applications will all share. - Create a second tenant, configure a new application for `app4`, and configure the login page for this application. diff --git a/articles/hosted-pages/login/lock-passwordless.md b/articles/hosted-pages/login/lock-passwordless.md deleted file mode 100644 index d964ab0147..0000000000 --- a/articles/hosted-pages/login/lock-passwordless.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -description: How to use Lock Passwordless with Universal Login ---- -# Universal Login with Lock Passwordless - -Using Lock Passwordless in a universal login page is the easiest and most secure implementation of [passwordless authentication](/connections/passwordless) that can be achieved. Additionally, universal login is the **only** way to perform passwordless authentication with native applications at this time. - -## Lock Passwordless Template - -You can start out with a basic template that will provide you with a working, ready-to-use example of Lock with Passwordless Mode in the login page. - -In the [dashboard](${manage_url}), go to **Hosted Pages**, and then to the **Login** page section. - -At the top of the code editor for the page contents, you'll see a dropdown, titled **Default Templates**. Here you can choose from `Lock`, `Lock Passwordless`, or `Custom UI`. - -Choose `Lock Passwordless` to get started. - -![Login Page](/media/articles/hosted-pages/hlp-lock-passwordless.png) - -## Next Steps - -Are you looking for more information about Lock? Or are you ready to get started with your own login page? - -::: next-steps -* [Read more about Lock](/libraries/lock) -* [Get started on your own login page](${manage_url}/#/login_page) -::: diff --git a/articles/hosted-pages/login/lock.md b/articles/hosted-pages/login/lock.md deleted file mode 100644 index c5ef0b0a41..0000000000 --- a/articles/hosted-pages/login/lock.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -description: How to use Lock with Universal Login ---- -# How to Use Lock with Universal Login - -[Lock](/libraries/lock) is a signup and authentication widget that provides quick and easy authentication for your application's users without requiring you to design the UI or interact manually with an Auth0 API. - -## Customize Lock in the Login Page - -The default login page for your tenant is a template that will use Lock to provide your users with an attractive interface and smooth authentication process, as discussed above. You can look over that template and use it as a starting point if you choose to customize it in any way. - -If you want to change any of Lock's [configurable options](/libraries/lock/configuration), you can do so using the [Hosted Pages](${manage_url}/#/login_page) editor interface. These options can alter the behavior of Lock itself, or the look and feel of the widget using the theming options. See the [configuration documentation](/libraries/lock/v11/configuration) for details on how to customize Lock. - -When you're done making changes to the code, click **Save** to persist the changes. - -![Login Page](/media/articles/hosted-pages/hlp-lock.png) - -## Next Steps - -::: next-steps -* [Read more about Lock](/libraries/lock) -* [Get started on your own login page](${manage_url}/#/login_page) -::: diff --git a/articles/hosted-pages/password-reset.md b/articles/hosted-pages/password-reset.md deleted file mode 100644 index 8e28f7ea9f..0000000000 --- a/articles/hosted-pages/password-reset.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Guide on how to use the hosted password reset page -crews: crew-2 ---- - -# Password Reset Page - -The Password Reset Page allows users to change their passwords in the event that they're unable to log in. Using this page, you can maintain consistency in the appearance of your pages (login, password reset, and so on), and your users can easily change their passwords as needed. - -## Enable the Custom Password Reset Page - -Using the [Auth0 Dashboard](${manage_url}/#/password_reset), you can enable your Hosted Password Reset Page by flipping the toggle switch. - -![Hosted Password Reset Page](/media/articles/hosted-pages/password-reset.png) - -## Edit the Custom Password Reset Page - -Once you've enabled the Password Reset Page for your tenant, 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. After you've made your changes, and make sure to click _Save_. - -### Custom Variables - -You can use JavaScript to retrieve the following custom variables: - -| 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.) | - -::: note -You can set/check the values for your `tenant` variables in the **Settings** area in [Tenant Settings](${manage_url}/#/tenant) -::: - -Within the Password Reset Page Editor, you'll see the following JavaScript embedded: - -```js - -``` - -Notice that the sample template uses the `tenant.picture_url` variable to return the value entered in the **Logo URL** field of the **Settings** area in [Tenant Settings](${manage_url}/#/tenant). Auth0 will retrieve the logo at that URL and display it on the password reset widget. If Auth0 cannot resolve the URL, it'll display a default image (note that the sample snippet below has all unrelated content removed, including mandatory fields): - -```js - -``` - -## Revert Your Changes - -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**. diff --git a/articles/hosted-pages/version-control.md b/articles/hosted-pages/version-control.md deleted file mode 100644 index ac3f4e2bd7..0000000000 --- a/articles/hosted-pages/version-control.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -description: How to back up your hosted pages using the Auth0 version control extensions ---- -# How to Use Version Control to Manage Your Hosted Pages - -You can use version control software to manage the source code of your hosted 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/articles/i18n/i18n-guide-android.md b/articles/i18n/i18n-guide-android.md index dba9f51f23..c415958ffe 100644 --- a/articles/i18n/i18n-guide-android.md +++ b/articles/i18n/i18n-guide-android.md @@ -1,6 +1,11 @@ --- title: Android guide to i18n description: Links to the Android guide on how to localize resource files. +topics: + - i18n + - android +contentType: how-to +useCase: localize --- # Android guide to i18n diff --git a/articles/i18n/i18n-guide-ios.md b/articles/i18n/i18n-guide-ios.md index e50ec405b3..d691be0649 100644 --- a/articles/i18n/i18n-guide-ios.md +++ b/articles/i18n/i18n-guide-ios.md @@ -1,5 +1,10 @@ --- description: This page is themguide to internationalizing an iOS application. +topics: + - i18n + - ios +contentType: how-to +useCase: localize --- # iOS guide to i18n diff --git a/articles/i18n/index.md b/articles/i18n/index.md index 4b0190b4d0..924045f31e 100644 --- a/articles/i18n/index.md +++ b/articles/i18n/index.md @@ -1,12 +1,17 @@ --- url: /i18n description: Links to documentation on internationalizing an application. +topics: + - i18n +contentType: index +useCase: localize --- # Internationalization and Multilingual settings Below you can find useful links in our documentation to handle different languages within Auth0. - [Customizing Your Emails](/email/templates) +- [Universal Login Internationalization](/universal-login/i18n) - [Lock: Internationalization](/libraries/lock/i18n) - [Password Options Translation](/i18n/password-options) - [iOS guide to i18n](/i18n/i18n-guide-ios) diff --git a/articles/i18n/password-options.md b/articles/i18n/password-options.md index a31e0d9872..f1bbff1601 100644 --- a/articles/i18n/password-options.md +++ b/articles/i18n/password-options.md @@ -1,5 +1,11 @@ --- description: How to customize the translation of Lock password features. +topics: + - i18n + - lock + - password +contentType: how-to +useCase: localize --- # Password Options Translation @@ -50,7 +56,7 @@ dict: { passwordConfirmationPlaceholder: "confirm your new password", passwordConfirmationMatchError: "Please ensure the password and the confirmation are the same.", successMessage: "Your password has been reset successfully.", - configurationError: "An error ocurred. There appears to be a misconfiguration in the form.", + configurationError: "An error occurred. There appears to be a misconfiguration in the form.", networkError: "The server cannot be reached, there is a problem with the network.", timeoutError: "The server cannot be reached, please try again.", serverError: "There was an error processing the password reset.", diff --git a/articles/identity-labs/01-web-sign-in/exercise-01.md b/articles/identity-labs/01-web-sign-in/exercise-01.md new file mode 100644 index 0000000000..1b27b80792 --- /dev/null +++ b/articles/identity-labs/01-web-sign-in/exercise-01.md @@ -0,0 +1,203 @@ +--- +section: exercises +description: Auth0 Digital Identity Lab 1, Exercise 1: Adding Web Sign-In +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 1, Exercise 1: Adding Web Sign-In + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/01-web-sign-in) and read through the instructions before getting started. +::: + +In this exercise, you will learn how to add sign-in to an app using: + +- Node.js + Express +- An Express middleware to handle checking authentication and redirecting to login +- Auth0 as an Authorization Server + +
      + +
      +
      +
      +
      +
      +
      + +A simple Node.js Express application has been created to get you started. This is a web application with two pages. The first page, served under the root path `/`, shows “Hello World” and a link (“Expenses”) to the second page. The second page, served at `/expenses`, shows a table with expenses. At this point, these expenses are hard-coded; you will learn how to consume them from an API secured with Auth0 in the next lab. + +1. Open your Terminal app, clone the [identity exercise repo](https://github.com/auth0/identity-102-exercises/), then go to the `/lab-01/begin` folder: + +```bash +❯ git clone https://github.com/auth0/identity-102-exercises.git +Cloning into 'identity-102-exercises'... + +❯ cd identity-102-exercises/lab-01/begin +``` + +2. Open a code editor like VS Code or Atom in the same directory (File > Open) and review the `server.js` code. This is a generic Node.js web application that uses `ejs` for views and `morgan` to log HTTP requests. + +3. The `.env-sample` file will be used for the environment variables you need for this lab. It’s populated with a `PORT` (the port number where the app will run) and an `APP_SESSION_SECRET` (value used to encrypt the cookie data). You will set the other values later on in the lab. For now, create a copy of this file in the same folder and name it `.env`. Run the following commands in your terminal (or copy, paste, and rename the sample file in your editor): + +```bash +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-01/begin + +# Copy the .env-sample file to a new .env file that the app will use +❯ cp .env-sample .env +``` + +4. In your terminal, use `npm` to install all the dependencies and start the application: + +```bash +❯ npm install +# Ignore any warnings + +added XX packages in X.XXs +❯ npm start + +listening on http://localhost:3000 +``` + +::: note +If you see a message like "Error: listen EADDRINUSE :::3000" in your terminal after starting the application, this means that port 3000 is in use somewhere. Change the `PORT` value in your `.env` file to "4000" and try again. +::: + +5. Open a Web browser and go to [localhost:3000](http://localhost:3000) (or `http://localhost:PORT` where PORT is the value of the environment variable, in case you changed its value). You should see a page with a “Hello World” message. Click the Expenses link to view the expenses page. + +![First page of the starter app](/media/articles/identity-labs/lab-01-starter-app-rendered.png) + +6. Now, we're ready to start adding authentication! Switch to your terminal window and press `[CTRL]` + `[c]` to stop the server, then use `npm` to install the package you'll use to secure the app. The `express-openid-connect` package is a simple Express middleware that provides OpenID Connect and JWT implementation. + +```bash +# Continuing from previous terminal session ... +listening on http://localhost:3000 +^C # Command to stop the server +❯ npm install express-openid-connect@1.0.2 --save +# Ignore any warnings + ++ express-openid-connect@1.0.2 +added XX packages in X.XXs +``` + +7. Next, update your application code to require `express-openid-client` in the `server.js` file: + +```js +// lab-01/begin/server.js + +require('dotenv').config(); +// ... other required packages + +// Add the line below 👇 +const { auth } = require('express-openid-connect'); + +// ... +``` + +8. Now add the authentication middleware that will be used for all application routes: + +```js +// lab-01/begin/server.js +// ... + +const app = express(); +app.set('view engine', 'ejs'); +app.use(morgan('combined')); + +// Add the code below 👇 +app.use(auth({ + auth0Logout: true, + baseURL: appUrl +})); + +// ... other app routes +``` + +The middleware you installed automatically defines three routes in your application: + +- `/login` - builds the OpenID Connect request and redirects to the authorization server (in this case, Auth0). For this to work properly, the middleware needs to include specific parameters with the request. You will configure these values using environment variables in the next step. +- `/callback` - handles the response from the authorization server, performs required validations like nonce, state, and token verification using the `openid-client` package, and sets the user in the session from the ID token claims. +- `/logout` - terminates the session in the application and redirects to Auth0 to end the session there as well. + +The middleware will also augment Express’s request object with additional properties whenever the request is authenticated. For example, `req.openid.user` is a property that will contain user information. + +::: note +The `auth0Logout: true` configuration key passed to `auth()` tells the middleware that, when the user logs out of the application, they should be redirected to a specific Auth0 URL to end their session there as well. +::: + +The middleware needs to be initialized with some information to build a proper OpenID request and send it to the authorization server. This information includes: + +- **The URL of the authorization server.** This URL will be used to download the OpenID Connect configuration from the discovery document, available at the URL `https://{your-auth0-domain}/.well-known/openid-configuration` ([here is the configuration](https://auth0.auth0.com/.well-known/openid-configuration) for the main Auth0 tenant). The discovery document is a standard OpenID Connect mechanism used to publish relevant discovery metadata of the OpenID Connect provider, including a link to what keys should be used for validating the tokens it issues. +- **The unique identifier for your application.** This is created on the authorization server and is a unique string that identifies your application. This identifier must be provided in each request, so the authorization server knows what application the authentication request is for. + +You will use the Auth0 Dashboard to register your application with Auth0. Afterward, you’ll be able to retrieve the two values above and configure them as environment variables for your app. The middleware will read these environment variables and use them to build the request when a user tries to authenticate. + +9. Log into the Auth0 Dashboard, go to the [Applications page](${manage_url}/#/applications), and click the **Create Application** button. + +10. Set a descriptive name (e.g., "Identity Lab 1 - Web Sign In"), choose **Regular Web Applications** for the type, and click **Create**. + +11. You should now see the Quickstart section that describes how to integrate Auth0 with a production application. Click the **Settings** tab at the top to see the Application settings. + +12. Add your application’s callback URL - `http://localhost:3000/callback` (adjust the port number if needed) - to the **Allowed Callback URLs** field. Auth0 will allow redirects **only** to the URLs in this field after authentication. If the one provided in the authorization URL does not match any in this field, an error page will be displayed. + +![Application callback URL field](/media/articles/identity-labs/lab-01-callback-url-config.png) + +13. Next, add `http://localhost:3000` (adjust the port number if needed) to the **Allowed Logout URLs field**. Auth0 will allow redirects **only** to the URLs in this field after logging out of the authorization server. + +![Application logout URL field](/media/articles/identity-labs/lab-01-logout-url-config.png) + +14. Scroll down and click **Show Advanced Settings**, then **OAuth**. Make sure **JsonWebToken Signature Algorithm** is set to `RS256`. + +15. Scroll down and click **Save Changes** + +16. Open your `.env` file. Add `https://` to the **Domain** from Auth0 as the value for the `ISSUER_BASE_URL` key. Add the **Client ID** from Auth0 as the value for the `CLIENT_ID` key. Add a long, random string and the value for the `APP_SESSION_SECRET` key. You `.env` file should look similar to the sample below: + +``` +ISSUER_BASE_URL=https://your-tenant-name.auth0.com +CLIENT_ID=0VMFtHgN9mUa1YFoDx3CD2Qnp2Z11mvx +APP_SESSION_SECRET=a36877de800e31ba46df86ec947dab2fc8a2f7e1d23688ce2010cd076539bd28 +PORT=3000 +``` + +::: note +Mac users can enter the following in Terminal to get a random string suitable for the secret value: `openssl rand -hex 32`. This value is used by the session handler in the SDK to generate opaque session cookies. +::: + +17. Save the changes to `.env` and restart the server as before, but do not open it in a browser yet. + +Your app is now ready to authenticate with Auth0 using OpenID Connect! Before testing it, continue to the next exercise, where you will review the interactions that happen under the hood between your app and Auth0 while you sign up and log in. + +```bash +# Continuing from previous terminal session ... +listening on http://localhost:3000 +^C # Command to stop the server +❯ npm start + +listening on http://localhost:3000 +``` +
      +
      +
      + +Next → diff --git a/articles/identity-labs/01-web-sign-in/exercise-02.md b/articles/identity-labs/01-web-sign-in/exercise-02.md new file mode 100644 index 0000000000..1d5d2759a4 --- /dev/null +++ b/articles/identity-labs/01-web-sign-in/exercise-02.md @@ -0,0 +1,133 @@ +--- +section: exercises +description: Auth0 digital identity Lab 1, Exercise 2: Using Network Traces +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 1, Exercise 2: Using Network Traces + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/01-web-sign-in) and read through the instructions before getting started. +::: + +In this exercise, you will sign up for your application (which will also log you in) while exploring some of the relevant network traces of the authentication process. + +
      + +
      +
      +
      +
      +
      + +1. Using Chrome, open **Developer Tools**. Switch to the **Network** tab then open your local application. You should immediately be redirected to Auth0 to login. + +2. The first request you should see is a GET request to your application homepage: + +![Network request for application homepage](/media/articles/identity-labs/lab-01-network-trace-01.png) + +3. After that, you should see a GET request to `https://your-tenant-name.auth0.com/authorize`. This is the middleware added in exercise 1 taking over. The middleware checks if the user is logged in and, because they are not, it builds the OpenID Connect request to the authorization server URL and forwards the user to it. In this case, the complete GET request URL will look something like this (line breaks added for clarity): + +```text +https://YOUR_DOMAIN/authorize +?client_id=YOUR_CLIENT_ID +&scope=openid%20profile%20email +&response_type=id_token +&nonce=71890cc63567e17b +&state=85d5152581b310e3389b +&redirect_uri=http%3A%2F%2Flocalhost%3A3000 +&response_mode=form_post +``` + +--- + +The middleware sends several parameters. The important ones for this lab are: + +- `client_id`: the unique identifier of your app at the authorization server +- `response_type`: the requested artifacts; in this case, you are requesting an ID token +- `scope`: why the artifacts are required, i.e. what content and capabilities are needed +- `redirect_uri`: where the results are to be sent after the login operation, i.e. the callback URL. +- `response_mode`: how the response from the server is to be sent to the app; in this case, the response we want is a POST request. + +![Network request for authorization server](/media/articles/identity-labs/lab-01-network-trace-02.png) + +::: note +If you scroll down while on the **Headers** tab in Chrome Developer Tools to the **Query String Parameters** section, you can see the different URL parameters in a more-readable table format. +::: + +4. If you already have a user created, enter your credentials and continue below. If not, click the **Sign Up** link at the bottom (if you're using the classic page, this will be a tab at the top) and enter an email and password. + +5. A consent dialog will be shown requesting access to your profile and email. Click the green button to accept and continue. + +6. The authorization server will log you in and POST the response - an error if something went wrong or the ID token if not - back to the callback URL for your application. Once you’ve successfully logged in, you should see your user name on the page. This means authentication has been configured properly! + +![Network request for application callback](/media/articles/identity-labs/lab-01-network-trace-03.png) + +The complete trace of the callback request is: + +```text +Request URL: `http://localhost:3000/callback` +Request Method: POST +Status Code: 302 Found +Remote Address: [::1]:3000 +Referrer Policy: no-referrer-when-downgrade +Connection: keep-alive +Content-Length: 46 +Content-Type: text/html; charset=utf-8 +Date: Mon, 12 Nov 2018 23:00:08 GMT +Location: / +Set-Cookie: identity102-lab=eyJyZX[..]; path=/; httponly +Set-Cookie: identity102-lab.sig=wld5z7[..]; path=/; httponly +Vary: Accept +X-Powered-By: Express +id_token: eyJ0eX[..].eyJuaW[..].IEpcS5[..] +state: 85d5152581b310e3389b +``` + +::: note +If you see an error in your console about an ID token used too early, this is likely a clock skew issue in your local environment. Try restarting your machine and walking through the login steps again from the beginning. +::: + +7. Click on the callback request, then search for the Form Data section of the Headers tab of the Developer Console. Copy the complete `id_token` value. + +![Network request for ID token form post](/media/articles/identity-labs/lab-01-network-trace-04.png) + +8. Go to [jwt.io](https://jwt.io) and paste the ID token copied from the last step into the text area on the left. Notice that as soon as you paste it, the contents of the text area on the right are updated. This is because the site decodes your ID token and displays its contents (claims) in that panel. + +![Decoded ID token](/media/articles/identity-labs/lab-01-id-token-in-jwt-io.png) + +Note the following: + +- The token structure: it consists of the header (information about the token), the payload (the token’s claims and user profile information), and the signature. +- The claim `iss` is for the issuer of the token. It denotes who created and signed it. The value should match your Auth0 Domain value with an `https://` prefixed. +- The claim `sub` is the subject of the token. It denotes to whom the token refers. In our case, the value matches the ID of the Auth0 user. +- The claim `aud` is the audience of the token. It denotes for which app the token is intended. In our case, this matches the Client ID of the application that made the authentication request. +- The claim `iat` shows when the token was issued (seconds since Unix epoch) and can be used to determine the token’s age. +- The claim `exp` shows when the token expires (seconds since Unix epoch). + +🎉 **You have completed Lab 1 by building a web application with sign-on using OpenID Connect!** 🎉 + +
      +
      +
      + +← All Identity Labs diff --git a/articles/identity-labs/01-web-sign-in/index.md b/articles/identity-labs/01-web-sign-in/index.md new file mode 100644 index 0000000000..54291adf62 --- /dev/null +++ b/articles/identity-labs/01-web-sign-in/index.md @@ -0,0 +1,39 @@ +--- +section: exercises +classes: topic-page +description: Auth0 digital identity Lab 1: Web Sign-In +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 1: Web Sign-In + +This lab covers the process for adding sign-in to a basic Node.js application. This lab is the same exercise we provide for new employees in a technical role here at Auth0. + +::: warning +The Node OIDC npm package that this lab uses has not been tested, licensed, or officially released and should not be used in production. +::: + +## Prerequisites + +- Read the introduction on the [main Identity Labs page](/identity-labs) +- Watch the [Introduction to Identity video](/videos/learn-identity/01-introduction-to-identity) +- Watch the [OIDC and OAuth video](/videos/learn-identity/02-oidc-and-oauth) +- Watch the [Web Sign-In video](/videos/learn-identity/03-web-sign-in) +- Read [Using Express Middleware](https://expressjs.com/en/guide/using-middleware.html) (optional) +- Read [Beginner's Guide to Using npm](https://nodesource.com/blog/an-absolute-beginners-guide-to-using-npm/) (optional) + +## What You'll Need + +<%= include('../_includes/_what-you-need') %> + +--- + +**For Windows users** - We recommend that you use the Windows PowerShell terminal (instead of the Windows command line) so that the terminal commands provided in the lab instructions work as they are. This is because the syntax of the commands used in the labs is the same for the Mac and PowerShell terminals. + +Start → diff --git a/articles/identity-labs/02-calling-an-api/exercise-01.md b/articles/identity-labs/02-calling-an-api/exercise-01.md new file mode 100644 index 0000000000..b057e2d5b6 --- /dev/null +++ b/articles/identity-labs/02-calling-an-api/exercise-01.md @@ -0,0 +1,216 @@ +--- +section: exercises +description: Auth0 digital identity Lab 2, Exercise 1: Consuming APIs +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 2, Exercise 1: Consuming APIs + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/02-calling-an-api) and read through the instructions before getting started. +::: + +After learning how to secure your web application with Auth0 in [lab 1](/identity-labs/01-web-sign-in), you will now learn how to make this application consume APIs on behalf of your users. You will start by running an unsecured API and a web application to see both working together, and then you will secure your API with Auth0. + +
      + +
      +
      +
      +
      +
      +
      +
      +
      + +1. Open a new terminal and browse to `/lab-02/begin/api` in your locally-cloned copy of the [identity exercise repo](https://github.com/auth0/identity-102-exercises/). This is where the code for your API resides. The API is an Express backend that contains a single endpoint. This endpoint (served under the root path) returns expenses, which are data that belong to each user (though they are static and the same for all). + +<%= include('../_includes/_git-clone-note') %> + +2. Install the dependencies using npm: + +```bash +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-02/begin/api + +❯ npm install +# Ignore any warnings + +added XX packages in X.XXs +``` + +3. Next, copy `.env-sample` to `.env` and start the API: + +```bash +❯ cp .env-sample .env +❯ npm start + +listening on http://localhost:3001 +``` + +::: note +If you see a message like *Error: listen EADDRINUSE :::3001* in your terminal after starting the application, this means that port 3001 is in use somewhere. Change the `PORT` value in your `.env` file to "3002" and try again. +::: + +4. In a new terminal window or tab, navigate to the `/lab-02/begin/webapp` directory and install the dependencies using npm: + +```bash +# Navigating from the previous directory +❯ cd ../webapp + +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-02/begin/webapp + +❯ npm install +# Ignore any warnings + +added XX packages in X.XXs +``` + +5. Once again, copy the `.env-sample` to `.env` for the web application: + +```bash +❯ cp .env-sample .env +``` + +6. Update the web application `.env` file you just created with the same values as you used in lab 1. If you did not do lab 1 first, follow steps 9 through 15 [on this page](/identity-labs/01-web-sign-in/exercise-01) to create and configure an application with Auth0 and update the `.env` file. + +```text +ISSUER_BASE_URL=https://YOUR_DOMAIN +CLIENT_ID=YOUR_CLIENT_ID +API_URL=http://localhost:3001 +PORT=3000 +APP_SESSION_SECRET=LONG_RANDOM_STRING +``` + +::: note +If you changed the port for the API above, make sure to update the `API_URL` with this new value. +::: + +7. Start the web application using npm: + +```bash +❯ npm start + +listening on http://localhost:3000 +``` + +8. Open [localhost:3000](http://localhost:3000) in your browser. There, you will see the homepage of the web application and, if you log in, you will be able to access the expenses report. The page might look similar to the Lab 1 solution, however, the difference is that an external API provides the Expenses information instead of being hard-coded in the Web app. + +![First page of the starter application](/media/articles/identity-labs/lab-02-starter-app-rendered.png) + +Right now, even though the application requires authentication, the API does not. That is, you are calling the API from the Web app, without any authentication information. If you browse to the API's URL at [localhost:3001](http://localhost:3001) without logging in, you will see the expenses. In the following steps, you will update your application to call the API with a token. + +9. Open `webapp/server.js` in your code editor and make the following change: + +```js +// webapp/server.js + +app.use(auth({ + required: false, + auth0Logout: true, + baseURL: appUrl, + + // Add the additional configuration keys below 👇 + appSessionSecret: false, + authorizationParams: { + response_type: 'code id_token', + response_mode: 'form_post', + audience: process.env.API_AUDIENCE, + scope: 'openid profile email read:reports' + }, + handleCallback: async function (req, res, next) { + req.session.openidTokens = req.openidTokens; + req.session.userIdentity = req.openidTokens.claims(); + next(); + }, + getUser: async function (req) { + return req.session.userIdentity; + } + // 👆 + +})); +``` + +This change updates the configuration object passed to `auth()` and defines how you want the `express-openid-connect` library to behave. In this case, you configured the library with a new property called `authorizationParams` and passed in an object with three properties: + +- `response_type` - setting this field to `code id_token` indicates that you no longer want the middleware to fetch just an ID token (which is the default behavior for this package). Instead, you are specifying that you want an ID token *and* an authorization code. When you configure the `express-openid-connect` library to fetch an authorization code, the middleware automatically exchanges this code for an access token (this process is known as the Authorization Code Grant flow). Later, you will use the access token to call the API. +- `response_mode` - This is the same mode used in lab 1, a POST request from the authorization server to the application. +- `audience` - this tells the middleware that you want access tokens valid for a specific resource server (your API, in this case). As you will see soon, you will configure an `API_AUDIENCE` environment variable to point to the identifier of an API that you will register with Auth0. +- `scope` - securing your API uses a delegated authorization mechanism where an application (your web app) requests access to resources controlled by the user (the resource owner) and hosted by an API (the resource server). Scopes, in this case, are the permissions that the access token grants to the application on behalf of the user. In your case, you are defining four scopes: the first three (`openid`, `profile`, and `email`) are scopes related to the user profile (part of OpenID Connect specification). The last one, `read:reports`, is a custom scope that will be used to determine whether the caller is authorized to retrieve the expenses report from the API on behalf of a user. + +The `appSessionSecret`, `handleCallback`, and `getUser` additions change how the user session is handled and stores the incoming access and refresh tokens somewhere we can access later. + +10. Back in the `webapp/server.js` file, find the `/expenses` endpoint definition. In this code, you are making a request to the API, without any authorization information, to get a JSON resource. Note the use of the `requiresAuth()` middleware. This will enforce authentication for all requests to this endpoint. + +11. Update the endpoint definition to include authorization information in the request: + +```js +// webapp/server.js + +app.get('/expenses', requiresAuth(), async (req, res, next) => { + try { + + // Replace this code ❌ + /* + const expenses = await request(process.env.API_URL, { + json: true + }); + */ + + // ... with the code below 👇 + let tokenSet = req.openid.makeTokenSet(req.session.openidTokens); + const expenses = await request(process.env.API_URL, { + headers: { authorization: "Bearer " + tokenSet.access_token }, + json: true + }); + + // ... keep the rest + } + // ... +}); +``` + +In the new version of this endpoint, you are sending the access token in an `Authorization` header when sending requests to the API. By doing so, the web application consumes the API on behalf of the logged in user. + +12. Add the following two environment variables to the `webapp/.env` file: + +```text +API_AUDIENCE=https://expenses-api +CLIENT_SECRET=YOUR_APPLICATION_CLIENT_SECRET +``` + +The `API_AUDIENCE` value is the identifier for the API that will be created in the following exercise. To get your Client Secret, go to your Application settings page in the Auth0 Dashboard: + +![Application client secret field](/media/articles/identity-labs/lab-02-client-secret-config.png) + +**And that's it!** You have just configured your web application to consume the API on behalf of the logged in user. + +If you restart the application in your terminal, logout, and try to log back in, you will see an error because no resource server with the identifier `https://expenses-api` has been registered yet. In the next exercise, you will learn how to create and secure APIs with Auth0, and this request will begin to work. + +
      +
      +
      + +Next → diff --git a/articles/identity-labs/02-calling-an-api/exercise-02.md b/articles/identity-labs/02-calling-an-api/exercise-02.md new file mode 100644 index 0000000000..d4ecb91d29 --- /dev/null +++ b/articles/identity-labs/02-calling-an-api/exercise-02.md @@ -0,0 +1,144 @@ +--- +section: exercises +description: Auth0 digital identity Lab 2, Exercise 2: Securing APIs with Auth0 +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 2, Exercise 2: Securing APIs with Auth0 + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/02-calling-an-api) and read through the instructions before getting started. +::: + +In this exercise, you will register the API with Auth0 so that tokens can be issued for it. You will also learn how to secure your API with Auth0. You will refactor the API that your web application is consuming by installing and configuring some libraries needed to secure it with Auth0. + +
      + +
      +
      +
      +
      +
      +
      +
      +
      + +1. To register the API with Auth0, open the Auth0 Dashboard and go to the [APIs screen](${manage_url}/#/apis). + +2. Click the **Create API** button. Add a descriptive Name, paste `https://expenses-api` into the **Identifier** field, and click **Create**. + +3. Click the **Permissions** tab and add a new permission called `read:reports` with a suitable description. This custom permission is the one you will use to determine whether the client is authorized to retrieve expenses. + +4. In your terminal, restart your web application with `[CTRL]` + `[c]`, then `npm start`. + +5. Log out of the web application by clicking [logout](http://localhost:3000/logout), then log in again. When logging in, you will see a consent screen where Auth0 mentions that the web application is requesting access to the read:reports scope: + +![API consent screen on the authorization server](/media/articles/identity-labs/lab-02-api-consent-initial.png) + +6. Agree to this delegation by clicking the **Accept** button, and Auth0 will redirect you back to the application. Now, you should still be able to see your expenses on the expenses page, [localhost:3000/expenses](http://localhost:3000/expenses): + +![Application expenses page](/media/articles/identity-labs/lab-02-starter-app-rendered.png) + +::: note +If at any point, you want to see the consent screen again when logging in, you can go to the Users screen in the Auth0 Dashboard, click on the user you'd like to modify, click the **Authorized Applications** tab, find the application you're using, and click **Revoke**. The next time you log in, the consent screen will appear again. +::: + +As mentioned earlier, the expenses API is still not secure. You can see this by navigating directly to [localhost:3001](http://localhost:3001/). The expense data is available publicly, without an access token. The next steps will change the API to require a properly-scoped access token to view. + +4. In your terminal, stop your API with `[CTRL]` + `[c]`. + +5. Install the `express-oauth2-bearer` npm package. This is an Express authentication middleware used to protect OAuth2 resources, which validates access tokens: + +```bash +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-02/begin/api + +❯ npm install express-oauth2-bearer@0.4.0 --save +# Ignore any warnings + ++ express-oauth2-bearer@0.4.0 +added XX packages in X.XXs +``` + +6. Open the `api/api-server.js` file and add a statement to import the library. Make sure this is added after the dotenv require statement: + +```js +// api/api-server.js + +require('dotenv').config(); +// ... other require statements + +// Add the line below 👇 +const { auth, requiredScopes } = require('express-oauth2-bearer'); +``` + +7. Configure the Express app to use the authentication middleware for all requests: + +```js +// api/api-server.js + +// ... other require statements +const app = express(); + +// Add the line below 👇 +app.use(auth()); +``` + +8. Find the `/` endpoint code and update it to require the `read:reports` scope in access tokens. This is done by adding a `requiredScopes` middleware, as shown below: + +```js +// lab-02/begin/api/api-server.js + +// Change only the line below 👇 +app.get('/', requiredScopes('read:reports'), (req, res) => { + + // ... leave the endpoint contents unchanged. + +}); +``` + +The next time you run your API, all requests that do not include a valid access token (expired token, incorrect scopes, etc.) will return an error instead of the desired data. + +9. Open the `api/.env` file you created before and change the `ISSUER_BASE_URL` value to your own Auth0 base URL (same as the one in your application). The `.env` file should look like this: + +```text +PORT=3001 +ISSUER_BASE_URL=https://your-tenant-name.auth0.com +ALLOWED_AUDIENCES=https://expenses-api +``` + +10. Once again, start the API server with npm: + +```bash +❯ npm start + +listening on http://localhost:3001 +``` + +To test your secured API, refresh the expenses page in your application - [localhost:3000/expenses](http://localhost:3000/expenses). If everything works as expected, you will still be able to access this view (which means that the web app is consuming the API on your behalf). If you browse directly to the API at [localhost:3001](http://localhost:3001), however, you will get an error saying the token is missing. + +
      +
      +
      + +Next → diff --git a/articles/identity-labs/02-calling-an-api/exercise-03.md b/articles/identity-labs/02-calling-an-api/exercise-03.md new file mode 100644 index 0000000000..7d0c5c465e --- /dev/null +++ b/articles/identity-labs/02-calling-an-api/exercise-03.md @@ -0,0 +1,140 @@ +--- +section: exercises +description: Auth0 digital identity Lab 2, Exercise 3: Working with Refresh Tokens +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 2, Exercise 3: Working with Refresh Tokens + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/02-calling-an-api) and read through the instructions before getting started. +::: + +
      + +
      +
      +
      +
      +
      +
      + +Right now, if your users stay logged in for too long and try to refresh the `/expenses` page, they will face a problem. Access tokens were conceived to be exchanged by different services through the network (which makes them more prone to leakage), so they should expire quickly. When an access token is expired, your API won't accept it anymore, and your web application won't be able to fetch the data needed. A token expired error will be returned instead. + +To change this behavior, you can make your web app take advantage of yet another token: the refresh token. A refresh token is used to obtain new access tokens and/or ID tokens from the authorization server. In this exercise, we're going to modify the application to obtain a refresh token and use it to get a new access token when it expires. + +1. Navigate to the [APIs screen](${manage_url}/#/apis) in your Auth0 Dashboard and open the API created in the last exercise. Scroll down, turn on the **Allow Offline Access** option, and click **Save**: + +![Allow API to grant offline access](/media/articles/identity-labs/lab-02-api-allow-offline.png) + +2. Now, Open the `webapp/server.js` file and add `offline_access` to the `authorizationParams.scope` field passed to the `auth()` middleware: + +```js +// webapp/server.js + +app.use(auth({ + required: false, + auth0Logout: true, + appSessionSecret: false, + authorizationParams: { + response_type: 'code id_token', + response_mode: 'form_post', + audience: process.env.API_AUDIENCE, + + // Change only the line below 👇 + scope: 'openid profile email read:reports offline_access' + + }, + + // ... keep the rest + +})); +``` + +3. Now, find the following line in the `/expenses` endpoint code and replace it with the following: + +```js +// webapp/server.js + +app.get('/expenses', requiresAuth(), async (req, res, next) => { + try { + + let tokenSet = req.openid.makeTokenSet(req.session.openidTokens); + + // Add the code block below 👇 + if (tokenSet.expired()) { + tokenSet = await req.openid.client.refresh(tokenSet); + tokenSet.refresh_token = req.session.openidTokens.refresh_token; + req.session.openidTokens = tokenSet; + } + + // ... keep the rest + } + // ... +}); +``` + +This change will update your endpoint to check if the `tokenSet` is expired. If it is, the `Issuer` class will create a client that is capable of refreshing the `tokenSet`. To see the refreshing process in action, you will have to make a small change to your Auth0 API configuration. + +4. Navigate to the [APIs screen](${manage_url}/#/apis) in your Auth0 Dashboard and open the API created in the last exercise. Set both the **Token Expiration (Seconds)** and **Token Expiration For Browser Flows (Seconds)** values to 10 seconds or less and click **Save**: + +![Access token expiration time](/media/articles/identity-labs/lab-02-api-token-expiration.png) + +5. Back in your editor, add a log statement to `api/api-server.js` to show when the new access token was issued: + +```js +// api/api-server.js + +app.get('/', requiredScopes('read:reports'), (req, res) => { + + // Add the line below 👇 + console.log(new Date(req.auth.claims.iat * 1000)); + + // ... +}); +``` + +6. Restart both the application and API (`[CTRL]` + `[c]`, then `npm start`). + +7. Log out and log in again. This will get you a complete set of tokens (ID token, access token, and refresh token). Note, at this point, you will see a new consent screen for the offline_access scope, which you need to accept. + +Open [localhost:3000/expenses](http://localhost:3000/expenses) in your browser and refresh the page. You will see that your API logs a timestamp in the terminal. The same timestamp will be logged every time you refresh the page as long as your token remains valid. Then, if you wait a few seconds (more than ten) and refresh the view again, you will see that your API starts logging a different timestamp, which corresponds to the new token retrieved. This shows that you are getting a different access token every ten seconds and that your web application uses the refresh token automatically to get them. + +::: note +If you see an error in your console about an ID token used too early, this is likely a clock skew issue in your local environment. Try restarting your machine and walking through the login steps again from the beginning. You can also try going to "Date & Time" settings, unlock them if needed by clicking on the lock icon at the bottom, and disable and re-enable the "Set date and time automatically" option. +::: + +::: note +If you don't see changes in the "Issued At" claim in the console, make sure you have logged out and logged in again after applying the changes above. +::: + +::: note +If you are using PowerShell in Windows and you see blank lines instead of the timestamp logging in the terminal, it could be the font color of the logs is the same as the background. As an alternative, you can run the API server from the Windows command line, or change the background color in PowerShell. +::: + +🎉 **You have completed Lab 2 by building a web application that calls an API with refresh capability!** 🎉 + +
      +
      +
      + +← All Identity Labs diff --git a/articles/identity-labs/02-calling-an-api/index.md b/articles/identity-labs/02-calling-an-api/index.md new file mode 100644 index 0000000000..9b636eda3f --- /dev/null +++ b/articles/identity-labs/02-calling-an-api/index.md @@ -0,0 +1,36 @@ +--- +section: exercises +description: Auth0 digital identity Lab 2: Calling an API +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 2: Calling an API + +This lab covers the process for adding sign-in to a basic Node.js application and calling an API. This lab is the same exercise we provide for new employees in a technical role here at Auth0. + +::: warning +The Node OIDC and bearer token npm packages that this lab uses has not been tested, licensed, or officially released and should not be used in production. +::: + +## Prerequisites + +- Read the introduction on the [main Identity Labs page](/labs/) +- Watch the [Calling an API video](/videos/learn-identity/04-calling-an-api) +- Read [Using Express Middleware](https://expressjs.com/en/guide/using-middleware.html) (optional) +- Read [Beginner's Guide to Using npm](https://nodesource.com/blog/an-absolute-beginners-guide-to-using-npm/) (optional) + +## What You'll Need + +<%= include('../_includes/_what-you-need') %> + +--- + +**For Windows users** - We recommend that you use the Windows PowerShell terminal (instead of the Windows command line) so that the terminal commands provided in the lab instructions work as they are. This is because the syntax of the commands used in the labs is the same for the Mac and PowerShell terminals. + +Start → diff --git a/articles/identity-labs/03-mobile-native-app/exercise-01.md b/articles/identity-labs/03-mobile-native-app/exercise-01.md new file mode 100644 index 0000000000..eddea08b18 --- /dev/null +++ b/articles/identity-labs/03-mobile-native-app/exercise-01.md @@ -0,0 +1,274 @@ +--- +section: exercises +description: Auth0 digital identity Lab 3, Exercise 1: Adding Authentication +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 3, Exercise 1: Adding Authentication + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/03-mobile-native-app) and read through the instructions before getting started. +::: + +In this exercise, you will add authentication to an existing iOS application. A simple iOS application has been provided to get you started. This is a single-view application with a button to launch the Auth0 authentication process. + +
      + +
      +
      +
      +
      +
      +
      +
      +
      + +1. Launch Xcode, go to **File > Open**, and open `/lab-03/exercise-01/begin/exercise-01.xcworkspace` in your locally-cloned copy of the [identity exercise repo](https://github.com/auth0/identity-102-exercises/). + +<%= include('../_includes/_git-clone-note') %> + +::: note +If the project complains about a missing dependency, you might have opened `exercise-01.xcodeproj` instead of `exercise-01.xcworkspace` (note the extension). +::: + +This project is a bare-bones application that imports the [Auth0.swift](https://github.com/auth0/auth0.swift) dependency to provide the OpenID Connect implementation. There is also a stub method called `actionLogin` for processing the touch of the login button. + +2. In the bar at the top of the project window, click the device selector and pick a late-model iPhone, then click the Play button (or **Product > Run** from the Xcode menu) to run the app. + +![Device simulator selection](/media/articles/identity-labs/lab-03-choose-device-and-run.png) + +The simulator may take a few moments to load the first time, and then you should see the following: + +![First time running iOS application](/media/articles/identity-labs/lab-03-first-run.png) + +3. Touch the **Log In** button. This will output a "Log In" message to the Debug area in Xcode. If you don’t see the Debug view, you can enable it with **View > Debug Area > Show Debug Area**. + +![iOS application debug console in Xcode](/media/articles/identity-labs/lab-03-first-debug-area.png) + +4. Before any calls are made to the Auth0 authorization server, you need to set up a new Auth0 Application for handling Native Applications. Log into the Auth0 Dashboard, go to the [Applications page](${manage_url}/#/applications), and click the **Create Application** button. + +5. Enter a descriptive name, select **Native** as the application type, and click **Create**. + +6. Click on the **Settings** tab and scroll down to the **Allowed Callback URLs** field. Enter the value below (modified with your tenant domain): + +```text +com.auth0.identity102://${account.namespace}/ios/com.auth0.identity102/callback +``` + +7. Scroll down and click **Show Advanced Settings**, then **OAuth**. Make sure **JsonWebToken Signature Algorithm** is set to `RS256`. + +8. Click **Save Changes** + +You might be wondering why the callback URL is in this format. There are two parts to this: + +- The first element is the scheme of the application, which for the purposes of this exercise, is defined as `com.auth0.identity102`. Whenever Safari needs to handle a request with this scheme, it will route it to our application (you will set up this custom URL scheme URL later in the lab). +- The rest of the URL is in a format that the Auth0.swift SDK specifies for callbacks. + +9. Now the sample iOS application needs to be configured with the **Client ID** and **Domain** values from the Auth0 Application. Return to Xcode and open the `exercise-01/Auth0.plist` file. You should see value placeholders for **ClientId** and **Domain**. Replace these with the values from the Auth0 Application created above. + +![iOS application plist values](/media/articles/identity-labs/lab-03-plist.png) + +::: note +The domain must not have any prefix like in the previous labs. Enter it exactly as it is provided in the Auth0 dashboard. +::: + +To be able to use the callback that was configured in the Auth0 dashboard, a URL scheme handler needs to be registered in our iOS application so that it can respond to requests made to the callback URL. + +10. In the file navigator on the left, click on `exercise-01` to open the project settings, then click on the **Info** tab. + +![Project settings for iOS application](/media/articles/identity-labs/lab-03-project-settings-info-tab.png) + +11. Scroll down to **URL Types**, expand the section, click the **+** button, and enter or select the following details: + +- **Identifier**: `auth0` +- **URL Schemes**: `$(PRODUCT_BUNDLE_IDENTIFIER)` +- **Role**: `None` + +Just as `http` is a URL Scheme that will launch a browser, the bundle identifier of the app has a URL Scheme (which will resolve to `com.auth0.identity102`) will tell iOS that any time this scheme is used in a URL, it must be routed to our application. That will be the case of the callback used by Auth0 after you log in. + +12. Now, the application needs to have the Auth0.swift SDK handle the callback in order to proceed with the authentication flow. In the Project Navigator on the left, open `exercise-01/AppDelegate.swift` and add the following import statement just below the other one: + +```swift +// exercise-01/AppDelegate.swift + +import UIKit + +// Add the line below 👇 +import Auth0 +``` + +13. In the same file, add the following method inside the `AppDelegate` class: + +```swift +// exercise-01/AppDelegate.swift +// ... +class AppDelegate: UIResponder, UIApplicationDelegate { + + var window: UIWindow? + + // Add the code below 👇 + func application(_ + app: UIApplication, + open url: URL, + options: [UIApplication.OpenURLOptionsKey : Any] + ) -> Bool { + return Auth0.resumeAuth(url, options: options) + } + + // ... other existing methods +} +``` + +When another app requests a URL containing the custom scheme, the system will launch your app if necessary, bring it to the foreground, and call the method above. The iOS Framework provides the delegate method above for you to implement so that you can parse the contents of the URL and take appropriate action. In this case, you need this information to continue the authentication flow process. You will see later in this exercise why this step is needed. + +Now that the iOS application is configured with your Auth0 application credentials and is able to receive and process callbacks, complete the following steps to see how to construct the OpenID Connect request to the authorization server. + +14. Open `exercise-01/ViewController.swift` and add the following code inside the `actionLogin` method, after the line that prints the "Log In" message to the console: + +```swift +// exercise-01/ViewController.swift +// ... + @IBAction func actionLogin(_ sender: Any) { + print("Log In") + + // Add the code below 👇 + Auth0 + .webAuth() + .scope("openid profile email") + .logging(enabled: true) + .start { response in + switch(response) { + case .success(let result): + print("Authentication Success") + print("Access Token: \(result.accessToken ?? "No Access Token Found")") + print("ID Token: \(result.idToken ?? "No ID Token Found")") + case .failure(let error): + print("Authentication Failed: \(error)") + } + } + } +// ... +``` + +15. Run the app again by clicking the Play button (or **Product > Run** from the Xcode menu). Once the app has launched, touch the **Log In** button. You should see a permission prompt from iOS. Touch **Continue** to proceed to the Auth0 login page, which is rendered within a browser. + +![Universal login page loaded](/media/articles/identity-labs/lab-03-login-confirmation.png) + +16. Log in using your database user, and you will be taken back to the app. Nothing will have changed visually, but if you take a look at the Debug Area in Xcode you will see something like this: + +```text +Authentication Success +Access Token: vxPp0Xtg3wkZJudFZWzqMQByYF98Qyer +ID Token: eyJ0eX[..].eyJodH[..].kLtZDg[..] +``` + +To view the contents of your ID Token, you can copy and paste it into [jwt.io](https://jwt.io/) to view the claims. + +Now that you have an ID token, it's important to validate it to ensure that it can be trusted. A helper method `isTokenValid` is already included in the project; you can review its code in `Extras/Utils.swift` to learn how the validation is performed. It should be called after obtaining the token, to illustrate how it is used. + +17. Back in the `actionLogin` method in `ViewController.swift`, add the line below: + +```swift +// exercise-01/ViewController.swift +// ... + + @IBAction func actionLogin(_ sender: Any) { + print("Log In") + + Auth0 + // ... + case .success(let result): + // ... other print statements + + // Add the line below 👇 + print("ID Token Valid: \(isTokenValid(result.idToken!))") + + // ... failure case + } + } +// ... +``` + +18. Run the app again, log in, and take a look at the logs in Xcode. You should see an entry "ID Token Valid:" with the status of the validation (true or false). + +Congratulations! You have successfully added Auth0 authentication to your native iOS app using an authorization code grant! + +The authorization code grant by itself 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. The Proof Key for Code Exchange (PKCE) is a technique used to mitigate this authorization code interception attack. + +With PKCE, for every authorization request, the application creates a cryptographically random key called the **code verifier**, hashes that value into a **code challenge**, and sends the **code challenge** to the authorization server to get the authorization code. When the application receives the code after a successful login, it will send the code and the code verifier to the token endpoint to exchange them for the requested tokens. + +Since you previously enabled logging in our `WebAuth` call with the `logging()` method, it is easy to see the process flow in the Debug Area. + +19. Run the iOS Application, touch the **Log In** button, and then take a look at the Debug Area. The iOS application initiates the flow and redirects the user to the `/authorize` endpoint, sending the `code_challenge` and `code_challenge_method` parameters. It also sends a `response_type` of `code` (line breaks added below for readability): + +```text +SafariAuthenticationSession: +https://${account.namespace}/authorize +?code_challenge=VsPaQ0gJjnluA2vwV0piY-D-DTCltGI9GbYkBNHvPHQ +&response_type=code +&redirect_uri=com.auth0.identity102://${account.namespace}/ios/com.auth0.identity102/callback +&state=RFnNyPj4NOZMUW8IpDBr-j3UgO4gCbhBZtLpWB_vmDo +&client_id=${account.clientId} +&scope=openid%20profile +&code_challenge_method=S256 +&auth0Client=eyJzd2lmdC12ZXJzaW9uIjoiMy4wIiwibmFtZSI6IkF1dGgwLnN3aWZ0IiwidmVyc2lvbiI6IjEuMTMuMCJ9 +``` + +20. Once again, enter your credentials and log in. Auth0 redirects the user back to the iOS application by calling the callback with the authorization code in the query string: + +```text +iOS Safari: +com.auth0.identity102://${account.namespace}/ios/com.auth0.identity102/callback +?code=6SiMHrJHbG2aAPrj +&state=RFnNyPj4NOZMUW8IpDBr-j3UgO4gCbhBZtLpWB_vmDo +``` + +21. The Auth0.swift SDK will process the query string and send the authorization `code` and `code_verifier` together with the `redirect_uri` and the `client_id` to the token endpoint of the authorization server: + +```text +POST /oauth/token + +{"grant_type":"authorization_code", +"redirect_uri":"com.auth0.identity102:\/\/${account.namespace}\/ios\/com.auth0.identity102\/callback", +"code":"6SiMHrJHbG2aAPrj", +"code_verifier":"qiV8gYUrPco3qBlejLeZzgC9DMtXZY1GddzZpmVxyxw", +"client_id":"${account.clientId}"} +``` + +22. The authorization server validates this information and returns the requested access and ID tokens. If successful, you will see the following response containing your tokens: + +```text +Content-Type: application/json + +{"access_token":"ekhGPSE7xdhOTJuTo2dV-TYyJV-OTYrO", +"id_token":"eyJ0eX[..].eyJodH[..].1kZccn[..]", +"expires_in":86400, +"token_type":"Bearer"} +``` + +In the next exercise, you will use a token to validate and authorize the user and authorize against a protected API. + +
      +
      +
      + +Next → diff --git a/articles/identity-labs/03-mobile-native-app/exercise-02.md b/articles/identity-labs/03-mobile-native-app/exercise-02.md new file mode 100644 index 0000000000..c0a673e7d9 --- /dev/null +++ b/articles/identity-labs/03-mobile-native-app/exercise-02.md @@ -0,0 +1,340 @@ +--- +section: exercises +description: Auth0 digital identity Lab 3, Exercise 2: Calling a Secured API +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - concept +--- +# Lab 3, Exercise 2: Calling a Secured API + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/03-mobile-native-app) and read through the instructions before getting started. +::: + +In this exercise, you are going to enable the native application to authorize against the protected API backend that was built in [Lab 2, Exercise 2](/identity-labs/02-calling-an-api/exercise-02). In that lab, you set up an Auth0 API server for your Expenses API with an audience value of `https://expenses-api`. + +
      + +
      +
      +
      +
      +
      +
      + + +If you have already completed lab 2, you can use the same Auth0 configuration and local files to run the API needed for this lab. Just go to `/lab-02/begin/api` in your locally-cloned copy of the [identity exercise repo](https://github.com/auth0/identity-102-exercises/) and run `npm start` in your terminal before beginning this exercise. Make sure your token expiration times in Auth0 are back to normal (at least an hour for both). + +::: panel If you did not complete Lab 2 +If you are doing this lab by itself, you can use the completed exercise sample code: + +1. Go to `/lab-02/end/api` and run `npm install` in your terminal. + +2. Follow steps 1-3 on [this page](/identity-labs/02-calling-an-api/exercise-02) to create an API in Auth0. + +3. Create a copy of the `.env` file in the same directory as above, change the `ISSUER_BASE_URL` value to include your tenant name, and save the file. + +4. Back in the terminal, run `npm start`. + +```bash +# Starting from the Lab 3 begin folder... +❯ cd ../../../lab-02/end/api + +❯ pwd +/Users/username/identity-102-exercises/lab-02/end/api + +❯ cp .env-sample .env + +❯ vim .env +# Change the ISSUER_BASE_URL value ... + +❯ npm install + +added XX packages in X.XXs + +❯ npm start + +listening on http://localhost:3001 +``` + +::: + +Regardless of which API codebase you're using, you should now be able to load [localhost:3001](http://localhost:3001/) in your browser and see an error saying `UnauthorizedError: bearer token is missing`. + +5. For this exercise, we're going to open a different project in Xcode than the one we used in exercise 1. Go to **File > Open** in Xcode and select `lab-03/exercise-02/begin/exercise-02.xcworkspace` (make sure you pick the right file extension), then open `exercise-02/ViewController.swift`. This code picks up where the previous exercise left off and adds a new button to call the API. + +6. Open the `exercise-02/Auth0.plist` file and replace the placeholder values for **ClientId** and **Domain** with the ones from the Auth0 Application created before. + +7. Click the Play button (or **Product > Run** from the Xcode menu) to run the app. + +![iOS application Call API button](/media/articles/identity-labs/lab-03-call-api-button.png) + +8. Touch the **Call API** button, and you should see a "Call API" message in the Debug area in Xcode. + +![Call API debug message in Xcode console](/media/articles/identity-labs/lab-03-call-api-debug-area.png) + +You will now add code to make the API call from the mobile app. However, before doing so, you need to modify the authentication code to include the API's audience for authorization and the necessary scopes so that the required permissions are requested. + +9. In the `actionLogin` method, which contains our authentication call, include the audience for the API we want to access. With this in place, there will be an additional audience inside the access token after successful authentication. + +```swift +// exercise-02/ViewController.swift +// ... + + @IBAction func actionLogin(_ sender: Any) { + Auth0 + .webAuth() + .scope("openid profile") + + // Add the line below 👇 + .audience("https://expenses-api") + + // ... + } + } +// ... +``` + +10. Run the app from Xcode again, click **Log In**, and check the debug logs. You should see a block of output like below: + +```text +Authentication Success +Access Token: eyJ0eXA[..].eyJpc3[..].XeiZaS[..] +ID Token: eyJ0eXA[..].eyJodH[..].Lv1TY8[..] +Token Valid: true +``` + +11. Copy and paste the value of the **Access Token** into [jwt.io](https://jwt.io). Notice the `scope` value of `openid profile`. In Lab 2, the additional scope `read:reports` was added, which is not present in the token yet: + +```js +{ + "iss": "https://${account.namespace}/", + "sub": "auth0|1234567890", + "aud": [ + + // New audience 👇 + "https://expenses-api", + "https://${account.namespace}/userinfo" + ], + "iat": 1566840738, + "exp": 1566840746, + "azp": "${account.clientId}", + + // Existing scopes 👇 + "scope": "openid profile" +} +``` + +12. Now, add the `read:reports` scope to the parameter in the `scope()` method within `actionLogin`: + +```swift +// exercise-02/ViewController.swift +// ... + + @IBAction func actionLogin(_ sender: Any) { + Auth0 + .webAuth() + + // Replace this line ❌ + // .scope("openid profile") + + // ... with the line below 👇 + .scope("openid profile read:reports") + + // ... + } + } +``` + +13. Run the app again, log in, and check the access token in [jwt.io](https://jwt.io) once more. You should now see the `read:reports` scope in the payload. It’s time to make a call to the API! + +14. To use the access token we obtained during login in the `actionAPI` method, you need a way to access this variable. Create a private variable in the `ViewController` class: + +```swift +// exercise-02/ViewController.swift +// ... +import Auth0 + +class ViewController: UIViewController { + + // Add the line below 👇 + private var accessToken: String? + + // ... +} +``` + +15. In the `.success` code block of the `actionLogin` method, set the new `accessToken` value to be what was returned from the token endpoint: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionLogin(_ sender: Any) { + // ... + case .success(let result): + // ... + + // Add the line below 👇 + self.accessToken = result.accessToken + + case .failure(let error): + // ... + } +// ... +``` + +16. In the `actionAPI` method in the same class, check that the user has authenticated and that you have an access token before making a call to the API: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionAPI(_ sender: Any) { + print("Call API") + + // Add the code below 👇 + guard let accessToken = self.accessToken else { + print("No Access Token found") + return + } + } +// ... +``` + +Here, you are assigning the class-scoped property `accessToken` to a local `accessToken` variable. If the class-scoped property is empty, an error will be returned. + +17. Again in the `actionAPI` method, add the code below to start an API request: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionAPI(_ sender: Any) { + // ... code from above + + // Add the code below 👇 + let url = URL(string: "http://localhost:3001")! + var request = URLRequest(url: url) + } +// ... +``` + +::: note +If your API is running on a different port or URL, make sure to change that above. +::: + +18. You also need a way to send the access token to the API. This is done by adding an HTTP Authorization request header: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionAPI(_ sender: Any) { + // ... code from above + + // Add the code below 👇 + request.addValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization") + request.log() + } +// ... +``` + +19. Finally, the request needs to be executed. You will use the functionality built into the iOS framework - `URLSession` - to perform the network operation: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionAPI(_ sender: Any) { + // ... code from above + + // Add the code below 👇 + let task = URLSession.shared.dataTask(with: request) { + data, response, error in + print(response ?? "No Response") + } + task.resume() // Execute the request + } +// ... +``` + +20. Let's try calling the API from our mobile app. Save your changes from above, run the app, and tap **Log In**. After successfully authenticating, tap the **Call API** button and check the logs in the Debug area for the API response: + +```text +Call API +GET http://localhost:3001 +Headers: + Optional(["Authorization": "Bearer eyJ0eX[..].eyJpcM[..].dpN8sK[..]"]) + { URL: http://localhost:3001/ } { Status Code: 200, Headers { + Connection = ( + "keep-alive" + ); + "Content-Length" = ( + 195 + ); + "Content-Type" = ( + "application/json; charset=utf-8" + ); + Date = ( + "Tue, 27 Aug 2019 14:53:40 GMT" + ); + Etag = ( + "W/\"c3-oBamo6wQLwSzwYwQczXJ+w5tl5o\"" + ); + "X-Powered-By" = ( + Express + ); +} } +``` + +The `Status Code: 200` (OK) lets us know the request was executed successfully. If you want to see it fail, simply comment out the line that adds the Authorization Bearer header, re-rerun the app, and try logging in again. You will see a `Status Code: 401` (Unauthorized). + +21. You can see from the `Content-Length` header that there is a body in the response; output the raw data from the API by updating the `dataTask` closure with the following code: + +```swift +// exercise-02/ViewController.swift +// ... + @IBAction func actionAPI(_ sender: Any) { + // ... code from above + + let task = URLSession.shared.dataTask(with: request) { + data, response, error in + print(response ?? "No Response") + + // Add the code below 👇 + if let data = data { + print(String(data: data, encoding: .utf8) ?? "No Body") + } + } + // ... + } +// ... +``` + +22. Re-run the app, login, and call the API once more. You should now see the expenses in the debug area in Xcode: + +```js +[{"date":"2019-08-27T15:02:04.838Z","description":"Pizza for a Coding Dojo session.","value":102}, +{"date":"2019-08-27T15:02:04.838Z","description":"Coffee for a Coding Dojo session.","value":42}] +``` + +You have now integrated your native application frontend with a protected API backend! In the next exercise, you will look at how the access token can be refreshed without having the user go through the web-based authentication flow each time. + +
      +
      +
      + +Next → diff --git a/articles/identity-labs/03-mobile-native-app/exercise-03.md b/articles/identity-labs/03-mobile-native-app/exercise-03.md new file mode 100644 index 0000000000..1cf3321b8e --- /dev/null +++ b/articles/identity-labs/03-mobile-native-app/exercise-03.md @@ -0,0 +1,232 @@ +--- +section: exercises +description: Auth0 digital identity Lab 3, Exercise 3: Working with Refresh Tokens +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 3, Exercise 3: Working with Refresh Tokens + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/03-mobile-native-app) and read through the instructions before getting started. +::: + +In this exercise, you will explore the use of refresh tokens. A refresh token is a special kind of token that can be used to obtain a renewed access token. You are able to request new access tokens until the refresh token is blacklisted. It’s important that refresh tokens are stored securely by the application because they essentially allow a user to remain authenticated forever. + +
      + +
      +
      +
      +
      +
      +
      + +For native applications such as our iOS application, 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. + +1. Go to **File > Open** in Xcode and select `lab-03/exercise-03/begin/exercise-03.xcworkspace` (make sure you pick the right file extension), then open `exercise-03/ViewController.swift`. This code picks up where the previous exercise left off and adds a new button to refresh the access token. + +2. Open the `exercise-03/Auth0.plist` file and replace the placeholder values for **ClientId** and **Domain** with the ones from the Auth0 Application created before. + +3. Click the Play button (or **Product > Run** from the Xcode menu) to run the app. Touch the **Refresh Token** button and look for a “Refresh Token” message to the Debug area in Xcode. + +![Refresh token button in iOS application](/media/articles/identity-labs/lab-03-refresh-token-button.png) + +You are now going to add the `offline_access` scope, which gives the iOS application access to resources on behalf of the user for an extended period of time. Before you can use this scope, you need to make sure that Auth0 will allow applications to ask for refresh tokens for your API. + +4. Navigate to the [APIs screen in your Auth0 Dashboard](${manage_url}/#/apis). Open the API that you created to represent your expenses API and ensure the **Allow Offline Access** option is on. + +![Allow offline access for API](/media/articles/identity-labs/lab-03-allow-offline-access.png) + +5. Next, we're going to add the `offline_access` scope to the authentication request. Open `exercise-03/ViewController.swift` and, in the `actionLogin` method, add `offline_access` to the `.scope()` method. + +```swift +// exercise-03/ViewController.swift +// ... + @IBAction func actionLogin(_ sender: Any) { + Auth0 + .webAuth() + + // Replace this line ❌ + // .scope("openid profile read:reports") + + // ... with the line below 👇 + .scope("openid profile read:reports offline_access") + + // ... + } + } +// ... +``` + +6. Click the Play button (or **Product > Run** from the Xcode menu) to run the app. Log in again and check the Debug area in Xcode for the response. + +```js +{ + "access_token":"3tjDJ3hsFOSyCr02spWHUhHNajxLRonv", + + // Here is the refresh token we asked for 👇 + "refresh_token":"sAvc4BJyOGs2I6Yc4e6r9NmReLp0kc-I6peiauDEt-usE", + + "id_token": "eyJ0eX[..].eyJodH[..].thhf0M[..]", + "expires_in": 86400, + "token_type": "Bearer" +} +``` + +7. We're going to send the refresh token to the authorization server using a `refresh_token` grant to get a new access token. In `ViewController.swift` and create a private variable in the `ViewController` class to create a way for `actionRefresh` method to access the refresh token. + +```swift +// exercise-03/ViewController.swift +// ... +class ViewController: UIViewController { + + private var accessToken: String? + + // Add the line below 👇 + private var refreshToken: String? + + // ... +} +// ... +``` + +8. Assign the refresh token obtained during authentication to this private variable in the `.success` code block. + +```swift +// exercise-03/ViewController.swift +// ... + @IBAction func actionLogin(_ sender: Any) { + // ... + case .success(let result): + // ... + self.accessToken = result.accessToken + + // Add the line below 👇 + self.refreshToken = result.refreshToken + + case .failure(let error): + // ... + } +// ... +``` + +9. In the `actionRefresh` method, check that the user has authenticated and that a refresh token is available before making any calls to the authentication API. In the code below, the class-scoped property `refreshToken` is assigned to a local `refreshToken` variable. If the class-scoped property is empty, an error will be returned. + +```swift +// exercise-03/ViewController.swift +// ... + @IBAction func actionRefresh(_ sender: Any) { + print("Refresh Token") + + // Add the code below 👇 + guard let refreshToken = self.refreshToken else { + print("No Refresh Token found") + return + } + } +// ... +``` + +10. The Auth0.swift SDK makes available a `.renew()` method, which takes a refresh token as a parameter and performs a call to the authorization server's token endpoint using the `refresh_token` grant. Add the following code to the `actionRefresh` method after the code from the previous step. + +```swift +// exercise-03/ViewController.swift +// ... + @IBAction func actionRefresh(_ sender: Any) { + // ... code from the previous steps + + // Add the code below 👇 + Auth0 + .authentication() + .logging(enabled: true) + .renew(withRefreshToken: refreshToken) + .start { response in + switch(response) { + case .success(let result): + print("Refresh Success") + print("New Access Token: \(result.accessToken ?? "No Access Token Found")") + self.accessToken = result.accessToken + case .failure(let error): + print("Refresh Failed: \(error)") + } + } + } +// ... +``` + +11. Click the Play button (or **Product > Run** from the Xcode menu) to re-run the app. Tap **Log In** and, after successful authentication, touch the **Refresh Token** button. Look in the Xcode the debug area for the request. You should see a `POST` to the token endpoint, showing the refresh token grant in action. + +```text +POST https://${account.namespace}/oauth/token HTTP/1.1 +Auth0-Client: eyJuYW1lIjoiQXV0aDAuc3dpZnQiLCJ2ZXJzaW9uIjoiMS4xMy4wIiwic3dpZnQtdmVyc2lvbiI6IjMuMCJ9 +Content-Type: application/json + +{"grant_type":"refresh_token","client_id":"${account.clientId}","refresh_token":"2CNxaPe0UIkX_PZkLEkKuoAuRsP6Ycg81XR1jQlTyn1dt"} +``` + +12. Look for the response after the request above. You should see a response including a new `access_token`, new `id_token`, and a new `expires_in` time (some of the trace was omitted for brevity). + +```text +HTTP/1.1 200 +Content-Type: application/json +Date: Tue, 27 Aug 2019 16:25:26 GMT +x-ratelimit-remaining: 29 +x-ratelimit-reset: 1566923126 +x-ratelimit-limit: 30 +Content-Length: 1923 + +{"access_token":"eyJ0eX[..].eyJpc3[..].Smqrd7[..]", +"id_token":"eyJ0eX[..].eyJua[..].Ff5Q5[..]", +"scope":"openid profile read:reports offline_access", +"expires_in":3600,"token_type":"Bearer"} +``` + +Notice that you don’t receive a new `refresh_token` in the response from the authorization server. The `refresh_token` from the initial authentication must be retained. Also, note that in the code added to the `actionRefresh` method the `access_token` received is stored in the `self.accessToken` class property. This is so the new access token can be used in other methods. If you try calling the API again, the request will be made with your new access_token. + +Now that you are able to obtain a fresh access token by using the refresh token, it’s time to see what happens when a token expires. + +13. Navigate to the [APIs screen in your Auth0 Dashboard](${manage_url}/#/apis) and open the expenses API. Set both the **Token Expiration** and the **Token Expiration For Browser Flows** fields to 10 seconds and save the changes. + +14. In your app simulator, tap **Log In** to walk through the authentication process again and get a new access token with the shorter expiration. Immediately tap the **Call API** button to see the API call succeed. + +15. Wait 10 seconds for the token to expire and click the **Call API** button again. You should see the API call fail with a `Status Code: 401` in the debug area. + +```text + { URL: http://localhost:3001/ } { Status Code: 401, Headers { + Date = ( + "Tue, 27 Aug 2019 16:36:10 GMT" + ); + "www-authentication" = ( + "Bearer realm=\"api\", error=\"invalid_token\", error_description=\"invalid token\"" + ); +} } +``` + +16. Tap **Refresh Token** and check the debug area to see the refresh token grant happen. Then, tap **Call API**, and you should get a `Status Code: 200` along with the expenses data again. + +🎉 **You have completed Lab 3 by building a native mobile application calling a secure API with refresh capability!** 🎉 + +
      +
      +
      + +← All Identity Labs diff --git a/articles/identity-labs/03-mobile-native-app/index.md b/articles/identity-labs/03-mobile-native-app/index.md new file mode 100644 index 0000000000..f872387025 --- /dev/null +++ b/articles/identity-labs/03-mobile-native-app/index.md @@ -0,0 +1,37 @@ +--- +section: exercises +description: Auth0 digital identity Lab 3: Mobile Native App +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 3: Mobile Native App + +## Prerequisites + +- Read the introduction on the [main Identity Labs page](/labs/) +- Watch the [Desktop and Mobile Apps video](/videos/learn-identity/05-desktop-and-mobile-apps) +- Apple's [Developing iOS Apps: Build a Basic UI](https://developer.apple.com/library/archive/referencelibrary/GettingStarted/DevelopiOSAppsSwift/BuildABasicUI.html) tutorial to get a feeling of the Xcode's UI (optional) + +## What You'll Need + +**A Mac computer** - A Mac is required to install Xcode. + +--- + +**An Apple account** - Required to download Xcode and install Xcode. + +--- + +**Xcode** - Download and install Xcode from the App Store. After installation is complete, open it so that you go through the first-time setup, which can take up to 10 minutes. This will require around 6GB of hard drive space and up to 30 minutes total to complete. + +--- + +<%= include('../_includes/_what-you-need') %> + +Start → diff --git a/articles/identity-labs/04-single-page-app/exercise-01.md b/articles/identity-labs/04-single-page-app/exercise-01.md new file mode 100644 index 0000000000..5318d93499 --- /dev/null +++ b/articles/identity-labs/04-single-page-app/exercise-01.md @@ -0,0 +1,366 @@ +--- +section: exercises +description: Auth0 digital identity Lab 4, Exercise 1: Adding Sign On +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 4, Exercise 1: Adding Sign On + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/04-single-page-app) and read through the instructions before getting started. +::: + +In this lab, you will learn how to add sign-on capabilities to a Single-Page Application (SPA) and how to make this app consume an API that is secured with Auth0. You will integrate the SPA with Auth0 so that your users are able to use the Auth0 Universal Login Page to authenticate. + +The SPA in question is a vanilla JavaScript application that consumes an API similar to the one you have used in previous labs (this API also exposes a secured endpoint that returns a list of expenses). The difference is that the API in this lab does two additional things: + +- The API supports CORS to enable the SPA to consume it from a different domain (or a different port in a local environment). +- The API exposes a public endpoint that returns a summary of its database. The SPA consumes this endpoint on its homepage to share the summary publicly. + +In this exercise, you will focus on integrating the SPA with Auth0 and getting the profile of the logged-in user. Exercise 2 will show how to consume the private endpoint exposed by the API. + +
      + +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      + +1. First, you will run a version of the app that is not integrated with Auth0. Open a new terminal and browse to `/lab-04/exercise-01/begin/api` in your locally-cloned copy of the [identity exercise repo](https://github.com/auth0/identity-102-exercises/). This is where the code for your API resides. Install the dependencies using npm. + +```bash +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-04/exercise-01/begin/api + +❯ npm install +# Ignore any warnings + +added XX packages in X.XXs +``` + +2. Make a copy of the `.env-sample` file and name it `.env`. + +```bash +❯ cp .env-sample .env +``` + +3. Edit the new `.env` file to add your tenant domain and save the file. + +```text +PORT=3001 +ISSUER_BASE_URL=https://${account.namespace} +ALLOWED_AUDIENCES=https://expenses-api +``` + +4. Run the API: + +```bash +❯ npm start +``` + +5. Open a new terminal in the `/lab-04/exercise-01/begin/spa` folder and run `http-server` to host the SPA. + +```bash +# Navigating from the previous directory +❯ cd ../spa + +# Make sure we're in the right directory +❯ pwd +/Users/username/identity-102-exercises/lab-04/exercise-01/begin/spa + +❯ npx http-server . -p 5000 -c-1 +npx: installed 26 in 3.459s +Starting up http-server, serving . +Available on: + http://127.0.0.1:5000 + http://10.10.10.10:5000 + http://192.168.1.4:5000 +Hit CTRL-C to stop the server +``` + +::: note +On the command above, `-p 5000` makes the server listen on port 5000, and `-c-1` makes browsers ignore their own cache. This last parameter is important to facilitate the development process. +::: + +6. Open [localhost:5000](http://localhost:5000) in a web browser, and you should see the page below. If you do not see the App Summary section, make sure your API is properly running at port 3001. + +![Initial load for single-page application](/media/articles/identity-labs/lab-04-initial-load.png) + +This is the homepage of your SPA. Right now, this SPA has no integration with Auth0. Also, the app is only consuming the public endpoint provided by the API. This endpoint returns two pieces of information: the total number of expenses recorded in the database (two, in this case), and the sum of their amount ($144.00). The SPA is using this information to feed the "App Summary" section of the page you are seeing. + +7. To register this SPA with Auth0, log into the Auth0 Dashboard, go to the [Applications page](${manage_url}/#/applications), and click the **Create Application** button. + +8. Set a descriptive name (e.g., "Identity Lab 4 - Single Page App"), choose **Single Page Web Application** for the type, and click **Create**. + +9. You should now see the Quickstart section that describes how to integrate Auth0 with a production application. Click the **Settings** tab at the top to see the Application settings. + +10. Add `http://localhost:5000/#callback` to the **Allowed Callback URLs** field. Auth0 will allow redirects **only** to the URLs in this field after authentication. If the one provided in the authorization URL does not match any in this field, an error page will be displayed. + +11. Add `http://localhost:5000` to the **Allowed Web Origins** field. This field defines what URLs will be able to issue HTTP requests to Auth0 during a [silent authentication process](https://auth0.com/docs/api-auth/tutorials/silent-authentication). Your SPA will leverage this mechanism to check whether the current browser has an active session on the Auth0 authorization server. + +12. Add `http://localhost:5000` to the **Allowed Logout URLs** field. Auth0 will allow redirects **only** to the URLs in this field after logging out of the authorization server. + +13. Scroll down and click **Show Advanced Settings**, then **OAuth**. Make sure **JsonWebToken Signature Algorithm** is set to `RS256`. + +14. Scroll down and click **Save Changes** + +Now that you have registered your SPA with Auth0, you can update your code to integrate both. Below is a summary of the steps you will execute: + +- Import [auth0-spa-js](https://github.com/auth0/auth0-spa-js) and configure it with your own Auth0 settings. +- Add code to handle the authentication callback. +- Add code to restrict content to authenticated users only. +- Implement login and logout. +- Obtain and display user profile information. + +The [auth0-spa-js](https://github.com/auth0/auth0-spa-js) SDK is a simple, lightweight, and opinionated client developed by Auth0 that executes the OAuth 2.0 Authorization Code Grant Flow with PKCE. This client allows developers to quickly and securely implement authentication in their browser-based applications. + +15. Open the `spa/index.html` file and search for the ` + + + + +``` + +16. Open `spa/app.js`. This file contains the code that starts your SPA in the browser. At the top of it, you will see several constants that reference DOM elements. Right after those definitions, add the variable declaration to allow `auth0Client` to be used globally. + +```js +// spa/app.js +// ... other constants +const loadingIndicator = document.getElementById('loading-indicator'); + +// Add the line below 👇 +let auth0Client; +``` + +17. In the `window.onload` function, add the code that configures the auth0-spa-js library with your own Auth0 details. Replace both placeholders with the **Domain** and **Client ID** properties for your SPA Application in Auth0. + +```js +// spa/app.js +// ... + +window.onload = async function() { + let requestedView = window.location.hash; + + // Add the code below 👇 + auth0Client = await createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}' + }); + + // ... +}; +``` + +18. Implement the authentication callback after the snippet above in the `window.onload` function. + +```js +// spa/app.js +// ... + +window.onload = async function() { + // ... code from the previous step + + // Add the code below 👇 + if (requestedView === '#callback') { + await auth0Client.handleRedirectCallback(); + window.history.replaceState({}, document.title, '/'); + } + + // ... +}; +``` + +The `requestedView` variable is used to identify if the request in question refers to a user coming back from the authentication process (i.e., if this is a user being redirected back to the application by Auth0 after authenticating). + +19. Restrict site content to authenticated users only by finding the `allowAccess` function definition (at the bottom of the file) and replacing it with an authentication check. + +```js +// spa/app.js +// ... + +/* Replace the code below ❌ +async function allowAccess() { + await loadView('#home', content); + return false; +} +*/ + +// ... with this 👇 +async function allowAccess() { + if (await auth0Client.isAuthenticated()) { + return true; + } + await loadView('#home', content); + return false; +} +``` + +The goal of this function is to allow or deny access to whatever route calls it. This function is called from the `#expenses` route to ensure the user is logged in. Although you won't use that route on this exercise (only on the next one), you can check the code in the `spa/scripts/expenses.js` file. The previous version of this function was hardcoded always to deny access and redirect to the #home route because no authentication mechanism was in place yet. + +You are now making use of the `isAuthenticated()` method provided by the SPA SDK to block unauthenticated users from accessing the route calling this function. If an anonymous user tries to access it, the app will detect that they are not authenticated and will redirect them back to the homepage. + +20. To give users a way to log in and view restricted content, open the `spa/scripts/navbar.js` file. There, you will see the definition of a few constants within the `async function()` [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE). Below that, we'll add code to handle a click event on the login button. + +```js +// spa/scripts/navbar.js +(async function() { + // ... other constants + const logOutButton = document.getElementById('log-out'); + + // Add the code below 👇 + logInButton.onclick = async () => { + await auth0Client.loginWithRedirect({ + redirect_uri: 'http://localhost:5000/#callback' + }); + }; + +})(); +``` + +The logInButton button will now, when clicked, invoke the `loginWithRedirect()` method provided by the SPA SDK to start the authentication process. When users click the login button, they will be redirected to the authorization server. + +The `redirect_uri` property passed to the `loginWithRedirect()` method defines the URL that Auth0 must call after the authentication phase is concluded. This is the same URL listed in the **Allowed Callback URLs** field in the Auth0 Dashboard. If you use another URL without whitelisting it first, Auth0 will show an error page. + +21. To define what happens when users click the logout button, add the code below right after the code from the previous step in the same function. + +```js +// spa/scripts/navbar.js +(async function() { + // ... code from the previous example + + // Add the code below 👇 + logOutButton.onclick = () => { + auth0Client.logout({ + returnTo: 'http://localhost:5000' + }); + }; + +})(); +``` + +In this case, you are making the `logOutButton` button invoke the `logout()` method provided by the SPA SDK to end the user's Auth0 session. The `returnTo` property passed to this method works similar to the `redirect_uri` passed to the `loginWithRedirect()` method. This logout return URL was whitelisted in your Auth0 Application using the **Allowed Logout URLs** field. + +22. Now, you will implement the behavior in your application that depends on whether the user is authenticated or not. After the code from the previous step, add the following code: + +```js +// spa/scripts/navbar.js +(async function() { + // ... code from the previous example + + // Add the code below 👇 + const isAuthenticated = await auth0Client.isAuthenticated(); + if (isAuthenticated) { + const user = await auth0Client.getUser(); + profilePicture.src = user.picture; + userFullname.innerText = user.name; + + logOutButton.style.display = 'inline-block'; + } else { + logInButton.style.display = 'inline-block'; + } + +})(); +``` + +You defined a flag called `isAuthenticated` that defines if the user is authenticated or not. If they are authenticated, you use the `getUser()` method provided by the SPA SDK to extract their profile details. These details populate the screen with the name of the user and their picture. + +The `isAuthenticated` flag also defines what button the app will show based on their authentication status: the `logInButton` or the `logOutButton`. If the user has a session with this application, the app will show the `logOutButton` button. Otherwise, it will show the `logInButton`. + +23. Save all your changes and refresh the browser. You will see a screen that is slightly different from the previous one. + +![Login button for single-page application](/media/articles/identity-labs/lab-04-login-button-showing.png) + +24. In this new screen, click the **Log In** button to start the authentication process. Log in with your database user and accept the consent request. After successful authentication, Auth0 will redirect you back to your app, and your profile details (username and picture) will be shown near the upper-right corner: + +![Login complete on single-page application](/media/articles/identity-labs/lab-04-login-complete.png) + +::: note +If you log in using a social identity provider (Google, Facebook, etc.), you will need to log in every time you refresh the SPA. This happens because you are using Auth0’s test development keys for the identity provider. To prevent this from happening, you would need to register your application with the relevant Identity Provider and replace the test development keys on the Auth0 dashboard with your own. However, for the purposes of this lab, you should log in with a username and password to avoid the aforementioned behavior. + +For more information, see [Test Social Connections with Auth0 Developer Keys](https://auth0.com/docs/connections/social/devkeys). +::: + +If you want to test the `allowAccess()` function, which restricts access for particular routes depending on whether the user is authenticated, try navigating to [localhost:5000/#expenses](http://localhost:5000/#expenses). If you are logged in, the page will load successfully showing a "Loading..." text (the content for this page will be implemented in the next exercise). If you are not logged in, the app will redirect you to the homepage. + +25. Let's explore the relevant network traces of the authentication process used in this lab. First, click the **Log Out** button, then, once you return to the app with your session ended, open Chrome's **Developer Tools** and go to the **Network** tab. + +26. Click the **Log In** button. The first thing you will see in **Developer Tools** is a request similar to this: + +```text +https://${account.namespace}/authorize?client_id=... +``` + +This request is created and triggered by the SPA SDK when a user clicks on the login button. If you check the query parameters passed alongside this URL, you will find, among others, the following: + +- `client_id` - the unique identifier of your application for the authorization server. +- `response_type` - the artifacts needed to authenticate the user in your application. In this case, the SPA SDK is requesting an authorization code. This indicates to Auth0 that you will be using the [Authorization Code Grant Flow](https://auth0.com/docs/api-auth/tutorials/authorization-code-grant) (as defined by the OAuth 2.0 specification). +- `scope` - a space-delimited list of permissions that the application requires. In this case, your app is requesting `openid profile email`. These are scopes defined by the [OpenID Connect specification](/scopes/current/oidc-scopes) and give your app access to specific data in the user profile. +- `code_challenge` - this is a code that the authorization server will store and associate with the authorization request. In a future step, before issuing tokens to your application, the authorization server will use this code to verify (against another code called `code_verifier` that is handled internally by the SPA SDK) if it is secure to issue tokens. By using the code challenge and verifier, the SPA SDK is making the authorization process use a variant of the Authorization Code Grant Flow called PKCE. + +27. Log in again by clicking **Log In**. After Auth0 redirects back to your application, check the **Network** tab in **Developer Tools**, and you will see a list of requests, starting with the callback. Filter the requests and show only the XHR ones (those generated by an XMLHttpRequest JavaScript object). + +28. Click on the "token" request (if there are two, click the second one). You will see that it is a `POST` request to the token endpoint of the authorization server. This request exchanges the code retrieved on the authentication process for the tokens needed in your application. + +29. To see the data sent to the token endpoint, scroll to the bottom of the **Headers** tab. There, you will see that the request payload includes the following fields: `client_id`, `code`, `code_verifier`, `grant_type`, and `redirect_uri`. + +![Network request for token endpoint POST](/media/articles/identity-labs/lab-04-token-ep-post.png) + +30. Switch to the **Preview** tab to see the tokens returned by the authorization server. + +![Network response from token endpoint POST](/media/articles/identity-labs/lab-04-token-ep-response.png) + +::: note +If you are using a content blocker or browser setting that blocks third-party cookies, you will notice that in the step below, when authenticated, you need to log in again after refreshing the page. In that case, try changing your content blocker settings to allow your Auth0 domain (or turning it off altogether for localhost). Blocking all third-party cookies is not generally recommended as it is known to cause issues in some Web sites. This problem does not occur when [Custom Domains](/custom-domains) are used. +::: + +31. If you refresh the SPA and change **Developer Tools** to filter requests by Doc (Documents), you will see a request called `authorize`. This request is similar to the one issued after the authentication process with a few differences: + +- The request uses a different `response_mode`, in this case `web_message`. This is part of a strategy used to [renew tokens silently](/api-auth/tutorials/silent-authentication#renew-expired-tokens). +- The request defines a new query parameter called `prompt` set to `none`. As defined in the OpenID Connect protocol, this parameter is used on [authentication requests that must not display user interaction](https://auth0.com/docs/api-auth/tutorials/silent-authentication). This parameter is also part of the silent authentication process. + +![Silent authentication network request from single-page application](/media/articles/identity-labs/lab-04-silent-auth-request.png) + +For this to work properly, the silent authentication process requires the referrer URL to be whitelisted. This is why you added `http://localhost:5000` to the **Allowed Web Origins** field for your Auth0 Application. Otherwise, the silent authentication process would fail, and your users would need to log in again interactively. + +
      +
      +
      + +Next → diff --git a/articles/identity-labs/04-single-page-app/exercise-02.md b/articles/identity-labs/04-single-page-app/exercise-02.md new file mode 100644 index 0000000000..c04c5c6d4d --- /dev/null +++ b/articles/identity-labs/04-single-page-app/exercise-02.md @@ -0,0 +1,189 @@ +--- +section: exercises +description: Auth0 digital identity Lab 4, Exercise 2: Calling a Protected API +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 4, Exercise 2: Calling a Protected API + +::: warning +If you came to this page directly, go to the [first page of this lab](/identity-labs/04-single-page-app) and read through the instructions before getting started. +::: + +In this exercise, you will learn how to make your SPA consume, on behalf of the user, the private endpoint exposed by the API. + +
      + +
      +
      +
      +
      +
      +
      + +::: note +You can continue using the source code from the previous exercise, or if you are starting from scratch, use the code in the `exercise-02/begin` folder. Make sure you run steps 1-6 in [exercise 1](/identity-labs/04-single-page-app/exercise-01) either way. +::: + +To make your SPA consume the private endpoint on the user's behalf, it must fetch an access token first, then call the protected API. The first time your application asks for an access token for an API, the authorization server will request explicit consent from your users. + +To request this consent, your application will open a popup that will load a page from the authorization server. On that page, your users will learn what type of access your application is requesting, and they will be able to grant access or deny it. + +1. Open `spa/scripts/expenses.js`. You will see a few constants that reference DOM elements (like `loadExpensesButton` and `loadingExpenses`). Right after these constants, add the configuration code for the API. + +```js +// spa/scripts/expenses.js +(async function() { + // ... other constants + const loadingExpenses = document.getElementById('loading-expenses'); + + // Add the code below 👇 + const expensesAPIOptions = { + audience: 'https://expenses-api', + scope: 'read:reports', + }; + + // ... +})(); +``` + +The `expensesAPIOptions` constant is a configuration object that will tell the SPA SDK the audience and scope needed in the access token your application will request. The SDK will try to fetch access tokens capable of consuming the `https://expenses-api` API with the `read:reports` scope. + +2. Request the access token required to retrieve the expenses from the protected API on behalf of the user with the code below. + +```js +// spa/scripts/expenses.js +(async function() { + // ... code from the previous example + + // Add the code below 👇 + try { + const accessToken = await auth0Client.getTokenSilently(expensesAPIOptions); + await loadExpenses(accessToken); + } catch (err) { + if (err.error !== 'consent_required') { + alert('Error while fetching access token. Check browser logs.'); + return console.log(err); + } + + loadExpensesButton.onclick = async () => { + accesstoken = await auth0Client.getTokenWithPopup(expensesAPIOptions); + await loadExpenses(accesstoken); + }; + + consentNeeded.style.display = 'block'; + loadExpensesButton.style.display = 'inline-block'; + loadingExpenses.style.display = 'none'; + } + + // ... +})(); +``` + +The lines above are nested inside a `try/catch` block and are executed when the expenses view is requested. First, the application calls the `getTokenSilently()` method (provided by the SPA SDK) to see if your application is able to fetch a token without involving your user. If your app fetches the access token successfully, the application calls the `loadExpenses()` function with this token to load and display expenses (you will define this function in the next step). + +If your application is not able to fetch an access token (an error occurs, or the user is not logged in), the application checks if the problem is `consent_required`, which means that the user has not given consent to access the API yet. If that is not the case, it means an unknown error has been raised, and your application will alert the user and log the error to the browser’s console. + +If `consent_required` is indeed the problem, then you define the behavior of the `loadExpensesButton` and show the `consentNeeded` and `loadExpensesButton` DOM elements. These DOM elements are responsible for letting the user know that they will need to give your application explicit consent to consume the API on their behalf. More specifically, after reading the message, if your users click the `loadExpensesButton`, your application will trigger the SDK-provided `getTokenWithPopup()` method to open a popup where your users will be able to give consent. + +3. Call the API using the access token with the code below. + +```js +// spa/scripts/expenses.js +(async function() { + // ... code from the previous example + + // Add the code below 👇 + async function loadExpenses(accesstoken) { + try { + const response = await fetch('http://localhost:3001/', { + method: 'GET', + headers: { authorization: 'Bearer ' + accesstoken } + }); + + if (!response.ok) { + throw 'Request status: ' + response.status; + } + + const expenses = await response.json(); + displayExpenses(expenses); + } catch (err) { + console.log(err); + alert('Error while fetching expenses. Check browser logs.'); + } + } + + // ... +})(); +``` + +After fetching an access token (silently or explicitly through the popup), your application will invoke the function above to issue a request to the private API on the user's behalf. Note the `authorization` header passed to the `fetch()` function; this header includes the access token required to consume the expenses API. + +After executing the request to the API, if successful, the `displayExpenses()` function is called. This function creates the DOM elements on the page to represent the expenses and is already defined in the `spa/scripts/expenses.js` file at the bottom. + +4. Open `spa/scripts/navbar.js` and search for the block that gets executed when the user `isAuthenticated`. Inside this block, right after changing the display property of the `logOutButton`, add the code below. This will display a link to the expenses view in the navigation bar when the user is authenticated. + +```js +// spa/scripts/navbar.js +(async function() { + // ... code from the previous example + + const isAuthenticated = await auth0Client.isAuthenticated(); + if (isAuthenticated) { + // ... + + // Add the line below 👇 + expensesLink.style.display = 'inline-block'; + } // ... + +})(); +``` + +5. You are now ready to test the new version of the application. Save all the changes and reload the application in your browser. You should see the **Expenses** link in the navigation bar at the top. + +![Expenses link on single-page application](/media/articles/identity-labs/lab-04-expenses-link-showing.png) + +6. Click **Expenses** link, and you should see the consent prompt. + +![Consent link on single-page application](/media/articles/identity-labs/lab-04-consent-link-showing.png) + +7. Because you have not provided consent yet, you will see an **Allow App to Load Expenses** button. Clicking it will open the consent popup; note that the **Reports** scope is now included. + +![Consent prompt on single-page application](/media/articles/identity-labs/lab-04-consent-prompt.png) + +In the popup, click the **Accept** button to give consent. The popup will close, and your application will get the access token it needs. With this token, the SPA will call the `loadExpenses()` function and show the data retrieved from the API. + +![Expenses API data loading in single-page application](/media/articles/identity-labs/lab-04-expenses-data-showing.png) + +::: note +If you want to recreate the scenario where consent is needed, go to the [Users screen of the Auth0 Dashboard](${manage_url}/#/users), view your test user, click the **Authorized Applications** tab, and click **Revoke** for the single-page application with the Expenses API audience. + +![Revoke application permission for an API](/media/articles/identity-labs/lab-04-revoke-app.png) +::: + +🎉 **You have completed Lab 4 by building a single-page application calling a secure API!** 🎉 + +
      +
      +
      + +← All Identity Labs diff --git a/articles/identity-labs/04-single-page-app/index.md b/articles/identity-labs/04-single-page-app/index.md new file mode 100644 index 0000000000..ad3e3e9c30 --- /dev/null +++ b/articles/identity-labs/04-single-page-app/index.md @@ -0,0 +1,28 @@ +--- +section: exercises +description: Auth0 digital identity Lab 4: Single Page App +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index + - concept +--- +# Lab 4: Single Page App + +## Prerequisites + +- Read the introduction on the [main Identity Labs page](/identity-labs) +- Watch the [Single Page Apps video](/videos/learn-identity/06-single-page-apps) + +## What You'll Need + +<%= include('../_includes/_what-you-need') %> + +--- + +**For Windows users** - We recommend that you use the Windows PowerShell terminal (instead of the Windows command line) so that the terminal commands provided in the lab instructions work as they are. This is because the syntax of the commands used in the labs is the same for the Mac and PowerShell terminals. + +Start → diff --git a/articles/identity-labs/_includes/_git-clone-note.md b/articles/identity-labs/_includes/_git-clone-note.md new file mode 100644 index 0000000000..53e86ad21e --- /dev/null +++ b/articles/identity-labs/_includes/_git-clone-note.md @@ -0,0 +1,3 @@ +::: note +If you've never cloned a repo before, please see [GitHub's instructions](https://help.github.com/en/articles/cloning-a-repository) on how to do so. +::: diff --git a/articles/identity-labs/_includes/_what-you-need.md b/articles/identity-labs/_includes/_what-you-need.md new file mode 100644 index 0000000000..70bdc1ae49 --- /dev/null +++ b/articles/identity-labs/_includes/_what-you-need.md @@ -0,0 +1,21 @@ +**Node environment** - Install [Node.js](https://nodejs.org) directly or using [Homebrew](https://formulae.brew.sh/formula/node) or [NVM](https://github.com/nvm-sh/nvm) on a Mac. The labs were tested on Node.js v10.15.0 and NPM 6.4.1 (though they may work in other versions as well). + +--- + +**An Auth0 account** - Sign up for a free Auth0 account [here](https://auth0.com/signup). We recommend starting with a new, empty tenant that can be deleted when you have completed the exercises. If you're using an existing test or dev tenant, make sure that all Rules are turned **off** and MFA is turned **off**. + +--- + +**An Auth0 database user** - Use a new username/email and password user in a test database connection instead of a social, enterprise, or passwordless login. While social logins might work, using development keys can cause the labs to run differently. Choose a simple password that's easy to type as you will be logging in and out multiple times. You can use the same user across all of the labs. + +--- + +**A web browser** - This lab was built and tested using Google Chrome; Safari, Firefox, and Edge should all work fine as well. Disable any active ad blockers used for the domain of your local site, as well as for the Auth0 domain from your tenant. + +--- + +**The Identity Labs Git repo** - All the code you need to start, as well as the completed exercise for guidance, is located [here](https://github.com/auth0/identity-102-exercises). You need to clone that repo just once for all four labs. Use the correct folder relative to the lab you are working on. All file references in this lab are relative to `/begin` unless otherwise indicated. An `/end` folder is included as well to help with troubleshooting and compare your work with a working sample. + +--- + +**For macOS users** - If you are new to macOS, check [these quick tips](https://blogs.mulesoft.com/dev/newbie/quick-tips-for-developers-new-to-mac/) for developers new to Mac. Make sure you allow the display of hidden files and become familiar with running basic commands in the terminal. diff --git a/articles/identity-labs/index.md b/articles/identity-labs/index.md new file mode 100644 index 0000000000..cc71bbef74 --- /dev/null +++ b/articles/identity-labs/index.md @@ -0,0 +1,73 @@ +--- +section: exercises +description: Auth0 digital identity labs +topics: + - digital identity + - OIDC + - OpenId Connect + - OAuth2 +contentType: + - index +--- +# Auth0 Identity Labs + + **Welcome to the home for Auth0's digital identity labs!** These exercises serve as a learning tool to be combined with our [Learn Identity video series](/videos/learn-identity). Each lab is meant to be completed once a video (or series of videos) is complete. + +_A few general things to keep in mind as you work through these labs:_ + +**Plan to take around 1 hour or so (longer depending on your coding experience) for each lab.** Optionally, video demonstrations of the lab exercises are available. + +**These labs are designed to illustrate the basic concepts of digital identity, OAuth, and OpenID Connect.** The goal is to see the parameters and data that come together to create a complete authentication flow. As such, take your time and read through each section carefully. Completing the lab successfully is less important than understanding the concepts within. + +**The code samples here should not be used as-is in a production app.** The code here was written for instructional purpose and simplicity. For guidance on integrating Auth0 with a new or existing app, please see the Quickstarts listed on our [documentation home page](/) (choose an application type, then the technology you're using). + +Each lab will have a list of pre-requisites to complete or install. Please take note of specific version numbers as these can have an effect on how the labs work. + +ℹ️ The error messages displayed in the browser and in the console can often clue you into something that is going wrong. Auth0 error pages typically include a link under the "Technical Details" header that will give you more information about what went wrong. A "SyntaxError" line in your terminal window when starting the server indicates a typo or missed line. + +ℹ️ The code samples will indicate what lines to add or modify. In most cases, the order of operations (as in, when a particular line of code runs) matters greatly, so pay attention to those lines and the description above each snippet. + +```js +// lab-01/begin/server.js +// 👆 That is the file you should be in for these changes. + +require('dotenv').config(); +// 👆 This is code that should not be changed. + +// ... other required packages +// 👆 This is information to help you place the new code. + +// Add the code below 👇 +const session = require('cookie-session'); +const { auth } = require('express-openid-connect'); +// 👆 This is what should be added + +// ... +// 👆 This indicates that there is other code after that should not be changed. +``` + +ℹ️ Terminal commands are proceeded by a `❯` character. If you're copying those commands, exclude that character and the space that follows. Exclude all lines that do not start with `❯`; those are there to show the expected output. + +```text +# This line is informational; read but don't use. +❯ this line is the command to copy + +This line shows sample output; read but don't use. +``` + +**And with that, let's get started!** + + diff --git a/articles/integrations/_office-365-deep-linking.md b/articles/integrations/_office-365-deep-linking.md index 1ff44d5745..b6d457ae6e 100644 --- a/articles/integrations/_office-365-deep-linking.md +++ b/articles/integrations/_office-365-deep-linking.md @@ -6,7 +6,7 @@ Certain implementations might require deep linking to SharePoint Online for exam https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr={YOUR_CUSTOM_DOMAIN}&wreply={DEEP_LINK} ``` -The first parameter, `YOUR_CUSTOM_DOMAIN` should be the domain you've configured in Azure AD for SSO (eg: `fabrikam.com`). By specifying this as the `whr`, Azure AD will know it needs to redirect to Auth0 instead of showing the login page. +The first parameter, `YOUR_CUSTOM_DOMAIN` should be the domain you've configured in Azure AD for Single Sign-on (SSO) (e.g., `fabrikam.com`). By specifying this as the `whr`, Azure AD will know it needs to redirect to Auth0 instead of showing the login page. The `DEEP_LINK` parameter should be an encoded url within Office 365 (like a page in SharePoint Online, Exchange, ...). diff --git a/articles/integrations/apigee.md b/articles/integrations/apigee.md new file mode 100644 index 0000000000..4010377b94 --- /dev/null +++ b/articles/integrations/apigee.md @@ -0,0 +1,59 @@ +# Securing Apigee with Auth0 + +If you are using Apigee Edge for developing and managing your backend service APIs, you can use Auth0 to secure access to your API proxies. + +## Prerequisites + +Before you begin, you'll need to: + +1. Have an [Apigee Edge API proxy](https://docs.apigee.com/api-platform/get-started/get-started) that needs to be secured. +2. [Sign up](https://auth0.com/signup) for an account with Auth0. + +The process of building your API proxy is outside the scope of this article. Instead, we will focus on securing an API proxy that you already have using Auth0. + +## Create a custom API + +First, [register your Apigee Edge API Proxy using the Dashboard](/getting-started/set-up-api). Auth0 needs to recognize Apigee as an audience to make sure that any Access Tokens issued are issued with the correct audience. The user authenticates with Auth0 via the application, and the application specifies this audience value to make sure that the Access Token possesses the right scopes for the audience provided. + +You'll need to do the following: + +1. Provide a name for your API (e.g., `apigee`). +2. Provide an identifier for your API: `urn:apigee:target:api` +3. Choose a [signing algorithm](/tokens/concepts/signing-algorithms): `RS256` (default) + +When you register your Apigee Edge API Proxy, Auth0 also creates a **Machine to Machine (M2M)** application on your behalf and names it to match the API you registered. You can use this application for testing; it is automatically configured to be authorized to call your API. + +## Note variables from the test application + +Switch to the test application created when registering your API and make note of the variables that were set during the process of registering your API and creating the associated M2M application. You will need them for subsequent steps of this tutorial. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of your test application. + +2. Scroll down and make note of the following variables: + +* API audience +* Auth0 domain +* Client ID +* Allowed callback URL(s): The URLs to which the user can be redirected after authentication. You can specify multiple URLs by comma-separating them. (This is typically done to handle different environments where each needs its own redirects.) + +## Implement the Client Credentials flow + +Now you're ready to implement the [Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials#request-token) to request the Access Tokens you can provide to Apigee Edge. Note that in this scenario, you will use the Client Credentials Flow because you are using Apigee with your backend service APIs, which represents a Machine-to-Machine (M2M) application; other scenarios may require the use of different flows. + +To learn how to log in and get an Access Token that can be used to call Apigee Edge, see [Call API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials). + +## Validate the Access Token + +Once you've requested and received an Access Token from Auth0, you'll be able to use it to call the API proxy you set up with Edge. + +When you [use your Access Token](https://docs.apigee.com/api-platform/security/oauth/using-access-tokens.html), the first thing Apigee Edge will do is [verify the token](https://docs.apigee.com/api-platform/security/oauth/using-access-tokens.html#addingaverifyaccesstokenpolicy). + +Auth0 Access Tokens are [JSON Web Tokens (JWTs)](/tokens/concepts/jwts), so you can take advantage of Apigee Edge's [Verify JWT policy](https://docs.apigee.com/api-platform/reference/policies/verify-jwt-policy#verify-a-jwt-signed-with-the-rs256-algorithm) to do this. + +Apigee Edge will verify the token before anything else happens; if the token is rejected, then all processing will stop and Edge will return an error to the client. + +## Testing + +To test your implementation, make an [HTTP POST call to Apigee Edge](https://docs.apigee.com/api-platform/security/oauth/oauth-20-client-credentials-grant-type.html#callingtheprotectedapi) with the Auth0-issued Access Token included in the header of the call. + +When you receive a successful response, extract the token and review it to verify the inclusion of required/requested user claims. diff --git a/articles/integrations/authenticating-a-tessel-device.md b/articles/integrations/authenticating-a-tessel-device.md index f8cdaa7025..98fa54a29c 100644 --- a/articles/integrations/authenticating-a-tessel-device.md +++ b/articles/integrations/authenticating-a-tessel-device.md @@ -1,5 +1,10 @@ --- description: How to authenticate and authorize a Tessel device with Auth0. +topics: + - integrations + - tessel +contentType: how-to +useCase: integrate-saas-sso --- # Authenticating & Authorizing a Tessel device with Auth0 diff --git a/articles/integrations/authenticating-devices-using-mqtt.md b/articles/integrations/authenticating-devices-using-mqtt.md index 6d4ea78eb3..4484950046 100644 --- a/articles/integrations/authenticating-devices-using-mqtt.md +++ b/articles/integrations/authenticating-devices-using-mqtt.md @@ -1,6 +1,11 @@ --- description: How to authenticate and authorize devices using MQTT with Auth0. toc: true +topics: + - integrations + - mqtt +contentType: how-to +useCase: integrate-saas-sso --- # Authenticating & Authorizing Devices using MQTT with Auth0 @@ -90,7 +95,7 @@ Auth0Mosca.prototype.authenticateWithJWT = function(){ if( username !== 'JWT' ) { return callback("Invalid Credentials", false); } - // console.log('Passsord:'+password); + // console.log('Password:'+password); jwt.verify(password, self.clientSecret, function(err,profile){ if( err ) { return callback("Error getting UserInfo", false); } @@ -107,8 +112,8 @@ Auth0Mosca.prototype.authenticateWithCredentials = function(){ var self = this; return function(client, username, password, callback) { - - var data = { + + var data = { client_id: self.clientId, // {client-name} username: username.toString(), password: password.toString(), @@ -156,7 +161,7 @@ module.exports = Auth0Mosca; ``` -`authenticateWithCredentials` uses the [OAuth2 Resource Owner Password Credential Grant](/protocols#oauth-resource-owner-password-credentials-grant) to authenticate the broker and all connections to it. Each time a `publisher` or a `subscriber` send a __CONNECT__ message to the broker the `authenticate` function is called. In it we call the Auth0 endpoint and forward the device's `username`/`password`. Auth0 validates this against it's account store (that is the first `request.post` in the code). If successful, it validates and parses the Json Web Token to obtain the device profile and adds it to the `client` object that represents either the `subscriber` or the `publisher`. That's done in the `jwt.verify` call. +`authenticateWithCredentials` uses the [OAuth2 Resource Owner Password Credential Grant](/protocols#oauth-resource-owner-password-credentials-grant) to authenticate the broker and all connections to it. Each time a `publisher` or a `subscriber` send a __CONNECT__ message to the broker the `authenticate` function is called. In it we call the Auth0 endpoint and forward the device's `username`/`password`. Auth0 validates this against its account store (that is the first `request.post` in the code). If successful, it validates and parses the JSON Web Token (JWT) to obtain the device profile and adds it to the `client` object that represents either the `subscriber` or the `publisher`. That's done in the `jwt.verify` call. By convention, all devices connected to the broker have an account in Auth0: diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/_aws-dev-guide-link.md b/articles/integrations/aws-api-gateway/custom-authorizers/_aws-dev-guide-link.md new file mode 100644 index 0000000000..d628329c10 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/_aws-dev-guide-link.md @@ -0,0 +1 @@ +For details, see the Amazon API Gateway developer guide: [Use API Gateway Lambda Authorizers](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html). diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/index.md b/articles/integrations/aws-api-gateway/custom-authorizers/index.md index 714e46d00d..cfa8e782f6 100644 --- a/articles/integrations/aws-api-gateway/custom-authorizers/index.md +++ b/articles/integrations/aws-api-gateway/custom-authorizers/index.md @@ -1,22 +1,34 @@ --- description: How to use secure AWS API Gateway using custom authorizers that accept Auth0-issued Access Tokens +topics: + - integrations + - aws + - api-gateway +contentType: + - index + - concept + - tutorial +useCase: + - secure-an-api --- # Secure AWS API Gateway Endpoints Using Custom Authorizers +<%= include('../../../_includes/_webtask') %> + With AWS, you can create powerful, serverless, highly scalable APIs and applications using [Lambda](https://aws.amazon.com/lambda/), [API Gateway](https://aws.amazon.com/api-gateway/), and a JavaScript application for the front-end. -A serverless application runs custom code as a compute service without the need to maintain an operating environment to host your service. Instead, a service like [AWS Lambda](https://aws.amazon.com/lambda/) or [webtask.io](https://webtask.io) executes your code on your behalf. +A serverless application runs custom code as a compute service without the need to maintain an operating environment to host your service. Instead, a service like [AWS Lambda](https://aws.amazon.com/lambda/) executes your code on your behalf. The API Gateway extends the capabilities of Lambda by adding a service layer in front of your Lambda functions to extend security, manage input and output message transformations, and provide capabilities like throttling and auditing. A serverless approach simplifies your operational demands since concerns like scaling out and fault tolerance are now the responsibility of the compute service that is executing your code. -This tutorial will show you how to set up your API with API Gateway, create and configure your Lambda functions (including the custom authorizers) to secure your API endpoints, and implement the authorization flow so that your users can retrieve the Access Tokens needed to gain access to your API from Auth0. +This tutorial will show you how to set up your API with API Gateway, create and configure your Lambda functions (including the custom authorizers) to secure your API endpoints, and implement the authorization flow so that your users can retrieve the Access Tokens needed to gain access to your API from Auth0. More specifically, the custom authorizers will: 1. Confirm that the Access Token has been passed via the `authorization` header of the request to access the API -2. Verify the [RS256 signature](/apis#signing-algorithms) of the Access Token using a public key obtained via a [JWKS endpoint](/jwks) -3. Ensure the Access Token has the required Issuer `iss` and Audience `aud` claims +2. Verify the [RS256 signature](/apis#signing-algorithms) of the Access Token using a public key obtained via a [JWKS endpoint](/tokens/concepts/jwks) +3. Ensure the Access Token has the required Issuer `iss` and Audience `aud` claims ::: note New to OAuth 2.0? Check out our [introduction to OAuth 2.0](/protocols/oauth2). @@ -31,13 +43,13 @@ To that end, this tutorial will be divided into the following sections. ## How API Gateway Custom Authorizers Work -[According to Amazon](http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html), an API Gateway custom authorizer is a "Lambda function you provide to control access to your API using bearer token authentication strategies, such as OAuth or SAML." +[According to Amazon](http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html), an API Gateway custom authorizer is a "Lambda function you provide to control access to your API using bearer token authentication strategies, such as OAuth or SAML." Whenever someone (or some program) attempts to call your API, API Gateway checks to see if there's a custom authorizer configured for the API. If **there is a custom authorizer for the API**, API Gateway calls the custom authorizer and provides the authorization token extracted from the request header received. -You can use the custom authorizer to implement different types of authorization strategies, including [JWT](/jwt) verification, to return IAM policies authorizing the request. If the policy returned is invalid or if the permissions are denied, the API call fails. +You can use the custom authorizer to implement different types of authorization strategies, including [JWT](/tokens/concepts/jwts) verification, to return IAM policies authorizing the request. If the policy returned is invalid or if the permissions are denied, the API call fails. For a valid policy, API caches the returned policy, associating it with the incoming token and using it for the current and subsequent requests. You can configure the amount of time for which the policy is cached. The default value is `300` seconds, and the maximum length of caching is `3600` seconds (you can also set the value to 0 to disable caching). @@ -45,13 +57,13 @@ For a valid policy, API caches the returned policy, associating it with the inco Before beginning this tutorial, you'll need to [sign up for an AWS account](https://portal.aws.amazon.com/gp/aws/developer/registration/index.html). This grants you access to all of the AWS features we'll use in this tutorial, including API Gateway and Lambda. All new members receive twelve months of free tier access to AWS. -## Further Reading +<%= include('./_aws-dev-guide-link') %> + +## Next steps -::: next-steps * [API Authorization](/api-auth) -* [Obtain an Auth0 Access Token](/tokens/access-token#how-to-get-an-access-token) -* [JSON Web Key Sets (JWKS)](/jwks) -::: +* [Get Access Tokens](/tokens/guides/get-access-tokens) +* [JSON Web Key Sets (JWKS)](/tokens/concepts/jwks) <%= include('./_stepnav', { next: ["Configure the Auth0 API", "/integrations/aws-api-gateway/custom-authorizers/part-1"] diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md index dba78fb534..2c6c36ed24 100644 --- a/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md @@ -1,5 +1,12 @@ --- -desc: Configure Auth0 for use with AWS API Gateway +description: Configure Auth0 for use with AWS API Gateway +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial, Part 1: Create an Auth0 API @@ -14,9 +21,9 @@ You'll be asked to provide values for the following fields: | Field | Description | | - | - | -| Name | A friendly name for your API. This is the name you'll see in your list of Auth0 APIs | -| Identifier | A logical identifier for your API (we recommend formatting this identifier like a URL `https://your-api-gateway`) | -| Signing Algorithm | The algorithm you want Auth0 to use to sign the issued Access Tokens | +| Name | A friendly name for your API. This is the name you'll see in your list of Auth0 APIs. | +| Identifier | A logical identifier for your API. We recommend formatting this identifier like a URL `https://your-api-gateway`. | +| Signing Algorithm | The algorithm you want Auth0 to use to sign the issued Access Tokens. To learn more, see [Signing Algorithms](/tokens/concepts/signing-algorithms). | Click **Create** to proceed. diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md index 4aaaa44a66..115172a1dd 100644 --- a/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md @@ -1,6 +1,13 @@ --- description: Step 2 of Amazon API Gateway Tutorial toc: true +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial, Part 2: Import and Deploy the API Gateway API @@ -110,7 +117,7 @@ Click on the link to submit the `GET / method` request in a browser. This should ![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-8.png) -Next, we'll make a call to **GET** under `/pets/{petId}`. In the **Stages** page, expand the tree under **Test**. +Next, we'll make a call to **GET** under `/pets/{petId}`. In the **Stages** page, expand the tree under **Test**. Click **GET** under `/pets/{petId}`. ![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-9.png) @@ -140,4 +147,4 @@ Now that we have a fully functional API that's managed by API Gateway, we'll... <%= include('./_stepnav', { prev: ["Configure the Auth0 API", "/integrations/aws-api-gateway/custom-authorizers/part-1"], next: ["Create the Custom Authorizers", "/integrations/aws-api-gateway/custom-authorizers/part-3"] -}) %> \ No newline at end of file +}) %> diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md index db09a3574c..0e2584b436 100644 --- a/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md @@ -1,12 +1,19 @@ --- description: Step 3 of Amazon API Gateway Tutorial toc: true +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial, Part 3: Create the Custom Authorizers In [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1), we showed you how to configure Auth0 for use with API Gateway, and in [part 2](/integrations/aws-api-gateway/custom-authorizers/part-2) of this tutorial, we showed you how to import, test, and deploy an API using Amazon Web Services' (AWS) API Gateway. In this tutorial, we will show you how to secure this API so that only those with the appropriate authorization may access the back-end behind the API. -To do this, we will be using API Gateway's custom [request] authorizers, which allow you to authorize your APIs using bearer token authorization strategies, such as OAuth 2.0 or SAML. For each incoming request, the following happens: +To do this, we will be using API Gateway's custom [request] authorizers, which allow you to authorize your APIs using bearer token authorization strategies, such as OAuth 2.0 or SAML. For each incoming request, the following happens: 1. API Gateway checks for a properly-configured custom authorizer. 2. API Gateway calls the custom authorizer (which is a Lambda function) with the authorization token. @@ -27,13 +34,13 @@ You can [download a sample custom authorizer](https://github.com/auth0-samples/j | - | - | | **`TOKEN_ISSUER`** | The issuer of the token. If Auth0 is the token issuer, use `https://${account.namespace}/`. Be sure to include the trailing slash.| | **`JWKS_URI`** | The URL of the JWKS endpoint. If Auth0 is the token issuer, use `https://${account.namespace}/.well-known/jwks.json` | -| **`AUDIENCE`** | The **audience** value of the API you created in [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1) | +| **`AUDIENCE`** | The **identifier** value of the API you created in [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1) | As an example, the text of your .env file should look something like this when complete: ```text JWKS_URI=https://${account.namespace}/.well-known/jwks.json -AUDIENCE=hVG7...3QA1q +AUDIENCE=https://your-api-gateway TOKEN_ISSUER=https://${account.namespace}/ ``` @@ -41,7 +48,7 @@ TOKEN_ISSUER=https://${account.namespace}/ a. First, obtain a valid JWT Access Token. There are multiple methods by which you can get one, and the method you choose depends on your application's type, trust level, or overall end-user experience. -You can get a test token for your API by going to **APIs > Your API > Test** in the [dashboard](${manage_url}/#/apis). For specific details refer to [How to get an Access Token](/tokens/access-token#how-to-get-an-access-token). +You can get a test token for your API by going to **APIs > Your API > Test** in the [dashboard](${manage_url}/#/apis). For specific details refer to [Get Access Tokens](/tokens/guides/get-access-tokens). b. Create a local `event.json` file containing the token. You can copy the sample file (run `cp event.json.sample event.json`). Replace `ACCESS_TOKEN` with your JWT token, and `methodArn` with the appropriate ARN value for the `GET` method of your API. @@ -82,31 +89,12 @@ If the value of `Effect` is `Allow`, your authorizer would've allowed the call t The IAM role has the required permissions to call Lambda functions; before we can proceed with our custom authorizer, we'll need to create an IAM role that can call our custom authorizer whenever API Gateway receives a request for access. 1. Log in to AWS and navigate to the [IAM Console](https://console.aws.amazon.com/iam). Click **Roles** in the left-hand navigation bar. - 2. Click **Create new role**. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-1.png) - -3. Under **AWS Service Role**, find the **AWS Lambda** row and click the associated **Select** button. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-2.png) - -4. On the **Attach Policy** screen, select the **AWSLambdaRole**. You can use the provided filter to narrow down the list of options. Click **Next Step** to proceed. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-4.png) - -5. On **Set role name and review**, provide a **Role name**, such as `Auth0Integration`. Leave the rest of the fields as is. Click **Create role**. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-5.png) - +3. Under **AWS service** select the **AWS Lambda** row and click the **Next: Permissions** button. +4. On the **Attach permissions policy** screen, select the **AWSLambdaRole**. You can use the provided filter to narrow down the list of options. Click **Next: Tags**, then click **Next: Review** to proceed. +5. On the **Review** screen, provide a **Role name**, such as `Auth0Integration`. Leave the rest of the fields as is. Click **Create role**. 6. Once AWS has created your role, you'll be directed back to the **Roles** page of IAM. Select your new role. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-6.png) - 7. On the **Summary** page for the role you've just created, click on to the **Trust relationships** tab. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-8.png) - 8. Click **Edit trust relationship**, and populate the **Policy Document** field with the following JSON snippet: ```json @@ -145,65 +133,39 @@ Now that you've configured your custom authorizer for your environment and teste ![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-11.png) -3. On the **Select blueprint** page, click **Author from scratch** to create a blank function. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png) - -4. On the **Configure triggers** page, click **Next** (you don't need to configure a trigger). - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-13.png) - -5. On the **Configure function** page, you'll provide all of the information needed for your new Lambda function. Under **Basic information**, provide values for the following parameters: +3. On the **Select blueprint** page, click **Author from scratch** to create a blank function. Under **Basic information**, provide values for the following parameters: | **Parameter** | **Value** | | - | - | | **Name** | A name for your Lambda function, such as `jwtRsaCustomAuthorizer` | | **Description** | A description for your Lambda function (optional) | -| **Runtime** | Select `Node.js 4.3` | +| **Runtime** | Select `Node.js 10.x` | -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-14.png) +![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png) -a. Next, provide the function code. Under **Code entry type**, select **Upload a .ZIP file**. Click **Upload** and select the `custom-authorizer.zip` bundle you created earlier. +4. Click **Create Function** to continue. -b. Then, create the following three **Environment variables**. Note that this information is identical to that which is the `.env` file. +![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-13.png) + +5. On the **Configuration** page of your function, scroll down to the **Function Code** section. +6. Select **Upload a .ZIP file** as the **Code entry type**. +7. Click **Upload** and select the `custom-authorizer.zip` bundle you created earlier. +8. Then, create the following three **Environment variables**. Note that this information is identical to that which is the `.env` file. | **Parameter** | **Value** | | - | - | | **`TOKEN_ISSUER`** | The issuer of the token. If Auth0 is the token issuer, use `https://${account.namespace}/` | | **`JWKS_URI`** | The URL of the JWKS endpoint. If Auth0 is the token issuer, use `https://${account.namespace}/.well-known/jwks.json` | -| **`AUDIENCE`** | The **audience** value of the API you created in [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1) | - -c. In the **Lambda function handler and role** section, set the following values: - -| **Parameter** | **Value** | -| - | - | -| **Handler** | `index.handler` | -| **Role** | `Choose an existing role` | -| **Existing role** | Select the IAM role you created in the steps above. | - -d. Open up the **Advanced settings** area, and set **Timeout** to **30** sec. - -When you've provided all of the information above, click **Next**. - -e. Review the information you've provided for your Lambda function. If everything looks correct, click **Create function**. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-15.png) - -If AWS successfully creates your function, you'll see the following. +| **`AUDIENCE`** | The **identifier** value of the API you created in [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1) | -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-16.png) +9. In the **Execution role** section, select **Use an existing role** then select the IAM role you created previously as the **Existing role**. -6. Test the Lambda function you just created. Click **Test** in the top right corner. - -7. Copy the contents of your `event.json` file into the Input test event JSON (you can use the default "Hello World" template). - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-17.png) - -Click **Save and test**. If the test was successful, you'll see the following. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-18.png) - -Expanding the output window should show a message similar to the one you received after your successful local test. +10. Under **Basic settings** set **Timeout** to **30** sec. +11. Click **Save**. +12. Test the Lambda function you just created. Click **Test** in the top right corner. +13. Copy the contents of your `event.json` file into the **Configure test event** form. You can use the default "Hello World" event template. +14. Click **Create**. +15. Run your test by selecting it and clicking **Test**. If the test was successful, you'll see: "Execution result: succeeded". Expanding the output window should show a message similar to the one you received after your successful local test. ![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-19.png) @@ -217,30 +179,23 @@ Open the **PetStore** API we created earlier. ![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-22.png) -Using the left-hand navigation bar, open **Authorizers**. If this is the first authorizer you've created, you'll see the **New custom authorizer** configuration screen by default. If not, you can bring up this screen by clicking **Create > Custom Authorizer** on the center panel. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-23.png) - -Set the following parameters: +Using the left-hand navigation bar, open **Authorizers** and select **Create New Authorizer** then set the following parameters: | **Parameter** | **Value** | | - | - | -| **Lambda region** | Use the region for the Lambda function you created previously | -| **Lambda function** | `jwtRsaCustomAuthorizer` | -| **Authorizer name** | `jwt-rsa-custom-authorizer` | -| **Execution role** | The IAM Role ARN you copied above | -| **Identity token source** | `Authorization` | -| **Token validation expression** | `^Bearer [-0-9a-zA-z\.]*$` | -| **Result TTL in seconds** | `3600` | - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-24.png) +| **Name** | `jwt-rsa-custom-authorizer` | +| **Type** | Select **Lambda** | +| **Lambda Region** | Use the region for the Lambda function you created previously | +| **Lambda Function** | `jwtRsaCustomAuthorizer` | +| **Lambda Invoke Role** | The IAM Role ARN you copied above | +| **Lambda Event Payload** | Select **Token** | +| **Token Source** | `Authorization` | +| **Token Validation** | `^Bearer [-0-9a-zA-z\.]*$` | +| **TTL (seconds)** | `3600` | Click **Create**. -After AWS creates the authorizer and the page refreshes, you'll see a new **Test your authorizer** section at the bottom of the screen. You can test your authorizer by providing the Auth0 token (`Bearer ey...`) you've previously used and clicking **Test**. - -![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-25.png) - +After AWS creates the authorizer and the page refreshes, test your authorizer by clicking **Test** and providing the Auth0 token (`Bearer ey...`) you previously used. If the test was successful, you'll see a response similar to the following. ![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-26.png) diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md index 4895ae2e1a..148a41cca0 100644 --- a/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md @@ -1,5 +1,12 @@ --- description: How to set your API methods to use your custom authorizer +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial, Part 4: Secure the API Using Custom Authorizers @@ -10,13 +17,15 @@ In [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1), you config Log in to AWS and navigate to the [API Gateway Console](http://console.aws.amazon.com/apigateway). +<%= include('./_aws-dev-guide-link') %> + ![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-1.png) ::: note Custom authorizers are set on a method by method basis; if you want to secure multiple methods using a single authorizer, you'll need to repeat the following instructions for each method. ::: -Open the **PetStore** API we created in [part 2](/integrations/aws-api-gateway-2/part-2) of this tutorial. Under the **Resource** tree in the center pane, select the **GET** method under the `/pets` resource. +Open the **PetStore** API we created in [part 2](/integrations/aws-api-gateway/part-2) of this tutorial. Under the **Resource** tree in the center pane, select the **GET** method under the `/pets` resource. ![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-2.png) @@ -24,7 +33,7 @@ Select **Method Request**. ![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-3.png) -Under **Settings**, click the **pencil** icon to the right **Authorization** and choose the `jwt-rsa-custom-authorizer` custom authorizer you created in [part 3](/integrations/aws-api-gateway-2/part-3). +Under **Settings**, click the **pencil** icon to the right **Authorization** and choose the `jwt-rsa-custom-authorizer` custom authorizer you created in [part 3](/integrations/aws-api-gateway/part-3). ![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-4.png) diff --git a/articles/integrations/aws-api-gateway/delegation/_delegation-version-warning.md b/articles/integrations/aws-api-gateway/delegation/_delegation-version-warning.md new file mode 100644 index 0000000000..f42507d886 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/_delegation-version-warning.md @@ -0,0 +1,5 @@ +::: version-warning +This feature uses delegation. By default, delegation is disabled for tenants without an add-on in use as of 8 June 2017. If you are not already using delegation, please use the drop-down to learn how to implement custom authorizers instead. + +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/articles/integrations/aws-api-gateway/delegation/index.md b/articles/integrations/aws-api-gateway/delegation/index.md index 1164c8fd2c..64c61344ab 100644 --- a/articles/integrations/aws-api-gateway/delegation/index.md +++ b/articles/integrations/aws-api-gateway/delegation/index.md @@ -1,23 +1,31 @@ --- title: Amazon API Gateway Tutorial Introduction description: How to build a serverless application using Token-based Authentication with AWS API Gateway and Lambda. +topics: + - integrations + - aws + - api-gateway +contentType: + - tutorial + - index +useCase: + - secure-an-api --- - # Build a Serverless Application Using Token-Based Authentication with AWS API Gateway and Lambda -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= include('./_delegation-version-warning') %> + +<%= include('../../../_includes/_webtask') %> With AWS, you can create powerful, serverless, highly scalable APIs and applications through AWS Lambda, Amazon API Gateway, and a JavaScript application. -A serverless application runs custom code as a compute service without the need to maintain an operating environment to host your service. Instead, a service like [AWS Lambda](https://aws.amazon.com/lambda/) or [webtask.io](https://webtask.io) executes your code on your behalf. +A serverless application runs custom code as a compute service without the need to maintain an operating environment to host your service. Instead, a service like [AWS Lambda](https://aws.amazon.com/lambda/) executes your code on your behalf. Amazon API Gateway extends the capabilities of AWS Lambda by adding a service layer in front of your Lambda functions to extend security, manage input and output message transformations, and provide capabilities like throttling and auditing. A serverless approach simplifies your operational demands, since concerns like scaling out and fault tolerance are now the responsibility of the compute service that is executing your code. However, you often want to tie your APIs to your existing users, either from social providers like Twitter and Facebook, or within your own organization from Active Directory or a customer database. This tutorial demonstrates how to authorize access of your Amazon API Gateway methods for your existing users using Auth0 delegation for AWS and integration with AWS Identity and Access Management (IAM). -Next, the tutorial walks you through setting up the Amazon API Gateway using AWS Lambda functions, securing those functions with AWS IAM roles, and then using Auth0 delegation to obtain a token for the AWS IAM role. It will then show you how to assign different permissions to various classes of users, like internal database or social users, and how to flow identity using a JSON Web Token (JWT). +Next, the tutorial walks you through setting up the Amazon API Gateway using AWS Lambda functions, securing those functions with AWS IAM roles, and then using Auth0 delegation to obtain a token for the AWS IAM role. It will then show you how to assign different permissions to various classes of users, like internal database or social users, and how to flow identity using a JSON Web Token (JWT). You will be taken through the following steps: diff --git a/articles/integrations/aws-api-gateway/delegation/part-1.md b/articles/integrations/aws-api-gateway/delegation/part-1.md index df1887f009..145d08c4e6 100644 --- a/articles/integrations/aws-api-gateway/delegation/part-1.md +++ b/articles/integrations/aws-api-gateway/delegation/part-1.md @@ -1,12 +1,17 @@ --- title: AWS API Gateway Tutorial - Set Up the Amazon API Gateway description: Step 1 of Amazon API Gateway Tutorial +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= include('./_delegation-version-warning') %> ## Step 1 - Set up the Amazon API Gateway diff --git a/articles/integrations/aws-api-gateway/delegation/part-2.md b/articles/integrations/aws-api-gateway/delegation/part-2.md index 877bd10143..e96b9a1882 100644 --- a/articles/integrations/aws-api-gateway/delegation/part-2.md +++ b/articles/integrations/aws-api-gateway/delegation/part-2.md @@ -1,12 +1,17 @@ --- title: Amazon API Gateway Tutorial - Adding Security and Deploying description: Step 2 of Amazon API Gateway Tutorial +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= include('./_delegation-version-warning') %> ## Step 2 - Secure and Deploy the Amazon API Gateway @@ -14,9 +19,9 @@ Now that you have your API running, you need to add security. In this step, you * Secure the update API to limit access to authenticated users with a specific AWS IAM role; * Configure Auth0 delegation to use AWS IAM federation capabilities; -* Obtain an AWS Access Token that uses the AWS IAM role. +* Obtain an AWS Access Token that uses the AWS IAM role. -Once your API is secure, you'll build a serverless, single page application (SPA). The SPA will rely on federating identity to determine which users are allowed access. By combining AWS IAM Integration for AWS Gateway API, AWS IAM Identity Federation for SAML, and Auth0 Delegation for AWS, you can enable users from many different sources, including Social Providers or enterprise connections, to access your APIs. The following diagram illustrates a sample flow using a SAML-based Identity Provider and Auth0 SAML Federation and Delegation for AWS. +Once your API is secure, you'll build a serverless, single-page application (SPA). The SPA will rely on federating identity to determine which users are allowed access. By combining AWS IAM Integration for AWS Gateway API, AWS IAM Identity Federation for SAML, and Auth0 Delegation for AWS, you can enable users from many different sources, including Social Providers or enterprise connections, to access your APIs. The following diagram illustrates a sample flow using a SAML-based Identity Provider and Auth0 SAML Federation and Delegation for AWS. ![Authentication Flow](/media/articles/integrations/aws-api-gateway/auth-flow.png) @@ -54,7 +59,7 @@ Log in to your Auth0 account. You will be brought to the Management Dashboard. C ![Auth0 Management Dashboard](/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png) -Name your new application *AWS API Gateway*, and indicate that this Application is going to be a *Single Page Application*. Click **Create**. +Name your new application *AWS API Gateway*, and indicate that this Application is going to be a *Single-Page Application*. Click **Create**. ![Create Application](/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png) @@ -183,7 +188,7 @@ Click the edit icon beside the **Authorization Type**, and select *AWS_IAM*. Now ### 2. Set Up CORS and Deploy the API -Our Single Page Application (SPA) will access web API methods from a domain different from that of the page. The *Cross-Origin Resource Sharing* setting needs to explicitly permit this action for the browser to allow access to the AWS API Gateway. Typically, the browser will first issue an `OPTIONS` request to see what actions the site will permit. +Our Single-Page Application (SPA) will access web API methods from a domain different from that of the page. The *Cross-Origin Resource Sharing* setting needs to explicitly permit this action for the browser to allow access to the AWS API Gateway. Typically, the browser will first issue an `OPTIONS` request to see what actions the site will permit. Select `/pets` under Resources, and click **Create Method**. In the drop-down, select **OPTIONS**, and click the **checkmark** to save the setting. diff --git a/articles/integrations/aws-api-gateway/delegation/part-3.md b/articles/integrations/aws-api-gateway/delegation/part-3.md index fbfc58c453..f2049e1858 100644 --- a/articles/integrations/aws-api-gateway/delegation/part-3.md +++ b/articles/integrations/aws-api-gateway/delegation/part-3.md @@ -1,16 +1,21 @@ --- title: Amazon API Gateway Tutorial - Building the App description: Step 3 of Amazon API Gateway Tutorial +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= include('./_delegation-version-warning') %> ## Step 3 - Build the Application -In this step, you will build a single page, serverless application using the AngularJS framework that you will serve out of an AWS S3 bucket configured to act as a static website. +In this step, you will build a single-page, serverless application using the AngularJS framework that you will serve out of an AWS S3 bucket configured to act as a static website. ### 1. Set Up Your Sample Application @@ -51,11 +56,11 @@ You should also see the page for viewing pets. ### Use Delegation to Get an AWS Token -At this point, you have authentication set up with Auth0, and you have an OpenId JWT. Here is the directory structure for the generated code: +At this point, you have authentication set up with Auth0, and you have an OpenID JWT. Here is the directory structure for the generated code: ![S3 website directory structure](/media/articles/integrations/aws-api-gateway/aws-api-gateway-project.png) -You can use Auth0's delegation capability to obtain an AWS Access Token that is based on the Auth0 identity token. Behind the scenes, Auth0 authenticates your identity token, and then uses SAML based on the addon that you configured. +You can use Auth0's delegation capability to obtain an AWS Access Token that is based on the Auth0 identity token. Behind the scenes, Auth0 authenticates your identity token, and then uses SAML based on the addon that you configured. Update `pets/login/login.js` as follows to get an AWS delegation token from the identity token after a successful signin with `auth.signin`. Note that you are treating any user not logged in using a Social Connection as an admin. Later, we'll code a second role and show better ways to enforce role selection. diff --git a/articles/integrations/aws-api-gateway/delegation/part-4.md b/articles/integrations/aws-api-gateway/delegation/part-4.md index 0993354a10..8e2766db92 100644 --- a/articles/integrations/aws-api-gateway/delegation/part-4.md +++ b/articles/integrations/aws-api-gateway/delegation/part-4.md @@ -1,12 +1,17 @@ --- title: Amazon API Gateway Tutorial - Using Multiple Roles description: Step 4 of Amazon API Gateway Tutorial +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api --- # AWS API Gateway Tutorial -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= include('./_delegation-version-warning') %> ## Step 4 - Use Multiple Roles with Amazon API Gateway @@ -26,7 +31,7 @@ The following diagram illustrates AWS IAM role assignments for two different use ![AWS Roles in Use](/media/articles/integrations/aws-api-gateway/roles-in-use.png) -For cases where you want to make decisions within your code (for example, you might want a credit check of a user buying a pet), you will want to flow identity as well. This will be demonstrated below in [Step 5 - Using Identity Tokens to Flow Identity](/integrations/aws-api-gateway/part-5). +For cases where you want to make decisions within your code (for example, you might want a credit check of a user buying a pet), you will want to flow identity as well. This will be demonstrated below in [Step 5 - Using Identity Tokens to Flow Identity](/integrations/aws-api-gateway/delegation/part-5). ### 1. Create the PetPurchase API Resource @@ -170,14 +175,14 @@ If you haven't used Login with Amazon before, there is also a link called **How Once you've entered the appropriate information, click **Try** to ensure that everything is set up correctly. ::: note -When you configure LWA using the Amazon console, be sure to enter into *Allowed Return URLs* the callback URL to your Auth0 Application, which should look something like `https://johndoe.auth0.com/login/callback`. The Auth0 help page will show you specifically what to enter. +When you configure LWA using the Amazon console, be sure to enter into *Allowed Return URLs* the callback URL to your Auth0 Application, which should look something like `https://johndoe.auth0.com/login/callback`. The Auth0 help page will show you specifically what to enter. ::: In the Auth0 Dashboard, go back to **Applications**, select your Application, and then open up the **Connections** page. Ensure that *amazon* is enabled under Social Connections. ![AWS Connections](/media/articles/integrations/aws-api-gateway/part-4/aws-connections.png) -#### Deploy the API and Update the Single Page Application +#### Deploy the API and Update the Single-Page Application ##### Deploy the API @@ -222,7 +227,7 @@ function buyPet(user, id) { … ``` -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. +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) diff --git a/articles/integrations/aws-api-gateway/delegation/part-5.md b/articles/integrations/aws-api-gateway/delegation/part-5.md index 036f52bfca..0b8697e298 100644 --- a/articles/integrations/aws-api-gateway/delegation/part-5.md +++ b/articles/integrations/aws-api-gateway/delegation/part-5.md @@ -1,18 +1,23 @@ --- 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 -::: version-warning -Delegation is considered deprecated in Auth0. Please integrate Auth0 using custom authorizers. Use the drop-down to switch to these docs. -::: +<%= 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); +* 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. @@ -37,7 +42,7 @@ There are several ways of adding a user's information to the JWT. The following 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`: +In `login.js`, you can see this scope specified in the parameters passed to `auth.signin`: ```js $scope.login = function() { @@ -162,7 +167,7 @@ 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; +* 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. diff --git a/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md b/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md index 72c5c1e8de..09bdb2005f 100644 --- a/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md +++ b/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md @@ -1,6 +1,14 @@ --- 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 @@ -27,7 +35,7 @@ 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 the name of the incoming request header containing the API caller's identity token to `Authorization`. +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. diff --git a/articles/integrations/aws/aws-api-setup.md b/articles/integrations/aws/aws-api-setup.md index 68da2facad..4612c92ce4 100644 --- a/articles/integrations/aws/aws-api-setup.md +++ b/articles/integrations/aws/aws-api-setup.md @@ -2,10 +2,15 @@ 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 -The 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 [Enable SSO to the AWS Console](/aws/integrations/sso) or [API Gateway](/integrations/aws-api-gateway) tutorials for complete examples. +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 @@ -17,7 +22,7 @@ Set the following parameters: | Parameter | Description and Sample Value | | - | - | -| Provider Type | The type of provider. Set as `SAML` | +| 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** | @@ -122,4 +127,4 @@ In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home# ### Next Steps -* [AWS Services Supported by IAM](http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html). \ No newline at end of file +* [AWS Services Supported by IAM](http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html). diff --git a/articles/integrations/aws/index.md b/articles/integrations/aws/index.md index 6c59531d37..e61b193cd1 100644 --- a/articles/integrations/aws/index.md +++ b/articles/integrations/aws/index.md @@ -2,6 +2,13 @@ classes: topic-page title: Amazon Web Services (AWS) url: /integrations/aws +topics: + - integrations + - aws +contentType: index +useCase: + - secure-an-api + - integrate-third-party-apps ---
      @@ -14,7 +21,7 @@ url: /integrations/aws \ No newline at end of file diff --git a/articles/integrations/aws/session-tags.md b/articles/integrations/aws/session-tags.md new file mode 100644 index 0000000000..d147362eae --- /dev/null +++ b/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/articles/integrations/aws/sso.md b/articles/integrations/aws/sso.md index 76c9b4e137..cd4f6d2506 100644 --- a/articles/integrations/aws/sso.md +++ b/articles/integrations/aws/sso.md @@ -1,25 +1,43 @@ --- -description: How to use SSO with AWS +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 --- -# Enable SSO to the AWS Console +# 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 -Log in to the [Management 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. +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. -![](/media/articles/integrations/aws/addons.png) + ![Applications](/media/articles/dashboard/guides/app-list.png) -You'll be asked to configure this add-on using the pop-up that appears immediately after you've enabled the SAML2 Web App. +2. When the configuration pop-up appears, on the **Settings** tab, populate **Application Callback URL** with `https://signin.aws.amazon.com/saml`. -On the **Settings** tab, populate **Application Callback URL** with `https://signin.aws.amazon.com/saml` and paste the following SAML configuration code into **Settings**: + ![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": "https://signin.aws.amazon.com/saml", + "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" @@ -28,85 +46,55 @@ On the **Settings** tab, populate **Application Callback URL** with `https://sig "passthroughClaimsWithNoMapping": false, "mapUnknownClaimsAsIs": false, "mapIdentities": false, - "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent", + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", "nameIdentifierProbes": [ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" ] } ``` -![](/media/articles/integrations/aws/configure.png) - -Scroll to the bottom and click **Save**. - -Click over to the **Usage** tab. You'll need to configure Auth0 as the identity provider (IdP) for AWS, which requires you to provide the appropriate metadata to AWS. You can obtain a file containing this information by clicking **Identity Provider Metadata**. - -![](/media/articles/integrations/aws/idp-download.png) - -## Configure AWS - -At this point, you're ready to continue the configuration process from the AWS side. - -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**. +3. Scroll to the bottom, and click **Enable**. -![](/media/articles/integrations/aws/create-provider.png) +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**. -Set the following parameters: + ![SAML2 Web App Usage](/media/articles/integrations/aws/idp-download.png) -| 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 you downloaded in the previous step here. | +## Complete external Identity Provider configuration in AWS -![](/media/articles/integrations/aws/aws-configure-provider.png) +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. -Click **Next Step**. Verify your settings and click **Create** if everything is correct. +## Create an AWS IAM Role -![](/media/articles/integrations/aws/create-provider-confirm.png) +To use the provider, you must create an IAM role using the provider in the role's trust policy. -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**. -In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home#/roles). Click **Create New Role**. +2. On the next page, you will be asked to select the type of trusted entity. Select **SAML 2.0 Federation**. -![](/media/articles/integrations/aws/iam-new-role.png) +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. -On the **Select role type** page, select **Role for identity provider access**. +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**. -![](/media/articles/integrations/aws/select-role-type.png) +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. -Click **Select** for the **Grant Web Single Sign-On (WebSSO) access to SAML providers** option. When prompted, set the provider you created above as the **SAML provider** and click **Next Step** to proceed. +6. On the **Review** page, set the **Role Name** and review your settings. Provide values for the following parameters: -![](/media/articles/integrations/aws/select-saml-provider-to-trust.png) + | Parameter | Definition | + | - | - | + | Role name | A descriptive name for your role | + | Role description | A description of what your role is used for | -On the **Verify Role Trust** page, accept the **Policy Document** proposed (this policy tells IAM to trust the Auth0 SAML IdP). Click **Next Step**. - -On **Attach Policy**, 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. Click **Next Step**. - -Finally, 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 | - -Review the **Trusted entities** and **Policies** information, then click **Create Role**. - -![](/media/articles/integrations/aws/iam-review-role.png) - -At this point, you'll have created the necessary role to associate with your provider. +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 how to define a server-side rule for assigning a role in an advanced use case, see the [Amazon API Gateway tutorial](/integrations/aws-api-gateway). +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 map an AWS role to a user, you'll need to create a [rule](/rules) for this purpose. +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). -::: note -For more information on 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) { @@ -126,9 +114,9 @@ function (user, context, callback) { 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. -There are multiple ways by which you can obtain these two values. In the example above, both of these values are hard-coded into the rules. You might also store these values in the [user profile](/user-profile), or you might derive them using other attributes. +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. -For example, if you're using Active Directory, you can map properties associated with users, such as `group` to the appropriate AWS role: +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 = { @@ -144,7 +132,7 @@ context.samlConfiguration.mappings = { }; ``` -### Mapping Multiple Roles +### Map Multiple Roles You can also assign an array to the role mapping (so you'd have `awsRoles = [ role1, role2 ]` instead of `awsRoles: role1`) @@ -213,10 +201,11 @@ function (user, context, callback) { } ``` -## Test Your Setup - -You are now set up for single sign-on to AWS. You can find the `Identity Provider Login URL` on the [Management Dashboard](${manage_url}). Open up your [application](${manage_url}/#/applications) to the **SAML2 Addon** settings area, and click over to the **Usage** tab. +## Test setup -![](/media/articles/integrations/aws/idp-download.png) +You are now set up for Single Sign-on (SSO) to AWS and can test your setup. -To test the single sign-on, navigate to the URL indicated. You should be redirected to the Auth0 sign in page. If you successfully sign in, you'll be redirected again, this time to AWS. +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/articles/integrations/aws/tokens.md b/articles/integrations/aws/tokens.md index ef46fc997b..cd984901df 100644 --- a/articles/integrations/aws/tokens.md +++ b/articles/integrations/aws/tokens.md @@ -1,12 +1,19 @@ --- 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 -::: panel-warning Legacy Grant Types -As of 8 June 2017, new Auth0 customers cannot add any of the legacy grant types to their applications, which are required for use with the [Delegation endpoint](/api/authentication#get-token-info). Legacy grant types are only available for previous customers while they migrate to new flows, to avoid breaking changes. To find the secure alternative for your case refer to [Secure Alternatives to the Legacy Grant Types](/applications/application-grant-types#secure-alternatives-to-the-legacy-grant-types). If you have any questions about which alternative you should use, please contact [Support](${env.DOMAIN_URL_SUPPORT}). -::: +<%= 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). @@ -30,7 +37,7 @@ Log in to Auth0's Management Dashboard, navigate to the [Applications](${manage_ ![](/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. +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 @@ -57,13 +64,13 @@ The following is a sample AWS IAM policy: } ``` -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 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](/jwt)). This `id_token` is then used to request an Auth0 and AWS token using the delegation endpoint. +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: diff --git a/articles/integrations/azure-api-management/configure-auth0.md b/articles/integrations/azure-api-management/configure-auth0.md index 74a89eb908..d8eb7151d5 100644 --- a/articles/integrations/azure-api-management/configure-auth0.md +++ b/articles/integrations/azure-api-management/configure-auth0.md @@ -1,6 +1,13 @@ --- 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 @@ -14,7 +21,7 @@ To use Auth0 as an [OAuth 2.0 authorization server](/protocols/oauth2#oauth-role 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#application-types), 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. +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**. @@ -25,8 +32,8 @@ 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. See [Signing Algorithms](/apis#signing-algorithms) for additional information | +| 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**. @@ -38,7 +45,6 @@ When your API is ready, you'll be shown the **Quick Start** page for the API. Sw ## Step 2: Create a Connection -After you've created your API and your Application, you'll need to create a [Connection](/applications/connections), which is a source of users. For the purposes of this example, we'll create a [Database Connection](/connections/database). ::: 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). @@ -64,7 +70,7 @@ Once Auth0 has created your Connection, you'll be redirected to your Connection' 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**. +Go to the [Users section](${manage_url}/#/users) of the Management Dashboard. Click **Create User**. ![](/media/articles/integrations/azure-api-mgmt/auth0/user.png) diff --git a/articles/integrations/azure-api-management/configure-azure.md b/articles/integrations/azure-api-management/configure-azure.md index 9b6bdcdaa2..fd8219189b 100644 --- a/articles/integrations/azure-api-management/configure-azure.md +++ b/articles/integrations/azure-api-management/configure-azure.md @@ -1,6 +1,13 @@ --- 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 @@ -18,9 +25,7 @@ In this section, you'll: ## Step 1: Create Your API Management Instance -To create a new API management service, click on **New** > **Web + Mobile** > **API management**. - -![](/media/articles/integrations/azure-api-mgmt/azure/azure-portal-api-management.png) +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: @@ -32,87 +37,55 @@ You'll be asked to provide the following configuration variables: | 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 | +| 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. | -![](/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-config.png) +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. -![](/media/articles/integrations/azure-api-mgmt/azure/deployment-in-progress.png) - ## 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. -Launch the API Management service that you created in the previous step. - -![](/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-home.png) - -Open up the Publisher Portal, and click on **Import 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) -![](/media/articles/integrations/azure-api-mgmt/azure/publisher-portal.png) - -You'll be importing an API **from URL**. - -![](/media/articles/integrations/azure-api-mgmt/azure/import-api.png) - -Set the following parameters: - -| Parameter | Description | -| --------- | ----------- | -| Specification document URL | The URL Azure will use to retrieve your API's specification. For this example, use `http://calcapi.cloudapp.net/calcapi.json`. | -| Specification format | The API specification format. Use `Swagger`. | -| New/Existing API | set this to **New** | -| Web API URL suffix | The value appended to the base URL of your API management service that uniquely identifies the API you're currently creating, such as `calc` | -| Web API URL scheme | The protocol used to access your API (for this example, set this to `HTTPs`) | -| Products | Add this API to the `Starter` product. This is a basic, getting-started-with-Azure container that holds your sample products and applies entry-level rate limits to your calls. | - -![](/media/articles/integrations/azure-api-mgmt/azure/import-api-config.png) - -When done, click **Save** to import your API. You'll be redirected to the summary page for your API when it's fully imported. - -![](/media/articles/integrations/azure-api-mgmt/azure/basic-calc-api.png) +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. -Navigate to **Security** > **OAuth 2.0**. - -![](/media/articles/integrations/azure-api-mgmt/azure/oauth2-servers.png) +Find the **Security** area of your API Management service instance's near left navigation bar, and click **OAuth 2.0**. -Click on **Add Authorization Server**. You'll see the configuration screen that lets you provide details about your Auth0 tenant. +Click on **Add**. You'll see the **Add OAuth2 service** configuration screen that lets you provide details about your Auth0 tenant. -![](/media/articles/integrations/azure-api-mgmt/azure/new-oauth2-server-config.png) - -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](/api-auth/grant/authorization-code), [Implicit](/api-auth/grant/implicit), [Resource Owner Password](/api-auth/grant/password), [Client Credentials](/api-auth/grant/client-credentials). +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 | | --------- | ----------- | -| Name | A descriptive name for your authorization server, such as `Auth0` | +| 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` | -| Application 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 | +| 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](/api-auth/tutorials/authorization-code-grant#1-get-the-user-s-authorization) | +| 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` | -| Application authentication methods | Method used to authenticate the application; Auth0's is `BASIC` | +| 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) | +| 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. +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 **Save** to persist your changes. - -![](/media/articles/integrations/azure-api-mgmt/azure/new-server-saved.png) +When complete, click **Create** to persist your changes. ### Set the Allowed Callback URL @@ -124,53 +97,37 @@ 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. You can do so using the Azure Publisher Portal. - -Begin by navigating to the APIs tab, and select the Basic Calculator API. - -![](/media/articles/integrations/azure-api-mgmt/azure/api-list.png) +Before you can use Auth0 to secure your API, you'll need to set your API to use Auth0. -Click over to the **Security** tab. +In the near-left navigation column, click **APIs**. Select the Basic Calculator API; this redirects you to the **Design** tab. -![](/media/articles/integrations/azure-api-mgmt/azure/security.png) +Click over to the **Settings** tab. -Under **User Authorization**, select **OAuth 2.0**. In the new **Authorization Server** field that appears, select the server you configured in the previous step. - -![](/media/articles/integrations/azure-api-mgmt/azure/set-auth0-as-authserver.png) +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 Portal** to launch the developer-facing side of your APIs. - -![](/media/articles/integrations/azure-api-mgmt/azure/developer-portal.png) - -Go to APIs > Basic Calculator (or the API you've created for this tutorial). +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. -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-apis.png) +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. -This opens up to the page where you can make a `GET` call that allows you to add two integers. - -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-calculator.png) - -Click Try It. This will bring up the page where you can provide the parameters for your call. +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**. -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-try-it.png) - 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. -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-auth.png) - 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. -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-token.png) - 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. -![](/media/articles/integrations/azure-api-mgmt/azure/dev-portal-200-response.png) +## 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 @@ -179,7 +136,7 @@ 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. +4. Secured your API using Auth0 and (optionally) verified the Access Token. <%= include('./_stepnav', { prev: ["1. Configure Auth0", "/integrations/azure-api-management/configure-auth0"] diff --git a/articles/integrations/azure-api-management/index.md b/articles/integrations/azure-api-management/index.md index 5eb9c2eb7d..f3419f00af 100644 --- a/articles/integrations/azure-api-management/index.md +++ b/articles/integrations/azure-api-management/index.md @@ -1,5 +1,12 @@ --- 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 diff --git a/articles/integrations/azure-tutorial.md b/articles/integrations/azure-tutorial.md index fe86d8bceb..e3f8078c28 100644 --- a/articles/integrations/azure-tutorial.md +++ b/articles/integrations/azure-tutorial.md @@ -1,41 +1,47 @@ --- 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 -From an Auth0 integration perspective, the code is the same, regardless of where your app is running: on Microsoft Azure or your local dev environment. +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: -To integrate applications supported by the Microsoft Azure platform, consider these tutorials: - -* [ASP.NET application](/server-platforms/aspnet)
      +* [ASP.NET application](/quickstart/backend/aspnet-core-webapi-v1_1)
      Simple non-intrusive integration with any version of ASP.NET. -* [Node.js application](/server-platforms/nodejs)
      +* [Node.js application](/quickstart/backend/nodejs)
      Integration using [passport](http://passportjs.org/). -* [Microsoft Azure Mobile Services](http://blog.auth0.com/2013/03/17/Authenticate-Azure-Mobile-Services-apps-with-Everything-using-Auth0/)
      -Blog post explaining how to integrate with a Microsoft Azure Mobile Services backend. - --- ### Tip: change Auth0 configuration when deploying to Microsoft Azure -There is one consideration that you might want to take into account when deploying to Microsoft Azure (or any other environment). +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`. -We recommend creating one application per environment in Auth0 (such as "Dev", "Test", "QA", and so on). +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. -Each application has a different `Client Id` and `Client Secret` and can be configured with a different callback URL. You can use the [Web.config transformations](http://msdn.microsoft.com/en-us/library/dd465326.aspx) to apply a transformation depening on the Build Configuration you use. For instance +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. -`Web.config` -``` + +This is the base configuration in `Web.config`: + +```xml ``` -`Web.Release.config` -``` +The following snippet, `Web.Release.config`, contains the necessary transformations. We want to utilize the `Release` build and are targeting Production. + +```xml @@ -45,9 +51,9 @@ Each application has a different `Client Id` and `Client Secret` and can be conf ``` -Then, whenever you have to reference the ClientID, Secret or callback, you use this syntax: +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 ``` -Whether you deploy to Microsoft Azure Web Sites or a Cloud Service the Web.config transformation will run. +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 -To test your web.config transforms you can use this [awesome tool](http://webconfigtransformationtester.apphb.com/). +Use the [Web.config Transformation Tester](http://webconfigtransformationtester.apphb.com/) to verify the results of any `web.config` transformations. ::: diff --git a/articles/integrations/configuration-to-query-users-from-google-apps.md b/articles/integrations/configuration-to-query-users-from-google-apps.md deleted file mode 100644 index d94aad38df..0000000000 --- a/articles/integrations/configuration-to-query-users-from-google-apps.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -description: How to setup the configuration needed to query users from a Google Apps domain. ---- -# Enable Ability to Query Users from a Google Apps Domain - -In order to query [Google Apps](https://admin.google.com) domain users, you must enable API access. - -::: note -You must be a Google Apps domain administrator to make these changes. -::: - -1. Log in to the Google Apps Admin console, and select **Security**. - -![Google Admin Console](/media/articles/google-admin-sdk/google-apps-admin.png) - -2. Check **Enable API access**. - -![Google Apps API Reference](/media/articles/google-admin-sdk/api-reference.png) - -## Keep reading - -:::next-steps -* [Google Apps Admin SDK](https://developers.google.com/admin-sdk/) -* [Enable API access in the Admin console](https://support.google.com/a/answer/60757?hl=en) -::: \ No newline at end of file diff --git a/articles/integrations/configure-wsfed-application.md b/articles/integrations/configure-wsfed-application.md index e871f688bf..d6629e86c7 100644 --- a/articles/integrations/configure-wsfed-application.md +++ b/articles/integrations/configure-wsfed-application.md @@ -1,18 +1,23 @@ --- 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`. +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: +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 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. +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 diff --git a/articles/integrations/google-cloud-platform.md b/articles/integrations/google-cloud-platform.md index 0f8d1a334c..5b8581ee99 100644 --- a/articles/integrations/google-cloud-platform.md +++ b/articles/integrations/google-cloud-platform.md @@ -2,6 +2,11 @@ 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 @@ -56,7 +61,7 @@ Field | Description `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 signature. Set this to `"https://${account.namespace}/.well-known/jwks.json"` +`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. @@ -187,7 +192,7 @@ You'll get the following response: 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`: +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) @@ -209,4 +214,4 @@ Perform a `GET` request to your API with an Authorization Header of `Bearer {ACC } ``` -And that's it! \ No newline at end of file +And that's it! diff --git a/articles/integrations/index.md b/articles/integrations/index.md index c5106ee5a8..c73d303ef5 100644 --- a/articles/integrations/index.md +++ b/articles/integrations/index.md @@ -2,33 +2,181 @@ 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

      -

      - Take a look below to find tutorials on integrating Auth0 with other applications and services! +

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

      • -
    • - Single Sign On Integrations -

      - Learn how to set up Single Sign On between Auth0 and various services. -

      -
      • -
    \ No newline at end of file + diff --git a/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md b/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md index 7e804f2e03..77803499d1 100644 --- a/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md +++ b/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md @@ -1,17 +1,24 @@ --- -description: How to integrate Auth0 with Amazon Cognito using an OpenID Connect Provider. +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](/identityproviders#social) (Facebook, Twitter, and so on), [Enterprise providers](/identityproviders#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. +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 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). +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. @@ -57,7 +64,7 @@ Now, you need to create an Identity Pool in the [Cognito Console](https://consol ![Confirmation page](/media/articles/scenarios/amazon-cognito/allow-role.png) -1. Click **Edit Identity Pool** to view the the Identity Pool ID. +1. Click **Edit Identity Pool** to view the Identity Pool ID. ![View the Identity Pool ID](/media/articles/scenarios/amazon-cognito/pool-id.png) @@ -67,7 +74,7 @@ Now, you need to create an Identity Pool in the [Cognito Console](https://consol ## 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. +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**. @@ -75,7 +82,7 @@ By default Auth0 will use the HS256 signature algorithm which is not supported i ## Implementation -You can use [Auth0 Lock](https://github.com/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). +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. @@ -102,6 +109,6 @@ dataset.synchronize() ## Keep reading ::: next-steps -* [Amazon Cognito: Open ID Connect Providers](http://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html) +* [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/articles/integrations/marketing/adobe-campaign/index.md b/articles/integrations/marketing/adobe-campaign/index.md index 21b8e1d1f8..9e1dcd8e58 100644 --- a/articles/integrations/marketing/adobe-campaign/index.md +++ b/articles/integrations/marketing/adobe-campaign/index.md @@ -1,19 +1,20 @@ --- -title: Adobe Campaign Integration -description: Learn how to import your Auth0 user data into Adobe Campaign. +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 --- -# Adobe Campaign Integration +# Export User Data To Adobe Campaign -## Import Users 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). -To import your Auth0 users into Adobe Campaign: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file into Adobe Campaign with the [Adobe Campaign Import Wizard](https://docs.campaign.adobe.com/doc/AC/en/PTF_Importing-Exporting_data_About_generic_import_and_export.html). - -### Create a User Data File +## 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. @@ -34,10 +35,10 @@ User Field | Column Name 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 +## Import a user data file ::: note -[Adobe Campaign Documentation: Importing Data](https://docs.campaign.adobe.com/doc/AC/en/PTF_Importing-Exporting_data_Importing_data.html) +[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**. @@ -52,20 +53,14 @@ 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. -![Adobe Campaign Import Wizard Template Selection](/media/articles/integrations/marketing/adobe-campaign/template-selection.png) - 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. -![Adobe Campaign Import Wizard Field Mapping](/media/articles/integrations/marketing/adobe-campaign/field-mapping.png) - 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. -![Adobe Campaign Import Wizard Data Import Execution](/media/articles/integrations/marketing/adobe-campaign/import-execution.png) - That's it! You successfully imported your Auth0 users into Adobe Campaign. diff --git a/articles/integrations/marketing/alterian/index.md b/articles/integrations/marketing/alterian/index.md index 689adc8fac..5f39fbdff9 100644 --- a/articles/integrations/marketing/alterian/index.md +++ b/articles/integrations/marketing/alterian/index.md @@ -1,19 +1,19 @@ --- -title: Alterian Integration -description: Learn how to import your Auth0 user data into Alterian. +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 --- -# Alterian Integration +# Export User Data To Alterian -## Import Users 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. -To import your Auth0 users into Alterian: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file into Alterian with the Campaign Manager's Data Import tool. - -### Create a User Data File +## 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. @@ -34,7 +34,7 @@ User Field | Column Name 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 +## 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) @@ -56,6 +56,6 @@ To import your CSV file into Alterian, follow these steps: ![Data Import: New Imports](/media/articles/integrations/marketing/alterian/new-data-imports.png) -7. After you've reviewed your settings, click **Run Processess**. +7. After you've reviewed your settings, click **Run Processes**. That's it! You successfully imported your Auth0 users into Alterian. diff --git a/articles/integrations/marketing/constant-contact/index.md b/articles/integrations/marketing/constant-contact/index.md index 6bbb815a23..55048e1ca4 100644 --- a/articles/integrations/marketing/constant-contact/index.md +++ b/articles/integrations/marketing/constant-contact/index.md @@ -1,19 +1,19 @@ --- -title: Constant Contact Integration -description: Learn how to import your Auth0 user data into Constant Contact. +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 --- -# Constant Contact Integration +# Export User Data To Constant Contact -## Import Users 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. -To import your Auth0 users into Constant Contact: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file on the Constant Contact dashboard. - -### Create a User Data File +## 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. @@ -34,7 +34,7 @@ User Field | Column Name 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 +## 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) diff --git a/articles/integrations/marketing/eloqua/index.md b/articles/integrations/marketing/eloqua/index.md index e5b57bc699..7b3e3bad71 100644 --- a/articles/integrations/marketing/eloqua/index.md +++ b/articles/integrations/marketing/eloqua/index.md @@ -1,19 +1,20 @@ --- -title: Oracle Eloqua Integration -description: Learn how to import your Auth0 user data into Eloqua. +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 --- -# Oracle Eloqua Integration +# Export User Data To Oracle Eloqua -## Import Users to 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. -To import your Auth0 users into Eloqua: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file using Oracl Eloqua's contact upload wizard. - -### Create a User Data File +## 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. @@ -34,7 +35,7 @@ User Field | Column Name 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 +## 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) diff --git a/articles/integrations/marketing/index.md b/articles/integrations/marketing/index.md index a11730596e..b562fe8e1b 100644 --- a/articles/integrations/marketing/index.md +++ b/articles/integrations/marketing/index.md @@ -1,12 +1,16 @@ --- classes: topic-page -title: Marketing Integrations -description: Learn how to integrate Auth0 with marketing applications and services. +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 ---
    -

    Marketing Integrations

    +

    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!

    diff --git a/articles/integrations/marketing/mailchimp/index.md b/articles/integrations/marketing/mailchimp/index.md index e3c7f2e62b..6b9c68dafc 100644 --- a/articles/integrations/marketing/mailchimp/index.md +++ b/articles/integrations/marketing/mailchimp/index.md @@ -1,19 +1,19 @@ --- -title: MailChimp Integration -description: Learn how to import your Auth0 user data into MailChimp. +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 --- -# MailChimp Integration +# Export User Data To MailChimp -## Import Users 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/). -To import your Auth0 users into MailChimp: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file into MailChimp on the [MailChimp Dashboard](https://login.mailchimp.com/). - -### Create a User Data File +## 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. @@ -38,7 +38,7 @@ User Field | Column Name 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 +## 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) diff --git a/articles/integrations/marketing/marketo/index.md b/articles/integrations/marketing/marketo/index.md index 06e062f8ae..4df61e62c9 100644 --- a/articles/integrations/marketing/marketo/index.md +++ b/articles/integrations/marketing/marketo/index.md @@ -1,19 +1,19 @@ --- -title: Marketo Integration -description: Learn how to import your Auth0 user data into Marketo. +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 --- -# Marketo Integration +# Export User Data To Marketo -## Import Users 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. -To import your Auth0 users into Marketo: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file 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 +## 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. @@ -34,7 +34,7 @@ User Field | Column Name 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 +### Import a user data file ::: note [Marketo Documentation: Bulk Lead Import](http://developers.marketo.com/rest-api/bulk-import/bulk-lead-import/) diff --git a/articles/integrations/marketing/sailthru/index.md b/articles/integrations/marketing/sailthru/index.md index 2a8ecfc2e9..c4eaeb32a1 100644 --- a/articles/integrations/marketing/sailthru/index.md +++ b/articles/integrations/marketing/sailthru/index.md @@ -1,19 +1,19 @@ --- -title: Sailthru Integration -description: Learn how to import your Auth0 user data into Sailthru. +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 --- -# Sailthru Integration +# Export User Data To Sailthru -## Import Users 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. -To import your Auth0 users into Sailthru: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file to a list on your Sailthru dashboard. - -### Create a User Data File +## 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. @@ -34,7 +34,7 @@ User Field | Column Name 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 +### 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) diff --git a/articles/integrations/marketing/salesforce-marketing-cloud/index.md b/articles/integrations/marketing/salesforce-marketing-cloud/index.md index c7cc7a1c73..95a203e3a0 100644 --- a/articles/integrations/marketing/salesforce-marketing-cloud/index.md +++ b/articles/integrations/marketing/salesforce-marketing-cloud/index.md @@ -1,19 +1,20 @@ --- -title: Salesforce Marketing Cloud Integration -description: Learn how to import your Auth0 user data into Salesforce Marketing Cloud. +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 --- -# Salesforce Marketing Cloud Integration +# Export User Data To Salesforce Marketing Cloud -## Import Users 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). -To import your Auth0 users into Salesforce Marketing Cloud: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file into Salesforce Marketing Cloud using [Email Studio](https://help.marketingcloud.com/en/documentation/exacttarget/getting_started/). - -### Create a User Data File +## 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. @@ -34,7 +35,7 @@ User Field | Column Name 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 +## 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/) diff --git a/articles/integrations/marketing/salesforce/index.md b/articles/integrations/marketing/salesforce/index.md index 5c3b49aa12..586964c0f1 100644 --- a/articles/integrations/marketing/salesforce/index.md +++ b/articles/integrations/marketing/salesforce/index.md @@ -1,19 +1,19 @@ --- -title: Salesforce Integration -description: Learn how to import your Auth0 user data into Salesforce. +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 --- -# Salesforce Integration +# Export User Data To Salesforce -## Import Users 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). -To import your Auth0 users into Salesforce: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file into Salesforce using the [Data Import Wizard](https://help.salesforce.com/articleView?id=data_import_wizard.htm). - -### Create a User Data File +## 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. @@ -38,7 +38,7 @@ User Field | Column Name 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 +## 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) diff --git a/articles/integrations/marketing/watson-campaign-automation/index.md b/articles/integrations/marketing/watson-campaign-automation/index.md index c3c72a65df..5f65f357ce 100644 --- a/articles/integrations/marketing/watson-campaign-automation/index.md +++ b/articles/integrations/marketing/watson-campaign-automation/index.md @@ -1,19 +1,19 @@ --- -title: Watson Campaign Automation Integration -description: Learn how to import your Auth0 user data into Watson Campaign Automation. +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 --- -# Watson Campaign Automation Integration +# Export User Data To Watson Campaign Automation -## Import Users 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. -To import your Auth0 users into Watson Campaign Automation: - -- Export your user data as a CSV file with the [User Import / Export Extension](/extensions/user-import-export). -- Import the file (database) on your Watson Campaign Automation dashboard. - -### Create a User Data File +## 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. @@ -38,7 +38,7 @@ User Field | Column Name 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 +## 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) diff --git a/articles/integrations/office-365-custom-provisioning.md b/articles/integrations/office-365-custom-provisioning.md index 2cefb0cf2d..cddf7399d4 100644 --- a/articles/integrations/office-365-custom-provisioning.md +++ b/articles/integrations/office-365-custom-provisioning.md @@ -1,12 +1,20 @@ --- 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 SSO for these users. +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, Google Apps, ... logins to your Office 365 environment. +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 @@ -39,14 +47,14 @@ 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 + 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 the rule code. +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. @@ -54,7 +62,7 @@ In the code you'll also see that the rule will wait about 15 seconds after the u 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://tehsis.github.io/webtaskio-canirequire/ + // https://auth0-extensions.github.io/canirequire/ var rp = require('request-promise'); var uuidv4 = require('uuid'); @@ -62,17 +70,17 @@ function (user, context, callback) { 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 + // it will look like // https://manage.auth0.com/#/externalapps/{the_client_id}/settings - var AUTH0_OFFICE365_CLIENT_ID = 'CLIENT_ID_OF_MY_THIRD_PARTY_APP_IN_AUTH0'; + 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 = 'mycompanyurl.onmicrosoft.com'; + var AAD_DOMAIN = configuration.AAD_DOMAIN; // The Application ID generated while creating the Azure AD app. - var AAD_APPLICATION_ID = 'fc885c73-ce83-4d1e-9fo3-kako45460489'; + var AAD_APPLICATION_ID = configuration.AAD_APPLICATION_ID; // The generated API key for the Azure AD app. - var AAD_APPLICATION_API_KEY = 'ZqnwPIsiMP07Wz7AQkx0RsD7mYTElny1tpKot8lizE9='; + 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 @@ -119,7 +127,7 @@ function (user, context, callback) { .then(connectWithUser) .catch(callback); - // Requests an access_token to interact with Windows Graph API. + // Requests an Access Token to interact with Windows Graph API. function getAzureADToken() { var options = { method: 'POST', @@ -139,7 +147,7 @@ function (user, context, callback) { return rp(options); } - // Gets the access_token requested above and assembles a new request + // 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; @@ -219,7 +227,7 @@ function (user, context, callback) { } // After provisioning the user and giving a license to them, we record - // (on Auth) that this Google Apps user has already been provisioned. We + // (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() { diff --git a/articles/integrations/office-365.md b/articles/integrations/office-365.md index eccdf8653a..03c17657ba 100644 --- a/articles/integrations/office-365.md +++ b/articles/integrations/office-365.md @@ -1,10 +1,16 @@ --- 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. +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 @@ -24,7 +30,7 @@ Office 365 uses Azure AD as an identity store which supports different account m 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. +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.). @@ -76,7 +82,7 @@ Set-MsolDomainAuthentication -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/yNqQMENaYIONxAaQmrct341tZ9joEjTi/FederationMetadata/2007-06/FederationMetadata.xml?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" @@ -159,19 +165,23 @@ 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: -```JavaScript +```js function (user, context, callback) { - const office365ClientId = 'xxxxxx'; // put the right client id + // 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 === 'fabrikam.be') { - return 'urn:fabrikam.be'; - } else if (domain === 'contoso.com') { - return 'urn:contoso.com'; + if (domain === primaryDomain) { + return 'urn:' + primaryDomain; + } else if (domain === secondaryDomain) { + return 'urn:' + secondaryDomain; } return null; } diff --git a/articles/integrations/office365-connection-deprecation-guide.md b/articles/integrations/office365-connection-deprecation-guide.md index 675e313065..28a608c5ca 100644 --- a/articles/integrations/office365-connection-deprecation-guide.md +++ b/articles/integrations/office365-connection-deprecation-guide.md @@ -1,5 +1,14 @@ --- 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 diff --git a/articles/integrations/sharepoint-apps.md b/articles/integrations/sharepoint-apps.md index ebc09afba0..54666c43c3 100644 --- a/articles/integrations/sharepoint-apps.md +++ b/articles/integrations/sharepoint-apps.md @@ -1,9 +1,14 @@ --- 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. +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. @@ -41,7 +46,7 @@ Since Auth0 is in between your app and the Office 365 infrastructure, you need t * `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) +* `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: @@ -76,7 +81,7 @@ Users will install your app from the Office Marketplace. When they click on the ![](/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). +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 diff --git a/articles/integrations/sharepoint.md b/articles/integrations/sharepoint.md index 73c8ed6552..4870a916cb 100644 --- a/articles/integrations/sharepoint.md +++ b/articles/integrations/sharepoint.md @@ -1,10 +1,15 @@ --- -description: How to integrate with SharePoint 2010/2013, including setup, troubleshooting, acessing logs and next steps. +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. +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 @@ -74,11 +79,11 @@ Depending on which claims have been mapped when installing the claims provider t ## Customizing the Login Page -You can customize the login page by following the instructions in the [documentation on customizing the login page](/hosted-pages/login#how-to-customize-your-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. +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. @@ -89,14 +94,43 @@ You need to add a reference to jQuery at the top of the `` section of the Before calling `lock.show()`, add code to modify the HTML DOM that adds the link. ```js -lock.on('signin ready', function() { - $('.auth0-lock-tabs-container') - .after(''); - }); +// 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) @@ -135,7 +169,7 @@ When David logs in using his Azure AD account (and the Security Groups attribute ![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)**. +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) { diff --git a/articles/integrations/sso/_template.md b/articles/integrations/sso/_template.md index b103547d16..3cf0d599a6 100644 --- a/articles/integrations/sso/_template.md +++ b/articles/integrations/sso/_template.md @@ -1,20 +1,22 @@ -# ${service} Single Sign On Integration +# 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 tutorial are valid for Active Directory Rights Management Services 2008 and earlier. +The steps in this guide are valid for Active Directory Rights Management Services 2008 and earlier. ::: <% } %> -The ${service} Single Sign On (SSO) Integration lets your users log in to ${service} with Auth0 [identity providers](/identityproviders), and provides SSO to [configured applicationss](/sso/current/setup). +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 a New SSO Integration +## Create an SSO Integration -Navigate to [Dashboard > SSO Integrations](${manage_url}/#/externalapps) and click **+ Create New 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) -Select the **${service}** option. +Next, select a provider. ![](/media/articles/sso/integrations/options.png) @@ -22,13 +24,16 @@ Set the name for your SSO Integration. Click **Create**. ![](/media/articles/sso/integrations/name.png) -You will be brought to the **${service} Configuration Instructions** page. We'll perform these steps in a later section. +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) -Next, click on the **Settings** tab to configure the integration's settings. +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 -## Configure Settings +### Settings On the **Settings** page, configure the following values: @@ -88,6 +93,16 @@ On the **Settings** page, configure the following values: The connection to use with this integration, typically an Active Directory connection. <% } %> + <% if (service === "Sentry") { %> + + Organization Slug + The 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 Prefix + Your URL prefix if you're using Sentry Community Edition; otherwise, leave blank. + + <% } %> <% if (service === "Slack") { %> Team Name @@ -133,24 +148,27 @@ On the **Settings** page, configure the following values: <% } %> - Use Auth0 instead of the IdP to do single sign on - If enabled, Auth0 will handle Single Sign On instead of ${service}. + 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**. -## Configure ${service} - -When you configure ${service}, refer to the **${service} Configuration Instructions** page on [Dashboard > SSO Integrations > ${service}](${manage_url}/#/externalapps/) and follow each of the steps as shown. +### Enable Connections -![](/media/articles/sso/integrations/${img}.png) +<% 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. +::: -## Enable Connections +<% } %> +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). -Click the **Connections** tab for the integration to select which connections you want to enable for this integration. +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}. -## Setup Complete +## Complete Set Up -That's it! You've set up a Single Sign On integration with ${service} and Auth0. Your users can now choose this as a way to authenticate. \ No newline at end of file +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/articles/integrations/sso/ad-rms.md b/articles/integrations/sso/ad-rms.md index 7f835a1f2b..c54065deb4 100644 --- a/articles/integrations/sso/ad-rms.md +++ b/articles/integrations/sso/ad-rms.md @@ -1,11 +1,21 @@ --- -title: Active Directory RMS Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Active Directory RMS and Auth0. +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('./_template', { - service: "Active Directory RMS", - img: "ad-rms" -}) %> +<%= 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/articles/integrations/sso/adobe-sign.md b/articles/integrations/sso/adobe-sign.md new file mode 100644 index 0000000000..ade392a1f9 --- /dev/null +++ b/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/articles/integrations/sso/box.md b/articles/integrations/sso/box.md index 1eff9a1a8d..808a65ec41 100644 --- a/articles/integrations/sso/box.md +++ b/articles/integrations/sso/box.md @@ -1,11 +1,19 @@ --- -title: Box Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Box and Auth0. +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('./_template', { - service: "Box", - img: "box" -}) %> +<%= 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/articles/integrations/sso/cisco-webex.md b/articles/integrations/sso/cisco-webex.md new file mode 100644 index 0000000000..2619fcdd71 --- /dev/null +++ b/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/articles/integrations/sso/cloudbees.md b/articles/integrations/sso/cloudbees.md index ef7a05345f..912c641323 100644 --- a/articles/integrations/sso/cloudbees.md +++ b/articles/integrations/sso/cloudbees.md @@ -1,11 +1,19 @@ --- -title: CloudBees Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with CloudBees and Auth0. +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('./_template', { - service: "CloudBees", - img: "cloudbees" -}) %> +<%= 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/articles/integrations/sso/concur.md b/articles/integrations/sso/concur.md index 510ff39fe0..96a7527cca 100644 --- a/articles/integrations/sso/concur.md +++ b/articles/integrations/sso/concur.md @@ -1,11 +1,19 @@ --- -title: Concur Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Concur and Auth0. +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('./_template', { - service: "Concur", - img: "concur" -}) %> +<%= 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/articles/integrations/sso/datadog.md b/articles/integrations/sso/datadog.md new file mode 100644 index 0000000000..3cf7f55a83 --- /dev/null +++ b/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/articles/integrations/sso/disqus.md b/articles/integrations/sso/disqus.md index 6e840e7fa1..def0e7328a 100644 --- a/articles/integrations/sso/disqus.md +++ b/articles/integrations/sso/disqus.md @@ -1,13 +1,18 @@ --- -title: Disqus Single Sign On Integration -description: How to set up Single Sign On (SSO) integration with Disqus and Auth0. +title: Disqus Single Sign-On Integration +description: Learn how to set up Single Sign-on (SSO) integration with Disqus and Auth0. toc: true -public: true +public: false +topics: + - sso + - disqus +contentType: how-to +useCase: integrate-saas-sso --- -# Disqus Single Sign On Integration +# 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. +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 @@ -32,12 +37,12 @@ Disqus allows you to embed a discussion section onto your site where your users 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 +## Enable and Configure Single Sign-on with Disqus -Once you have installed and configured your Disqus instance, you need to enable Single Sign On. +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). +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. diff --git a/articles/integrations/sso/dropbox.md b/articles/integrations/sso/dropbox.md index aae1f6212d..8e4f2b3105 100644 --- a/articles/integrations/sso/dropbox.md +++ b/articles/integrations/sso/dropbox.md @@ -1,11 +1,19 @@ --- -title: Dropbox Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Dropbox and Auth0. +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('./_template', { - service: "Dropbox", - img: "dropbox" -}) %> +<%= 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/articles/integrations/sso/dynamics-crm.md b/articles/integrations/sso/dynamics-crm.md index de51ff191b..70382fd3bc 100644 --- a/articles/integrations/sso/dynamics-crm.md +++ b/articles/integrations/sso/dynamics-crm.md @@ -1,11 +1,20 @@ --- -title: Microsoft Dynamics CRM Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Microsoft Dynamics CRM and Auth0. +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('./_template', { - service: "Microsoft Dynamics CRM", - img: "dynamics-crm" -}) %> +<%= 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/articles/integrations/sso/echosign.md b/articles/integrations/sso/echosign.md deleted file mode 100644 index c0817a0655..0000000000 --- a/articles/integrations/sso/echosign.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: EchoSign Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Adobe EchoSign and Auth0. -toc: true -public: true ---- - -<%= include('./_template', { - service: "EchoSign", - img: "echosign" -}) %> diff --git a/articles/integrations/sso/egencia.md b/articles/integrations/sso/egencia.md new file mode 100644 index 0000000000..032d4f2031 --- /dev/null +++ b/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/articles/integrations/sso/egnyte.md b/articles/integrations/sso/egnyte.md index 682c83d828..fd5395bcac 100644 --- a/articles/integrations/sso/egnyte.md +++ b/articles/integrations/sso/egnyte.md @@ -1,11 +1,19 @@ --- -title: Egnyte Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Egnyte and Auth0. +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('./_template', { - service: "Egnyte", - img: "egnyte" -}) %> +<%= 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/articles/integrations/sso/eloqua.md b/articles/integrations/sso/eloqua.md new file mode 100644 index 0000000000..3c1fe2c7e2 --- /dev/null +++ b/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/articles/integrations/sso/freshdesk.md b/articles/integrations/sso/freshdesk.md new file mode 100644 index 0000000000..46018221fe --- /dev/null +++ b/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/articles/integrations/sso/github-enterprise-cloud.md b/articles/integrations/sso/github-enterprise-cloud.md new file mode 100644 index 0000000000..8ad8b8220d --- /dev/null +++ b/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/articles/integrations/sso/github-enterprise-server.md b/articles/integrations/sso/github-enterprise-server.md new file mode 100644 index 0000000000..3a49e22ce5 --- /dev/null +++ b/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/articles/integrations/sso/google-workspace.md b/articles/integrations/sso/google-workspace.md new file mode 100644 index 0000000000..b9abad69f3 --- /dev/null +++ b/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/articles/integrations/sso/heroku.md b/articles/integrations/sso/heroku.md new file mode 100644 index 0000000000..9ad96804fb --- /dev/null +++ b/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/articles/integrations/sso/hosted-graphite.md b/articles/integrations/sso/hosted-graphite.md new file mode 100644 index 0000000000..e72168fcc7 --- /dev/null +++ b/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/articles/integrations/sso/index.md b/articles/integrations/sso/index.md index d01d7da474..afe2efda39 100644 --- a/articles/integrations/sso/index.md +++ b/articles/integrations/sso/index.md @@ -1,44 +1,48 @@ --- -title: Single Sign On Integrations -description: Overview of Auth0 Single Sign On (SSO) Integrations. +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 Integrations - -Single Sign On (SSO) Integrations enable the use of external services for single sign-on. +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) -- [Disqus](/integrations/sso/disqus) +- [Datadog](/integrations/sso/datadog) - [Dropbox](/integrations/sso/dropbox) -- [Microsoft Dynamics CRM](/integrations/sso/dynamics-crm) -- [Adobe Echosign](/integrations/sso/echosign) +- [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) -- [SalesForce](/integrations/sso/salesforce) -- [SharePoint](/integrations/sso/sharepoint) +- [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) - -## 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 **Configuration Instructions** page for the provider, follow the instructions to complete the SSO Integration. diff --git a/articles/integrations/sso/litmos.md b/articles/integrations/sso/litmos.md new file mode 100644 index 0000000000..d29d7ccc42 --- /dev/null +++ b/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/articles/integrations/sso/new-relic.md b/articles/integrations/sso/new-relic.md index 8838d04cb3..68fbf8906b 100644 --- a/articles/integrations/sso/new-relic.md +++ b/articles/integrations/sso/new-relic.md @@ -1,11 +1,20 @@ --- -title: New Relic Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with New Relic and Auth0. +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') %> -<%= include('./_template', { - service: "New Relic", - img: "new-relic" -}) %> diff --git a/articles/integrations/sso/office-365.md b/articles/integrations/sso/office-365.md index 7df5a3843b..155d016fdd 100644 --- a/articles/integrations/sso/office-365.md +++ b/articles/integrations/sso/office-365.md @@ -1,11 +1,19 @@ --- -title: Office 365 Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Office 365 and Auth0. +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('./_template', { - service: "Office 365", - img: "office-365" -}) %> +<%= 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/articles/integrations/sso/pluralsight.md b/articles/integrations/sso/pluralsight.md new file mode 100644 index 0000000000..48c55cfa21 --- /dev/null +++ b/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/articles/integrations/sso/salesforce.md b/articles/integrations/sso/salesforce.md index 3f615d329d..2946044f0f 100644 --- a/articles/integrations/sso/salesforce.md +++ b/articles/integrations/sso/salesforce.md @@ -1,11 +1,19 @@ --- -title: Salesforce Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Salesforce and Auth0. +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('./_template', { - service: "Salesforce", - img: "salesforce" -}) %> +<%= 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/articles/integrations/sso/sentry.md b/articles/integrations/sso/sentry.md new file mode 100644 index 0000000000..5bf371deb2 --- /dev/null +++ b/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/articles/integrations/sso/sharepoint.md b/articles/integrations/sso/sharepoint.md index f770cc10e6..8fde6b36df 100644 --- a/articles/integrations/sso/sharepoint.md +++ b/articles/integrations/sso/sharepoint.md @@ -1,11 +1,19 @@ --- -title: SharePoint Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with SharePoint and Auth0. +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: true +public: false +topics: + - sso + - sharepoint +contentType: how-to +useCase: integrate-saas-sso --- - -<%= include('./_template', { - service: "SharePoint", - img: "sharepoint" -}) %> +<%= 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/articles/integrations/sso/slack.md b/articles/integrations/sso/slack.md index f450bd207b..7fff98bb76 100644 --- a/articles/integrations/sso/slack.md +++ b/articles/integrations/sso/slack.md @@ -1,15 +1,23 @@ --- -title: Slack Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Slack and Auth0. +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('./_template', { - service: "Slack", - img: "slack" -}) %> +<%= 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](https://get.slack.help/hc/en-us/articles/203772216-Enabling-SAML-based-single-sign-on). +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/articles/integrations/sso/springcm.md b/articles/integrations/sso/springcm.md index 10d1ac7406..ca7ea7e521 100644 --- a/articles/integrations/sso/springcm.md +++ b/articles/integrations/sso/springcm.md @@ -1,11 +1,19 @@ --- -title: SpringCM Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with SpringCM and Auth0. +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('./_template', { - service: "SpringCM", - img: "springcm" -}) %> +<%= 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/articles/integrations/sso/sprout-video.md b/articles/integrations/sso/sprout-video.md new file mode 100644 index 0000000000..9299a866ec --- /dev/null +++ b/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/articles/integrations/sso/tableau-online.md b/articles/integrations/sso/tableau-online.md new file mode 100644 index 0000000000..89848db4c2 --- /dev/null +++ b/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/articles/integrations/sso/tableau-server.md b/articles/integrations/sso/tableau-server.md new file mode 100644 index 0000000000..648e77c4ab --- /dev/null +++ b/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/articles/integrations/sso/workday.md b/articles/integrations/sso/workday.md new file mode 100644 index 0000000000..d77f02f586 --- /dev/null +++ b/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/articles/integrations/sso/workpath.md b/articles/integrations/sso/workpath.md new file mode 100644 index 0000000000..6857d56b43 --- /dev/null +++ b/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/articles/integrations/sso/zendesk.md b/articles/integrations/sso/zendesk.md index 97e8dbb037..f4409ec17d 100644 --- a/articles/integrations/sso/zendesk.md +++ b/articles/integrations/sso/zendesk.md @@ -1,11 +1,19 @@ --- -title: Zendesk Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Zendesk and Auth0. +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('./_template', { - service: "Zendesk", - img: "zendesk" -}) %> +<%= 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/articles/integrations/sso/zoom.md b/articles/integrations/sso/zoom.md index e160025877..c987b3d838 100644 --- a/articles/integrations/sso/zoom.md +++ b/articles/integrations/sso/zoom.md @@ -1,11 +1,19 @@ --- -title: Zoom Single Sign On Integration -description: How to set up a Single Sign On (SSO) integration with Zoom and Auth0. +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('./_template', { - service: "Zoom", - img: "zoom" -}) %> +<%= 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/articles/integrations/using-auth0-as-an-identity-provider-with-github-enterprise.md b/articles/integrations/using-auth0-as-an-identity-provider-with-github-enterprise.md deleted file mode 100644 index 024189639e..0000000000 --- a/articles/integrations/using-auth0-as-an-identity-provider-with-github-enterprise.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -description: How to use Auth0 as an identity provider with GitHub Enterprise. -crews: crew-2 ---- - -# Using Auth0 as an Identity Provider with GitHub Enterprise - -When using GitHub Enterprise, you can configure Auth0 to act as an identity provider. - -## Configure Your Auth0 Application - -Create a new or select an existing Application using the [Applications](${manage_url}/#/applications) page of the Management Dashboard. - -On the row associated with your chosen Application, click on the **Addons** button, which is the second button from the right on the appropriate Application row. - -![](/media/articles/scenarios/github-enterprise/clients.png) - -When the **Addons** page opens, set the slider in the box called **SAML2 WEB APP** to the right. The slider will turn green to indicate that the Addon is active. - -![](/media/articles/scenarios/github-enterprise/addons.png) - -You will then be presented with the Addon Settings page: - -![](/media/articles/scenarios/github-enterprise/addon-settings.png) - -Set the following configuration variables: - -* **Application Callback URL**: the Assertion consumption URL of your GitHub Exterprise instance; - * Example: `https://your_github_enterprise_url/saml/consume` -* **Settings**: the URL for your GitHub Enterprise instance set as the `audience`. - * Example: `{ "audience": "https://your_github_enterprise_url" }` - -You can check the validity of these settings by clicking **Debug**. - -To persist your changes, click **Save**. - -To obtain the values necessary for configuring your GitHub Enterprise account, switch over to the **Usage** tab. - -![](/media/articles/scenarios/github-enterprise/addon-usage.png) - -You will need values/files for the following configuration settings: - -* Issuer; -* Auth0 Certificate (download this file so that you can upload it to GitHub); -* Identity Provider Login URL. - -## Configure Your GitHub Enterprise Account - -Log in to your GitHub Enterprise Management Console. You should have a custom URL that follows this format: `https:// your_github_enterprise_url:8443/setup/settings`. - -Navigate to the **Authentication** section under the **Settings** page. - -![](/media/articles/scenarios/github-enterprise/auth-settings.png) - -Set the following configuration variables: - -* **Authentication Type**: Set as *SAML*; -* **Single sign-on URL**: Paste the *Identity Provider Login URL* copied from the Auth0 Dashboard here; -* **Issuer**: Paste the *Issuer* value copied from the Auth0 Dashboard here. The format of the value is `urn:.auth0.com`. - -Upload the Auth0 Certificate you downloaded under **Replace Certificate**. - -![](/media/articles/scenarios/github-enterprise/auth-certificate.png) - -Click **Save** to persist your changes. Saving automatically restarts your GitHub Enterprise instance. At this point, anyone accessing your GitHub Enterprise will be prompted to sign in with Auth0. diff --git a/articles/integrations/using-auth0-to-secure-a-cli.md b/articles/integrations/using-auth0-to-secure-a-cli.md index 6baac904f5..deacfe2ad6 100644 --- a/articles/integrations/using-auth0-to-secure-a-cli.md +++ b/articles/integrations/using-auth0-to-secure-a-cli.md @@ -1,40 +1,44 @@ --- -title: Using Auth0 to secure a CLI +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 + - --- -# Using Auth0 to secure a CLI +# Secure a CLI with Auth0 -Authentication in CLI programs is straightforward if the identity provider supports sending credentials, like database connections, SMS passwordless and AD. If the identity provider requires a browser redirect, then the process is slightly more complicated. +There are three ways to secure a CLI with Auth0 in order of most secure to least secure: -::: note - If your identity provider supports sending credentials, then the grant you should implement is the [Client Credentials](/api-auth/grant/client-credentials). For details on how to implement this refer to [How to implement the Client Credentials Grant](/api-auth/tutorials/client-credentials). -::: - -Auth0 implements the [Proof Key for Code Exchange by OAuth Public Clients](https://tools.ietf.org/html/rfc7636). This flow makes it easy to add authentication to a CLI while keeping higher standards of security. +* [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) -## How PKCE works +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. -Traditionally, public applications (such as mobile apps, SPAs and CLIs) have used the [implicit flow](/api-auth/grant/implicit) to obtain a token. In this flow, there's no __application authentication__ because there's no easy way of storing a `client_secret`. +## Device Authorization Flow -The [PKCE flow](/api-auth/grant/authorization-code-pkce) (`pixy` for friends), increases security by adding a cryptographic challenge in the token exchange. This prevents rogue apps to intercept the response from Auth0, and get hold of the token. +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. -## How to implement PKCE +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). -The steps to follow to implement this grant are the following: +## Client Credentials Grant Flow -1. __Create a Code Verifier__. This is a randomly generated value that will be used to generate the `code_challenge` (which will be sent in the authorization request). +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. -2. __Create a Code Challenge__. A hashed (`SHA256`) and base64Url encoded value, generated using the `code_verifier`. +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). -3. __Initiate the Authorization Request__. The regular OAuth 2.0 authorization request, with the caveat that now it includes two parameters: the `code_challenge` and the `code_challenge_method` which should be `S256`. If the authorization is successful, then Auth0 will redirect the browser to the callback with a `code` query parameter: `${account.callback}/?code=123`. +## Resource Owner Password Grant Flow -::: warning - In order for the CLI to be able to receive the callback and retrieve the code, it should run on the web server. -::: +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). -4. __Exchange the Authorization Code for a Token__. With the `code`, the program then uses the [/oauth/token endpoint](/api/authentication#authorization-code-pkce-) to obtain a token. In this second step, the CLI program adds a `verifier` parameter with the exact same random secret generated in step 1. Auth0 uses this to correlate and verify that the request originates from the same application. If successful the response is another JSON object, with an `id_token`, and `access_token`. Note that if the `verifier` doesn't match with what was sent in the [/authorize endpoint](/api/authentication#authorization-code-grant-pkce-), the request will fail. +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 - For implementation details and sample scripts, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce). -::: +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/articles/libraries/_includes/_change_get_profile.md b/articles/libraries/_includes/_change_get_profile.md index 41cdc0a986..96838117ae 100644 --- a/articles/libraries/_includes/_change_get_profile.md +++ b/articles/libraries/_includes/_change_get_profile.md @@ -1,5 +1,5 @@ ### Change calls to getProfile() -The deprecated `getProfile()` function was reimplemented in Lock 11. The previous implementation received an [ID Token](/tokens/id-token) as a parameter and returned the user profile. +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](/tokens/access-token) parameter instead. +The new implementation requires an Access Token parameter instead. diff --git a/articles/libraries/_includes/_configure_custom_domain.md b/articles/libraries/_includes/_configure_custom_domain.md index 3e346bdc10..5a98890df2 100644 --- a/articles/libraries/_includes/_configure_custom_domain.md +++ b/articles/libraries/_includes/_configure_custom_domain.md @@ -10,16 +10,16 @@ var lock = new Auth0Lock('${account.clientId}', 'login.your-domain.com', options); ``` -4. Set the `configurationBaseUrl` option to `https://cdn.auth0.com`. +4. Set the `configurationBaseUrl` option to `https://cdn.us.auth0.com`. ``` var options = { - configurationBaseUrl: 'https://cdn.auth0.com' + configurationBaseUrl: 'https://cdn.us.auth0.com' }; ``` ::: note -The CDN URL varies by region. For regions outside of the US, use `https://cdn.{region}.auth0.com` (for example, use `eu` for Europe, `au` for Australia). +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 diff --git a/articles/libraries/_includes/_default_values.md b/articles/libraries/_includes/_default_values.md index ac6d09ca78..48b1b9eff4 100644 --- a/articles/libraries/_includes/_default_values.md +++ b/articles/libraries/_includes/_default_values.md @@ -1,6 +1,6 @@ ### Default values -Auth0.js v9 will default the value of the [scope](/scopes) parameter to `openid profile email`. +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: diff --git a/articles/libraries/_includes/_default_values_lock.md b/articles/libraries/_includes/_default_values_lock.md index 8549aa5117..b66229d099 100644 --- a/articles/libraries/_includes/_default_values_lock.md +++ b/articles/libraries/_includes/_default_values_lock.md @@ -1,6 +1,6 @@ ### Default values -Lock 11 will default the [scope](/scopes) parameter to `'openid profile email'`. This is to make the **Last time you logged in with** window work correctly. +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: diff --git a/articles/libraries/_includes/_embedded_sso.md b/articles/libraries/_includes/_embedded_sso.md index 8a7bbf58d5..bd379358ae 100644 --- a/articles/libraries/_includes/_embedded_sso.md +++ b/articles/libraries/_includes/_embedded_sso.md @@ -1,10 +1,10 @@ -### SSO with embedded authentication +### Single Sign-On with embedded authentication -Apps with embedded login must meet two criteria in order to have SSO. +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](/applications/application-types#first-party-application). SSO with third party applications will not work. +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](/hosted-pages/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/application-types#third-party-application). +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/articles/libraries/_includes/_get_lock_latest_version.md b/articles/libraries/_includes/_get_lock_latest_version.md index 7c1cbac020..8f775a2240 100644 --- a/articles/libraries/_includes/_get_lock_latest_version.md +++ b/articles/libraries/_includes/_get_lock_latest_version.md @@ -1,6 +1,6 @@ ### Update Lock -Update the Lock library using npm or yarn. +Update the Lock library using npm or yarn. ```bash # installation with npm diff --git a/articles/libraries/_includes/_ip_ranges.md b/articles/libraries/_includes/_ip_ranges.md index 28d3422886..b3813c37ce 100644 --- a/articles/libraries/_includes/_ip_ranges.md +++ b/articles/libraries/_includes/_ip_ranges.md @@ -1,7 +1,7 @@ -### Single sign on using IP ranges +### 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. +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/articles/libraries/_includes/_last_logged_in_window.md b/articles/libraries/_includes/_last_logged_in_window.md index 2b00879df0..696166ebfb 100644 --- a/articles/libraries/_includes/_last_logged_in_window.md +++ b/articles/libraries/_includes/_last_logged_in_window.md @@ -1,7 +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](/api-auth/grant/authorization-code) (that is, when specifying `response_type='code'`). It will always prompt for credentials. +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. -The **Last time you logged in with** window will also 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). +### 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/articles/libraries/_includes/_legacy_flows.md b/articles/libraries/_includes/_legacy_flows.md index 00734a885b..b6793b4966 100644 --- a/articles/libraries/_includes/_legacy_flows.md +++ b/articles/libraries/_includes/_legacy_flows.md @@ -1,5 +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](tokens/refresh-token), using [id tokens](/tokens/id-token) to call APIs, and accessing non-standard claims in the user profile. +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/articles/libraries/_includes/_oidc_conformant.md b/articles/libraries/_includes/_oidc_conformant.md index d600036909..ec12a82cf5 100644 --- a/articles/libraries/_includes/_oidc_conformant.md +++ b/articles/libraries/_includes/_oidc_conformant.md @@ -2,4 +2,4 @@ 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 always uses Cross Origin Authentication and does not use the '/ssodata' endpoint, this flag is not longer needed. If specified, it will be ignored. +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/articles/libraries/_includes/_review_get_ssodata.md b/articles/libraries/_includes/_review_get_ssodata.md index 5c9538812c..509974a67a 100644 --- a/articles/libraries/_includes/_review_get_ssodata.md +++ b/articles/libraries/_includes/_review_get_ssodata.md @@ -2,7 +2,7 @@ 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](/api-auth/grant/authorization-code) (such as when you specify `response_type='code'`). It will always return that there is not a current session. +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. @@ -21,6 +21,6 @@ If you are going to keep using `getSSOData()`, take into account the changes in | 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](/hosted-pages/login). It will not return `strategy`, only `name` | +| 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` | -In order for the function to work properly, you need to ask for `scope='openid profile email'` when you initialize Auth0.js. +For the function to work properly, you need to ask for `scope='openid profile email'` when you initialize Auth0.js. diff --git a/articles/libraries/_includes/_spa_js_faq.md b/articles/libraries/_includes/_spa_js_faq.md new file mode 100644 index 0000000000..0595e4e5fb --- /dev/null +++ b/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/articles/libraries/_includes/_verifying_migration.md b/articles/libraries/_includes/_verifying_migration.md index 5d72199ebc..a4edd88b3c 100644 --- a/articles/libraries/_includes/_verifying_migration.md +++ b/articles/libraries/_includes/_verifying_migration.md @@ -1,6 +1,6 @@ ### Verifying your migration -Once you have migrated your codebase, you should no longer see [deprecation notes in your logs](/errors/deprecation-errors). +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. diff --git a/articles/libraries/auth0-android/configuration.md b/articles/libraries/auth0-android/configuration.md index d3c5b085b2..08e87aef3f 100644 --- a/articles/libraries/auth0-android/configuration.md +++ b/articles/libraries/auth0-android/configuration.md @@ -2,6 +2,11 @@ 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 @@ -12,7 +17,7 @@ Auth0.Android can be configured with a variety of options, listed below. The `withConnection` option allows you to specify a connection that you wish to authenticate with. ```java -WebAuthProvider.init(account) +WebAuthProvider.login(account) .withConnection("twitter") .start(this, authCallback); ``` @@ -24,17 +29,17 @@ Code grant is the default mode, and will always be used unless calling `useCodeG 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.init(account) +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. +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.init(account) +WebAuthProvider.login(account) .withScope("openid email profile") .start(this, authCallback); ``` @@ -45,10 +50,10 @@ 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](/tutorials/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. +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.init(account) +WebAuthProvider.login(account) .withConnectionScope("email", "profile", "calendar:read") .start(this, authCallback); ``` @@ -60,17 +65,17 @@ To send additional parameters on the authentication, use `withParameters`: ```java Map parameters = new HashMap<>(); //Add entries -WebAuthProvider.init(account) +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. +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.init(account) +WebAuthProvider.login(account) .withScheme("myapp") .start(this, authCallback); ``` @@ -81,10 +86,10 @@ Scheme must be lowercase! ## withAudience -To provide an audience, use `withAudience`. +To provide an audience, use `withAudience`. ```java -WebAuthProvider.init(account) +WebAuthProvider.login(account) .withScope("openid") .withAudience("https://${account.namespace}/userinfo") .start(this, authCallback); @@ -95,17 +100,17 @@ WebAuthProvider.init(account) 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.init(account) +WebAuthProvider.login(account) .withState("my-custom-state") .start(this, authCallback); ``` ## withNonce -By default a random [nonce](/api-auth/tutorials/nonce) is generated and sent when the response type includes `id_token`. If you need to use a custom value instead, use `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.init(account) +WebAuthProvider.login(account) .withNonce("my-custom-nonce") .start(this, authCallback); ``` diff --git a/articles/libraries/auth0-android/database-authentication.md b/articles/libraries/auth0-android/database-authentication.md index ffa37294e7..430ed70c91 100644 --- a/articles/libraries/auth0-android/database-authentication.md +++ b/articles/libraries/auth0-android/database-authentication.md @@ -2,18 +2,24 @@ 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 the [universal login](/hosted-pages/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/application-grant-types) for more information. +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. +Additionally, specifying the **audience** will yield an OIDC-conformant response during authentication. ```java authentication @@ -33,7 +39,7 @@ authentication ``` ::: note -The default scope used is `openid`. +The default scope used is `openid`. ::: ## Sign up with database connection diff --git a/articles/libraries/auth0-android/index.md b/articles/libraries/auth0-android/index.md index 528d8a08dd..adfdcc3f4d 100644 --- a/articles/libraries/auth0-android/index.md +++ b/articles/libraries/auth0-android/index.md @@ -3,6 +3,13 @@ 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 @@ -18,19 +25,7 @@ Android API version 15 or newer is required. ## Installation -Auth0.Android is available through [Gradle](https://gradle.org/). To install it, simply add the following line to your `build.gradle` file: - -```gradle -dependencies { - compile "com.auth0.android:auth0:1.+" -} -``` - -::: note -You can check for the latest version on the repository [Readme](https://github.com/auth0/auth0.android#installation), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22auth0%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/auth0). -::: - -After adding your Gradle dependency, make sure to remember to sync your project with Gradle files. +<%= include('../../quickstart/native/android/_includes/_gradle.md') %> ## Permissions @@ -69,11 +64,9 @@ account.setOIDCConformant(true); //Use the account in the API applications ``` -Passwordless authentication **cannot be used** with this flag set to `true`. For more information, please see the [OIDC adoption guide](/api-auth/tutorials/adoption). - ## 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: +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 @@ -148,17 +141,17 @@ Finally, don't forget to add the internet permission: 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](hosted-pages/login): +Now, let's authenticate a user by presenting the universal [login page](/universal-login): ```java -WebAuthProvider.init(account) +WebAuthProvider.login(account) .withAudience("https://${account.namespace}/userinfo") .start(this, authCallback); ``` The authentication result will be delivered to the callback. -To ensure an Open ID Connect compliant response 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). +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 @@ -170,7 +163,7 @@ 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. +To get the information associated with a given user's Access Token, you can call the `userInfo` endpoint, passing the token. ```java authentication @@ -223,4 +216,4 @@ Take a look at the following resources to see how the Auth0.Android SDK can be c * [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) -::: \ No newline at end of file +::: diff --git a/articles/libraries/auth0-android/passwordless.md b/articles/libraries/auth0-android/passwordless.md index 56a5578db2..166610f555 100644 --- a/articles/libraries/auth0-android/passwordless.md +++ b/articles/libraries/auth0-android/passwordless.md @@ -2,16 +2,37 @@ 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 -<%= include('../../_includes/_native_passwordless_warning') %> +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. -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 -Note that Passwordless authentication **cannot be used** with the [OIDC Conformant Mode](/api-auth/intro) enabled. +### Enable the Passwordless OTP Grant for the Application -## 1. Request the code +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. @@ -31,7 +52,9 @@ authentication }); ``` -## 2. Input the code +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. @@ -51,6 +74,8 @@ authentication }); ``` +You can use the `loginWithSms` method to send the code received by SMS and authenticate the user. + ::: note -The default scope used is `openid`. +The default scope used is `openid`. ::: diff --git a/articles/libraries/auth0-android/save-and-refresh-tokens.md b/articles/libraries/auth0-android/save-and-refresh-tokens.md index 8d6e5e5fe0..c70ab2403e 100644 --- a/articles/libraries/auth0-android/save-and-refresh-tokens.md +++ b/articles/libraries/auth0-android/save-and-refresh-tokens.md @@ -2,20 +2,22 @@ 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](/refresh-token) that can be used to request a new user token, without forcing the user to perform authentication again. +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. -First, add the library dependency to your build.gradle file: - -```gradle -compile 'com.auth0.android:auth0:1.+' -``` +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. @@ -56,7 +58,7 @@ manager.clearCredentials(); ### 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. +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() { @@ -100,7 +102,7 @@ The methods to obtain, save, check for existence and clearing the credentials ar ### 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. +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; @@ -122,3 +124,12 @@ protected void onActivityResult(int requestCode, int resultCode, Intent data) { 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/articles/libraries/auth0-android/user-management.md b/articles/libraries/auth0-android/user-management.md index 0010b6bde5..51c085825e 100644 --- a/articles/libraries/auth0-android/user-management.md +++ b/articles/libraries/auth0-android/user-management.md @@ -2,16 +2,22 @@ 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 (Read more about [Linking Accounts](/link-accounts) with Auth0) +* 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](/metadata) +* Update [user metadata](/users/concepts/overview-user-metadata) -## Initializing the API Application +## 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. @@ -20,9 +26,9 @@ Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); UsersAPIClient users = new UsersAPIClient(account, "token"); ``` -## Linking users +## 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 be linked, this is the way to go. +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. @@ -42,7 +48,7 @@ users }); ``` -## Unlinking users +## 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). diff --git a/articles/libraries/auth0-php/authentication-api.md b/articles/libraries/auth0-php/authentication-api.md new file mode 100644 index 0000000000..570ccc6e83 --- /dev/null +++ b/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/articles/libraries/auth0-php/basic-use.md b/articles/libraries/auth0-php/basic-use.md new file mode 100644 index 0000000000..758fd798ad --- /dev/null +++ b/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/articles/libraries/auth0-php/index.md b/articles/libraries/auth0-php/index.md new file mode 100644 index 0000000000..666ad55e32 --- /dev/null +++ b/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/articles/libraries/auth0-php/jwt-validation.md b/articles/libraries/auth0-php/jwt-validation.md new file mode 100644 index 0000000000..3c98d21c19 --- /dev/null +++ b/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/articles/libraries/auth0-php/management-api.md b/articles/libraries/auth0-php/management-api.md new file mode 100644 index 0000000000..2fbae10fe9 --- /dev/null +++ b/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/articles/libraries/auth0-php/troubleshooting.md b/articles/libraries/auth0-php/troubleshooting.md new file mode 100644 index 0000000000..cbd531246b --- /dev/null +++ b/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/articles/libraries/auth0-react/index.md b/articles/libraries/auth0-react/index.md new file mode 100644 index 0000000000..c490c1e05e --- /dev/null +++ b/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/articles/libraries/auth0-spa-js/index.md b/articles/libraries/auth0-spa-js/index.md new file mode 100644 index 0000000000..0055131f0e --- /dev/null +++ b/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/articles/libraries/auth0-spa-js/migrate-from-auth0js.md b/articles/libraries/auth0-spa-js/migrate-from-auth0js.md new file mode 100644 index 0000000000..40ce0aa180 --- /dev/null +++ b/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/articles/libraries/auth0-swift/database-authentication.md b/articles/libraries/auth0-swift/database-authentication.md index 2b86867c73..039f9467b1 100644 --- a/articles/libraries/auth0-swift/database-authentication.md +++ b/articles/libraries/auth0-swift/database-authentication.md @@ -1,10 +1,21 @@ --- section: libraries toc: true -description: Using Database Connections with Auth0.Swift +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 @@ -19,12 +30,11 @@ Auth0 password: "secret-password", connection: "Username-Password-Authentication", userMetadata: ["first_name": "First", - "last_name": "Last"] - ) + "last_name": "Last"]) .start { result in switch result { case .success(let user): - print("User Signed up: \(user)") + print("User: \(user)") case .failure(let error): print("Failed with \(error)") } @@ -46,7 +56,7 @@ Auth0 .start { result in switch result { case .success(let credentials): - print("Obtained credentials: \(credentials)") + print("Credentials: \(credentials)") case .failure(let error): print("Failed with \(error)") } diff --git a/articles/libraries/auth0-swift/index.md b/articles/libraries/auth0-swift/index.md index 523332759e..bc88fd539e 100644 --- a/articles/libraries/auth0-swift/index.md +++ b/articles/libraries/auth0-swift/index.md @@ -3,7 +3,15 @@ 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. @@ -14,15 +22,29 @@ Check out the [Auth0.swift repository](https://github.com/auth0/Auth0.swift) on ## Requirements -- iOS 9 or later -- Xcode 8 -- Swift 3.0 +- 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, add the following lines to your `Cartfile`: +If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`: ```ruby github "auth0/Auth0.swift" ~> 1.0 @@ -31,22 +53,25 @@ github "auth0/Auth0.swift" ~> 1.0 Then run `carthage bootstrap`. ::: note -For more information about Carthage usage, check [the official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). +For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). ::: -### Cocoapods +### SPM -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: +If you are using the Swift Package Manager, open the following menu item in Xcode: -```ruby -use_frameworks! -pod 'Auth0', '~> 1.0' +**File > Swift Packages > Add Package Dependency...** + +In the **Choose Package Repository** prompt add this url: + +```text +https://github.com/auth0/Auth0.swift.git ``` -Then, run `pod install`. +Then press **Next** and complete the remaining steps. ::: note -For further reference on Cocoapods, check [the official documentation](http://guides.cocoapods.org/using/getting-started.html). +For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app). ::: ## Adding Auth0 Credentials @@ -66,9 +91,9 @@ You will need to add an `Auth0.plist` file, containing your Auth0 client id and ``` -### Web-based Auth (iOS Only) +### 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: +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 @@ -100,20 +125,30 @@ If your `Info.plist` is not shown in this format, you can **Right Click** on `In 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: +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(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any]) -> Bool { - return Auth0.resumeAuth(url, options: options) +func application(_ application: NSApplication, open urls: [URL]) { + Auth0.resumeAuth(urls) } ``` -#### Authenticate with universal login +#### Authenticate with Universal Login -The first step in adding authentication to your iOS 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](/hosted-pages/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 -To ensure an [OpenID Connect compliant response](/api-auth/intro), 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/intro#how-to-use-the-new-flows). +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 @@ -121,17 +156,21 @@ Auth0 .webAuth() .audience("https://${account.namespace}/userinfo") .start { result in - switch result { + switch result { // Auth0.Result case .success(let credentials): - print("credentials: \(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 -If you need help between the two types of login flows, refer to [Browser-Based vs. Native Login Flows on Mobile Devices](/tutorials/browser-based-vs-native-experience-on-mobile) +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 @@ -146,7 +185,7 @@ Auth0 .start { result in switch result { case .success(let credentials): - print("credentials: \(credentials)") + print("Credentials: \(credentials)") case .failure(let error): print(error) } @@ -155,7 +194,7 @@ Auth0 #### Authenticate using a specific scope -Using scopes can allow you to return specific claims for specfic 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) for further details about them. +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 @@ -166,7 +205,7 @@ Auth0 .start { result in switch result { case .success(let credentials): - print("credentials: \(credentials)") + print("Credentials: \(credentials)") case .failure(let error): print(error) } @@ -175,7 +214,7 @@ Auth0 ### 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, but depending on the requested scope the claims returned may vary. You can also use the `sub` value to call the [Management API](#Management-API) and return a full user profile. +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 @@ -193,12 +232,12 @@ Auth0 ## Next Steps -Take a look at the following resources to see how the Auth0.Swift SDK can be customized for your needs: +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 TouchID Authentication](/libraries/auth0-swift/touchid-authentication) -::: \ No newline at end of file +* [Auth0.Swift Touch ID / Face ID Authentication](/libraries/auth0-swift/touchid-authentication) +::: diff --git a/articles/libraries/auth0-swift/passwordless.md b/articles/libraries/auth0-swift/passwordless.md index f79eb83bdc..664f8e8d7f 100644 --- a/articles/libraries/auth0-swift/passwordless.md +++ b/articles/libraries/auth0-swift/passwordless.md @@ -1,13 +1,20 @@ --- section: libraries toc: true -description: Using Auth0.Swift in Passwordless mode +description: Using Auth0.Swift in passwordless mode +topics: + - libraries + - swift + - passwordless +contentType: how-to +useCase: enable-mobile-auth --- + # Passwordless Authentication with Auth0.Swift -<%= include('../../_includes/_native_passwordless_warning') %> +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. -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 @@ -25,7 +32,7 @@ In this example, requesting the code is done by calling `startPasswordless` with ```swift Auth0 .authentication() - .startPasswordless(email: "support@auth0.com", connection: "email") + .startPasswordless(email: "support@auth0.com") .start { result in switch result { case .success: @@ -44,14 +51,34 @@ Once the user has a code, they can input it. Call the `login` method, and pass i Auth0 .authentication() .login( - usernameOrEmail: "support@auth0.com", - password: "123456", - realm: "Username-Password-Authentication" - ) + 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)") + print("Access Token: \(credentials.accessToken)") case .failure(let error): print(error) } @@ -79,4 +106,4 @@ or | `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`. | +| `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/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md b/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md index acc67867b9..c633a9c650 100644 --- a/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md +++ b/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md @@ -1,35 +1,41 @@ --- 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](/refresh-token) that can be used to request a new user token, without asking for credentials again. +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: +First import the `Auth0` module: ```swift import Auth0 ``` -Next, present the Login: +Next present the Universal Login page: -```swift +```swift let credentialsManager = CredentialsManager(authentication: Auth0.authentication()) Auth0 .webAuth() .scope("openid profile offline_access") .audience("https://${account.namespace}/userinfo") - .start { - switch $0 { + .start { result in + switch result { case .failure(let error): - // Handle the error + // Handle error case .success(let credentials): // Pass the credentials over to the Credentials Manager credentialsManager.store(credentials: credentials) @@ -37,13 +43,17 @@ Auth0 } ``` +::: 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 that you have valid credentials stored in the manager. If not the user can then be directed to authenticate. +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 Page + // Present login screen } ``` @@ -54,21 +64,21 @@ 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 + // Handle error, present login page } - // Valid credentials, you can access the token properties such as `idToken`, `accessToken`. + // 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, then store the renewed credentials to the Keychain and finally return them in the closure. +::: 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. +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. -First thing you need to 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. +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") @@ -77,15 +87,19 @@ Auth0 .webAuth() .scope("openid profile offline_access") .audience("https://${account.namespace}/userinfo") - .start { - switch $0 { + .start { result in + switch result { case .failure(let error): - // Handle the error + // Handle error case .success(let credentials): - guard let accessToken = credentials.accessToken, let refreshToken = credentials.refreshToken else { // Handle Error } - 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 + 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 } } ``` @@ -103,12 +117,19 @@ Auth0 .start { result in switch(result) { case .success(let credentials): - // Store the new Access Token + // 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") - // You do not get a new refresh_token, you can still use the one you originally had + keychain.setString(refreshToken, forKey: "refresh_token") case .failure(let error): keychain.clearAll() - // Handle Error + // Handle error } } ``` diff --git a/articles/libraries/auth0-swift/touchid-authentication.md b/articles/libraries/auth0-swift/touchid-authentication.md index 6f47432214..e86bcad058 100644 --- a/articles/libraries/auth0-swift/touchid-authentication.md +++ b/articles/libraries/auth0-swift/touchid-authentication.md @@ -1,12 +1,20 @@ --- section: libraries -description: How to implement Touch ID authentication with Auth0.swift. +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 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. +# Auth0.swift Touch ID / Face ID Authentication -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 the Touch 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 @@ -18,27 +26,37 @@ import Auth0 ### Credentials Manager -Setup the Credentials Manager and enable Touch ID authentication, you can pass the title to show in the Touch ID prompt: +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 -let credentialsManager = CredentialsManager(authentication: Auth0.authentication()) -credentialsManager.enableTouchAuth(withTitle: "Touch to Authenticate") +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 login page and pass the credentials upon successful authentication to the Credentials Manager. +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 { - switch $0 { + .start { result in + switch result { case .failure(let error): - // Handle the error - print("Error: \(error)") + // Handle error case .success(let credentials): // Store credentials securely with the Credentials Manager credentialsManager.store(credentials: credentials) @@ -48,15 +66,15 @@ Auth0 ### Renew User Credentials -When you need to renew the user's credentials you can call the `credentials` method from the Credentials Manager to take care of this. The user will be promoted for Touch ID. +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 + // Handle error + // Fallback to login screen } - // Continue routing the user as authentication was a success + // Continue routing the user as authentication was successful } ``` @@ -64,4 +82,4 @@ There is no need manually store the new credentials as this is handled by the Cr ## Next Steps -You can download a sample project and follow the tutorial in our [Touch ID Authentication](/quickstart/native/ios-swift/08-touch-id-authentication) quickstart. +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/articles/libraries/auth0-swift/user-management.md b/articles/libraries/auth0-swift/user-management.md index edcd6a9ef3..c2ad08deab 100644 --- a/articles/libraries/auth0-swift/user-management.md +++ b/articles/libraries/auth0-swift/user-management.md @@ -2,44 +2,51 @@ 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 functionality that allows you to link and unlink separate user accounts from different providers, tying them to a single profile (Read more about [Linking Accounts](/link-accounts) with Auth0). It also allows you to update user metadata. +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. -## Linking users +## 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 be linked, this is the way to go. +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 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. +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 token") + .users(token: "user-scoped access token") .link(userId, withOtherUserToken: "another user token") .start { result in switch result { case .success(let userInfo): - print("user: \(userInfo)") + print("User: \(userInfo)") case .failure(let error): print(error) } } ``` -## Unlinking users +## Unlink users -Unlinking users is a similar provess to the linking of users. The `unlink` method takes three parameters, though: the secondary user id, and the secondary provider (the provider of the secondary user), and the primary user id. +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 token") + .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)") + print("User: \(userInfo)") case .failure(let error): print(error) } @@ -47,19 +54,19 @@ Auth0 ``` ::: note -Note that 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. +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. ::: -## Retrieving user metadata +## Retrieve user metadata ```swift Auth0 - .users(token: idToken) + .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)") + print("User: \(userInfo)") case .failure(let error): print(error) } @@ -68,16 +75,16 @@ Auth0 ## 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. +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 token") + .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)") + print("User: \(userInfo)") case .failure(let error): print(error) } diff --git a/articles/libraries/auth0js/index.yml b/articles/libraries/auth0js/index.yml index 82ff282c42..44a74ecb88 100644 --- a/articles/libraries/auth0js/index.yml +++ b/articles/libraries/auth0js/index.yml @@ -2,10 +2,6 @@ versioning: baseUrl: libraries/auth0js current: v9 versions: - - v7 - - v8 - v9 defaultArticles: - v7: index - v8: index v9: index diff --git a/articles/libraries/auth0js/v7/index.md b/articles/libraries/auth0js/v7/index.md deleted file mode 100644 index 2e760f8327..0000000000 --- a/articles/libraries/auth0js/v7/index.md +++ /dev/null @@ -1,779 +0,0 @@ ---- -section: libraries -toc: true -description: How to install, initialize and use auth0.js v7 ---- - -# Auth0.js v7 Reference - -<%= include('../../../_includes/_version_warning_auth0js') %> - -Auth0.js is a client-side library for [Auth0](http://auth0.com), for use in your web apps. It allows you to trigger the authentication process and parse the [JSON Web Token](http://openid.net/specs/draft-jones-json-web-token-07.html) (JWT) with just the Auth0 `clientID`. Once you have the JWT, you can use it to authenticate requests to your HTTP API and validate the JWT in your server-side logic with the `clientSecret`. - -::: note -Check out the [Auth0.js repository](https://github.com/auth0/auth0.js/tree/v7) on GitHub. -::: - -## 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 run example` from the root of this project, and then browse to your app running on the node server, presumably at `http://localhost:3000`. - - - -It's that easy! - -## Usage - -Now, let's get started integrating auth0.js into your project. We'll cover [methods of installation](#installation-options), [how to initialize auth0.js](#initialize), [signup](#signup), [login](#login), [Passwordless](#passwordless-authentication), [accessing user profiles](#user-profile), and more! - -### 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): - -```sh -npm install auth0-js -``` - -Install via [bower](http://bower.io): - -```sh -bower install auth0.js -``` - -Include via our CDN: - -```html - -``` - -If you are using [browserify](http://browserify.org/), you will want to install with `npm i auth0-js --production --save`. - -### Initialize - -::: note -The following examples use jQuery, but auth0.js is not tied to jQuery and any library can be used with it. -::: - -Construct a new instance of the Auth0 application as follows: - -```html - - -``` -### Signup - -Here is an example of the `signup` method and some sample code for the form. - -```html -

    Signup Database Connection

    - - - - -``` - -### Login - -This method can be referenced as `signin` or as `login` indifferently. It triggers the login on any of your active identity providers. The following are several examples of calling the `login` method with particular parameters; use the one that makes the most sense for your needs. - -```js - //trigger login with google - $('.login-google').click(function () { - auth0.login({ - connection: 'google-oauth2' - }); - }); - - //trigger login with github - $('.login-github').click(function () { - auth0.login({ - connection: 'github' - }); - }); - - //trigger login with an enterprise connection - $('.login-microsoft').click(function () { - auth0.login({ - connection: 'contoso.com' - }); - }); - - //trigger login with a db connection - $('.login-dbconn').click(function () { - auth0.login({ - connection: 'db-conn', - username: $('.username').val(), - password: $('.password').val(), - }); - }); - - //trigger login with a db connection and avoid the redirect - $('.login-dbconn').click(function () { - auth0.login({ - connection: 'db-conn', - username: $('.username').val(), - password: $('.password').val(), - }, - function (err, result) { - // store in cookies - }); - }); - - //trigger login popup with google - $('.login-google-popup').click(function (e) { - e.preventDefault(); - auth0.login({ - connection: 'google-oauth2', - popup: true, - popupOptions: { - width: 450, - height: 800 - } - }, function(err, result) { - if (err) { - alert("something went wrong: " + err.message); - return; - } - alert('Hello!'); - }); - }); -``` - -You can also request scopes that are not were not configured for the connection. - -```js - //trigger login requesting additional scopes with google - $('.login-google').click(function () { - auth0.login({ - connection: 'google-oauth2', - connection_scope: ['https://www.googleapis.com/auth/orkut', 'https://picasaweb.google.com/data/'] - }); - }); - - // alternatively a comma separated list also works - $('.login-google').click(function () { - auth0.login({ - connection: 'google-oauth2', - connection_scope: 'https://www.googleapis.com/auth/orkut,https://picasaweb.google.com/data/' - }); - }); -``` - -Trigger the login with offline mode support to get the `refresh_token` - -```js -$('.login-dbconn').click(function () { - auth0.login({ - connection: 'db-conn', - username: $('.username').val(), - password: $('.password').val(), - scope: 'openid offline_access' - }, - function (err, result) { - // store in cookies - // result.refreshToken is sent because offline_access is set as a scope - }); - }); -``` - -### Logout - -After a user logs in, a JSON Web Token (JWT) is returned and this token can be saved in a cookie or in browser storage for later use. In addition to this, an SSO cookie gets set in the user's browser (unless specifying `sso: false`). - -If you would like to log the user out from their current browser session in your app, provide a method for removing their JWT from the browser. - -```js - $('.logout-dbconn').click(function() { - // local storage example - localStorage.removeItem('id_token'); - }); -``` - -If you would like to invalidate the user's Auth0 SSO session, use the `logout` method from `auth0.js`. - -```js - $('.logout-dbconn').click(function() { - auth0.logout(); - }); -``` - -This method will redirect the user to an Auth0-hosted page that says "OK". You may pass a `returnTo` value to specify where the user should be redirected to after logout. - -```js - $('.logout-dbconn').click(function() { - auth0.logout({ returnTo: 'http://localhost:3000' }, { version: 'v2' }); - }); -``` - -You must whitelist the **Logout URL** for your app at either the account level or the app level. To whitelist a logout URL for your entire account, provide it in your [advanced settings](${manage_url}/#/account/advanced). To whitelist for the application only, provide the logout URL in your [application settings](${manage_url}/#/clients). - -If you whitelist the logout URL at the application level, pass the `client_id` for your app in the query object. - -```js - $('.logout-dbconn').click(function() { - auth0.logout({ returnTo: 'http://localhost:3000', client_id: AUTH0_CLIENT_ID }, { version: 'v2' }); - }); -``` - -For more information about logout, see the [documentation](https://auth0.com/docs/logout). - -### Passwordless Authentication - -Passwordless authentication allows users to log in by receiving a one-time password via email or text message. - -#### With Email - -One option for Passwordless authentication is using email. Once you have configured a passwordless `email` connection, you can request a link or a code to be sent via email that will allow the receiver to sign in to your application. - -##### Link - -```js -$('.request-email-link').click(function (ev) { - ev.preventDefault(); - - auth0.requestMagicLink({ - email: $('.email-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; - } - // the request was successful and you should receive - // an email with the link at the specified address - }); -}); -``` - -##### Code - -```js -$('.request-email-code').click(function (ev) { - ev.preventDefault(); - - auth0.requestEmailCode({ - email: $('.email-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; - } - // the request was successful and you should receive - // an email with the code at the specified address - }); -}); -``` - -Once you receive the code you can call `verifyEmailCode` to authenticate the user using an `email` and a `code`. - -```js -auth0.verifyEmailCode({ - email: $('.email-input').val(), - code: $('.email-code-input').val() -}, function (err, result) { - if (err) { - alert("something went wrong: " + err.error_description); - return; - } - alert('Hello'); -}); -``` - -If you provide a `callbackURL` parameter when constructing the Auth0 instance, a redirect will be performed and the callback will only be invoked in the case of an error (notice it takes a single argument). - -```js -auth0.verifyEmailCode({ - email: $('.email-input').val(), - code: $('.email-code-input').val() -}, function (err) { - if (err) { - alert("something went wrong: " + err.error_description); - return; - } -}); -``` - -#### With SMS - -You can also do Passwordless authentication via SMS. First you must activate and configure your passwordless [Twilio](https://twilio.com) connection in our [dashboard](${manage_url}/#/connections/passwordless). - -After that you can request a passcode to be sent via SMS to a phone number. Ensure the phone number has the proper [full-length format](https://www.twilio.com/help/faq/phone-numbers/how-do-i-format-phone-numbers-to-work-internationally). - - -```js -$('.request-sms-code').click(function (ev) { - ev.preventDefault(); - - auth0.requestSMSCode({ - phoneNumber: $('.phone-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; - } - // the request was successful and you should receive - // a SMS with the code at the specified phone number - }); -}); -``` - -Once you receive the code you can call `verifySMSCode` to authenticate the user using an `phoneNumber` and a `code`. - -```js -auth0.verifySMSCode({ - phoneNumber: $('.phone-input').val(), - code: $('.sms-code-input').val() -}, function (err, result) { - if (err) { - alert("something went wrong: " + err.error_description); - return; - } - alert("Hello"); -}); -``` - -If you provide a `callbackURL` parameter when constructing the Auth0 instance, a redirect will be performed and the callback will only be invoked in the case of an error (notice it takes a single argument). - -```js -auth0.verifySMSCode({ - phoneNumber: $('.phone-input').val(), - code: $('.sms-code-input').val() -}, function (err) { - if (err) { - alert("something went wrong: " + err.error_description); - return; - } -}); -``` - -### User Profile - -The `getProfile` method allows you to obtain the user information after a successful login. - -```js -auth0.getProfile(idToken, function (err, profile) { - if(err) { - // handle error - return; - } - - alert('hello ' + profile.name); -}); -``` - -How do you acquire the `idToken` depends on the mode you are using to log in. See below for examples for [redirect](#single-page-apps) and [popup](#popup-mode) modes. - -### Processing the Callback - -How does control return back to your app after a login has been attempted? This all depends on which login "mode" you choose to use (**Redirect** or **Popup**) and in some cases, which type of connection you're using. - -#### Redirect Mode - -The default mode of the `login` method is Redirect Mode. Here two separate "redirect" actions will occur when `login` is called. First, the browser will navigate to a separate login page to collect the user's credentials. Once the user successfully logs in, the browser will redirect the user *back* to your application via the `callbackURL`. - -For example, let's say you've initialized your Auth0 application as shown in the [Initialize](#initialize) section above. Then the following call to `login` using your `google-oauth2` social connection would result in a redirect to a Google login page and then a redirect back to `http://my-app.com/callback` if successful: - -```js -auth0.login({ - connection: 'google-oauth2' -}); -``` - -##### Single Page Apps - -If you're building a SPA (Single Page Application) and using Redirect Mode, then your `callbackURL` should send the user back to the same page. And because the `responseType` initialization option was set to `'token'`, Auth0 will also append a hash to that URL that will contain an `access_token` and `id_token` (the JWT). After control returns to your app, the full user profile can be retrieved via the `parseHash` and `getProfile` methods: - -```js -$(function () { - var result = auth0.parseHash(window.location.hash); - - //use result.idToken to call your rest api - - if (result && result.idToken) { - // optionally fetch user profile - auth0.getProfile(result.idToken, function (err, profile) { - alert('hello ' + profile.name); - }); - - // If offline_access was a requested scope - // You can grab the result.refresh_token here - - } else if (result && result.error) { - alert('error: ' + result.error); - } -}); -``` - -If the `scope` option used with the `login` method did not contain `openid profile`, then the profile will only contain `user_id`. In that case just parse the hash to obtain the user ID: - -```js -$(function () { - var result = auth0.parseHash(window.location.hash); - if (result && result.profile) { - alert('your user_id is: ' + result.profile.sub); - //use result.id_token to call your rest api - } - }); -}); -``` - -If there is no hash, `result` will be null. If the hash contains the JWT, the `profile` field will be populated. - -##### Regular Web Apps - -If you're building a regular web application (HTML pages rendered on the server), then `callbackURL` should point to a server-side endpoint that will process the successful login, primarily to set some sort of session cookie. In this scenario you should make sure the `responseType` option is `'code'` (or just not specified) when the Auth0 application is created: - -```js -var auth0 = new Auth0({ - domain: 'mine.auth0.com', - clientID: 'dsa7d77dsa7d7', - callbackURL: 'http://my-app.com/callback' - // responseType not set (defaults to 'code') -}); -``` - -On successful login, Auth0 will redirect to your `callbackURL` with an appended authorization `code` query parameter. Unlike the SPA scenario, this `code` value should get processed completely server-side. - -::: panel Authorization Code Grant -Server-side processing of the `code` looks something like this: Using whichever [Auth0 server-side SDK](/quickstart/webapp) necessary, the endpoint on the server should exchange the `code` for an `access_token` and `id_token` and optionally a full user profile. It should then set some kind of local session cookie, which is what enables a user to be "logged in" to the website and usually contains data from the user profile. It should finally redirect the user back to a meaningful page. -::: - -#### Popup Mode - -Besides Redirect Mode, the `login` method also supports Popup Mode, which you enable by passing `popup: true` in the `options` argument. In this mode the browser will *not* be redirected to a separate login page. Instead Auth0 will display a popup window where the user enters their credentials. The advantage of this approach is that the original page (and all of its state) remains intact, which can be important, especially for certain Single Page Apps. - -::: panel-warning Popup mode issues -While Popup Mode does have the advantage of preserving page state, it has some issues. Often times users have popup blockers that prevent the login page from even displaying. There are also known issues with mobile browsers. For example, in recent versions of Chrome on iOS, the login popup does not get closed properly after login (see an example [here](https://github.com/auth0/lock/issues/71)). For these reasons, we encourage developers to favor Redirect Mode over Popup Mode, even with Single Page Apps. -::: - -In Popup Mode you also have no need to be redirected back to the application, since, once the user has logged in, the popup is simply closed. Instead Auth0 uses the `login` method's `callback` argument to return control to your client-side application, for both failed and successful logins. Along with the `err` argument, `callback` should also receive a `result` argument with the following properties: `idTokenPayload, idToken, accessToken, state` (and optionally `refreshToken` if the `offline_access` scope has been requested): - -```js -auth0.login({ - popup: true, - connection: 'google-oauth2' -}, -function(err, result) { - if (err) { - // Handle the error! - return; - } - - // Success! - - // optionally fetch user profile - auth0.getProfile(result.idToken, function (err, profile) { - alert('hello ' + profile.name); - }); -}); -``` - -#### Database and Active Directory/LDAP connections - -The behavior of Redirect and Popup Modes differs if you're using a [Database](/connections/database/mysql) or [Active Directory/LDAP](/connections/enterprise/active-directory) connection. Those differences depend on two factors: whether SSO ([Single Sign-On](/sso/single-sign-on)) is enabled and whether or not credentials are being directly passed to the `login` method. - -##### SSO enabled - -By default SSO is enabled (equivalent to passing the `sso: true` option to the `login` method). This means that after a successful login, Auth0 will set a special cookie that [can be used](#sso) to automatically log a user onto additional websites that are registered as Auth0 apps. When using either the Database or Active Directory/LDAP connections with SSO enabled, you can still choose to go with Redirect or Popup Mode. - -As with other connection types, Redirect Mode will happen by default. The browser will navigate to a login page that will prompt the user for their credentials and then, when login is complete, redirect back to the `callbackURL`. However, one of the unique options you have with Database and Active Directory/LDAP connections is that the redirect to the login page can be bypassed if the `username` and `password` options are passed to the `login` method. These values are typically collected via a *custom login form* in your app: - -```js -auth0.login({ - connection: 'db-conn', - username: $('.username').val(), - password: $('.password').val(), -}, -function (err) { - // this only gets called if there was a login error -}); -``` - -If the login is successful, the browser will then be redirected to `callbackURL`. And as shown above, a `callback` argument should also be provided to the `login` method that handles any authentication errors (without redirecting). - -Furthermore, sometimes you don't want a redirect to occur at all after a login. This is often the case with Single Page Apps where a redirect will result in loss of important page state. To handle all login results client-side, simply provide additional parameters to the `callback` argument JavaScript function: - -```js -auth0.login({ - connection: 'db-conn', - username: $('.username').val(), - password: $('.password').val(), -}, -function(err, result) { - if (err) { - // Handle the error! - return; - } - - // Success! -}); -``` - -::: note -This `callback` approach is similar to what you'd do in the [Popup Mode](#popup-mode) scenario described earlier, except no popups (or redirects) occur since credentials are provided to the `login` method and success and failure is handled in the `callback` argument. -::: - -You can still do Popup Mode with SSO enabled with a Database or Active Directory/LDAP connection if you want to (but please see the **WARNING** in the [Popup Mode](#popup-mode) section above). This is similar to the Redirect Mode scenario where you don't have a custom login form, but want to use a popup window to collect the user's credentials, and also want control to return to the client-side code (vs. redirecting to `callbackURL`). This behavior would occur if you simply specified the `popup: true` option: - -```js -auth0.login({ - connection: 'db-conn', - popup: true -}, -function(err, result) { - if (err) { - // Handle the error! - return; - } - - // Success! -}); -``` - -##### SSO disabled - -If you explicitly don't want SSO enabled in your application, you can pass the `sso: false` option to the `login` method. The result is that when a login occurs, Auth0 performs a CORS POST request (or in IE8 or 9 a JSONP request) against a special "resource owner" endpoint (`/ro`), which allows users to authenticate by sending their username and password. Also, no SSO cookie is set. - -There are a couple important constraints at play when SSO is disabled: - -* Because the `/ro` endpoint requires credentials, the `username` and `password` options must be passed to the `login` method -* It's not possible to use Popup Mode when SSO is disabled, even if you pass `popup: true` - -This leaves you with a call to the `login` method that looks something like this: - -```js -auth0.login({ - connection: 'db-conn', - sso: false, - username: $('.username').val(), - password: $('.password').val() -}, -function(err) { - // this only gets called if there was a login error -}); -``` - -If the login succeeds, Auth0 will redirect to your `callbackURL`, and if it fails, control will be given to the `callback`. - -And if you don't want that redirect to occur (for example, you have a Single Page App), you can use a `callback` argument that takes the additional parameters (like what's shown in [Popup Mode](#popup-mode)), and control will go to your callback function with a failed or successful login. - -### Response configuration - -By default, after a successful login, the browser is redirected back to the `callbackURL` with an authorization `code` included in the `query` string. This `code` is then used by a server to obtain an Access Token. The Access Token can be obtained directly if you provide the `responseType: 'token'` option. In this case the Access Token will be included in the fragment (or hash) part of the `callbackURL`. Finally, you can specify `responseType: 'id_token'` if you just need an `id_token`. - -```js -var auth0 = new Auth0({ - domain: 'mine.auth0.com', - clientID: 'dsa7d77dsa7d7', - callbackURL: 'http://my-app.com/callback', - responseType: 'token' // also 'id_token' and 'code' (default) -}); -``` - -Besides being included in the URL, the code or the tokens can be encoded in HTML form and transmitted via an HTTP POST request to the `callbackUrl`. The `responseMode: 'form_post'` option needs to be used to activate this flow. - -```js -var auth0 = new Auth0({ - domain: 'mine.auth0.com', - clientID: 'dsa7d77dsa7d7', - callbackURL: 'http://my-app.com/callback', - responseMode: 'form_post', - responseType: 'token' // also 'id_token' and 'code' (default) -}); -``` - -Both `responseType` and `responseMode` options were added in version `7.2.0`. In previous versions, a subset of the functionality of these options was available through `callbackOnLocationHash`. `responseType: 'code'` is equivalent to `callbackOnLocationHash: false` and `responseType: 'token'` is equivalent to `callbackOnLocationHash: true`. The `callbackOnLocationHash` option is still available for compatibility reasons, but it has been deprecated and will be removed in version `8.0.0`. Also note that is not possible to use `callbackOnLocationHash` and `responseType` at the same time. - -```js -// The next two snippets are equivalent, and a code will be included in the -// callbackURL after a successful login -var auth0 = new Auth0({ - // ... - responseType: 'code' -}); - -var auth0 = new Auth0({ - // ... - callbackOnLocationHash: false -}); - -// The next two snippets are equivalent, and a token will be included in the -// callbackURL after a successful login -var auth0 = new Auth0({ - // ... - responseType: 'token' -}); - -var auth0 = new Auth0({ - // ... - callbackOnLocationHash: true -}); -``` - -### Change Password (database connections): - -```js - $('.change_password').click(function () { - auth0.changePassword({ - connection: 'db-conn', - email: 'foo@bar.com' - }, function (err, resp) { - if(err){ - console.log(err.message); - }else{ - console.log(resp); - } - - }); - }); -``` - -This request will always return a 200, even if the user doesn't exist. -The user will receive an email with a link to reset their password. - -### Delegation Token Request - -A delegation token is a new token for a different service or app/API. - -If you just want to get a new token for an addon that you've activated, you can do the following: - -```js -var options = { - id_token: "your ID Token", // The id_token you have now - api: 'firebase', // This defaults to the first active addon if any or you can specify this - "scope": "openid profile" // default: openid -}; - -auth0.getDelegationToken(options, function (err, delegationResult) { - // Call your API using delegationResult.id_token -}); -``` - -If you want to get the token for another API or App: - -```js -var options = { - id_token: "your ID Token", // The id_token you have now - api: 'auth0' // This is default when calling another app that doesn't have an addon - targetClientId: 'The other application id' -}; - -auth0.getDelegationToken(options, function (err, delegationResult) { - // Call your API using delegationResult.id_token -}); -``` - -### Refresh Token - -If you want to refresh your existing (not expired) token, you can just do the following: - -```js -auth0.renewIdToken(current_id_token, function (err, delegationResult) { - // Get here the new delegationResult.id_token -}); -``` - -If you want to refresh your existing (expired) token, if you have the refresh_token, you can call the following: - -```js -auth0.refreshToken(refresh_token, function (err, delegationResult) { - // Get here the new delegationResult.id_token -}); -``` - -### Validate User - -You can validate a user of a specific connection using username and password: - -```js -auth0.validateUser({ - connection: 'db-conn', - username: 'foo@bar.com', - password: 'blabla' -}, function (err, valid) { }); -``` - -### SSO - -Method `getSSOData` fetches Single Sign-On information: - -```js - auth0.getSSOData(function (err, ssoData) { - if (err) return console.log(err.message); - expect(ssoData.sso).to.exist; - }); -``` - -The returned `ssoData` object will contain the following fields, for example: - -```js -{ - sso: true, - sessionClients: [ - "jGMow0KO3WDJELW8XIxolqb1XIitjkYL" - ], - lastUsedClientID: "jGMow0KO3WDJELW8XIxolqb1XIitjkYL", - lastUsedUsername: "alice@example.com", - lastUsedConnection: { - name: "Username-Password-Authentication", - strategy: "auth0" - } -} -``` - -Load Active Directory data if available (Kerberos): - -```js - auth0.getSSOData(true, fn); -``` - -When Kerberos is available you can automatically trigger Windows Authentication. As a result the user will immediately be authenticated without taking any action. - -```js - auth0.getSSOData(true, function (err, ssoData) { - if (!err && ssoData && ssoData.connection) { - auth0.login({ connection: ssoData.connection }); - } - }); -``` - - - -[npm-image]: https://img.shields.io/npm/v/auth0-js.svg?style=flat-square -[npm-url]: https://npmjs.org/package/auth0-js -[travis-image]: https://travis-ci.org/auth0/auth0.js.svg?branch=master -[travis-url]: https://travis-ci.org/auth0/auth0.js -[coveralls-image]: https://img.shields.io/coveralls/auth0/auth0.js.svg?style=flat-square -[coveralls-url]: https://coveralls.io/r/auth0/auth0.js?branch=master -[david-image]: http://img.shields.io/david/auth0/auth0.js.svg?style=flat-square -[david-url]: https://david-dm.org/auth0/auth0.js -[license-image]: http://img.shields.io/npm/l/auth0-js.svg?style=flat-square -[license-url]: #license -[downloads-image]: http://img.shields.io/npm/dm/auth0-js.svg?style=flat-square -[downloads-url]: https://npmjs.org/package/auth0-js diff --git a/articles/libraries/auth0js/v8/index.md b/articles/libraries/auth0js/v8/index.md deleted file mode 100644 index f4e66a876b..0000000000 --- a/articles/libraries/auth0js/v8/index.md +++ /dev/null @@ -1,557 +0,0 @@ ---- -section: libraries -toc: true -description: How to install, initialize and use auth0.js v8 ---- -# Auth0.js v8 Reference - -<%= include('../../../_includes/_version_warning_auth0js') %> - -Auth0.js is a client-side library for Auth0. Using auth0.js in your web apps makes it easier to do authentication and authorization with Auth0 in your web apps. - -::: note -Check out the [Auth0.js repository](https://github.com/auth0/auth0.js/tree/v8) on GitHub. -::: - -## 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](#sign-up), [login](#login), [logout](#logout), and more! - -### 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): - -```sh -npm install auth0-js -``` - -Install via [bower](http://bower.io): - -```sh -bower install auth0.js -``` - -```html - -``` - -Include via our CDN: - -```html - -``` - -::: note -For production use, the latest patch release (for example, 8.0.0) is recommended, rather than the latest minor release indicated above. -::: - -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). | -| `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'`. | -| `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`. The `query` value is only supported when `responseType` is `code`. | -| `_disableDeprecationWarnings` | optional | (Boolean) Disables the deprecation warnings, defaults to `false`. | - -## 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](/hosted-pages/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. | -| `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](/api-auth/tutorials/adoption/scope-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. | -| `leeway` | optional | (Integer) A value in seconds; leeway to allow for clock skew with regard to JWT expiration times. | - -::: 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 JWT expiration times, to prevent that from occuring. -::: - -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({ - //Any additional options can go here -}, function(err, authResult) { - //do something -}); -``` - -And for social login with popup using `authorize`: - -```js -webAuth.popup.authorize({ - connection: 'twitter' -}, function(err, authResult) { - //do something -}); -``` - -### webAuth.redirect.loginWithCredentials() - -To login using redirect with credentials to enterprise connections, the `redirect.loginWithCredentials` method is used. - -```js -webAuth.redirect.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' -}, function(err, authResult) { - // Auth tokens in the result or an error -}); -``` - -The use of `webauth.redirect.loginWithCredentials` is not recommended when using Auth0.js in your apps; it is recommended that you use `webauth.login` instead. - -However, using `webauth.redirect.loginWithCredentials` **is** the correct choice for use in the universal login page, and is the only way to have SSO cookies set for your users who login using universal login. - -### webAuth.popup.loginWithCredentials() - -To login using popup mode with credentials to enterprise connections, the `popup.loginWithCredentials` method is used. - -```js -webAuth.popup.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' -}, function(err, authResult) { - // Auth tokens in the result or an error -}); -``` - -### webAuth.login() - -The `login` method allows for [cross-origin auth](/cross-origin-authentication) using 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', -}); -``` - -### 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 authentication. - -```js -// Calculate URL to redirect to -var url = webAuth.client.buildAuthorizeUrl({ - clientID: '${account.clientId}', - responseType: 'token id_token', - redirectUri: '${account.callback}', - state: 'YOUR_STATE' -}); - -// 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()`. The [OAuth state documentation](/protocols/oauth2/oauth-state) describes how to do use it correctly. -::: - -## 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 complete the passwordless login. - -::: note -In order to use `passwordlessLogin`, the options `redirectUri` and `responseType: 'token'` 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 must be used by the application 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) | - -::: note -This method requires that your tokens are signed with RS256 rather than HS256. For more information about this, check the [Auth0.js v8 Migration Guide](/libraries/auth0js/migration-guide#the-parsehash-method). -::: - -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 -{ - "email_verified": "false", - "email": "test@example.com", - "clientID": "AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH", - "updated_at": "2017-02-07T20:50:33.563Z", - "name": "tester9@example.com", - "picture": "https://gravatar.com/avatar/example.png", - "user_id": "auth0|123456789012345678901234", - "nickname": "tester9", - "identities": [ - { - "user_id": "123456789012345678901234", - "provider": "auth0", - "connection": "Username-Password-Authentication", - "isSocial": "false" - } - ], - "created_at": "2017-01-20T20:06:05.008Z", - "sub": "auth0|123456789012345678901234" -} -``` - -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({ - audience: 'https://example.com/api/v2', - scope: 'openid read:something write:otherthing', - responseType: 'token id_token', - 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. - -## 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 | -| `connection` | required | (String) The database connection name on your application upon which to attempt user account creation | - -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 has a current session in Auth0 server for your domain. The method accepts any valid OAuth2 parameters that would normally be sent to `authorize`. - -```js -webAuth.checkSession({ - audience: 'https://example.com/api/v2', - scope: 'read:something write:otherthing' -}, function (err, authResult) { - // err if automatic parseHash fails - ... -}); -``` - -The actual redirect to `/authorize` happens inside an iframe, so it will not reload your application or redirect away from it. - -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`. -::: - -## 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. - -## Cross-Origin authentication - -Using auth0.js within your application (rather than using [universal login](/hosted-pages/login)) requires cross-origin authentication. Make sure you read the [cross-origin authentication documentation](/cross-origin-authentication) to understand how to properly configure your application to make it work. - -## 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 (Read more about [Linking Accounts](/link-accounts) with Auth0). 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. - -```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. Visit the [User Metadata](/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 this user account. If the id is in the format `facebook|1234567890`, the id required is the portion after the delimiting pipe. Visit the [Linking Accounts](/link-accounts) documentation for more details on linking accounts. - -```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/articles/libraries/auth0js/v8/migration-guide.md b/articles/libraries/auth0js/v8/migration-guide.md deleted file mode 100644 index 61331a035c..0000000000 --- a/articles/libraries/auth0js/v8/migration-guide.md +++ /dev/null @@ -1,216 +0,0 @@ ---- -section: libraries -title: Auth0.js v7 to v8 Migration Guide -description: How to migrate from auth0.js v7 to auth0.js v8 -toc: true ---- -# Auth0.js v7 to v8 Migration Guide - -The following instructions assume you are migrating from **auth0.js v7** to **auth0.js v8**. - -The goal of this migration guide is to provide you with all of the information you would need to update Auth0.js in your application. Of course, your first step is to include the latest version of auth0.js. Beyond that, take a careful look at each of the areas on this page. You will need to change your implementation of auth0.js to reflect the new changes. - -Take a look below for more information about changes and additions to Auth0.js in version 8! - -## Reasons to Migrate - -The first question to answer before getting into the changes is why to migrate your app to the new version at all. Here are a few quick points that address that: - -* With version 8 of the Auth0.js SDK, you can use [our latest and most secure authentication pipeline](/api-auth/intro), compliant with the OpenID Connect specification. For more information, refer to the below section [Use of API Auth and Metadata](#use-of-api-auth-and-metadata). -* Auth0.js v8 was rewritten from scratch, improving its cohesion and performance and coming with more tests to be utilized. -* Long term support - As is often the case with new iterations of projects, v8 will be supported for significantly longer than v7. - -### Use of API Auth and Metadata - -There are often situations where your APIs will need to authorize limited access to users, servers, or servers on behalf of users. Managing these types of authorization flows and access to your APIs is much easier with Auth0. If you need to use these [API Auth](/api-auth) features, we recommend that you upgrade to [auth0.js v8](/libraries/auth0js/v8). - -Alternatively, you could also simply request the metadata in a different way, for example with a rule to add custom claims to either the returned `id_token` or `access_token` as described in the [custom claims](/scopes/current#custom-claims) section of the scopes documentation. - -::: note -You can find detailed information about supported methods in the [Auth0.js v8](/libraries/auth0js) documentation, and generated documentation on all methods [here](http://auth0.github.io/auth0.js/global.html) for further reading. -::: - -## Initialization of auth0.js - -Initialization of auth0.js in your application will now use `auth0.WebAuth` instead of `Auth0` - -```html - - -``` - -## Login - -The `login` method of version 7 was divided into several different methods in version 8, based on the type of auth you need, rather than the old `login` method. - -### webAuth.authorize() - -The `authorize` method can be used for logging in users via [universal login](/hosted-pages/login), or via social connections, as exhibited below. - -For hosted login, one must call the authorize endpoint - -```js -webAuth.authorize({ - //Any additional options can go here -}); -``` - -For social logins, the connection 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({ - //Any additional options can go here -}); -``` - -And social login with popup - -```js -webAuth.popup.authorize({ - connection: 'twitter' -}); -``` - -### webAuth.redirect.loginWithCredentials() - -To login with credentials to enterprise connections, the `redirect.loginWithCredentials` method is used. - -With redirect - -```js -webAuth.redirect.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' -}); -``` - -### webAuth.popup.loginWithCredentials() - -Or, popup authentication can be performed with `popup.loginWithCredentials`. - -```js -webAuth.popup.loginWithCredentials({ - connection: 'Username-Password-Authentication', - username: 'testuser', - password: 'testpass', - scope: 'openid' -}); -``` - -### webAuth.client.login() - -The `client.login` method allows for non redirect auth using custom database connections, using /oauth/token. - -```js -webAuth.client.login({ - realm: 'tests', - username: 'testuser', - password: 'testpass', - scope: 'openid profile', - audience: 'urn:test' -}); -``` - -### Passwordless Login - -Passwordless authentication is no longer available using the v7 methods. Now, passwordless is a simpler process, begun by calling `passwordlessStart` and completed by calling `passwordlessLogin`. See the v8 [documentation on Passwordless Authentication](/libraries/auth0js#passwordless-login) for more details! - -```js -webAuth.passwordlessStart({ - connection: 'Username-Password-Authentication', - send: 'code', // code or link - email: 'foo@bar.com' // either send an email param or a phoneNumber param - }, function (err,res) { - // handle errors or continue - } -); -``` - -```js -webAuth.passwordlessLogin({ - connection: 'Username-Password-Authentication', - email: 'foo@bar.com', - verificationCode: '389945' - }, function (err,res) { - // handle errors or continue - } -); -``` - -## Id Token Validation - -When the `id_token` signature method is HS256, auth0.js cannot validate the token, as it does not have the secret key. To populate the `idTokenPayload` property in the `parseHash` callback, it will call the [/userinfo](/api/authentication#get-user-info) endpoint to retrieve user information. - -If the `id_token` is signed with RS256, auth0.js will validate the token, decode it, and populate the `idTokenPayload` with the decoded data. - -:::note -We recommend that you use RS256 for signing tokens in Single Page Applications. -::: - -### Switching from HS256 to RS256 - -::: panel-warning Before Changing the Signing Algorithm -Please note that altering the signing algorithm for your application will immediately change the way your user's tokens are signed. This means that if you have already implemented JWT verification for your application somewhere, your tokens will not be verifiable until you update the logic to account for the new signing algorithm. -::: - -To switch from HS256 to RS256 for a specific application, follow these instructions: - -1. Go to [Dashboard > Applications](${manage_url}/#/applications) -1. Select your application -1. Go to _Settings_ -1. Click on __Show Advanced Settings__ -1. Click on the _OAuth_ tab in Advanced Settings -1. Change the __JsonWebToken Signature Algorithm__ to `RS256` - -Remember that if the token is being validated anywhere else, changes might be needed there as well in order to comply. - -## Refreshing Tokens - -When a token is nearing expiration, or is expired, you may wish to simply renew the token rather than requiring a new transaction. - -In [auth0.js v7](/libraries/auth0js/v7#refresh-token), the `renewIdToken()` and `refreshToken()` methods were used to Refresh Tokens. In [auth0.js v8](/libraries/auth0js#using-checksession-to-acquire-new-tokens), refreshing tokens is done via the `checkSession()` method. If a user is already authenticated, `checkSession()` can be used to acquire a new token for that user. - -## Delegation - -Delegation is now done via the `delegation` method, which takes an `options` object containing the following potential parameters: - -* __client_id__ (required): a string; the Auth0 application identifier -* __grant_type__ (required): a string; must be `urn:ietf:params:oauth:grant-type:jwt-bearer` -* __id_token__ (required): a string; either a valid id_token or a valid refresh_token is required -* __refresh_token__: a string; either a valid refresh_token or a valid id_token is required -* __target__: a string; the target application id of the delegation -* __scope__: a string; either `'openid'` or `'openid profile email'` -* __api_type__: a string; the api to be called - -```js -webAuth.client.delegation({ - client_id: '${account.clientId}', - grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer', - id_token: 'valid idToken here', - target: 'target client id here', - scope: 'openid' -}); -``` - -## User Management - -Linking accounts and gathering info has also changed. You can now instantiate a Management application object and call the `getUser`, `patchUserMetadata`, and `linkUser` methods on it to get a user's profile, update their metadata, or link two user accounts together. For more information, read about [user management](/libraries/auth0js#user-management) in the auth0.js documentation. diff --git a/articles/libraries/auth0js/v9/index.md b/articles/libraries/auth0js/v9/index.md index 74276efc4c..4366c9d400 100644 --- a/articles/libraries/auth0js/v9/index.md +++ b/articles/libraries/auth0js/v9/index.md @@ -1,15 +1,24 @@ --- section: libraries toc: true -title: Auth0.js v9 Reference +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 v9 Reference -Auth0.js is a client-side library for Auth0. It is recommended for use in single page apps, and auth0.js in your SPA makes it easier to do authentication and authorization with Auth0. +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: @@ -66,24 +75,24 @@ There are two required parameters that must be passed in the `options` object wh | --- | --- | --- | | `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). | -| `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. | +| `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'`. | +| `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 JWT expiration times. | +| `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 JWT expiration times, to prevent that from occuring. +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`. +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: +::: 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` @@ -96,17 +105,18 @@ You can choose a method for login based on the type of auth you need in your app ### webAuth.authorize() -The `authorize()` method can be used for logging in users via [universal login](/hosted-pages/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. +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](/api-auth/tutorials/adoption/scope-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. | +| `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 the [state parameter documentation](/protocols/oauth2/oauth-state). | +| `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. @@ -132,9 +142,10 @@ 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 + //do something }); ``` @@ -142,15 +153,41 @@ 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 + //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() -The `login` method allows for [cross-origin authentication](/cross-origin-authentication) using database connections, using `/co/authenticate`. +<%= 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** | | --- | --- | --- | @@ -190,16 +227,16 @@ var url = webAuth.client.buildAuthorizeUrl({ ``` ::: 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()`. The [OAuth state documentation](/protocols/oauth2/oauth-state) describes how to do use it correctly. +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). +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'`. +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({ @@ -212,7 +249,7 @@ var webAuth = new auth0.WebAuth({ ### 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: +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** | | --- | --- | --- | @@ -234,7 +271,7 @@ webAuth.passwordlessStart({ ); ``` -### Verify passwordless +### 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: @@ -248,7 +285,7 @@ If sending a code, you will then need to prompt the user to enter that code. You 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: 'token'` must be specified when first initializing WebAuth. +In order to use `passwordlessLogin`, the options `redirectUri` and `responseType` must be specified when first initializing WebAuth. ::: ```js @@ -271,14 +308,14 @@ The `parseHash` method takes an `options` object that contains the following par | **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` +| `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` | +| `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 | @@ -330,7 +367,7 @@ webAuth.checkSession({ }); ``` -The `webAuth.checkSession` method will automatically verify that the returned `id_token`'s `nonce` claim is the same as the option. +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'}) %> @@ -363,8 +400,9 @@ To sign up a user, use the `signup` method. This method accepts an options objec | --- | --- | --- | | `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](/metadata) | +| `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. @@ -391,9 +429,9 @@ Signups should be for database connections. Here is an example of the `signup` m ## 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 `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 use get a new token for the API that was specified as the audience when `webAuth` was initialized: +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) { @@ -402,6 +440,8 @@ webAuth.checkSession({}, function (err, authResult) { }); ``` +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 @@ -421,12 +461,18 @@ Note that `checkSession()` triggers any [rules](/rules) you may have set up, so 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. @@ -450,9 +496,9 @@ The user will then receive an email which will contain a link that they can foll ## 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 (Read more about [Linking Accounts](/link-accounts) with Auth0). It also allows you to update user metadata. +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. +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. @@ -463,7 +509,7 @@ var webAuth = new auth0.WebAuth({ clientID: '${account.clientId}', domain: '${account.namespace}', redirectUri: 'http://example.com', - audience: `https://${account.namespace}/api/v2/˜`, + audience: `https://${account.namespace}/api/v2/`, scope: 'read:current_user', responseType: 'token id_token' }); @@ -474,9 +520,9 @@ You can also do so by using `checkSession()`: ``` webAuth.checkSession( { - audience: `https://${account.namespace}/api/v2/˜`, + audience: `https://${account.namespace}/api/v2/`, scope: 'read:current_user' - }, function(err, result) { + }, function(err, result) { // use result.accessToken } ); @@ -511,7 +557,7 @@ 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. Visit the [User Metadata](/metadata) documentation for more details on user metadata. +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); @@ -521,7 +567,7 @@ auth0Manage.patchUserMetadata(userId, userMetadata, cb); 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 this user account. If the id is in the format `facebook|1234567890`, the id required is the portion after the delimiting pipe. Visit the [Linking Accounts](/link-accounts) documentation for more details on linking accounts. +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); diff --git a/articles/libraries/auth0js/v9/migration-angular.md b/articles/libraries/auth0js/v9/migration-angular.md index 20bcf3fff7..ee64ca6012 100644 --- a/articles/libraries/auth0js/v9/migration-angular.md +++ b/articles/libraries/auth0js/v9/migration-angular.md @@ -2,6 +2,17 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-angularjs-v6.md b/articles/libraries/auth0js/v9/migration-angularjs-v6.md index 36afc7f865..b87b3568e6 100644 --- a/articles/libraries/auth0js/v9/migration-angularjs-v6.md +++ b/articles/libraries/auth0js/v9/migration-angularjs-v6.md @@ -2,7 +2,18 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-angularjs-v7.md b/articles/libraries/auth0js/v9/migration-angularjs-v7.md index 769c55a61c..6020f63d6c 100644 --- a/articles/libraries/auth0js/v9/migration-angularjs-v7.md +++ b/articles/libraries/auth0js/v9/migration-angularjs-v7.md @@ -2,7 +2,18 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-angularjs-v8.md b/articles/libraries/auth0js/v9/migration-angularjs-v8.md index a229a40820..edea9b70ee 100644 --- a/articles/libraries/auth0js/v9/migration-angularjs-v8.md +++ b/articles/libraries/auth0js/v9/migration-angularjs-v8.md @@ -2,7 +2,18 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-guide.md b/articles/libraries/auth0js/v9/migration-guide.md index 0781834347..51c3f7a950 100644 --- a/articles/libraries/auth0js/v9/migration-guide.md +++ b/articles/libraries/auth0js/v9/migration-guide.md @@ -2,7 +2,17 @@ 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 @@ -10,18 +20,14 @@ toc: true ## Should I migrate to v9? -Everyone should migrate to v9. All previous versions are deprecated, and will be removed from service July 16, 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. - -::: note -Previously, deprecated Auth0.js versions were planned to be removed from service on April 1, 2018. However, the Removal of Service date has been extended to **July 16, 2018** due to a [mitigation of the risks posed by deprecated versions](/cross-origin-authentication/fingerprinting). Customers are still encouraged to migrate applications to the latest version **as soon as possible** in order to ensure that applications continue to function properly. -::: +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. +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 SSO is required](/guides/login/migration-sso) + * [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) @@ -30,9 +36,9 @@ The documents below describe all the changes that you should be aware of when mi * [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) -:::note 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 @@ -44,4 +50,6 @@ You have already migrated to Auth0.js 9 but you still see this error in your log 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](/hosted-pages/login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. If this happens after **July 16, 2018** the user will not be able to log in. +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/articles/libraries/auth0js/v9/migration-react.md b/articles/libraries/auth0js/v9/migration-react.md index 480b82c679..633c543fbb 100644 --- a/articles/libraries/auth0js/v9/migration-react.md +++ b/articles/libraries/auth0js/v9/migration-react.md @@ -2,6 +2,17 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-v6-v9.md b/articles/libraries/auth0js/v9/migration-v6-v9.md index f742bc1215..99375af3f5 100644 --- a/articles/libraries/auth0js/v9/migration-v6-v9.md +++ b/articles/libraries/auth0js/v9/migration-v6-v9.md @@ -2,7 +2,17 @@ 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 diff --git a/articles/libraries/auth0js/v9/migration-v7-v9.md b/articles/libraries/auth0js/v9/migration-v7-v9.md index 5471f91592..7a1c5bb666 100644 --- a/articles/libraries/auth0js/v9/migration-v7-v9.md +++ b/articles/libraries/auth0js/v9/migration-v7-v9.md @@ -2,7 +2,17 @@ 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 @@ -25,7 +35,7 @@ var auth0 = new Auth0({ responseType: 'token' }); -// With universal login +// With Universal Login auth0.login({}); // With a social or enterprise connection @@ -50,7 +60,7 @@ var webAuth = new auth0.WebAuth({ responseType: 'token id_token' }); -// with universal login +// with Universal Login webAuth.authorize({}); // with a social or enterprise connection @@ -77,7 +87,7 @@ var auth0 = new Auth0({ responseType: 'token' }); -// With universal login +// With Universal Login auth0.login({ popup: true }); @@ -106,7 +116,7 @@ var webAuth = new auth0.WebAuth({ responseType: 'token' }); -// with universal login +// with Universal Login webAuth.popup.authorize({}); // with a social or enterprise connection diff --git a/articles/libraries/auth0js/v9/migration-v8-v9.md b/articles/libraries/auth0js/v9/migration-v8-v9.md index 7bc448a3b2..2a40de08b2 100644 --- a/articles/libraries/auth0js/v9/migration-v8-v9.md +++ b/articles/libraries/auth0js/v9/migration-v8-v9.md @@ -2,7 +2,17 @@ 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 diff --git a/articles/libraries/custom-signup.md b/articles/libraries/custom-signup.md index 5b04f26bc4..fe0c3841bf 100644 --- a/articles/libraries/custom-signup.md +++ b/articles/libraries/custom-signup.md @@ -1,14 +1,26 @@ --- section: libraries -description: How to customize the user sign-up form with additional fields using Lock or the Auth0 API. +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 -In some cases, you may want to customize the user sign up form with more fields other than email and password. +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](/hosted-pages/login) option that you can use instead of designing your own custom sign up page. If you want to offer sign up and log in 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. +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 @@ -21,17 +33,15 @@ Lock's `additionalSignUpFields` option will only work with database signups. For ### Redirect to another page -One way to use social provider signups with Lock and collect custom fields is to use [redirect rules](/rules/redirect) to redirect the user to another page where you ask for extra information, and then redirect back to finish the authentication transaction. +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. Progressive profiling is a way by which you can slowly build up user profiles 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 for collecting the desired information, but with less friction at signup, since the goal of using a social IDP for signup is, at least in part, making it more effortless and streamlined for the user. - -For further reference, here is our [documentation on progressive profiling](/user-profile/progressive-profiling) as well as an Auth0 [blog post on progressive profiling](https://auth0.com/blog/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 -### 1. Create a Sign Up form to capture custom fields +### Create a signup form to capture custom fields ```html
    @@ -55,15 +65,22 @@ For further reference, here is our [documentation on progressive profiling](/use
    ``` -The `name` and `color` are custom fields. +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. ::: -### 2. Send the Form Data +### 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 `ClientId`, the `email` and `password` of the user being signed up, and the custom fields as part of `user_metadata`. +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 { @@ -75,7 +92,7 @@ Send a POST request to the [/dbconnections/signup](/api/authentication/reference }], "postData": { "mimeType": "application/json", - "text": "{\"client_id\": \"${account.clientId}\",\"email\": \"$('#signup-email').val()\",\"password\": \"$('#signup-password').val()\",\"user_metadata\": {\"name\": \"john\",\"color\": \"red\"}}" + "text": "{\"client_id\": \"${account.clientId}\",\"email\": \"$('#signup-email').val()\",\"password\": \"$('#signup-password').val()\",\"connection\": \"YOUR_CONNECTION_NAME\",\"name\": \"$('#name').val()\",\"user_metadata\": {\"color\": \"red\"}}" } } ``` @@ -92,7 +109,7 @@ When your users sign up, the custom fields are sent as part of `user_metadata`. ## 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. +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). @@ -109,20 +126,58 @@ window.auth0 = new Auth0({ Your server will then need to call APIv2 to add the necessary custom fields to the user's profile. -## Add Username to Sign Up form +## Add username to the signup form + +One common signup customization is to add a username to the signup. -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. -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. -Once this has been set, when a user is created manually in the Auth0 dashboard, the screen where users enter their information will prompt them for both an email and a username. +```html +
    +
    + Sign up +

    + +

    +

    + +

    +

    + +

    + +
    +
    +``` -Similarly, the Lock widget in sign up mode will prompt for a username, email and password. +```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() + } +} -Then users can log in with Username and Password. +$.ajax(settings).done(function (response) { + console.log(response); +}); +``` -## Optional: Verifying password strength +## 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 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. +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/articles/libraries/error-messages.md b/articles/libraries/error-messages.md index 3169930aa7..a6c1e29606 100644 --- a/articles/libraries/error-messages.md +++ b/articles/libraries/error-messages.md @@ -1,10 +1,20 @@ --- section: libraries -description: Common errors that you might get when you authenticate users using Auth0 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 Authentication Errors +# 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. This article lists the most common errors that you might get, if you use any of the Auth0 libraries for authentication. +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 @@ -12,13 +22,14 @@ In the case of a failed signup, the most common errors are: | **Error** | **Description** | |-|-| -| **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 | -| **unauthorized** | If you cannot sign up for this application. May have to do with the violation of a specific rule | | **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 @@ -26,13 +37,13 @@ In the case of a failed login, the most common errors are: | **Error** | **Description** | |-|-| -| **unauthorized** | The user you are attempting to sign in with is blocked | -| **too_many_attempts** | The account is blocked due to too many attempts to sign in | +| **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 | -| **mfa_required** | The user must provide the [multifactor authentication](/multifactor-authentication) code to authenticate | -| **mfa_registration_required** | The administrator has required [multifactor authentication](/multifactor-authentication), but the user has not enrolled | -| **mfa_invalid_code** | The [multifactor authentication](/multifactor-authentication) code provided by the user is invalid/expired | -| **PasswordStrengthError** | The password provided does not match the connection's [strength requirements](/connections/database/password-strength) | | **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) | -| **invalid_user_password** | The username and/or password used for authentication are invalid | -| **access_denied** | When using web-based authentication, the resource server denies access per OAuth2 specifications | +| **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/articles/libraries/index.md b/articles/libraries/index.md index 45b6e2478d..cb41e46b6c 100644 --- a/articles/libraries/index.md +++ b/articles/libraries/index.md @@ -2,41 +2,28 @@ section: libraries classes: topic-page title: Auth0 Libraries -description: Overview of the Auth0 Libraries and SDKs +description: Auth0 Libraries and SDKs overview +topics: + - libraries + - lock + - auth0js +contentType: + - index + - concept ---

    Auth0 Libraries

    -

    - There are several widgets and SDKs available for developers to provide a frictionless, simple experience when using Auth0. Take a look below to find documentation on the tools that you need to get started! +

    + 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/_lock_auth0js_deprecations_notice') %> - -## How Should You Implement Auth0? - -When adding Auth0 to your web apps, the best solution is to use Auth0's [universal login](/hosted-pages/login). Using universal login is a simple process, and prevents the pitfalls of [cross-origin authentication](/cross-origin-authentication). The login page uses by default the Lock Widget to authenticate users, but there is also a template for Lock Passwordless and a template for a custom UI built with the Auth0.js SDK available. - -You can customize the page in the [Hosted Pages Editor](${manage_url}/#/login_page). - -If universal login does not meet your requirements, however, Auth0 has a variety of options which can be embedded in your applications to assist with authentication. - -* [Lock](#lock) is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface. -* [Auth0 SDKs](#auth0-sdks) are client-side libraries that do not come with a user interface. These allow for expanded customization of the behavior and appearance of the login process. -* The [Authentication API](/api/authentication) can be used to integrate applications with Auth0 without using any of the Auth0 libraries. - -The best option to choose will depend on the needs of your app. Check out [When to Use Lock](/libraries/when-to-use-lock) for more information to help you decide between using Lock or an SDK. +<%= include('../_includes/_embedded_login_warning') %> ## Lock -The Lock widget is a simple way to integrate Auth0 into existing projects and provide the frictionless login and signup experience that you want for your app. Lock gives your users a customizable UI with which to authenticate in your app. - -The Lock widget for each platform has detailed reference documentation. - -### Lock Reference Documentation -
    • Lock for Web @@ -49,22 +36,19 @@ The Lock widget for each platform has detailed reference documentation.
    -### Lock Support Table - -Below are the GitHub links and support status for the various Lock widgets. +### Lock repositories and support status <%= include('../_includes/_libraries_support_lock') %> - -## Auth0 SDKs - -Auth0 SDKs include no UI. Instead, you would use one of these SDKs alongside your custom UI. - -### SDK Reference Documentation - -The most commonly used SDKs have reference documentation. +## SDKs -### SDK Support Table - -Below are listed all of the SDKs that are available for Auth0, with GitHub links and their support status. +### SDK repositories and support status <%= include('../_includes/_libraries_support_sdks') %> - -### Framework/Platform Integration SDK Support Table +### Platform integration repositories and support status <%= include('../_includes/_libraries_support_frameworks') %> - ::: note -Auth0 reserves the right to downgrade support for an SDK to Community-Supported at any time. +Auth0 reserves the right to downgrade an SDK from **Supported** to **Community-Supported** at any time. ::: diff --git a/articles/libraries/lock-android/_includes/_lock-version.md b/articles/libraries/lock-android/_includes/_lock-version.md index db1a84107b..4c92f0862e 100644 --- a/articles/libraries/lock-android/_includes/_lock-version.md +++ b/articles/libraries/lock-android/_includes/_lock-version.md @@ -1,3 +1,3 @@ ::: version-warning -This document covers an outdated version of Lock for Android. We recommend you to [upgrade to v2](/libraries/lock-android/v2/migration-guide) +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/articles/libraries/lock-android/v1/configuration.md b/articles/libraries/lock-android/v1/configuration.md index 7d1b245649..918f0e31ed 100644 --- a/articles/libraries/lock-android/v1/configuration.md +++ b/articles/libraries/lock-android/v1/configuration.md @@ -2,6 +2,16 @@ 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 @@ -193,7 +203,7 @@ After a successful sign up of a user, sign him/her in too. 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) +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); diff --git a/articles/libraries/lock-android/v1/delegation-api.md b/articles/libraries/lock-android/v1/delegation-api.md index 9ca1c0ea9a..f868a9de45 100644 --- a/articles/libraries/lock-android/v1/delegation-api.md +++ b/articles/libraries/lock-android/v1/delegation-api.md @@ -2,11 +2,24 @@ 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 @@ -15,7 +28,7 @@ Here's an example Lock lock = LockContext.getLock(this); AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); String apiType = "firebase"; -String token = .... //Your Auth0 id_token of the logged in User +String token = .... //Your Auth0 ID Token of the logged in User Map parameters = ParameterBuilder.newEmptyBuilder() .set("id_token", token) .set("api_type", apiType) diff --git a/articles/libraries/lock-android/v1/index.md b/articles/libraries/lock-android/v1/index.md index cfa92699ca..9c2bdbf318 100644 --- a/articles/libraries/lock-android/v1/index.md +++ b/articles/libraries/lock-android/v1/index.md @@ -3,7 +3,18 @@ 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 diff --git a/articles/libraries/lock-android/v1/internationalization.md b/articles/libraries/lock-android/v1/internationalization.md index aa711f2b94..141c75ae56 100644 --- a/articles/libraries/lock-android/v1/internationalization.md +++ b/articles/libraries/lock-android/v1/internationalization.md @@ -2,6 +2,17 @@ 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 diff --git a/articles/libraries/lock-android/v1/native-social-authentication.md b/articles/libraries/lock-android/v1/native-social-authentication.md index fc38397fbc..295964224c 100644 --- a/articles/libraries/lock-android/v1/native-social-authentication.md +++ b/articles/libraries/lock-android/v1/native-social-authentication.md @@ -1,6 +1,18 @@ --- 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 diff --git a/articles/libraries/lock-android/v1/passwordless-magic-link.md b/articles/libraries/lock-android/v1/passwordless-magic-link.md index 78b80274d7..a318f4fb5f 100644 --- a/articles/libraries/lock-android/v1/passwordless-magic-link.md +++ b/articles/libraries/lock-android/v1/passwordless-magic-link.md @@ -1,18 +1,31 @@ --- 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/application-grant-types) for more information. Alternatively, you can use Lock Passwordless with Auth0's [universal login](/hosted-pages/login). +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. +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**. @@ -25,7 +38,7 @@ This feature works as long as the user has not already chosen a default app to h 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 Andrdoi prior to 6.0, at least until the user chooses to always open the links with the app. +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. @@ -39,7 +52,7 @@ Auth0 will generate the [Digital Asset Links](https://developers.google.com/digi 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 lenght array, it can include all the fingerprints we want, so for example we could add both our release and debug fingerprints. +- **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 @@ -155,9 +168,9 @@ Also notice that in case we'll only use one passwordless method (SMS or Email) y ### 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 appropiate mode. +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` especifying the passwordless mode `MODE_EMAIL_MAGIC_LINK`: +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, diff --git a/articles/libraries/lock-android/v1/passwordless.md b/articles/libraries/lock-android/v1/passwordless.md index 9625d3f3bc..473c2ee94a 100644 --- a/articles/libraries/lock-android/v1/passwordless.md +++ b/articles/libraries/lock-android/v1/passwordless.md @@ -2,12 +2,25 @@ 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. +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). diff --git a/articles/libraries/lock-android/v1/refresh-jwt-tokens.md b/articles/libraries/lock-android/v1/refresh-jwt-tokens.md index b1e2f06655..6460b9756c 100644 --- a/articles/libraries/lock-android/v1/refresh-jwt-tokens.md +++ b/articles/libraries/lock-android/v1/refresh-jwt-tokens.md @@ -1,18 +1,33 @@ --- 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') %> -When an authentication is performed with the `offline_access` scope included, it will return a [Refresh Token](/refresh-token) that can be used to request a new JWT token and avoid asking the user their credentials again. +<%= 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 retreive `id_token` or `refresh_token` from the token when a the user logs in. +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() { @@ -21,17 +36,17 @@ private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() { Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER); String idToken = token.getIdToken(); String refreshToken = token.getRefreshToken(); - // Store id_token or refresh_token in a secure storage + // Store ID Token or Refresh Token in secure storage } }; ``` -Then, we need to store `id_token` or `refresh_token` in a secure storage after the user is authenticated by Auth0. And finally, you can request a new `id_token` using either of them by calling to Auth0`s **delegation** endpoint. +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 +## Using a non-expired ID Token ```java -String idToken = // Retrieve id_token from the secure storage +String idToken = // Retrieve ID Token from secure storage Lock lock = LockContext.getLock(this); AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); client.delegationWithIdToken(idToken).start(new RefreshIdTokenCallback() { @@ -47,10 +62,10 @@ client.delegationWithIdToken(idToken).start(new RefreshIdTokenCallback() { }); ``` -## Using refresh_token +## Using Refresh Token ```java -String refreshToken = // Retrieve refresh_token from the secure storage +String refreshToken = // Retrieve Refresh Token from secure storage Lock lock = LockContext.getLock(this); AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); client.delegationWithRefreshToken(refreshToken).start(new RefreshIdTokenCallback() { @@ -64,4 +79,4 @@ client.delegationWithRefreshToken(refreshToken).start(new RefreshIdTokenCallback //FAILURE } }); -``` \ No newline at end of file +``` diff --git a/articles/libraries/lock-android/v1/sending-authentication-parameters.md b/articles/libraries/lock-android/v1/sending-authentication-parameters.md index fece19d8fb..9ebaa1ad4e 100644 --- a/articles/libraries/lock-android/v1/sending-authentication-parameters.md +++ b/articles/libraries/lock-android/v1/sending-authentication-parameters.md @@ -1,12 +1,23 @@ --- 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 +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 @@ -26,11 +37,11 @@ The following parameters are supported: * `protocol` * `device` * `connection_scopes` -* `nonce` +* `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`. +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: @@ -48,11 +59,11 @@ Map parameters = builder 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'`: 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'`). +* `'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 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`). +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`. diff --git a/articles/libraries/lock-android/v1/use-your-own-ui.md b/articles/libraries/lock-android/v1/use-your-own-ui.md index 2e54486c2c..5ab6f8899c 100644 --- a/articles/libraries/lock-android/v1/use-your-own-ui.md +++ b/articles/libraries/lock-android/v1/use-your-own-ui.md @@ -1,13 +1,26 @@ --- 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 **uthentication failed** +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: diff --git a/articles/libraries/lock-android/v2/configuration.md b/articles/libraries/lock-android/v2/configuration.md index cc3efd8043..0a6bc8c3f2 100644 --- a/articles/libraries/lock-android/v2/configuration.md +++ b/articles/libraries/lock-android/v2/configuration.md @@ -2,10 +2,20 @@ 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. +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: @@ -27,7 +37,7 @@ Configurations options are added to the Lock Builder using the following format: ## 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. +- **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 @@ -40,7 +50,7 @@ Configurations options are added to the Lock Builder using the following format: - **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 will be attached to the user profile in `user_metadata`. See [this file](/libraries/lock-android/custom-fields) for more information. +- **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. @@ -52,12 +62,11 @@ Configurations options are added to the Lock Builder using the following format: - **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. -- **withAuthButtonSize(int)**: Allows to customize the Style of the Auth buttons. Possible values are `SMALL` and `BIG`. If this is not specified, it will default to `SMALL` when using **ClassicLock** with at least 2 Enterprise or Database connections, or when using **PasswordlessLock** with a Passwordless connection and less than 3 Social connections. On the rest of the cases, it will use `BIG`. - **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. +- **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. +- **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/articles/libraries/lock-android/v2/custom-authentication-providers.md b/articles/libraries/lock-android/v2/custom-authentication-providers.md index a605d6e322..44e93d8d40 100644 --- a/articles/libraries/lock-android/v2/custom-authentication-providers.md +++ b/articles/libraries/lock-android/v2/custom-authentication-providers.md @@ -2,6 +2,16 @@ 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 diff --git a/articles/libraries/lock-android/v2/custom-fields.md b/articles/libraries/lock-android/v2/custom-fields.md index 1a9742ec82..f68d7cf54b 100644 --- a/articles/libraries/lock-android/v2/custom-fields.md +++ b/articles/libraries/lock-android/v2/custom-fields.md @@ -2,6 +2,16 @@ 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 @@ -16,6 +26,8 @@ Create a new `CustomField` object passing all these 4 mandatory parameters. 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<>(); @@ -36,7 +48,7 @@ Lock lock = Lock.newBuilder(auth0, callback) .build(this); ``` -Thats 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. +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. @@ -52,3 +64,21 @@ Each custom field can only have one `FieldType` associated. * 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/articles/libraries/lock-android/v2/custom-theming.md b/articles/libraries/lock-android/v2/custom-theming.md index 48a3faff4c..9ed6a02d3f 100644 --- a/articles/libraries/lock-android/v2/custom-theming.md +++ b/articles/libraries/lock-android/v2/custom-theming.md @@ -2,6 +2,16 @@ 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 diff --git a/articles/libraries/lock-android/v2/delegation-api.md b/articles/libraries/lock-android/v2/delegation-api.md index c120fb3533..98291b7eb8 100644 --- a/articles/libraries/lock-android/v2/delegation-api.md +++ b/articles/libraries/lock-android/v2/delegation-api.md @@ -2,9 +2,21 @@ 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 @@ -14,7 +26,7 @@ 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 +String token = //Your Auth0 ID Token of the logged in User client.delegationWithIdToken(token, apiType) .start(new BaseCallback, AuthenticationException>() { @Override diff --git a/articles/libraries/lock-android/v2/index.md b/articles/libraries/lock-android/v2/index.md index 6ed265766e..1eb9d180a9 100644 --- a/articles/libraries/lock-android/v2/index.md +++ b/articles/libraries/lock-android/v2/index.md @@ -4,14 +4,25 @@ 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 -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](/hosted-pages/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/application-grant-types) for more information. +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. +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. @@ -43,7 +54,7 @@ You need to fill in a few settings in your [Auth0 Dashboard](${manage_url}) befo ### 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" +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 @@ -63,7 +74,7 @@ For a release keystore, replace the file, alias, store password and key password ## 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. +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 @@ -104,7 +115,7 @@ Add the `LockActivity`. android:label="@string/app_name" android:launchMode="singleTask" android:screenOrientation="portrait" - android:theme="@style/MyLock.Theme"/> + android:theme="@style/Lock.Theme"/> ``` ::: note @@ -119,7 +130,7 @@ In case you are using an older version of Lock the **intent-filter** must be add android:label="@string/app_name" android:launchMode="singleTask" android:screenOrientation="portrait" - android:theme="@style/MyLock.Theme"> + android:theme="@style/Lock.Theme"> @@ -182,14 +193,14 @@ private LockCallback callback = new AuthenticationCallback() { ``` ::: 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 the [Tokens documentation](/tokens) for more specifics. +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 an Open ID Connect compliant responses 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). +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: @@ -269,7 +280,7 @@ As this library depends on `Auth0.Android`, you should keep the files up to date ## Lock configuration -For a full list of Lock's configuration options, check out the [Lock for Android Configuration Reference](/libraries/lock-android/v2/configuration). Also, for users of v1 migrating to v2, read the [Migration Guide](/libraries/lock-android/v2/migration-guide) to see what options have changed. +For a full list of Lock's configuration options, check out the [Lock for Android Configuration Reference](/libraries/lock-android/v2/configuration). ## Error messages diff --git a/articles/libraries/lock-android/v2/internationalization.md b/articles/libraries/lock-android/v2/internationalization.md index 4190556ad2..f2dc13d979 100644 --- a/articles/libraries/lock-android/v2/internationalization.md +++ b/articles/libraries/lock-android/v2/internationalization.md @@ -2,6 +2,16 @@ 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 diff --git a/articles/libraries/lock-android/v2/keystore.md b/articles/libraries/lock-android/v2/keystore.md index fcf3a7ff90..7b31c26d29 100644 --- a/articles/libraries/lock-android/v2/keystore.md +++ b/articles/libraries/lock-android/v2/keystore.md @@ -2,6 +2,16 @@ 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 @@ -47,8 +57,8 @@ Certificate fingerprints: ## 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 "Mobile 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. +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 mobile settings, the Auth0 server won't return the call result to your application. +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/articles/libraries/lock-android/v2/migration-guide.md b/articles/libraries/lock-android/v2/migration-guide.md index 59baa4170e..7fcc499bb9 100644 --- a/articles/libraries/lock-android/v2/migration-guide.md +++ b/articles/libraries/lock-android/v2/migration-guide.md @@ -2,19 +2,32 @@ 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. +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. +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. Call the `userInfo` method on the API application passing the previously obtained Access Token. 1. A `UserProfile` instance is returned ```java @@ -49,6 +62,6 @@ As in the previous version, Lock for Android v2 can be configured with extra opt * `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. +* `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/articles/libraries/lock-android/v2/native-social-authentication.md b/articles/libraries/lock-android/v2/native-social-authentication.md index fc9e52eab1..94576b4705 100644 --- a/articles/libraries/lock-android/v2/native-social-authentication.md +++ b/articles/libraries/lock-android/v2/native-social-authentication.md @@ -2,6 +2,17 @@ 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 @@ -12,7 +23,7 @@ We recommend using browser-based flows, as explained in [Authentication via Auth ## 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. +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.+ @@ -36,7 +47,7 @@ You can check for the latest version on the repository [Readme](https://github.c 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. +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 @@ -48,7 +59,7 @@ You can check for the latest version on the repository [Readme](https://github.c 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 "Mobile Settings" tab. +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 @@ -149,7 +160,7 @@ 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 it's own list of Google Scopes. +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))); @@ -225,7 +236,7 @@ _You can check for the latest version on the repository [Readme](https://github. 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. +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 @@ -236,7 +247,7 @@ _You can check for the latest version on the repository [Readme](https://github. 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 "Mobile Settings" tab. +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 diff --git a/articles/libraries/lock-android/v2/passwordless-magic-link.md b/articles/libraries/lock-android/v2/passwordless-magic-link.md index eeb50778a1..b2479a7542 100644 --- a/articles/libraries/lock-android/v2/passwordless-magic-link.md +++ b/articles/libraries/lock-android/v2/passwordless-magic-link.md @@ -2,12 +2,21 @@ 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 -<%= include('../../../_includes/_native_passwordless_warning') %> - -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. +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. @@ -18,47 +27,27 @@ Go to your [application settings](${manage_url}/#/applications/${account.clientI - **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 SMS or Email connection. - +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 +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 +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 SMS Connection - -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 the following: - -```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. -::: - ### Using Email Connection -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: +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' %} @@ -92,17 +81,6 @@ In the `AndroidManifest.xml` file add the intent-filters inside the `Passwordles android:scheme="https" /> - - - - - - /sms" - android:scheme="https" /> - - ``` @@ -110,7 +88,7 @@ Make sure the Activity's `launchMode` is declared as `singleTask` or the result ## Usage -Lock Passwordless authenticates users by sending them an Email or SMS 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. +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 { @@ -161,11 +139,7 @@ Finally, just start `PasswordlessLock` from inside your activity and perform the startActivity(lock.newIntent(this)); ``` -Depending on which passwordless connections are enabled, Lock will send the LINK in an Email or SMS. The 'email' connection is selected first if available. - - -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. - +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 @@ -173,7 +147,7 @@ With App Links, in Android 6.0 (API level 23) and higher, Android allows an app 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 SMS connection: +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 @@ -183,7 +157,7 @@ Auth0 will generate the [Digital Asset Links](https://developers.google.com/digi /sms" + android:pathPrefix="/android/<%= "${applicationId}" %>/email" android:scheme="https" /> ``` diff --git a/articles/libraries/lock-android/v2/passwordless.md b/articles/libraries/lock-android/v2/passwordless.md index 9dbd4c3211..c5bbd7d967 100644 --- a/articles/libraries/lock-android/v2/passwordless.md +++ b/articles/libraries/lock-android/v2/passwordless.md @@ -2,12 +2,20 @@ 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 -<%= include('../../../_includes/_native_passwordless_warning') %> - -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. +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). @@ -15,11 +23,11 @@ You can achieve a similar result by sending a **LINK** that the user can click t 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](api-auth/tutorials/adoption). +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. +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' @@ -125,6 +133,8 @@ public class MainActivity extends Activity { 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); diff --git a/articles/libraries/lock-android/v2/refresh-jwt-tokens.md b/articles/libraries/lock-android/v2/refresh-jwt-tokens.md index 5d7f66fdec..3f039ce2c3 100644 --- a/articles/libraries/lock-android/v2/refresh-jwt-tokens.md +++ b/articles/libraries/lock-android/v2/refresh-jwt-tokens.md @@ -2,17 +2,29 @@ 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 -When an authentication is performed with the `offline_access` scope included, the returned Credentials will contain a [refresh_token](/refresh-token) and a `id_token`. Both tokens can be used to request a new `access_token` and avoid asking the user their credentials again. +<%= 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 +## Using Refresh Token ```java -String refreshToken = // Retrieve refresh_token from the secure storage +String refreshToken = // Retrieve Refresh Token from secure storage Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); auth0.setOIDCConformant(true); @@ -33,10 +45,10 @@ client.renewAuth(refreshToken) }); ``` -## Using a non-expired id_token +## Using a non-expired ID Token ```java -String idToken = // Retrieve id_token from the secure storage +String idToken = // Retrieve ID Token from the secure storage Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); auth0.setOIDCConformant(true); diff --git a/articles/libraries/lock-ios/_includes/_dependencies.md b/articles/libraries/lock-ios/_includes/_dependencies.md index d4e1eb5057..f0b8babdc6 100644 --- a/articles/libraries/lock-ios/_includes/_dependencies.md +++ b/articles/libraries/lock-ios/_includes/_dependencies.md @@ -1,12 +1,25 @@ ## 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, add the following lines to your `Cartfile`: +If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`: ```ruby github "auth0/Lock.swift" ~> 2.0 -github "auth0/Auth0.swift" ~> 1.0 ``` Then run `carthage bootstrap`. @@ -15,18 +28,20 @@ Then run `carthage bootstrap`. For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). ::: -### Cocoapods +### SPM -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: +If you are using the Swift Package Manager, open the following menu item in Xcode: -```ruby -use_frameworks! -pod 'Lock', '~> 2.0' -pod 'Auth0', '~> 1.0' +**File > Swift Packages > Add Package Dependency...** + +In the **Choose Package Repository** prompt add this url: + +```text +https://github.com/auth0/Lock.swift.git ``` -Then, run `pod install`. +Then press **Next** and complete the remaining steps. ::: note -For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). +For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app). ::: diff --git a/articles/libraries/lock-ios/_includes/_lock-version-1.md b/articles/libraries/lock-ios/_includes/_lock-version-1.md index c10a575955..fb21b112e4 100644 --- a/articles/libraries/lock-ios/_includes/_lock-version-1.md +++ b/articles/libraries/lock-ios/_includes/_lock-version-1.md @@ -1,3 +1,3 @@ ::: version-warning -This document covers an outdated version of Lock for iOS. We recommend you to [upgrade to v2](/libraries/lock-ios/v2/migration) +This document covers an outdated version of Lock for iOS. We recommend that you upgrade to v2. ::: diff --git a/articles/libraries/lock-ios/_includes/_lock-version.md b/articles/libraries/lock-ios/_includes/_lock-version.md index 62e81ed198..2596ef64e6 100644 --- a/articles/libraries/lock-ios/_includes/_lock-version.md +++ b/articles/libraries/lock-ios/_includes/_lock-version.md @@ -1,3 +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. If you are interested in upgrading to this version, take a look at the Lock v1 to Lock v2 migration guide. +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/articles/libraries/lock-ios/v1/customization.md b/articles/libraries/lock-ios/v1/customization.md index af14ee8457..ed76e46250 100644 --- a/articles/libraries/lock-ios/v1/customization.md +++ b/articles/libraries/lock-ios/v1/customization.md @@ -2,13 +2,24 @@ 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`: +Lock UI can be customized by creating your own `A0Theme` and overriding the default one before displaying `A0LockViewController`: ```objc A0Theme *myAwesomeTheme = [[A0Theme alloc] init]; diff --git a/articles/libraries/lock-ios/v1/delegation-api.md b/articles/libraries/lock-ios/v1/delegation-api.md index b53bde914b..81be9f0cf1 100644 --- a/articles/libraries/lock-ios/v1/delegation-api.md +++ b/articles/libraries/lock-ios/v1/delegation-api.md @@ -2,19 +2,33 @@ 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 +NSString *token = ...; // Auth0's ID Token obtained on login A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{ @"id_token": token, A0ParameterAPIType: @"firebase", @@ -28,7 +42,7 @@ A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{ ```swift let client = A0Lock.shared().apiClient() -let token = // Auth0's id_token obtained on login +let token = // Auth0's ID Token obtained on login let parameters = A0AuthParameters.new(with: [ "id_token": token, A0ParameterAPIType: "firebase" diff --git a/articles/libraries/lock-ios/v1/index.md b/articles/libraries/lock-ios/v1/index.md index 46da92b982..57b47e6a6c 100644 --- a/articles/libraries/lock-ios/v1/index.md +++ b/articles/libraries/lock-ios/v1/index.md @@ -6,22 +6,33 @@ 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, Google Apps and Salesforce. +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 **SSO** with 2 or more mobile apps, similar to Facebook and Messenger apps. +* 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). -* Passwordless authentication using **Touch ID** and **SMS**. ::: note Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift/tree/v1) on GitHub. @@ -109,21 +120,22 @@ Then call this method: 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:sourceApplication:annotation:` method and add the following line: +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 *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { - return [self.lock handleURL:url sourceApplication:sourceApplication]; +- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url + options:(NSDictionary *)options { + return [self.lock handleURL:url sourceApplication:app]; } ``` **Swift**: ```swift -func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool { - return self.lock.handle(url, sourceApplication: sourceApplication) +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + return self.lock.handle(url, sourceApplication: app) } ``` @@ -135,7 +147,7 @@ This call is required to be able to return to your application when authenticati `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: +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 @@ -271,7 +283,7 @@ Your `viewController` should also implement the `A0LockEventDelegate` methods: - (void)userAuthenticatedWithToken:(A0Token *)token profile:(A0UserProfile *)profile; - Calls `onAuthenticationBlock` of `A0LockViewController` with token and profile ``` -After implementating your `viewController`, you will need to return it in a `customSignUp` block of `A0LockViewController`. The default value for this block is `nil`. +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**: diff --git a/articles/libraries/lock-ios/v1/lock-ios-api.md b/articles/libraries/lock-ios/v1/lock-ios-api.md index b7c8f3b7d5..660eb5dbe3 100644 --- a/articles/libraries/lock-ios/v1/lock-ios-api.md +++ b/articles/libraries/lock-ios/v1/lock-ios-api.md @@ -2,6 +2,17 @@ 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 @@ -64,7 +75,7 @@ A0APIClient *client = [lock apiClient]; - (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** +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"]; @@ -202,7 +213,7 @@ controller.loginAfterSignup = NO; @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) +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]; diff --git a/articles/libraries/lock-ios/v1/logging.md b/articles/libraries/lock-ios/v1/logging.md index a64938781a..f33ff75ea7 100644 --- a/articles/libraries/lock-ios/v1/logging.md +++ b/articles/libraries/lock-ios/v1/logging.md @@ -2,13 +2,23 @@ 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). +Lock logs several pieces of useful debugging information using [CocoaLumberjack](https://github.com/CocoaLumberjack/CocoaLumberjack). ::: note diff --git a/articles/libraries/lock-ios/v1/native-social-authentication.md b/articles/libraries/lock-ios/v1/native-social-authentication.md index a26f03d9a4..56a08f5617 100644 --- a/articles/libraries/lock-ios/v1/native-social-authentication.md +++ b/articles/libraries/lock-ios/v1/native-social-authentication.md @@ -2,6 +2,18 @@ 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 @@ -9,7 +21,7 @@ description: How to enable native login for some the supported social social con <%= 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. +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-). ::: @@ -32,7 +44,7 @@ Before following these steps, please check our [documentation](/libraries/lock-i ### Facebook -Lock uses Facebook iOS SDK to obtain user's Access Token so you'll need to configure it using your Facebook App info: +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` @@ -54,7 +66,7 @@ A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticationWi ### 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. +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`: @@ -72,7 +84,7 @@ We need your twitter app's key & secret in order to sign the reverse auth reques 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 follwing [this wizard](https://developers.google.com/mobile/add?platform=ios) instead and download the file `GoogleServices-Info.plist` that is generated at the end. +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. diff --git a/articles/libraries/lock-ios/v1/password-reset-ios.md b/articles/libraries/lock-ios/v1/password-reset-ios.md index 04d18a3c47..9d7462f62f 100644 --- a/articles/libraries/lock-ios/v1/password-reset-ios.md +++ b/articles/libraries/lock-ios/v1/password-reset-ios.md @@ -2,6 +2,17 @@ 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 @@ -9,7 +20,7 @@ description: All you need to know about password reset with Lock for iOS. 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 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`. diff --git a/articles/libraries/lock-ios/v1/passwordless.md b/articles/libraries/lock-ios/v1/passwordless.md index 808536489a..6296f23b3c 100644 --- a/articles/libraries/lock-ios/v1/passwordless.md +++ b/articles/libraries/lock-ios/v1/passwordless.md @@ -2,6 +2,17 @@ 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 @@ -13,9 +24,9 @@ description: How to implement Passwordless authentication in Lock v1 `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. +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. +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 @@ -50,7 +61,7 @@ And you'll see SMS login screen ## 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: +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 diff --git a/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md b/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md index b2a33f96cc..69be180f58 100644 --- a/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md +++ b/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md @@ -2,20 +2,33 @@ 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') %> -When an authentication is performed with the `offline_access` scope included, it will return a [Refresh Token](/refresh-token) that can be used to request a new JWT token and avoid asking the user his/her +<%= 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. +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 = ...; @@ -43,9 +56,9 @@ controller.onAuthenticationBlock = { (profile, token) in // 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. +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 +## Using a non-expired ID Token ```objc A0Lock *lock = [A0Lock sharedLock]; @@ -54,10 +67,10 @@ 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! + //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. + //ID Token is no longer valid. //You should ask the user to login again!. }]; ``` @@ -70,16 +83,16 @@ if let token = keychain.stringForKey("id_token") { parameters: nil, success: { token in keychain.setString(token.idToken, forKey: "id_token") - //Just got a new 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. + //ID Token is no longer valid. //You should ask the user to login again!. }) } ``` -## Using refresh_token +## Using Refresh Token ```objc A0Lock *lock = [A0Lock sharedLock]; @@ -88,10 +101,10 @@ 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! + //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. + //Refresh Token is no longer valid. //You should ask the user to login again!. }]; ``` @@ -104,10 +117,10 @@ if let token = keychain.stringForKey("refresh_token") { parameters: nil, success: { token in keychain.setString(token.idToken, forKey: "id_token") - //Just got a new 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. + //Refresh Token is no longer valid. //You should ask the user to login again!. }) } diff --git a/articles/libraries/lock-ios/v1/sending-authentication-parameters.md b/articles/libraries/lock-ios/v1/sending-authentication-parameters.md index b9f51ddd0e..325e52750d 100644 --- a/articles/libraries/lock-ios/v1/sending-authentication-parameters.md +++ b/articles/libraries/lock-ios/v1/sending-authentication-parameters.md @@ -2,13 +2,23 @@ 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 +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]; ``` @@ -24,7 +34,7 @@ The following parameters are supported: * `protocol` * `device` * `connection_scopes` -* `nonce` +* `nonce` * `offline_mode` * `state`. @@ -43,11 +53,11 @@ A0AuthParameters *parameters = [A0AuthParameters newDefaultParams]; 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'`: 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'`). +* `'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 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`). +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`. diff --git a/articles/libraries/lock-ios/v1/swift.md b/articles/libraries/lock-ios/v1/swift.md index 961d6775f0..de468cce8c 100644 --- a/articles/libraries/lock-ios/v1/swift.md +++ b/articles/libraries/lock-ios/v1/swift.md @@ -2,13 +2,24 @@ 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). +**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`. diff --git a/articles/libraries/lock-ios/v1/use-your-own-ui.md b/articles/libraries/lock-ios/v1/use-your-own-ui.md index 9209033813..e7cd769663 100644 --- a/articles/libraries/lock-ios/v1/use-your-own-ui.md +++ b/articles/libraries/lock-ios/v1/use-your-own-ui.md @@ -2,6 +2,17 @@ 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 @@ -86,15 +97,15 @@ After that, you may want to save the user's token to be able to use them later, 2. Also add the following lines to your `AppDelegate` too ```objc - - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { - A0Lock *lock = ... //Get your Lock instance - return [lock handleURL:url sourceApplication:sourceApplication]; +- (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(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool { + func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { let lock = ... // Get your Lock instance - return lock.handle(url, sourceApplication: sourceApplication) + return lock.handle(url, sourceApplication: app) } ``` diff --git a/articles/libraries/lock-ios/v2/configuration.md b/articles/libraries/lock-ios/v2/configuration.md index ad915e9f20..20831500fb 100644 --- a/articles/libraries/lock-ios/v2/configuration.md +++ b/articles/libraries/lock-ios/v2/configuration.md @@ -4,6 +4,16 @@ 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 @@ -39,7 +49,7 @@ Allows Lock to be dismissed by the user. By default this is `false`. ### 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)](https://jwt.io/) containing user information. See the documentation on [Scopes](/scopes) for more information about authentication scopes. +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 { @@ -49,7 +59,7 @@ Scope used for authentication. By default is `openid`. It will return not only t #### Refresh Tokens -Specifying the `offline_access` scope in your Lock options will allow a [Refresh Token](/tokens/refresh-token) 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. +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 @@ -62,7 +72,49 @@ By default Lock will use Auth0's [Terms of Service](https://auth0.com/terms) and } ``` -## Database Options +### 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 @@ -80,7 +132,7 @@ The first screen to present to the user. The default is `.Login`, other options ```swift .withOptions { - $0.initialScreen = .Login + $0.initialScreen = .login } ``` @@ -96,7 +148,7 @@ Specify the type of identifier the login will require. The default is either: ` #### 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 the [Metadata Documentation](/metadata). Note that you must specify the icon to use with your custom text field. +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 { diff --git a/articles/libraries/lock-ios/v2/custom-fields.md b/articles/libraries/lock-ios/v2/custom-fields.md index 80fcbd88d2..3ce74320cf 100644 --- a/articles/libraries/lock-ios/v2/custom-fields.md +++ b/articles/libraries/lock-ios/v2/custom-fields.md @@ -2,15 +2,25 @@ 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 on a second screen after the user completes the basic fields (email, username, password). +**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 the [Metadata Documentation](/metadata). +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 { @@ -25,7 +35,7 @@ When signing up the default information requirements are the user's *email* and You must specify the icon to use with your custom text field. ::: -Thats 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. +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. diff --git a/articles/libraries/lock-ios/v2/customization.md b/articles/libraries/lock-ios/v2/customization.md index e7f4ce4d56..438a224801 100644 --- a/articles/libraries/lock-ios/v2/customization.md +++ b/articles/libraries/lock-ios/v2/customization.md @@ -4,11 +4,20 @@ 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. +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 @@ -267,7 +276,7 @@ The Lock Controller Status Bar style. ### UISearchBarStyle -The Lock Passwordless Search Bar style. +The Lock Passwordless Search Bar style. ```swift .withStyle { diff --git a/articles/libraries/lock-ios/v2/index.md b/articles/libraries/lock-ios/v2/index.md index 9c766f9eb6..ccde6a136d 100644 --- a/articles/libraries/lock-ios/v2/index.md +++ b/articles/libraries/lock-ios/v2/index.md @@ -4,10 +4,25 @@ 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 -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. +::: 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. @@ -15,9 +30,9 @@ Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift) on Gi ## Requirements -- iOS 9 or later -- Xcode 8 -- Swift 3.0 +- iOS 9+ +- Xcode 10+ +- Swift 4+ <%= include('../_includes/_dependencies') %> @@ -28,7 +43,7 @@ Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift) on Gi 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: [UIApplicationOpenURLOptionsKey : Any]) -> Bool { +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { return Lock.resumeAuth(url, options: options) } ``` @@ -123,7 +138,7 @@ Adding a database connection: ```swift .withConnections { - connections.database(name: "Username-Password-Authentication", requiresUsername: true) + $0.database(name: "Username-Password-Authentication", requiresUsername: true) } ``` @@ -131,8 +146,8 @@ Adding multiple social connections: ```swift .withConnections { - connections.social(name: "facebook", style: .Facebook) - connections.social(name: "google-oauth2", style: .Google) + $0.social(name: "facebook", style: .Facebook) + $0.social(name: "google-oauth2", style: .Google) } ``` diff --git a/articles/libraries/lock-ios/v2/internationalization.md b/articles/libraries/lock-ios/v2/internationalization.md index 6fd81ea34b..cda2d77a2b 100644 --- a/articles/libraries/lock-ios/v2/internationalization.md +++ b/articles/libraries/lock-ios/v2/internationalization.md @@ -2,6 +2,17 @@ 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 @@ -45,7 +56,7 @@ 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 the **Reference Language** selection. +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. diff --git a/articles/libraries/lock-ios/v2/logging.md b/articles/libraries/lock-ios/v2/logging.md index 8e37ff681d..821a5dae26 100644 --- a/articles/libraries/lock-ios/v2/logging.md +++ b/articles/libraries/lock-ios/v2/logging.md @@ -2,10 +2,20 @@ 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. +Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings. ## logLevel diff --git a/articles/libraries/lock-ios/v2/migration.md b/articles/libraries/lock-ios/v2/migration.md index b2e215d329..274c9bd896 100644 --- a/articles/libraries/lock-ios/v2/migration.md +++ b/articles/libraries/lock-ios/v2/migration.md @@ -4,10 +4,23 @@ 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. +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 @@ -19,7 +32,7 @@ Lock 2.0 is the latest major release of Lock iOS-OSX. This guide is provided in 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 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. @@ -58,22 +71,22 @@ In Lock v2, this is no longer required. In Lock v1 you'd add the following: ```swift -func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject?) -> Bool { - return A0Lock.shared().handle(url, sourceApplication: sourceApplication) +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: [UIApplicationOpenURLOptionsKey : Any]) -> Bool { +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`: +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 { @@ -131,13 +144,13 @@ Lock .present(from: self) ``` -So, in the `onAuth` callback, you'd only recieve the credentials of the user when the authentication is successful. +So, in the `onAuth` callback, you'd only receive the credentials of the user when the authentication is successful. ::: note -In constrast 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 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. +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 @@ -210,7 +223,7 @@ Lock #### Configuration options -If you needed to tweak Lock behaviour using it's options in v1, you would use the following format: +If you needed to tweak Lock behaviour using its options in v1, you would use the following format: ```swift let controller = A0Lock.shared().newLockViewController() @@ -272,6 +285,8 @@ Auth0 ### 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, but delegation is deprecated and not recommended for most use cases. See the [migrations notice](/migrations#api-authorization-with-third-party-vendor-apis) for more details. +<%= 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/articles/libraries/lock-ios/v2/passwordless.md b/articles/libraries/lock-ios/v2/passwordless.md index 7c9c648002..5f9478eca3 100644 --- a/articles/libraries/lock-ios/v2/passwordless.md +++ b/articles/libraries/lock-ios/v2/passwordless.md @@ -2,18 +2,31 @@ 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 -<%= include('../../../_includes/_native_passwordless_warning') %> +Lock Passwordless handles passwordless authentication using email and sms connections. -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 @@ -24,11 +37,10 @@ Lock **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. ### 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](/applications/enable-universal-links) you can add the following: +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 { @@ -44,4 +56,4 @@ If you are using Lock Passwordless and have specified the `.magicLink` option to func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool { return Lock.continueAuth(using: userActivity) } -``` \ No newline at end of file +``` diff --git a/articles/libraries/lock/index.yml b/articles/libraries/lock/index.yml index 68f1909501..a120986e44 100644 --- a/articles/libraries/lock/index.yml +++ b/articles/libraries/lock/index.yml @@ -2,10 +2,6 @@ versioning: baseUrl: libraries/lock current: v11 versions: - - v9 - - v10 - v11 defaultArticles: - v9: index - v10: index v11: index diff --git a/articles/libraries/lock/v10/api.md b/articles/libraries/lock/v10/api.md deleted file mode 100644 index 8be8ae0baf..0000000000 --- a/articles/libraries/lock/v10/api.md +++ /dev/null @@ -1,248 +0,0 @@ ---- -section: libraries -toc: true -description: Details on the Lock V10 API. ---- -# Lock: API Reference - -<%= include('../../../_includes/_version_warning_lock') %> - -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-event-callback-) 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 -- [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/v10/customization) for details. - -**Example:** - -```js -var clientId = '${account.clientId}'; -var domain = '${account.namespace}'; -// Instantiate Lock - without custom options -var lock = new Auth0Lock(clientId, domain); - -// Listen for the authenticated event and get profile -lock.on("authenticated", function(authResult) { - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } - - // Save token and profile locally - localStorage.setItem("accessToken", authResult.accessToken); - localStorage.setItem("profile", JSON.stringify(profile)); - - // Update DOM - }); -}); -``` - -## getUserInfo() - -```js -getUserInfo(accessToken, callback) -``` - -Once the user has logged in and you are in possesion 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/v10/customization#allowedconnections-array-) -- [auth.params](/libraries/lock/v10/customization#params-object-) -- [allowLogin](/libraries/lock/v10/customization#allowlogin-boolean-) -- [allowSignUp](/libraries/lock/v10/customization#allowsignup-boolean-) -- [allowForgotPassword](/libraries/lock/v10/customization#allowforgotpassword-boolean-) -- [initialScreen](/libraries/lock/v10/customization#initialscreen-string-) -- [rememberLastLogin](/libraries/lock/v10/customization#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/v10/customization). - -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.error_description - } - }); -}); -``` - -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/v10/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/v10/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 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`) - -### The authenticated event - -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 -// Listen for authenticated event; pass the result to a function as authResult -lock.on("authenticated", function(authResult) { - // Call getUserInfo using the token from authResult - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } - // Store the token from authResult for later use - localStorage.setItem('accessToken', authResult.accessToken); - // Display user information - show_profile_info(profile); - }); -}); -``` - -## resumeAuth() - -If you set the [auth.autoParseHash](/libraries/lock/v10/customization#autoparsehash-boolean-) option to `false`, you'll need to call this method 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"); - } - console.log(authResult.accessToken); -}); -``` - -## 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/articles/libraries/lock/v10/auth0js.md b/articles/libraries/lock/v10/auth0js.md deleted file mode 100644 index d87d4b8407..0000000000 --- a/articles/libraries/lock/v10/auth0js.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -section: libraries -description: How to use Lock v10 with auth0.js ---- -# Using Lock With auth0.js - -<%= include('../../../_includes/_version_warning_lock') %> - - -By nature, Lock and the Auth0.js SDK are different things. Lock provides a UI that is customizable (to an extent) with behavior that is customizable (to an extent). It is an easily deployed, easily used interface for Auth0 authentication in custom applications. - -For simple uses, Lock is all that is necessary. However, while using Lock, if more customization is required in an application than Lock allows, functionality from the Auth0.js SDK can be used alongside Lock to meet those needs. An example might be using Lock to handle signups and logins, while using auth0.js to [manage users](/libraries/auth0js#user-management) (read and update user metadata, link user accounts together, and similar tasks). - -### Including auth0.js - -If you are using the Auth0 CDN, you can also include the auth0.js script in the same manner: - -```html - - -``` - -If you installed Lock from npm, you should include `auth0-js` in your project dependencies and import it to pin the particular `auth0-js` version you're using. Before instantiating the `Auth0` object, you will need to require `auth0-js`: - -```js -var auth0 = require('auth0-js'); -``` - -Then, to use `auth0.js`, simply instantiate a new object: - -```js - var webAuth = new auth0.WebAuth({ - domain: '${account.namespace}', - clientID: '${account.clientId}' -}); -``` - -If you need further detail about usage, check out the [Auth0.js Reference](/libraries/auth0js). diff --git a/articles/libraries/lock/v10/authentication-modes.md b/articles/libraries/lock/v10/authentication-modes.md deleted file mode 100644 index 8e446cfdb0..0000000000 --- a/articles/libraries/lock/v10/authentication-modes.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -section: libraries -description: Details about Authentication Modes with Lock V10. -toc: true ---- -# Lock: Authentication Modes - -<%= include('../../../_includes/_version_warning_lock') %> - -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 - -![Lock - Redirect](/media/articles/libraries/lock/v10/gif/redirect.gif) - -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 10, 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. - -![Lock - Social Redirect](/media/articles/libraries/lock/v10/gif/social-redirect.gif) - -## Popup Mode - -![Lock - Redirect](/media/articles/libraries/lock/v10/gif/social-popup.gif) - -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**. - -::: warning -There is a known bug that prevents popup mode from functioning properly in Android or Firefox on iOS, and in Internet Explorer under certain circumstances. As such we recommend only using redirect mode (or if popup mode is absolutely required, detecting these special cases in which popup mode will fail and selectively enabling redirect mode). -::: - -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 - } - } -); -``` - -## Database connections and popup mode - -![Lock - Popup](/media/articles/libraries/lock/v10/gif/popup.gif) - -Some Auth0 features such as [MFA](/multifactor-authentication) and [SSO](/sso/single-sign-on) 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 and display MFA prompts if necessary; this popup window will be blank if users are not prompted for MFA, which might not be a desirable UX. 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 MFA or 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/articles/libraries/lock/v10/configuration.md b/articles/libraries/lock/v10/configuration.md deleted file mode 100644 index 37645264cf..0000000000 --- a/articles/libraries/lock/v10/configuration.md +++ /dev/null @@ -1,910 +0,0 @@ ---- -section: libraries -toc: true -description: Lock 10 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! ---- -# Lock: Configuration Options - -<%= include('../../../_includes/_version_warning_lock') %> - -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); -``` - -## Index of Configurable Options - -### Display - -| Option | Description | -| --- | --- | -| [allowAutocomplete](#allowautocomplete-boolean-) | Whether or not to allow autocomplete in the widget | -| [allowedConnections](#allowedconnections-array-) | limit the application connections shown in Lock to a particular set | -| [allowShowPassword](#allowshowpassword-boolean-) | Whether to allow the user to show password as typing | -| [autoclose](#autoclose-boolean-) | Whether or not Lock auto closes after a login | -| [autofocus](#autofocus-boolean-) | Whether or not focus is set on first input field | -| [avatar](#avatar-object-) | Obtain avatar from a non gravatar source | -| [closable](#closable-boolean-) | Whether or not Lock is closable | -| [container](#container-string-) | Embed Lock in a container | -| [language](#language-string-) | Change the language of Lock | -| [languageDictionary](#languagedictionary-object-) | Change text in particular sections of Lock | -| [popupOptions](#popupoptions-object-) | Customize the location of the popup | -| [rememberLastLogin](#rememberlastlogin-boolean-) | Whether to remember the last login option chosen | - -### Theming - -| Option | Description | -| --- | --- | -| [theme](#theme-object-) | The theme object contains the below theming options | -| [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 | - -### Social - -| Option | Description | -| --- | --- | -| [socialButtonStyle](#socialbuttonstyle-string-) | Force small or large social connection buttons | - -### Authentication - -| Option | Description | -| --- | --- | -| [auth](#auth-object-) | The auth object contains the below auth options | -| [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-) | Whether or not to enable Single Sign On behavior 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 | -| [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-) | Toggle "username", "password" or "username and password" | - -### Enterprise - -| Option | Description | -| --- | --- | -| [defaultEnterpriseConnection](#defaultenterpriseconnection-string-) | Specifies a connection if more than one present | - -### Other - -| Option | Description | -| --- | --- | -| [oidcConformant](#oidcconformant-boolean-) | Whether or not to use OIDC Conformant mode | -| [clientBaseUrl](#clientbaseurl-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 | -| [leeway](#leeway-integer-) | Add leeway for clock skew to JWT expiration times | - ---- - -## Display Options - -### allowAutocomplete {Boolean} - -Determines whether or not the email or username inputs will allow autocomplete (``). Defaults to `false`. - -```js -var options = { - allowAutocomplete: true -}; -``` - -### 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/v10/customization/lock-allowedconnections-database.png) - -![Lock - Allowed Connections](/media/articles/libraries/lock/v10/customization/lock-allowedconnections-social.png) - -### 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/v10/customization/lock-allowshowpassword.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/v10/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/v10/customization/lock-closable.png) - -### container {String} - -The `id` of the html element where the widget will be shown. - -::: note -This makes the widget appear inline within your `div` instead of in a modal pop-out window. -::: - -```html -
    - - -``` - -![Lock - Container](/media/articles/libraries/lock/v10/customization/lock-container.png) - -### 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/v10/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/v10/customization/lock-languagedictionary.png) - -Additionally, check out the [Customizing Error Messages](/libraries/lock/v10/customizing-error-messages) page or the [Internationalization](/libraries/lock/v10/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 = { - 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. Defaults to true. -Request for SSO data and enable **Last time you signed in with[...]** message. Defaults to `true`. - -```js -var options = { - rememberLastLogin: false -}; -``` - -## Theming Options - -### theme {Object} - -Theme options are grouped in the `theme` property of the `options` object. - -#### 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", - } - } - } -}; -``` - -#### 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/v10/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/v10/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/v10/customization/lock-theme-primarycolor.png) - -## Social Options - -### socialButtonStyle {String} - -Determines the size of the buttons for the social providers. Possible values are `big` and `small`. The default style depends on the connections that are available: - -- If only social connections are available, it will default to `big` when there are 5 connections at most, and default to `small` otherwise. -- If connections from types other than social are also available, it will default to `big` when there are 3 social connections at most, and default to `small` otherwise. - -First example, with three social connections, and other connections (in this case, a username-password connection) - with forced small buttons. - -```js -var options = { - socialButtonStyle: 'small' -}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small.png) - -Second example, with `socialButtonStyle` remaining at default behavior - three social connections, with no other connections enabled for this application in the dashboard. - -```js -var options = {}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default-social.png) - -Third example, with `socialButtonStyle` remaining at default behavior - the app has three social connections, with other connections turned on in the dashboard (in this case, a username-password connection). - -```js -var options = {}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png) - -Fourth example, with three social connections, and no other connections enabled in the dasbboard, but with forced small buttons. - -```js -var options = { - socialButtonStyle: 'small' -}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small-social.png) - -## Authentication Options - -### auth {Object} - -Authentication options are grouped in the auth property of the options object. - -```js -var options = { - auth: { - params: {param1: "value1"}, - redirect: true, - redirectUrl: "some url", - responseType: "token", - sso: true - } -}; -``` - -### 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/v10/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/v10/popup-mode) is chosen. - -::: warning -There is a known bug that prevents popup mode from functioning properly in Android or Firefox on iOS, and in Internet Explorer under certain circumstances. As such we recommend either only using redirect mode or detecting these special cases and selectively enabling redirect mode. For more info refer to this [Auth0 Community thread](https://community.auth0.com/questions/9768/popup-login-window-is-not-closed-after-authenticat). -::: - -```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' - } -}; -``` - -#### sso {Boolean} - -Tells Lock to use or not the Single Sign On session created by Auth0 so it can prompt the user to login with the last logged in user. The Auth0 session is not tied to this value since it depends on the application's or tenant' settings. - -::: warning -Failing to set this to true will result in multifactor authentication not working correctly. -::: - -```js -var options = { - auth: { - sso: true - } -}; -``` - -## 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 the [user metadata documentation](/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/lock/v10/custom-signup#using-lock) 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" - }] -} -``` - -![Lock - Additional Signup Fields](/media/articles/libraries/lock/v10/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" - }] -} -``` - -::: 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/v10/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/v10/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/v10/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 option = { - 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' -}; -``` - -### 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" - } -}; -``` - -### 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' -}; -``` - -## 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 -}; -``` - -## Other Options - -### oidcConformant {Boolean} - -Lock should be used in OIDC Conformant mode when embedding it directly in your application. When this mode is enabled, it will force Lock to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. This mode is **not** required when implementing [universal login](/hosted-pages/login). - -To enable OIDC conformant mode, pass a flag in the options object. - -```js -var options = { - oidcConformant: true -} -``` - -Using OIDC Conformant mode in Lock necessitates a cross-origin authentication flow which makes use of third party cookies to process the authentication transaction securely. - -For more information, please see the [OIDC adoption guide](/api-auth/tutorials/adoption) and the [cross-origin authentication documentation](/cross-origin-authentication). - -::: note -Although this flag was present in previous versions, official support was added only in version 10.22.0. -::: - -### clientBaseUrl {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 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: "http://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: "http://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 -}; -``` - -### 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 JWT expirations. Typically the value is no more than a minute or two at maximum. - -```js -var options = { - leeway: 30 -}; -``` - - - -[authparams-link]: /libraries/lock/v10/sending-authentication-parameters -[windowopen-link]: https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Position_and_size_features diff --git a/articles/libraries/lock/v10/customizing-error-messages.md b/articles/libraries/lock/v10/customizing-error-messages.md deleted file mode 100644 index 2609f827e4..0000000000 --- a/articles/libraries/lock/v10/customizing-error-messages.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -section: libraries -description: Customizing error messages with Lock 10 ---- -# Lock: Customizing Error Messages - -<%= include('../../../_includes/_version_warning_lock') %> - -You can customize the error messages that will be displayed in certain situations by providing a [languageDictionary option](/libraries/lock/v10/customization#languagedictionary-object-). A full listing of available `languageDictionary` fields to customize can be found in the GitHub repository's [English Dictionary file for Lock 10](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 -); -``` - -These errors will be shown on the widget header. diff --git a/articles/libraries/lock/v10/i18n.md b/articles/libraries/lock/v10/i18n.md deleted file mode 100644 index 99e935485e..0000000000 --- a/articles/libraries/lock/v10/i18n.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -section: libraries -description: Lock 10 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. ---- -# Lock: Internationalization - -<%= include('../../../_includes/_version_warning_lock') %> - -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. Take a look at that [i18n directory](https://github.com/auth0/lock/blob/master/src/i18n/) for a current list of provided languages. - -In order to use the below examples, you'll need to first include Lock in your page: - -```html - - -``` - -Then, you will need to define your `options` object, and instantiate Lock. - -```js -// Select a supported language -var options = { - language: 'es' -}; - -// Initiating our Auth0Lock -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - options -); -``` - -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). You can look at existing language files to provide an example format to copy for any new languages you wish to add yourself. If and when supported languages are added to Lock, they will be added to the `i18n` directory with new releases. - -::: 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). -::: - -You can also customize your own specific dictionary items using the `languageDictionary`option. This is especially useful if you want to keep the language using one of the supported languages, but change the specific wording of a few items, such as re-wording the `title` or making various other labels read different messages, but 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 -); -``` - -Furthermore, the `languageBaseUrl` option, which takes a string value (a URL), overrides the language source url for Auth0's provided translations. By default it uses to 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. - -::: note -For an example of available `languageDictionary` property names, and of how to structure a `language` file, see the [English dictionary file for Lock 10](https://github.com/auth0/lock/blob/master/src/i18n/en.js). And for more information on how to configure Lock, check out the [api reference](/libraries/lock/v10/api) or the full reference of [configuration options](/libraries/lock/v10/customization) that are available. -::: diff --git a/articles/libraries/lock/v10/index.md b/articles/libraries/lock/v10/index.md deleted file mode 100644 index 239bdb936e..0000000000 --- a/articles/libraries/lock/v10/index.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -section: libraries -toc: true -title: Lock 10 for Web -description: A widget that provides a frictionless login and signup experience for your web apps. -img: media/articles/libraries/lock-web.png ---- -# Lock 10 for Web - -<%= include('../../../_includes/_version_warning_lock') %> - -Lock is an embeddable login form, [configurable to your needs][lock-configuration] and ready for use on web apps. It enables you to easily add social identity providers to Lock, allowing your users to login seamlessly using any provider they want. - -::: note -Check out the [Lock repository](https://github.com/auth0/lock) on GitHub. -::: - -## Lock 10 Installation - -You can install Lock 10 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 (with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock/releases)): - -```html - -``` - -::: note -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][example-browserify] and [webpack][example-webpack]. - -## Usage - -### 1. Initializing Lock - -First, you'll need to initialize a new `Auth0Lock` object, and provide it with your Auth0 client ID (the unique application ID for each Auth0 application app, which you can get from the [management dashboard](${manage_url})) and your Auth0 domain (for example, `yourname.auth0.com`). - -```js -// Initializing 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). You can also save the token or profile to `localStorage` for later use. - -```js -// Listening for the authenticated event -lock.on("authenticated", function(authResult) { - // Use the token in authResult to getUserInfo() and save it to localStorage - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } - - document.getElementById('nick').textContent = profile.nickname; - - localStorage.setItem('accessToken', authResult.accessToken); - localStorage.setItem('profile', JSON.stringify(profile)); - }); -}); -``` - -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(); -}); -``` - -## Cross-Origin Authentication - -Embedding Lock within your application, rather than using [universal login](/hosted-pages/login), requires [cross-origin authentication](/cross-origin-authentication). In order to use embedded Lock v10 via cross-origin authentication, you must set the [oidcconformant](/libraries/lock/v10/configuration#oidcconformant-boolean-) option to `true`. - -## 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. - -## Next Steps - -This document has shown how to use Lock 10 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 v10 API Reference][lock-api] -* [Lock Configuration Options][lock-configuration] -* [Lock UI Customization][ui-customization] -::: - - - -[auth0-main]: https://auth0.com -[playground-url]: http://auth0.github.com/playground -[new-features]: /libraries/lock/v10/new-features -[example-browserify]: https://github.com/auth0/lock/tree/master/examples/bundling/browserify -[example-webpack]: https://github.com/auth0/lock/tree/master/examples/bundling/webpack -[display-modes]: /libraries/lock/v10/customization#container -[development-notes]: https://github.com/auth0/lock -[release-process]: https://github.com/auth0/lock -[sending-authentication-parameters]: /libraries/lock/v10/sending-authentication-parameters - -[getting-started]: /libraries/lock#lock-10-installation -[lock-configuration]: /libraries/lock/v10/configuration -[ui-customization]: /libraries/lock/v10/ui-customization -[lock-api]: /libraries/lock/v10/api -[lock-auth0js]: /libraries/lock/v10/auth0js -[lock-issues]: /libraries/lock/v10/issues -[migration-guide]: /libraries/lock/v10/migration-guide -[i18n-notes]: /libraries/lock/v10/i18n -[popup-mode]: /libraries/lock/v10/popup-mode diff --git a/articles/libraries/lock/v10/migration-guide.md b/articles/libraries/lock/v10/migration-guide.md deleted file mode 100644 index 5eed2c7561..0000000000 --- a/articles/libraries/lock/v10/migration-guide.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -section: libraries -toc: true -description: Lock 9 to Lock 10 Migration Guide ---- -# Lock 9 to Lock 10 Migration Guide - -The following instructions assume you are migrating from **Lock 9** to the latest **Lock 10**. If you are upgrading from a preview release of Lock 10, please refer to the [preview changes](#upgrading-from-preview-releases). Otherwise, read on! - -If you just want a quick list of new features to see what changes Lock 10 has introduced, take a look at the [new features page](/libraries/lock/v10/new-features). - -The goal of this migration guide is to provide you with all of the information you would need to update your Lock 9 installation to Lock 10. Of course, your first step is to install or include the latest version of Lock 10 rather than Lock 9. Beyond that, take a careful look at each of the areas on this page. You will need to change your implementation to reflect the new changes, not only the initialization of Lock and your calls to Lock methods, but especially any configuration options you were implementing may need inspected and changed. Take a look below for more information! - -## General Changes and Additions - -### User Profiles - -- The profile is no longer fetched automatically after a successful login, you need to call [lock.getUserInfo](/libraries/lock/v10/api#getuserinfo-). - -### Redirect Mode vs Popup Mode - -- Lock now uses Redirect Mode by default. To use [Popup Mode](/libraries/lock/v10/popup-mode), you must enable this explicitly with the [redirect](/libraries/lock/v10/configuration#redirect-boolean-) option `auth: { redirect: false }`. -- You no longer need to call `parseHash` when implementing Redirect Mode. The data returned by that method is provided to the `authenticated` event listener. - -### Configuration and Customization Options - -- The show method is no longer the place to include options to configure Lock's appearance or behavior. You instead pass the options to the constructor and then you [listen for an authenticated event](/libraries/lock/v10/api#on-) instead of providing a callback. - -```js -var options = { - theme: { - logo: 'https://example.com/logo.png', - primaryColor: '#31324F' - } -}; -``` - -```js -var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', options); -``` - -::: note -Lock 10 does _allow_ some configuration methods to be added to the show() method in order to override the defaults for special use cases. See more [in the Lock api doc](/libraries/lock/v10/api#show-). -::: - -### Events Changed - -- Events have significantly changed between Lock 9 and Lock 10. The events that were emitted [in Lock 9](/libraries/lock/v9/events) are no longer used in Lock 10. The new events list for Lock 10 can be found on the [Lock 10 API page](/libraries/lock/v10/api#on-). -- Important notes about the new `authenticated` event: The `authenticated` event listener has a single argument, an `authResult` object. This object contains the following properties: `idToken`, `accessToken`, `state`, `refreshToken` and `idTokenPayload`. Most of them correspond to the arguments which were previously passed to the `show` method's callback. - -### Internationalization - -- Not all languages supported by Lock v9 are supported by Lock v10. Please see the [i18n directory](https://github.com/auth0/lock/tree/master/src/i18n) in the GitHub repository for a current list of supported languages in Lock. - -### Removed Methods - -- The `showSignin`, `showSignup` and `showReset` methods are no longer available. You can emulate the behavior of this options with the [initialScreen](/libraries/lock/v10/configuration#initialscreen-string-), [allowLogin](/libraries/lock/v10/configuration#allowlogin-boolean-), [allowSignUp](/libraries/lock/v10/configuration#allowsignup-boolean-) and [allowForgotPassword](/libraries/lock/v10/configuration#allowforgotpassword-boolean-) options. -- The `getClient` method and the `$auth0` property are no longer available. You can, instead, simply instantiate `Auth0` when using functionality from `auth0.js`. If you need help with how to do this, see the [Using Lock with auth0js page](/libraries/lock/v10/auth0js). - -## Changes to configuration Options - -Some existing options suffered changes, in addition to the beforementioned removals and additions. Please see below for brief descriptions, or consult the [configuration reference](/libraries/lock/v10/configuration) for more information. - -### Display Options - -- The `connections` option was renamed to [allowedConnections](/libraries/lock/v10/configuration#allowedconnections-array-). -- The `focusInput` option was renamed to [autofocus](/libraries/lock/v10/configuration#autofocus-boolean-). -- The `gravatar` option was renamed to [avatar](/libraries/lock/v10/configuration#avatar-object-) and instead of taking `true` and `false` it now takes `null` or an object. -- The `dict` option was split into [language](/libraries/lock/v10/configuration#language-string-) and [languageDictionary](/libraries/lock/v10/configuration#languagedictionary-object-). The `language` option allows you to set the base dictionary for a given language and the `languageDictionary` option allows you to overwrite any translation. Also, the structure of the dictionary has been changed. - -### Theming Options - -- The `icon` option was renamed to [logo](/libraries/lock/v10/configuration#logo-string-) and namespaced under `theme`. Now you use it like this `theme: {logo: "https://example.com/icon.png"}`. -- The [primaryColor](/libraries/lock/v10/configuration#primarycolor-string-) option was namespaced under `theme`. Now you use it like this `theme: {primaryColor: "#ec4889"}`. - -### Social Options - -- The `socialBigButtons` option was renamed to [socialButtonStyle](/libraries/lock/v10/configuration#socialbuttonstyle-string-) and its possible values are `"small"` or `"big"` instead of `true` or `false`. - -### Authentication Options - -- The `authParams` option was renamed to [params](/libraries/lock/v10/configuration#params-object-) and namespaced under `auth`. Now you use it like this `auth: {params: {myparam: "myvalue"}}`. -- The `connection_scopes` parameter under `authParams` is now `connectionScopes` (under the `auth` option) `auth: {connectionScopes: {'facebook': ['scope1', 'scope2']}}`. -- The `popup` option was replaced by [redirect](/libraries/lock/v10/configuration#redirect-boolean-) which is namespaced under `auth`. If you previously used `popup: true` now you need to provide `auth: {redirect: false}`. -- The `callbackURL` option was renamed to [redirectUrl](/libraries/lock/v10/configuration#redirecturl-string-) and namespaced under `auth`. Now you use it like this `auth: {redirectUrl: "https://example.com/callback"}`. -- The [responseType](/libraries/lock/v10/configuration#responsetype-string-) option was namespaced under `auth`. Now you use it like this `auth: {responseType: "code"}`. -- The [sso](/libraries/lock/v10/configuration#sso-boolean-) option was namespaced under `auth`. Now you use it like this `auth: {sso: false}`. - -### Database Options - -- The `disableResetAction` option was renamed to [allowForgotPassword](/libraries/lock/v10/configuration#allowforgotpassword-boolean-). -- The `disableSignUpAction` option was renamed to [allowSignUp](/libraries/lock/v10/configuration#allowsignup-boolean-). -- The `defaultUserPasswordConnection` option has been replaced by the [defaultDatabaseConnection](/libraries/lock/v10/configuration#defaultdatabaseconnection-string-) and the [defaultEnterpriseConnection](/libraries/lock/v10/configuration#defaultenterpriseconnection-string-) options. -- The `resetLink` option was renamed to [forgotPasswordLink](/libraries/lock/v10/configuration#forgotpasswordlink-string-). -- The `signupLink` option was renamed to [signUpLink](/libraries/lock/v10/configuration#signuplink-string-) (change in casing). - -### Other Options - -- The `forceJSONP` option was removed. - -## Further Reading - -- Some other options were added, see [New Features page](/libraries/lock/v10/new-features) for details. -- Check out the [configuration page](/libraries/lock/v10/configuration) for more details on all of the configuration options that are available. -- Take a look at the [api page](/libraries/lock/v10/api) for more details on Lock 10's API. diff --git a/articles/libraries/lock/v10/new-features.md b/articles/libraries/lock/v10/new-features.md deleted file mode 100644 index b1e17b9278..0000000000 --- a/articles/libraries/lock/v10/new-features.md +++ /dev/null @@ -1,216 +0,0 @@ ---- -section: libraries -title: New Features in Lock 10 -description: Describes the new features introduced at Lock v10 -toc: true ---- -# New Features in Lock 10 - -<%= include('../../../_includes/_version_warning_lock') %> - -## Custom sign up fields - -You can add input fields to the sign up form with the new option `additionalSignUpFields`. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - additionalSignUpFields: [{ - name: "address", // required - placeholder: "enter your address", // required - icon: "https://example.com/address_icon.png", // optional - prefill: "street 123", // optional - validator: function(value) { // optional - // only accept addresses with more than 10 chars - return value.length > 10; - } - }] // more fields could be specified - }); -``` - -If the possible values for the field are predefined, you can add a field with the `"select"` `type`. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - additionalSignUpFields: [{ - type: "select", // required - name: "location", // required - placeholder: "choose your location", // required - options: [ // required - {value: "us", label: "United States"}, - {value: "fr", label: "France"}, - {value: "ar", label: "Argentina"} - ], - prefill: "us", // optional - icon: "https://example.com/assests/location_icon.png" // optional - }] - }, - function(error, result) { - // handle auth -}); -``` - -The `options` and `prefill` properties can also be functions, which is useful when you need to make a request to obtain their values. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - additionalSignUpFields: [{ - type: "select", // required - name: "location", // required - placeholder: "choose your location", // required - options: function(cb) { // required - // obtain options, in case of error you call cb with the error in the - // first arg instead of null - cb(null, options); - }, - prefill: function(cb) { // optional - // obtain prefill, in case of error you call cb with the error in the - // first arg instead of null - cb(null, prefill); - }, - icon: "https://example.com/assests/location_icon.png" // optional - }] - }, - function(error, result) { - // handle auth -}); -``` - -## Custom avatar provider - -By default, [Gravatar](http://gravatar.com/) is used to fetch the user avatar and display name, but you can obtain them from anywhere with the `avatar` option. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - avatar: { - url: function(email, cb) { - // Obtain the avatar url for the email input by the user, Lock - // will preload the image it 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); - } - } - } -); -``` - -If you don't want to display an avatar pass `null`. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - avatar: null - } -); -``` - -## Prefilled fields - -It is now possible to fill the user's email and/or username input if you know them beforehand with the `prefill` option. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - prefill: { - email: "someone@example.com", - username: "someone" - } - } -); -``` - -## Authentication options - -Authentication options have been grouped in their own namespace. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - auth: { - params: {name: "value"}, - redirect: true, - redirectUrl: window.location.href - responseType: "token", - sso: true - } - } -); -``` - -## Initial screen - -You may now choose the screen that will be first displayed when Lock is shown with the `initialScreen` option. The following are valid values: - -* `login` (default); -* `forgotPassword`; -* `signUp`; - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - initialScreen: "signUp" // "login" or "forgotPassword" - } -); -``` - -## Theme options - -Theme options have been grouped in their own namespace. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - theme: { - logo: "https://example.com/icon.png", - primaryColor: "#ec4889" - } - } -); -``` - -## Sign up Terms and Conditions - -You can ask the user to accept the terms and conditions by clicking a checkbox input before signing up with the `mustAcceptTerms` option. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - languageDictionary: { - signUpTerms: "I agree to the terms of service and privacy policy." - }, - mustAcceptTerms: true - } -); -``` diff --git a/articles/libraries/lock/v10/selecting-the-connection-for-multiple-logins.md b/articles/libraries/lock/v10/selecting-the-connection-for-multiple-logins.md deleted file mode 100644 index 0d833894d5..0000000000 --- a/articles/libraries/lock/v10/selecting-the-connection-for-multiple-logins.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -section: libraries -description: How to select different connection types for multiple login options with Lock V10. ---- -# Selecting the Connection in Lock - -<%= include('../../../_includes/_version_warning_lock') %> - -Auth0 allows you to offer your users multiple ways of authenticating. This is especially important with SaaS, multi-tenant apps, in which a single app is used by many different organizations, each one of which is potentially using different systems such as LDAP, Active Directory, Google Apps, or username/password stores. - -![](/media/articles/hrd/sd4h-6wlwOsQA1PCQKLAmtQ.png) - -::: note -Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery". A pompous name for a simple problem. -::: - -## Option 1: Programmatically - -When you initiate an authentication transaction with Auth0 you can optionally send a `connection` parameter. This value maps directly with any connection defined in the [Dashboard](${manage_url}). - -If using the [Lock](/libraries/lock/v10), this is as simple as initiating Lock with the following option: - -```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/v10/api#show-) for the `show` method for more information. -::: - -There are multiple practical ways of determining which of your `connection` value to indicate for any given user. Here are two common scenarios: - -* You can use vanity URLs: `https://{connection}.yoursite.com` or `https://www.yoursite.com/{connection}`. When a user arrives at your application with the vanity URL, you can pick up that value and pass it to Lock as the `allowedConnections` value. -* You can just ask the user to pick from a list of all of your available connections (or those you want to be chosen from) at some point, and then show only that connection to that user. -* You could use non-human-readable connection names and use some external mechanism to map these to users (for example, through a primary verification, out of band channel for example). - -::: note -The first two methods above assume it is acceptable for your app to disclose the names of all of your connections, which may not be appropriate for your application. -::: - -## Option 2: Using Email Domains with Lock - -The [Lock](/libraries/lock/v10) has built in functionality for identity provider selection. For social connections it will show logos for all those enabled in that particular app. - -An additional feature in the 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 is typing an e-mail 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. diff --git a/articles/libraries/lock/v10/sending-authentication-parameters.md b/articles/libraries/lock/v10/sending-authentication-parameters.md deleted file mode 100644 index 1512bdea40..0000000000 --- a/articles/libraries/lock/v10/sending-authentication-parameters.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -section: libraries -description: Lock V10 documentation on setting authentication parameters. ---- -# Lock: Authentication Parameters - -<%= include('../../../_includes/_version_warning_lock') %> - -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: `access_token`, `scope`, `protocol`, `device`, `request_id`, `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: - -* `scope: 'openid'`: _(default)_ 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). -* `scope: 'openid profile'`: will return all the user attributes in the token. Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. -* `scope: 'openid {attr1} {attr2} {attrN}'`: If you want only specific user attributes to be part of the `id_token` (For example: `scope: 'openid name email picture'`). When selecting specific attributes, the attributes chosen are from those available in the user's profile, which will vary from application to application. - -For more information about scopes, see the [scopes documentation page](/scopes). - -#### Example: retrieve a token with the profile data - -If you want to do this using Lock widget version 10, you should add the `scope` parameter. For example in AngularJS you would use the initializing method of `authProvider`: - -```js -authProvider.init({ - domain: AUTH0_DOMAIN, - clientID: AUTH0_CLIENT_ID, - loginUrl: '/login', - - auth: { - params: { - scope: 'openid profile' - } - } -}); -``` - -::: note -There is also a `connectionScopes` configuration option for Lock 10, 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. Read more about it on the [Lock Configuration Options](/libraries/lock/v10/customization#connectionscopes-object-) page. -::: - -### state {string} - -The `state` parameter is an arbitrary state value that will be mantained across redirects. It is useful to mitigate [CSRF attacks](http://en.wikipedia.org/wiki/Cross-site_request_forgery) and for any contextual information, [such as a return url](/tutorials/redirecting-users), that you might need after the authentication process is finished. - -[Click here to learn more about how to send/receive the state parameter.](/protocols/oauth-state) diff --git a/articles/libraries/lock/v10/ui-customization.md b/articles/libraries/lock/v10/ui-customization.md deleted file mode 100644 index 2759d6921d..0000000000 --- a/articles/libraries/lock/v10/ui-customization.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -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. ---- -# Lock: UI Customization - -<%= include('../../../_includes/_version_warning_lock') %> - -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/v10/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/v10/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/v10/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 the recommended method with Lock 10. The issue is that with new releases of Lock, some styling may change, leading to unintended problems if you are overriding the CSS. Additonally, 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 verion (`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 10, and the ones that existed for earlier versions of Lock will not work with Lock 10. -::: - -## 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/v10/customization) page or the [Lock API](/libraries/lock/v10/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/articles/libraries/lock/v11/api.md b/articles/libraries/lock/v11/api.md index 9dbf23c18c..58949c9ed4 100644 --- a/articles/libraries/lock/v11/api.md +++ b/articles/libraries/lock/v11/api.md @@ -2,10 +2,17 @@ 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-event-callback-) method section! +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 @@ -30,26 +37,42 @@ Initializes a new instance of `Auth0Lock` configured with your application's `cl **Example:** ```js -var clientId = '${account.clientId}'; -var domain = '${account.namespace}'; -// Instantiate Lock - without custom options -var lock = new Auth0Lock(clientId, domain); - -// Listen for the authenticated event and get profile -lock.on("authenticated", function(authResult) { - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } +var Auth = (function() { - // Save token and profile locally - localStorage.setItem("accessToken", authResult.accessToken); - localStorage.setItem("profile", JSON.stringify(profile)); + var privateStore = {}; - // Update DOM - }); -}); + 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() @@ -58,7 +81,7 @@ lock.on("authenticated", function(authResult) { getUserInfo(accessToken, callback) ``` -Once the user has logged in and you are in possesion of a token, you can use that token to obtain the user's profile with `getUserInfo`. This method replaces the deprecated `getProfile()`. +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. @@ -191,34 +214,60 @@ Lock will emit events during its lifecycle. The `on` method can be used to liste - `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 -// Listen for authenticated event; pass the result to a function as authResult -lock.on("authenticated", function(authResult) { - // Call getUserInfo using the token from authResult - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } - // Store the token from authResult for later use - localStorage.setItem('accessToken', authResult.accessToken); - // Display user information - show_profile_info(profile); - }); -}); +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() -If you set the [auth.autoParseHash](/libraries/lock/v11/configuration#autoparsehash-boolean-) option to `false`, you'll need to call this method 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`). +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`. @@ -228,6 +277,7 @@ 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); }); ``` diff --git a/articles/libraries/lock/v11/auth0js.md b/articles/libraries/lock/v11/auth0js.md deleted file mode 100644 index 63e285a1aa..0000000000 --- a/articles/libraries/lock/v11/auth0js.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: libraries -description: How to use Lock v11 with auth0.js v9 ---- -# Using Lock With auth0.js - -By nature, Lock and the Auth0.js SDK are different things. Lock provides a UI that is customizable (to an extent) with behavior that is customizable (to an extent). It is an easily deployed, easily used interface for Auth0 authentication in custom applications. - -For simple uses, Lock is all that is necessary. However, while using Lock, if more customization is required in an application than Lock allows, functionality from the Auth0.js SDK can be used alongside Lock to meet those needs. An example might be using Lock to handle signups and logins, while using auth0.js to [manage users](/libraries/auth0js#user-management) (read and update user metadata, link user accounts together, and similar tasks). - -### Including auth0.js - -If you are using the Auth0 CDN, you can also include the auth0.js script in the same manner: - -```html - - -``` - -If you installed Lock from npm, you should include `auth0-js` in your project dependencies and import it to pin the particular `auth0-js` version you're using. Before instantiating the `Auth0` object, you will need to require `auth0-js`: - -```js -var auth0 = require('auth0-js'); -``` - -Then, to use `auth0.js`, simply instantiate a new object: - -```js -var webAuth = new auth0.WebAuth({ - domain: '${account.namespace}', - clientID: '${account.clientId}' -}); -``` - -If you need further detail about usage, check out the [Auth0.js v9 Reference](/libraries/auth0js). diff --git a/articles/libraries/lock/v11/authentication-modes.md b/articles/libraries/lock/v11/authentication-modes.md index 9b971cad37..b11a8d6310 100644 --- a/articles/libraries/lock/v11/authentication-modes.md +++ b/articles/libraries/lock/v11/authentication-modes.md @@ -2,10 +2,18 @@ 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. +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 @@ -15,10 +23,6 @@ When you click the IdP button (For example, Facebook) with redirect mode, you ar 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**. -::: warning -There is a known bug that prevents popup mode from functioning properly in Android or Firefox on iOS, and in Internet Explorer under certain circumstances. As such we recommend only using redirect mode (or if popup mode is absolutely required, detecting these special cases in which popup mode will fail and selectively enabling redirect mode). -::: - Implementing Lock with Popup Mode is again a simple change of the `redirect` option from its default. ```js @@ -33,13 +37,19 @@ var lock = new Auth0Lock( ); ``` -## Database connections and popup mode +::: 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 [MFA](/multifactor-authentication) and [SSO](/sso/single-sign-on) between multiple applications depend on users being redirected to Auth0 to set a cookie on `'${account.namespace}'`. +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 and display MFA prompts if necessary. 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. +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 MFA or SSO between multiple applications, you can set `sso: false` when using Lock or auth0.js. +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: diff --git a/articles/libraries/lock/v11/configuration.md b/articles/libraries/lock/v11/configuration.md index 3de60e9cec..d5c1e9492c 100644 --- a/articles/libraries/lock/v11/configuration.md +++ b/articles/libraries/lock/v11/configuration.md @@ -2,64 +2,69 @@ 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. +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); ``` -## Index of Configurable Options - -### Display +## UI | Option | Description | | --- | --- | -| [allowAutocomplete](#allowautocomplete-boolean-) | Whether or not to allow autocomplete in the widget | -| [allowedConnections](#allowedconnections-array-) | limit the application connections shown in Lock to a particular set | -| [allowShowPassword](#allowshowpassword-boolean-) | Whether to allow the user to show password as typing | -| [autoclose](#autoclose-boolean-) | Whether or not Lock auto closes after a login | -| [autofocus](#autofocus-boolean-) | Whether or not focus is set on first input field | -| [avatar](#avatar-object-) | Obtain avatar from a non gravatar source | -| [closable](#closable-boolean-) | Whether or not Lock is closable | -| [container](#container-string-) | Embed Lock in a container | -| [language](#language-string-) | Change the language of Lock | +| [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 | -| [rememberLastLogin](#rememberlastlogin-boolean-) | Whether to remember the last login option chosen | +| [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 -### Theming +Theme options are grouped in the `theme` property of the `options` object. | Option | Description | | --- | --- | -| [theme](#theme-object-) | The theme object contains the below theming options | | [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 | -### Social - -| Option | Description | -| --- | --- | -| [socialButtonStyle](#socialbuttonstyle-string-) | Force small or large social connection buttons | +## Authentication -### Authentication +Authentication options are grouped in the `auth` property of the `options` object. | Option | Description | | --- | --- | -| [auth](#auth-object-) | The auth object contains the below auth options | -| [audience](#audience-string-) | The API which will be consuming your `access_token` | +| [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 | +| [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-) | Whether or not to enable Single Sign On behavior in Lock | +| [sso](#sso-boolean-) | Determines whether Single Sign-On is enabled or not in Lock | ### Database @@ -73,33 +78,41 @@ var lock = new Auth0Lock('clientID', 'account.auth0.com', options); | [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-) | Toggle "username", "password" or "username and password" | +| [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 +## 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 | | --- | --- | -| [clientBaseUrl](#clientbaseurl-string-) | Override your application's base URL | +| [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 | -| [leeway](#leeway-integer-) | Add leeway for clock skew to JWT expiration times | +| [connectionResolver](#connectionresolver-function-) | Optional callback function for choosing a connection based on the username information | --- -## Display Options +## UI Options ### allowAutocomplete {Boolean} -Determines whether or not the email or username inputs will allow autocomplete (``). Defaults to `false`. +Determines whether or not the email or username fields will allow autocomplete (``). Defaults to `false`. ```js var options = { @@ -107,6 +120,32 @@ var options = { }; ``` +### 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. @@ -131,23 +170,9 @@ var options = { Examples of `allowedConnections`: -![Lock - Allowed Connections](/media/articles/libraries/lock/v10/customization/lock-allowedconnections-database.png) - -![Lock - Allowed Connections](/media/articles/libraries/lock/v10/customization/lock-allowedconnections-social.png) +![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png) -### 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/v10/customization/lock-allowshowpassword.png) +![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png) ### autoclose {Boolean} @@ -209,7 +234,7 @@ var options = { Default behavior with Gravatar: -![Lock - Avatar](/media/articles/libraries/lock/v10/customization/lock-avatar.png) +![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-avatar.png) ### closable {Boolean} @@ -221,15 +246,13 @@ var options = { }; ``` -![Lock - Closable](/media/articles/libraries/lock/v10/customization/lock-closable.png) +![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. -::: note This makes the widget appear inline within your `div` instead of in a modal pop-out window. -::: ```html
    @@ -247,7 +270,23 @@ This makes the widget appear inline within your `div` instead of in a modal pop- ``` -![Lock - Container](/media/articles/libraries/lock/v10/customization/lock-container.png) +![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} @@ -260,7 +299,7 @@ var options = { }; ``` -![Lock - Language](/media/articles/libraries/lock/v10/customization/lock-language.png) +![Lock - Language](/media/articles/libraries/lock/v11/customization/lock-language.png) ### languageDictionary {Object} @@ -275,7 +314,7 @@ var options = { }; ``` -![Lock - Language Dictionary](/media/articles/libraries/lock/v10/customization/lock-languagedictionary.png) +![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. @@ -287,31 +326,63 @@ Options for the `window.open` [position and size][windowopen-link] features. Thi ```js var options = { - redirect: false, + 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. Defaults to true. -Request for SSO data and enable **Last time you signed in with[...]** message. Defaults to `true`. +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. +::: -## Theming Options +::: note +The **Last time you signed in with [...]** message will not be available under the following circumstances: -### theme {Object} +- 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. -#### authButtons {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" + } + } + } +}; +``` -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: +### 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`. @@ -337,7 +408,7 @@ var options = { }; ``` -#### labeledSubmitButton {Boolean} +### 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. @@ -349,11 +420,11 @@ var options = { }; ``` -![Lock - Labeled Submit Button](/media/articles/libraries/lock/v10/customization/lock-theme-labeledsubmitbutton.png) +![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} +### 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. @@ -365,9 +436,9 @@ var options = { }; ``` -![Lock - Theme - Logo](/media/articles/libraries/lock/v10/customization/lock-theme-logo.png) +![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png) -#### primaryColor {String} +### 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`. @@ -380,74 +451,37 @@ var options = { }; ``` -![Lock - Theme - Primary Color](/media/articles/libraries/lock/v10/customization/lock-theme-primarycolor.png) - -## Social Options - -### socialButtonStyle {String} - -Determines the size of the buttons for the social providers. Possible values are `big` and `small`. The default style depends on the connections that are available: - -- If only social connections are available, it will default to `big` when there are 5 connections at most, and default to `small` otherwise. -- If connections from types other than social are also available, it will default to `big` when there are 3 social connections at most, and default to `small` otherwise. - -First example, with three social connections, and other connections (in this case, a username-password connection) - with forced small buttons. - -```js -var options = { - socialButtonStyle: 'small' -}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small.png) - -Second example, with `socialButtonStyle` remaining at default behavior - three social connections, with no other connections enabled for this application in the dashboard. - -```js -var options = {}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default-social.png) - -Third example, with `socialButtonStyle` remaining at default behavior - the app has three social connections, with other connections turned on in the dashboard (in this case, a username-password connection). - -```js -var options = {}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png) - -Fourth example, with three social connections, and no other connections enabled in the dasbboard, but with forced small buttons. - -```js -var options = { - socialButtonStyle: 'small' -}; -``` - -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small-social.png) +![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png) ## Authentication Options -### auth {Object} +Authentication options are grouped in the `auth` property of the `options` object. -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"}, + params: { + param1: "value1", + scope: "openid profile email" + }, + autoParseHash: true, redirect: true, redirectUrl: "some url", + responseMode: "form_post", responseType: "token", - sso: true + 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. +The `audience` option indicates the API which will be consuming the Access Token that is received after authentication. ```js var options = { @@ -457,7 +491,7 @@ var options = { } ``` -#### autoParseHash {Boolean} +### 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. @@ -469,9 +503,9 @@ var options = { }; ``` -#### connectionScopes {Object} +### connectionScopes {Object} -This option allows you to set scopes to be sent to the oauth2/social connection for authentication. +This option allows you to set scopes to be sent to the oauth2/social connection for authentication. ```js var options = { @@ -485,7 +519,7 @@ var options = { 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} +### 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. @@ -504,14 +538,10 @@ var options = { For more details about supported parameters check the [Authentication Parameters][authparams-link] documentation page. ::: -#### redirect {Boolean} +### 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. -::: warning -There is a known bug that prevents popup mode from functioning properly in Android or Firefox on iOS, and in Internet Explorer under certain circumstances. As such we recommend either only using redirect mode or detecting these special cases and selectively enabling redirect mode. -::: - ```js var options = { auth: { @@ -520,7 +550,7 @@ var options = { }; ``` -#### redirectUrl {String} +### redirectUrl {String} The URL Auth0 will redirect back to after authentication. Defaults to the empty string "" (no redirect URL). @@ -536,7 +566,7 @@ var options = { When the `redirectUrl` is provided (set to non blank value) the `responseType` option will be defaulted to `code` if not manually set. ::: -#### responseMode {String} +### 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. @@ -550,9 +580,9 @@ var options = { }; ``` -#### responseType {String} +### 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. +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 = { @@ -566,27 +596,11 @@ var options = { 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. ::: -#### sso {Boolean} - -Tells Lock to use or not the Single Sign On session created by Auth0 so it can prompt the user to login with the last logged in user. The Auth0 session is not tied to this value since it depends on the application's or tenant' settings. - -::: warning -Failing to set this to true will result in multifactor authentication not working correctly. -::: - -```js -var options = { - auth: { - sso: true - } -}; -``` - ## 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 the [user metadata documentation](/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". +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. @@ -620,7 +634,32 @@ var options = { } ``` -![Lock - Additional Signup Fields](/media/articles/libraries/lock/v10/customization/lock-additionalsignupfields.png) +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 @@ -685,6 +724,20 @@ var options = { } ``` +#### 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. ::: @@ -700,7 +753,7 @@ var options = { }; ``` -![Lock - Allow Login](/media/articles/libraries/lock/v10/customization/lock-allowlogin.png) +![Lock - Allow Login](/media/articles/libraries/lock/v11/customization/lock-allowlogin.png) ### allowForgotPassword {Boolean} @@ -717,7 +770,7 @@ var options = { }; ``` -![Lock - Allow Forgot Password](/media/articles/libraries/lock/v10/customization/lock-allowforgotpassword.png) +![Lock - Allow Forgot Password](/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png) ### allowSignUp {Boolean} @@ -731,7 +784,7 @@ var options = { }; ``` -![Lock - Social Button Style](/media/articles/libraries/lock/v10/customization/lock-allowsignup.png) +![Lock - Social Button Style](/media/articles/libraries/lock/v11/customization/lock-allowsignup.png) ### defaultDatabaseConnection {String} @@ -758,7 +811,7 @@ var options = { Determines whether or not the user will be automatically signed in after a successful sign up. Defaults to `true`. ```js -var option = { +var options = { loginAfterSignUp: false }; ``` @@ -773,6 +826,10 @@ var options = { }; ``` +### 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`. @@ -791,7 +848,8 @@ Allows to set the initial value for the email and/or username inputs. When omitt var options = { prefill: { email: "someone@auth0.com", - username: "someone" + username: "someone", + phoneNumber: "+1234567890" } }; ``` @@ -821,6 +879,16 @@ var options = { }; ``` +### 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} @@ -843,15 +911,21 @@ var options = { }; ``` +## 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 -### clientBaseUrl {String} +### 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 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. +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: "http://www.example.com" + clientBaseUrl: "https://www.example.com" }; ``` @@ -861,13 +935,13 @@ Overrides the language source url for Auth0's provided translations. By default, ```js var options = { - languageBaseUrl: "http://www.example.com" + 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. +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 = { @@ -875,9 +949,17 @@ var options = { }; ``` +### 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 JWT expirations. Typically the value is no more than a minute or two at maximum. +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 = { diff --git a/articles/libraries/lock/v11/customizing-error-messages.md b/articles/libraries/lock/v11/customizing-error-messages.md index 63437efa19..1d06250ce5 100644 --- a/articles/libraries/lock/v11/customizing-error-messages.md +++ b/articles/libraries/lock/v11/customizing-error-messages.md @@ -1,6 +1,15 @@ --- 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 @@ -33,23 +42,9 @@ var lock = new Auth0Lock( ); ``` -If you are returning custom error codes from a [rule](/rules) or a [custom database script](/connections/database/custom-db#error-handling), you can also add the error messages in the dictionary: +## Custom errors in Rules -```js -//custom database script: getUser -function getByEmail (email, callback) { - callback(new ValidationError('custom-error-code', 'Some custom message')); -} -``` - -```js -languageDictionary: { - error: { - forgotPassword: { - "custom-error-code": "Your custom error message" - } - } -} -``` +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: -These errors will be shown on the widget header. +* 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/articles/libraries/lock/v11/i18n.md b/articles/libraries/lock/v11/i18n.md index 826fc4daf8..cdd35c7c3e 100644 --- a/articles/libraries/lock/v11/i18n.md +++ b/articles/libraries/lock/v11/i18n.md @@ -1,19 +1,74 @@ --- 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. Take a look at that [i18n directory](https://github.com/auth0/lock/blob/master/src/i18n/) for a current list of provided languages. +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. -In order to use the below examples, you'll need to first include Lock in your page: +## 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 ``` -Then, you will need to define your `options` object, and instantiate Lock. +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 @@ -29,13 +84,13 @@ var lock = new Auth0Lock( ); ``` -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). You can look at existing language files to provide an example format to copy for any new languages you wish to add yourself. If and when supported languages are added to Lock, they will be added to the `i18n` directory with new releases. - ::: 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). ::: -You can also customize your own specific dictionary items using the `languageDictionary`option. This is especially useful if you want to keep the language using one of the supported languages, but change the specific wording of a few items, such as re-wording the `title` or making various other labels read different messages, but leaving the remaining text on the widget intact. +## 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 @@ -54,8 +109,8 @@ var lock = new Auth0Lock( ); ``` -Furthermore, the `languageBaseUrl` option, which takes a string value (a URL), overrides the language source url for Auth0's provided translations. By default it uses to 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. - ::: note -For an example of available `languageDictionary` property names, and of how to structure a `language` file, see the [English dictionary file for Lock](https://github.com/auth0/lock/blob/master/src/i18n/en.js). And for more information on how to configure Lock, check out the [api reference](/libraries/lock/v11/api) or the full reference of [configuration options](/libraries/lock/v11/configuration) that are available. +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/articles/libraries/lock/v11/index.md b/articles/libraries/lock/v11/index.md index 5aef029a02..babcef08a8 100644 --- a/articles/libraries/lock/v11/index.md +++ b/articles/libraries/lock/v11/index.md @@ -4,10 +4,20 @@ 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, [configurable to your needs](/libraries/lock/v11/configuration), and recommended for use in single page apps. It enables you to easily add social identity providers, so that your users can login seamlessly using any provider they want. +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 @@ -55,17 +65,19 @@ If you are using browserify or webpack to build your project and bundle its depe ### 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-of-cross-origin-authentication) before implementing Lock. +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`). +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 @@ -75,26 +87,56 @@ var lock = new Auth0Lock( ); ``` -## 2. Authenticating and Getting User Info +### 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). You can also save the token or profile to `localStorage` for later use. +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 -// Listening for the authenticated event -lock.on("authenticated", function(authResult) { - // Use the token in authResult to getUserInfo() and save it to localStorage - lock.getUserInfo(authResult.accessToken, function(error, profile) { - if (error) { - // Handle error - return; - } - - document.getElementById('nick').textContent = profile.nickname; - - localStorage.setItem('accessToken', authResult.accessToken); - localStorage.setItem('profile', JSON.stringify(profile)); - }); -}); +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). @@ -122,7 +164,7 @@ document.getElementById('btn-login').addEventListener('click', function() { ## 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! +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. @@ -199,7 +241,7 @@ The below widget displays brief examples of implementing Auth0 in several ways: ## 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: +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) diff --git a/articles/libraries/lock/v11/migration-angular.md b/articles/libraries/lock/v11/migration-angular.md index 490daab83f..1eb1e5647d 100644 --- a/articles/libraries/lock/v11/migration-angular.md +++ b/articles/libraries/lock/v11/migration-angular.md @@ -2,9 +2,20 @@ 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. +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/articles/libraries/lock/v11/migration-angularjs-v10.md b/articles/libraries/lock/v11/migration-angularjs-v10.md index 3cb8875969..621be6bea3 100644 --- a/articles/libraries/lock/v11/migration-angularjs-v10.md +++ b/articles/libraries/lock/v11/migration-angularjs-v10.md @@ -2,7 +2,18 @@ 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 diff --git a/articles/libraries/lock/v11/migration-angularjs-v8.md b/articles/libraries/lock/v11/migration-angularjs-v8.md index 34cf927232..8152ec0ef0 100644 --- a/articles/libraries/lock/v11/migration-angularjs-v8.md +++ b/articles/libraries/lock/v11/migration-angularjs-v8.md @@ -2,10 +2,21 @@ 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. +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/articles/libraries/lock/v11/migration-angularjs-v9.md b/articles/libraries/lock/v11/migration-angularjs-v9.md index 2fd17e4194..6217541cf6 100644 --- a/articles/libraries/lock/v11/migration-angularjs-v9.md +++ b/articles/libraries/lock/v11/migration-angularjs-v9.md @@ -2,11 +2,22 @@ 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. +This guide will help you migrating your Angular 1.x application from Lock 9 to Lock v11. <%= include('../../_includes/_get_lock_latest_version') %> diff --git a/articles/libraries/lock/v11/migration-cordova.md b/articles/libraries/lock/v11/migration-cordova.md index a433940551..ce7a0e9ef2 100644 --- a/articles/libraries/lock/v11/migration-cordova.md +++ b/articles/libraries/lock/v11/migration-cordova.md @@ -1,10 +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. +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](/hosted-pages/login) in Cordova apps. See the [Cordova Quickstart](/quickstart/native/cordova/01-login) for an example of setting this up. +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/articles/libraries/lock/v11/migration-guide.md b/articles/libraries/lock/v11/migration-guide.md index 7a70fa7f08..a815c11a66 100644 --- a/articles/libraries/lock/v11/migration-guide.md +++ b/articles/libraries/lock/v11/migration-guide.md @@ -2,18 +2,26 @@ 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. +[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 will be removed from service July 16, 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. - -::: note -Previously, deprecated Lock versions were planned to be removed from service on April 1, 2018. However, the Removal of Service date has been extended to **July 16, 2018** due to a [mitigation of the risks posed by deprecated versions](/cross-origin-authentication/fingerprinting). Customers are still encouraged to migrate applications to the latest version **as soon as possible** in order to ensure that applications continue to function properly. -::: +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 @@ -21,7 +29,7 @@ The documents below describe all the changes that you should be aware of when mi * [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 SSO is required](/guides/login/migration-sso) +* [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) @@ -31,21 +39,13 @@ The documents below describe all the changes that you should be aware of when mi * [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) -:::note 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. -::: - -## Disabling legacy Lock API - -After you update to Lock v11 and/or Auth0.js v9, it is advised that you turn off the **Legacy Lock API** toggle in the Dashboard. This will make your Auth0 tenant behave as if the legacy API is no longer available. Starting on July 16, 2018, this option will be forcibly disabled, so it is recommended you opt-in before that time to verify that your configuration will work correctly. -You can find the setting in the [Advanced section](${manage_url}/#/tenant/advanced) of Tenant Settings. - -![Allowed Web Origins](/media/articles/libraries/lock/legacy-lock-api-off.png) +<%= include('../../../_includes/_embedded_login_warning') %> ## Troubleshooting -### Lock takes long to display the login options +### 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. @@ -63,4 +63,6 @@ You have already migrated to Lock 11 but you still see this error in your logs: 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](/hosted-pages/login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. If this happens after **July 16, 2018** the user will not be able to log in. +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/articles/libraries/lock/v11/migration-lock-passwordless.md b/articles/libraries/lock/v11/migration-lock-passwordless.md index 0fd8d19c07..3108edcae5 100644 --- a/articles/libraries/lock/v11/migration-lock-passwordless.md +++ b/articles/libraries/lock/v11/migration-lock-passwordless.md @@ -2,12 +2,25 @@ 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. +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). @@ -169,7 +182,7 @@ 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-). +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); @@ -184,7 +197,7 @@ 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 now [socialButtonStyle](/libraries/lock/v11/configuration#socialbuttonstyle-string-) +* `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 diff --git a/articles/libraries/lock/v11/migration-react.md b/articles/libraries/lock/v11/migration-react.md index 88b48ffdb7..fbac6ae04c 100644 --- a/articles/libraries/lock/v11/migration-react.md +++ b/articles/libraries/lock/v11/migration-react.md @@ -2,10 +2,21 @@ 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. +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. diff --git a/articles/libraries/lock/v11/migration-v10-v11.md b/articles/libraries/lock/v11/migration-v10-v11.md index 9c141698b7..16e9b75071 100644 --- a/articles/libraries/lock/v11/migration-v10-v11.md +++ b/articles/libraries/lock/v11/migration-v10-v11.md @@ -2,11 +2,21 @@ 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 --- -# Migrating from Lock v10 to v11 +# 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). +This guide includes all the information you need to update your Lock v10 application to [Lock v11](/libraries/lock). ## Migration demo diff --git a/articles/libraries/lock/v11/migration-v8-v11.md b/articles/libraries/lock/v11/migration-v8-v11.md index 638e589afa..2f2e3e53c6 100644 --- a/articles/libraries/lock/v11/migration-v8-v11.md +++ b/articles/libraries/lock/v11/migration-v8-v11.md @@ -2,11 +2,21 @@ 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. +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/articles/libraries/lock/v11/migration-v9-v11.md b/articles/libraries/lock/v11/migration-v9-v11.md index 79d26ad0b2..cb56f72034 100644 --- a/articles/libraries/lock/v11/migration-v9-v11.md +++ b/articles/libraries/lock/v11/migration-v9-v11.md @@ -2,17 +2,27 @@ 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). +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. +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') %> @@ -77,7 +87,7 @@ function login() } ``` -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. +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 diff --git a/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md b/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md index fd41b45814..928c694dac 100644 --- a/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md +++ b/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md @@ -1,22 +1,82 @@ --- 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 the Connection in Lock +# Selecting from Multiple Connection Options -Auth0 allows you to offer your users multiple methods of authenticating. This is especially important with SaaS, multi-tenant apps, in which a single app is used by many different organizations, each one of which is potentially using different systems such as LDAP, Active Directory, Google Apps, or username/password stores. +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". A pompous name for a simple problem. +Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery". ::: -## Option 1: Programmatically +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. -When you initiate an authentication transaction with Auth0 you can optionally send a `connection` parameter. This value maps directly with any connection defined in the [Dashboard](${manage_url}). +## 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"). -If using [Lock](/libraries/lock), this is as simple as initiating Lock with the following option: ```js var lock = new Auth0Lock( @@ -32,28 +92,48 @@ var lock = new Auth0Lock( 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. ::: -There are multiple practical ways of determining which of your `connection` value to indicate for any given user. Here are two common scenarios: - -* You can use vanity URLs: `https://{connection}.yoursite.com` or `https://www.yoursite.com/{connection}`. When a user arrives at your application with the vanity URL, you can pick up that value and pass it to Lock as the `allowedConnections` value. -* You can just ask the user to pick from a list of all of your available connections (or those you want to be chosen from) at some point, and then show only that connection to that user. -* You could use non-human-readable connection names and use some external mechanism to map these to users (such as through a primary verification, out of band channel for example). - -::: note -The first two methods above assume it is acceptable for your app to disclose the names of all of your connections, which may not be appropriate for your application. -::: +# Sending realm information from the application -## Option 2: Using Email Domains with Lock +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: -[Lock](/libraries/lock) has built in functionality for identity provider selection. For social connections it will show logos for all those enabled in that particular app. +``` +https://{YOUR_AUTH0_DOMAIN}/authorize?client_id=[...]&login_hint={customer} +``` -An additional feature in the 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: +`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. -![](/media/articles/libraries/lock/enterprise-connection.png) +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: -If a connection has domains mapped to it, then the password input field gets disabled automatically when a user is typing an e-mail with a mapped domain. - -![Lock using HRD/SSO](/media/articles/libraries/lock/hrd-sso.png) +```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 +} +``` -In the example above the domain `auth0.com` has been mapped to an enterprise connection. +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`. -Notice that you can associate multiple domains to a single connection. +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/articles/libraries/lock/v11/sending-authentication-parameters.md b/articles/libraries/lock/v11/sending-authentication-parameters.md index c7ed408449..fa5e7055ff 100644 --- a/articles/libraries/lock/v11/sending-authentication-parameters.md +++ b/articles/libraries/lock/v11/sending-authentication-parameters.md @@ -1,6 +1,14 @@ --- section: libraries description: Lock v11 documentation on setting authentication parameters. +topics: + - libraries + - lock +contentType: + - how-to + - reference +useCase: + - add-login --- # Lock Authentication Parameters @@ -14,7 +22,7 @@ var options = { }; ``` -The following parameters are supported: `access_token`, `scope`, `protocol`, `device`, `request_id`, `nonce` and `state`. +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&...`. @@ -66,10 +74,12 @@ There is also a `connectionScopes` configuration option for Lock v11, which allo ### state {string} -The `state` parameter is an arbitrary state value that will be mantained 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](/tutorials/redirecting-users), that you might need after the authentication process is finished. If a custom state parameter is not provided, Lock will automatically generate one. - -[Click here to learn more about how to send/receive the state parameter.](/protocols/oauth-state) +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/articles/libraries/lock/v11/ui-customization.md b/articles/libraries/lock/v11/ui-customization.md index 2ad64426c8..6bbb747ae9 100644 --- a/articles/libraries/lock/v11/ui-customization.md +++ b/articles/libraries/lock/v11/ui-customization.md @@ -1,10 +1,19 @@ --- 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. +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 @@ -18,7 +27,7 @@ There are a couple of theming options currently available, namespaced under the #### logo {String} -![Lock - Theme - Logo](/media/articles/libraries/lock/v10/customization/lock-theme-logo.png) +![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. @@ -32,7 +41,7 @@ var options = { #### primaryColor {String} -![Lock - Theme - Primary Color](/media/articles/libraries/lock/v10/customization/lock-theme-primarycolor.png) +![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`. @@ -86,7 +95,7 @@ var options = { }; ``` -![Lock - Language Dictionary](/media/articles/libraries/lock/v10/customization/lock-languagedictionary.png) +![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. @@ -103,9 +112,9 @@ 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. Additonally, 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. +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 verion (`x.y.z`) when including Lock, or downloading it. +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. diff --git a/articles/libraries/lock/v9/api.md b/articles/libraries/lock/v9/api.md deleted file mode 100644 index ce5cd394c2..0000000000 --- a/articles/libraries/lock/v9/api.md +++ /dev/null @@ -1,234 +0,0 @@ ---- -section: libraries -description: Lock V9 API Reference -title: Lock 9 API Reference -toc: true ---- -# Lock 9: API Reference - -<%= include('../../../_includes/_version_warning_lock') %> - -## Methods - -### Auth0Lock(clientID, domain[, options]) - -Initialize `Auth0Lock` with a `clientID` and the account's `domain`. - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); -``` - -::: note -For a full detail on options and parameters you can check the [Auth0Lock initialization][lock-initialization] wiki notes. -::: - -### .show([options, callback]) - -Open the widget on `signin` mode with `signup` and `reset` button actions if enabled for the configured/default account connection. - -You may call this method with a single parameter, two or even none. The following examples ilustrate this: - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// using defaults and resolved configuration -// from you account details -lock.show(); - -// passing some options -lock.show(options); - -// provide with a callback `fn` to be invoked -// at success or error authentication -lock.show(function (err, profile, token) {}); - -// or both options and callback -lock.show(options, function (err, profile, token) {}); - -``` - -::: note -Check the [Auth0Lock customization][lock-customization] article for more examples and options specification. Or enter the [Authentication modes][application-types] notes to learn more about implementing different authentication mechanics. -::: - -### .showSignin([options, callback]) - -Open the widget on `signin` mode, but without the bottom `signup` nor `reset` button actions. This method is useful when your site has custom *signup* and *reset* links at a different form. - -You may call this method with a single parameter, two or even none. The following examples ilustrate this: - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// using defaults and resolved configuration -// from you account details -lock.showSignin(); - -// passing some options -lock.showSignin(options); - -// provide with a callback `fn` to be invoked -// on `reset` success or error -lock.showSignin(function (err, profile, token) {}); - -// or both options and callback -lock.showSignin(options, function (err, profile, token) {}); -``` - -::: note -Check the [Auth0Lock customization][lock-customization] article for more examples and options specification. Or enter the [Authentication modes][application-types] notes to learn more about implementing different authentication mechanics. -::: - -### .showSignup([options, callback]) - -Open the widget on `signup` mode, but without the `cancel` button action to go back to `signin`. This method is useful when your site has custom *signin* and *reset* links at a different form. - -You may call this method with a single parameter, two or even none. The following examples ilustrate this: - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// using defaults and resolved configuration -// from you account details -lock.showSignup(); - -// passing some options -lock.showSignup(options); - -// provide with a callback `fn` to be invoked -// on `reset` success or error -lock.showSignup(function (err) {}); - -// or both options and callback -lock.showSignup(options, function (err) {}); -``` - -::: note -Check the [Auth0Lock customization][lock-customization] article for more examples and options specification. Or enter the [Authentication modes][application-types] notes to learn more about implementing different authentication mechanics. -::: - -### .showReset([options, callback]) - -Open the widget on `reset` mode, but without the bottom `cancel` button action to go back to `signin`. This method is useful when your site has custom *signin* and *signup* links at a different form. - -You may call this method with a single parameter, two or even none. The following examples ilustrate this: - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// using defaults and resolved configuration -// from you account details -lock.showReset(); - -// passing some options -lock.showReset(options); - -// provide with a callback `fn` to be invoked -// on `reset` success or error -lock.showReset(function (err) {}); - -// or both options and callback -lock.showReset(options, function (err) {}); -``` - -::: note -Check the [Auth0Lock customization][lock-customization] article for more examples and options specification. Or enter the [Authentication modes][application-types] notes to learn more about implementing different authentication mechanics. -::: - -### .hide([callback]) - -Close the widget and invoke `callback` when removed from DOM. - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// normal display -lock.show(options); - -// trigger hide when esc key pressed -document.addEventListener('keypress', function(e) { - // hide if esc - lock.hide(); -}, false); -``` - -### .logout([query]) - -Log out loggedin user with optional query parameters for the `GET` request. - -```js -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// Call logout with query parameters -lock.logout({ ref: window.location.href }); -``` - -## Events - -```js -var lock = new Auth0Lock(clientID, domain). - -// called every time triggered -lock.on('signin ready', function() { - // signin mode is displayed -}); - -// called only once -lock.once('signup ready', function() { - // signup mode is displayed -}); - -// remove all listener handlers for `event` -lock.removeAllListeners('signin ready'); - -// remove just the following handler -lock.removeListener('signin ready', signinHandlerFn); -``` - -### Index of events - -- `shown`: Triggers when the Lock early opens. -- `ready`: Triggers when the Lock is ready for user interaction. -- `close`: Triggers when the user manually closes the Lock. -- `hidden`: Triggers when the Lock has hidden. -- `signin ready`: Triggers when signin mode view is displayed. -- `signin submit`: Triggers when signin mode is submitted. -- `signin success`: Triggers when signin has succeeded with no error. -- `signin error`: Triggers when there's an error on the signin workflow. -- `signup ready`: Triggers when signup mode is displayed. -- `signup submit`: Triggers when singup mode is submitted. -- `signup success`: Triggers when signup was succeeded with no error. -- `signup error`: Triggers when there's an error on the signup workflow. -- `reset ready`: Triggers when reset mode is displayed. -- `reset submit`: Triggers when reset mode is submitted. -- `reset success`: Triggers when reset has succeeded with no error. -- `reset error`: Triggers when there's an error on the reset workflow. -- `loggedin ready`: Triggers when loggedin mode is displayed. -- `loggedin submit`: Triggers when loggedin panel is submitted. -- `kerberos ready`: Triggers when integrated windows authentication mode is displayed. -- `kerberos submit`: Triggers when integrated windows authentication mode is submitted. -- `loading ready`: Triggers when loading mode is displayed. -- `error shown`: Triggers when an error was displayed. - -### Examples - -```js -// Modify the options before the signin is submitted. -// Useful for changing the authParams based on the email address (which is available in the context). -lock.on('signin submit', function (options, context) { - if (!options.authParams) - options.authParams = {}; - options.authParams.login_hint = context.email; -}); -``` - -### Internals (use at your own risk) - -- `icon shown`: Triggered when Lock icon or gravatar image has been shown. -- `icon hidden`: Triggered when Lock icon or gravatar image has been hidden. -- `avatar shown`: Triggered when Lock avatar has been shown. -- `avatar hidden`: Triggered when Lock avatar has been hidden. -- `client fetch success`: Triggers when `clientID`'s config data is fetched. -- `client fetch error`: Triggers when there's an error when fetching `clientID`'s config data. -- `client loaded`: Triggers when `clientID`'s config data was loaded. -- `client initialized`: Triggers when `clientID`'s config data is fetched and loaded. \ No newline at end of file diff --git a/articles/libraries/lock/v9/authentication-modes.md b/articles/libraries/lock/v9/authentication-modes.md deleted file mode 100644 index 54b37f6eac..0000000000 --- a/articles/libraries/lock/v9/authentication-modes.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -section: libraries -description: Lock v9 doc on the different types of authentication modes. -toc: true ---- -# Lock: Authentication Modes - -<%= include('../../../_includes/_version_warning_lock') %> - -After Auth0 Lock is opened, you can choose any of the Identity Providers (IdP) that Auth0 has, to Login. Depending on how the IdP Web/App is opened, a different authentication mode is used. - -## Redirect Mode - -If after you click on the IdP button (Facebook for example), the Webapp you built gets redirected to Facebook, it means you're using Redirect Mode. Once you successfully login to Facebook, Facebook will redirect you back to your app (through Auth0). This means that if you had **any state in memory in your WebApp, it will be lost**. This is why a successful login with Redirect mode **cannot be handled with a callback** and must be handled with the `parseHash` method. - -### Example: Redirect Mode in SPA - -In this first example you'll see that a `callbackURL` isn't set. That's because by default the `callbackURL` is set to `location.href` which means the current URL. - -Optionally, [you can set the callbackURL to whatever you need](/libraries/lock/v9/configuration#callbackurl-string). Please bear in mind that if you do, you'll also need to specify `responseType: token` as part of the options. - -```js -var lock = new Auth0Lock(${account.clientId}, ${account.namespace}); - -var hash = lock.parseHash(); - -if (hash) { - if (hash.error) { - console.log("There was an error logging in", hash.error); - } else { - lock.getProfile(hash.id_token, function(err, profile) { - if (err) { - console.log('Cannot get user :(', err); - return; - } - - console.log("Hey dude", profile); - }); - } -} - -lock.show(); -``` - -### Example: Redirect Mode in Regular Web Apps - -When you're doing a Regular web app, you need that after a successful login through Auth0, your app is redirected to a callback endpoint that you've created in your server. That callback endpoint will receive the `code` from Auth0 which must then [be exchanged for an access_token to get the user information](/protocols#3-getting-the-access-token). - -This means that in this case, only redirect mode makes sense. - -```js -var lock = new Auth0Lock(${account.clientId}, ${account.namespace}); - -lock.show({ - callbackURL: 'http://myUrl.com/auth/callback' -}); -``` - -## Popup Mode - -If after you click on the IdP button (Facebook for example), a popup (new tab or window) is opened, it means you're 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 WebApp will recognize that the user has been authenticated. The WebApp has **never been redirected to any other page. This means that you won't lose any state in memory that your application had**. This is why we can **handle successful login with a callback** in this case. - -::: warning -There is a known bug that prevents popup mode from functioning properly in Android or Firefox on iOS, and in Internet Explorer under certain circumstances. As such we recommend only using redirect mode (or if popup mode is absolutely required, detecting these special cases in which popup mode will fail and selectively enabling redirect mode). -::: - -### Database connections and popup mode - -Some Auth0 features such as [MFA](/multifactor-authentication) and [SSO](/sso/single-sign-on) 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 and display MFA prompts if necessary; this popup window will be blank if users are not prompted for MFA, which might not be a desirable UX. 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 MFA or SSO between multiple applications, you can set `sso: false` when using Lock or auth0.js. - -For example: - -```js -auth.signin({ - sso: false, - ... -}, function (err, profile, token) { ... }); -``` - -### Example: Popup Mode in SPA - -Below is an example of an implementation of popup mode in a Single Page Application: - -```js -var lock = new Auth0Lock(${account.clientId}, ${account.namespace}); - -lock.show(function(err, profile, id_token) { - if (err) { - console.log("There was an error :/", err); - return; - } - - console.log("Hey dude", profile); -}) -``` diff --git a/articles/libraries/lock/v9/configuration.md b/articles/libraries/lock/v9/configuration.md deleted file mode 100644 index 3c766847f5..0000000000 --- a/articles/libraries/lock/v9/configuration.md +++ /dev/null @@ -1,498 +0,0 @@ ---- -section: libraries -description: How to configure user options with Lock V9 ---- -# Lock: User configurable options - -<%= include('../../../_includes/_version_warning_lock') %> - -The **Auth0Lock** can be customized through the `options` parameter sent to the `.show()` methods. - -```js -var lock = new Auth0Lock('clientID', 'account.auth0.com'); - -// default signin with signup and reset actions -lock.show(options); - -// only signin -lock.showSignin(options); - -// only signup -lock.showSignup(options); - -// only reset -lock.showReset(options); -``` - -## Table of Contents - -**For display customization**: - -- [connections](#connections-array-) -- [dict](#dict-string-object-) -- [container](#container-string-) -- [icon](#icon-string-) -- [closable](#closable-boolean-) -- [socialBigButtons](#socialbigbuttons-boolean-) -- [focusInput](#focusinput-boolean-) -- [usernameStyle](#usernamestyle-string-) -- [gravatar](#gravatar-boolean-) -- [disableSignupAction](#disablesignupaction-boolean-) -- [signupLink](#signuplink-string-) -- [disableResetAction](#disableresetaction-boolean-) -- [resetLink](#resetlink-string-) -- [popup](#popup-boolean-) -- [popupOptions](#popupoptions-object-) -- [loginAfterSignup](#loginaftersignup-boolean-) -- [rememberLastLogin](#rememberlastlogin-boolean-) -- [integratedWindowsLogin](#integratedwindowslogin-boolean-) -- [defaultUserPasswordConnection](#defaultuserpasswordconnection-string-) -- [defaultADUsernameFromEmailPrefix](#defaultadusernamefromemailprefix-boolean-) -- [theme](#theme-string-) - -**For authentication setup**: - -- [callbackURL](#callbackurl-string-) -- [responseType](#responsetype-string-) -- [forceJSONP](#forcejsonp-boolean-) -- [authParams](#authparams-object-) -- [sso](#sso-boolean-) - -### connections {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 signin form -lock.show({ - connections: ['Username-Password-Authentication'] -}); - -// ... social connections only -lock.show({ - connections: ['twitter', 'facebook', 'linkedin'] -}); - -// ... enterprise connections only -lock.show({ - connections: ['qraftlabs.com'] -}); -``` - -![](/media/articles/libraries/lock/customization/connections.png) - -### dict {String|Object} - -The `dict` option can be either a string matching any [supported language][lock-i18n] (`'en'`, `'es'`, `'it'`, ...) or an object containing your customized text labels. By using the last approach you can modify [any text label][lock-i18n] or even [customize error messages][lock-custom-errors]. - -```js -// select a supported language -lock.show({ - dict: 'es' -}); - -// or customize the text labels yourself -lock.show({ - dict: { - signin: { - title: "Login me in", - emailPlaceholder: "something@youremail.com" - } - } -}); -``` - -![](/media/articles/libraries/lock/customization/dict.png) - -### container {String} - -The Lock widget defaults to showing in a modal, but you can set the `container` option to the `id` of the HTML element where you wish the widget to be shown. This makes the widget appear inline, inside the element, instead of as a popup. - -````html -
    - - -```` - -![](/media/articles/libraries/lock/customization/container.png) - -### icon {String} - -`Url` for an image to load in place of the *Auth0Lock* header badge. Recommended max height of `58px` for a better user experience. Defaults to placeholder image. - -```js -// Show default placeholder -lock.show(); - -// customize with own logo/badge -lock.show({ - icon: 'https://auth0.com/boot/badge.png' -}); -``` - -![](/media/articles/libraries/lock/customization/icon.png) - -::: note -To disable the header badge entirely, [UI customizations][ui-customization] are required.. -::: - -### closable {Boolean} - -Enable/disable closable feature. Defaults to `true` for modal show and false for embedded. - -```js -// closable action enabled by default -lock.show(); - -// disable the closable action -lock.show({ - closable: false -}); -``` - -![](/media/articles/libraries/lock/customization/closable.png) - -### socialBigButtons {Boolean} - -Force large/small social buttons. Defaults to `true` when no `database` or `ad/ldap` connections enabled and `false` when at least one is configured. - -::: note -Setting this property will override previous defaults. -::: - -```js -// `false` when at least -// 1 database connection -lock.show(); - -// `true` when none -lock.show({ - connections: ['facebook', 'linkedin', 'amazon'] -}); - -// force big buttons -lock.show({ - socialBigButtons: true -}); - -// force small icons -lock.show({ - connections: ['facebook', 'linkedin', 'amazon'], - socialBigButtons: false -}); -``` - -![](/media/articles/libraries/lock/customization/socialBigButtons.png) - -### focusInput {Boolean} - -If true, the focus is set to the email field on the widget. Defaults to `false` when mobile or embedded mode, `true` in other cases. - -```js -lock.show({ - focusInput: false -}); -``` - -### usernameStyle {String} - -If you don't want to validate that the user enters an email, just set this to `username`. Defaults to `email` - -```js -// email as default username style -lock.show(); - -// force `username` input style -lock.show({ - usernameStyle: 'username' -}); -``` - -![](/media/articles/libraries/lock/customization/usernameStyle.png) - -### gravatar {Boolean} - -Default: `true` - -In `show`, `showSignin` and `showSignup` methods, when user types their email, their associated gravatar picture is displayed in the Lock header. - -![](/media/articles/libraries/lock/customization/gravatar.png) - -### disableSignupAction {Boolean} - -Hides the Signup button. Defaults to `true` on `show*()` options and `false` on `.show`. - -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 -// -lock.show({ - disableSignupAction: true -}); -``` - -![](/media/articles/libraries/lock/customization/disableSignupAction.png) - -### signupLink {String} - -Set the URL to be requested when clicking on the Signup button. When set, forces `disableSignupAction` to `false`. - -```js -// -lock.show({ - signupLink: 'https://yoursite.com/signup' -}); -``` - -### disableResetAction {Boolean} - -Hides the reset password button. Defaults to `true` on `show*()` options and `false` on `.show`. - -```js -// -lock.show({ - disableResetAction: true -}); -``` - -![](/media/articles/libraries/lock/customization/disableResetAction.png) - -### resetLink {String} - -Set the URL to be requested when clicking on the Reset password button. When set, forces `disableSignupAction` to `false`. - -```js -// -lock.show({ - resetLink: 'https://yoursite.com/reset-password' -}); -``` - -### popup {Boolean} - -If set to true, shows a popup when trying to login with a Social or Enterprise IdP. For more information, [read this](/libraries/lock/v9/authentication-modes#popup-mode). Defaults to `true` when a `callback` is set, otherwise `false`. - -```js -lock.show({ - popup: true -}); - -lock.show({}, function(err, profile) { - // Popup automatically set to true in this case -}); -``` - -![](/media/articles/libraries/lock/customization/popup.png) - -### popupOptions {Object} - -Options for the `window.open` [position and size][windowopen-link] features. This only applies if `popup` is set to true. - -```js -lock.show({ - popup: true, - popupOptions: { width: 300, height: 400, left: 200, top: 300 } -}); -``` - -![](/media/articles/libraries/lock/customization/popupOptions.png) - -### loginAfterSignup {Boolean} - -Triggers a sign in call after sign up. Defaults to `true`. - -```js -// will sign in user after sign up -lock.show(); - -// won't sign in user after sign up -lock.show({ - loginAfterSignup: false -}); -``` - -### rememberLastLogin {Boolean} - -Request for SSO data and enable **Last time you signed in with[...]** message. Defaults to `true`. - -```js -// rememberLastLogin is enabled by default -lock.show(); - -// and this way you can disable it -// to force for input credentials -lock.show({ - rememberLastLogin: false -}); -``` - -![](/media/articles/libraries/lock/customization/rememberLastLogin.png) - -### integratedWindowsLogin {Boolean} - -Allows for Realm discovery by `AD`, `LDAP` connections. Defaults to `true`. - -```js -// AD|LDAP Realm discovery enabled by default -lock.show(); - -// disable Realm discovery to force -// input of credentials -lock.show({ - integratedWindowsLogin: false -}); -``` - -### defaultUserPasswordConnection {String} - -When multiple Database/AD-LDAP connections, specify which one should be used with the Email/Password fields. Defaults to the first Database connection found (if exists) or the first AD-LDAP connection found. - -::: note -Shall be renamed to just `forceDatabase`. -::: - -```js -// defaults to the first configured -// database connection in Auth0's dashboard -// configured are `production-database`, -// `staging-database` and `test-database` -lock.show(); - -// defaults to the first on the list -// of provided database connections -lock.show({ - // `production-database` not listed - connections: ['staging-database', 'test-database'] -}); - -// force `test-database` -lock.show({ - defaultUserPasswordConnection: 'test-database' -}); -``` - -### defaultADUsernameFromEmailPrefix {Boolean} - -Resolve the AD placeholder username from the email's prefix. Defaults to `true`. - -```js -// default username from email prefix -lock.show(); - -// does not fill username input -lock.show({ - defaultADUsernameFromEmailPrefix: false -}); -``` - -![](/media/articles/libraries/lock/customization/defaultADUsernameFromEmailPrefix.png) - -### theme {String} - -This property allows to change the default `a0-theme-default` class to whatever delivered by this option. The result will be a containing CSS class like `a0-theme-`. The result of this will be a complete style reset of the Lock allowing to set your own theme/styles. Defaults to `default`. - -```js -// Default theme out of the box -lock.show(); - -// Theme reset -lock.show({ theme: false }); - -// Theme rename to `a0-theme-mycroft` -lock.show({ theme: 'mycroft' }); -``` - -### callbackURL {String} - -The url auth0 will redirect back after authentication. If not set, it defaults to `location.href`. If you don't set `callbackURL`, [responseType](#responsetype-string) will default to `token`. - -```js -lock.show({ - callbackURL: 'http://mydomain.com/callback' -}); -``` - -### responseType {String} - -Should be set to `token` for *Single Page Applications*, otherwise `code`. Defaults to `token` if `callbackURL` is __not__ set, `popup` mode is set to true or if a `callback` is supplied. Otherwise, it'll be `code`. - -```js -lock.show({ - responseType: 'token' -}); -``` - -### forceJSONP {Boolean} - -Force JSONP requests for all `auth0-js` instance requests. This setup is useful when no CORS allowed. Defaults to `false`. - -```js -lock.show({ - forceJSONP: true -}); -``` - -### authParams {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`. [Read here][authparams-link] to learn more about what `authParams` can be set. - -```js -lock.show({ - // ... other options ... - authParams: { - state: 'foo' - } -}); -``` - -::: note -For a full spec on every supported parameter check the wiki [article][authparams-link] on this topic. -::: - -### sso {Boolean} - -Sets a cookie used for single sign on. The cookie will be used later to allow `rememberLastLogin` display the **Last time you signed in with ...** message. This only applies to Database Connections when using `popup: true` and fires a popup where authentication takes place. Last but not least, it prompts for a multifactor authentication code, if enabled. - -::: warning -Failing to set this to true will result in multi-factor authentication not working correctly. -::: - -```js -lock.show({ - sso: true -}); -``` - -*** - -## Internally resolved - -The following are all internal options. The only reason they are listed here is to have a full documentation for the options object. - -::: note -Passing any of the following to the `options` object will be overridden by `Auth0Lock`s options manager. Do not attempt to modify these... it won't happen. -::: - -### mode {String} - -Set the `show` mode for the display. Allowed values are `signin`, `signup` and `reset`. Defaults to `signin`. - -### popupCallback {Function} - -Internally set from `callback` parameter - -[authparams-link]: /libraries/lock/v9/sending-authentication-parameters -[windowopen-link]: https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Position_and_size_features - -[lock-i18n]: /libraries/lock/v9/i18n -[lock-custom-errors]: /libraries/lock/v9/customizing-error-messages -[ui-customization]: /libraries/lock/v9/ui-customization diff --git a/articles/libraries/lock/v9/customizing-error-messages.md b/articles/libraries/lock/v9/customizing-error-messages.md deleted file mode 100644 index 1fd3504d6c..0000000000 --- a/articles/libraries/lock/v9/customizing-error-messages.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -section: libraries -description: Customizing error messages with Lock V9 ---- -# Lock: Customizing Error Messages - -<%= include('../../../_includes/_version_warning_lock') %> - -You can customize the error messages that will be displayed on certain situations by providing a [dict option](/libraries/lock/v9/customization#dict-object) at the [customization options](/libraries/lock/v9/customization). A full listing of available `dict` fields to customize can be found in the GitHub repository's [English Dictionary file for Lock 9](https://github.com/auth0/lock/blob/v9/i18n/en.json). Below is an example of some customized error messages: - -```js -// Initialize the Auth0Lock instance -var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); - -// Customize your error messages in a dictionary -var dict = { - loadingTitle: 'loading...', - close: 'close', - signin: { - wrongEmailPasswordErrorText: 'Custom error message for invalid user/pass.', - serverErrorText: 'There was an error processing the sign in.', - strategyEmailInvalid: 'The email is invalid.', - strategyDomainInvalid: 'The domain {domain} has not been setup.' - }, - signup: { - serverErrorText: 'There was an error processing the sign up.', - enterpriseEmailWarningText: 'This domain {domain} has been configured for Single Sign On and you can\'t create an account. Try signing in instead.' - }, - reset: { - serverErrorText: 'There was an error processing the reset password.' - } - // wrongEmailPasswordErrorText, serverErrorText, enterpriseEmailWarningText are used only if you have a Database connection - // strategyEmailInvalid is shown if the email is not valid - // strategyDomainInvalid is shown if the email does not have a matching enterprise connection - } -}; - -// Invoke the lock show method with the customized dictionary -lock.show({ dict: dict }); -``` - -These errors will be shown on the widget header: - -![Widget Header Errors](/media/articles/libraries/lock/v9/custom-error.png) diff --git a/articles/libraries/lock/v9/i18n.md b/articles/libraries/lock/v9/i18n.md deleted file mode 100644 index 7fa73e6327..0000000000 --- a/articles/libraries/lock/v9/i18n.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -section: libraries -description: Lock V9 internationalization ---- -# Lock: Internationalization - -<%= include('../../../_includes/_version_warning_lock') %> - -You can call instantiate the widget with the `dict` option: - -```javascript -var lock = new Auth0Lock('dsa7d77dsa7d7', 'mine.auth0.com'); - -lock.show({ - dict: 'es' -}); -``` - -Where dict can be a string matching the name of the file in the `i18n` folder or it could be an object literal as follows: - -```javascript -var lock = new Auth0Lock('dsa7d77dsa7d7', 'mine.auth0.com'); - -lock.show({ - dict: { - "loadingTitle": "loading...", - "close": "close", - "signin": { - .. //same as in i18n json files - } -}); -``` - -Finally you can also make changes to an existing dictionary by merging a new dictionary in an existing one (this sample uses [underscore.js](http://underscorejs.org/)): - -```javascript -lock.show({ - dict: _.merge(lock.$dicts.en, { - "signup:headerText": "Hi there, please enter your email and password" - }) -}) -``` - -![i18n-image](/media/articles/libraries/lock/v9/i18n-image.gif) - -::: note -For an example of available property names, [see the English dictionary file for Lock 9](https://github.com/auth0/lock/blob/v9/i18n/en.json). -::: diff --git a/articles/libraries/lock/v9/index.md b/articles/libraries/lock/v9/index.md deleted file mode 100644 index 132b62ae0c..0000000000 --- a/articles/libraries/lock/v9/index.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -section: libraries -description: Lock V9 documentation -title: Lock 9 for Web -toc: true ---- -# Lock 9 for Web - -<%= include('../../../_includes/_version_warning_lock') %> - -![Lock Image](/media/articles/libraries/lock/v9/lock-landing.png) - -[Auth0](https://auth0.com) is an authentication broker that supports social identity providers as well as enterprise identity providers such as Active Directory, LDAP, Google Apps, Salesforce. - -Lock makes it easy to integrate SSO in your app. You won't have to worry about: - -* Having a professional looking login dialog that displays well on any resolution and device. -* Finding the right icons for popular social providers. -* Remembering what was the identity provider the user chose the last time. -* Solving the home realm discovery challenge with enterprise users (such as asking the enterprise user the email, and redirecting to the right enterprise identity provider). -* Implementing a standard sign in protocol (OpenID Connect / OAuth2 Login) - -![Lock Sign Up](/media/articles/libraries/lock/v9/lock-signup.png) - -::: note -Check out the [Lock repository](https://github.com/auth0/lock/tree/v9) on GitHub. -::: - -::: note -You can try it out yourself online at our [Auth0 Lock playground][playground-url]. -::: - -## Install - -From [npm](https://npmjs.org): - -```sh -npm install auth0-lock -``` - -From [bower](http://bower.io): - -```sh -bower install auth0-lock -``` - -Or our CDN: - -```html - - - - - - - - -``` - -Replace `.x` and `.y` with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock). - -If you are targeting mobile audiences, it's recommended that you add: - -```html - -``` - -### Browserify - -If you are using browserify to build your project, you will need to add the following transformations required by Auth0 Lock: - -``` json -{ - "devDependencies": { - "brfs": "0.0.8", - "ejsify": "0.1.0", - "packageify": "^0.2.0" - } -} -``` - -## Initialization - -Auth0Lock v9 can be initialized with just a clientID and domain, or it can also take a third parameter, an `options` object. - -```js -// Initialize with clientID and domain -var lock = new Auth0Lock(clientID, domain); - -// Or, initialize with options -var lock = new Auth0Lock(clientID, domain, options); -``` - -### Parameters - -The possible parameters are detailed below. - -* **clientID {String}**: Your application clientID in Auth0. -* **domain {String}**: Your Auth0 domain. Usually ```.auth0.com```. -* **options {Object}**: - * **cdn {String}**: Use as CDN base url. Defaults to `domain` if it doesn't equal `*.auth0.com`. - * **assetsUrl {String}**: Use as assets base url. Defaults to `domain` if it doesn't equal `*.auth0.com`. - * **useCordovaSocialPlugins {boolean}**: When Lock is used in a Cordova/Phonegap application, it will try authenticating with social connections using a native plugin. The only plugin supported is [phonegap-facebook-plugin](https://github.com/Wizcorp/phonegap-facebook-plugin) but more will come soon. - -## Usage - -You can use **Auth0Lock** with [Popup mode][popup-mode] or [Redirect mode][redirect-mode]. To learn more about these modes, you can read the [Authentication Modes][authentication-modes] page. -There are different ways of implementing them according to your application needs. To see what kind of settings you should be using you can check the [Types of Applications article][application-types]. - -```js -// Initialize Auth0Lock with your `clientID` and `domain` -var lock = new Auth0Lock('xxxxxx', '.auth0.com'); - -// and deploy it -var login = document.querySelector('a#login') - -login.onclick = function (e) { - e.preventDefault(); - lock.show(function onLogin(err, profile, id_token) { - if (err) { - // There was an error logging the user in - return alert(err.message); - } - - // User is logged in - }); -}; -``` - -This is just one example of how **Auth0Lock** could work with a **Single Page Application** (SPA). Read the [Single Page Applications][spa-notes] and the [Regular Web Applications][webapps-notes] articles for a full explanation on how to implement those scenarios with Auth0 Lock and when to use each. - -## Examples - -The `example` directory has a ready-to-go app. In order to run it you need [node](http://nodejs.org/) installed. - -Then execute `npm i` to install dependencies (only once) and `npm example` from the root of this project. - -Finally, point your browser at `http://localhost:3000/` and play around. - -## Browser Compatibility - -We ensure browser compatibility in `Chrome`, `Safari`, `Firefox` and `IE >= 9`. We currently use [zuul](https://github.com/defunctzombie/zuul) along with [Saucelabs](https://saucelabs.com) to run integration tests on each push. - -## Issue Reporting - -If you have found a bug or if you have a feature request, please report them at this repository issues section. Please do not report security vulnerabilities on the public GitHub issue tracker. The [Responsible Disclosure Program](https://auth0.com/whitehat) details the procedure for disclosing security issues. - -## Resources - -* [Complete API][lock-configuration] -* [UI customization][ui-customization] -* [Single Page Applications][spa-notes] implementation notes. -* [Regular Web Applications][webapps-notes] implementing notes. -* [Overlay vs Embedded mode][display-modes] -* [Popup vs Redirect mode][authentication-modes] notes. **What are the authentication modes?**. -* [Error customization][error-customization] notes. -* [I18n][i18n-notes] notes. -* [Events][events-notes] notes. -* [Development][development-notes] notes. -* [Release process][release-process] notes. -* [Auth0Lock playground][playground-url] -* [Lock Authentication Parameters][sending-authentication-parameters] -* [Using Refresh Tokens](/libraries/lock/v9/using-a-refresh-token) -* Legacy **Auth0Widget** [Migration guide][migration-guide] to **Auth0Lock** - - - -[download1]: https://raw.github.com/auth0/lock/master/build/auth0-lock.js -[download2]: https://raw.github.com/auth0/lock/master/build/auth0-lock.min.js - -[npm-image]: https://img.shields.io/npm/v/auth0-lock.svg?style=flat-square -[npm-url]: https://npmjs.org/package/auth0-lock -[strider-image]: https://ci.auth0.com/auth0/lock/badge -[strider-url]: https://ci.auth0.com/auth0/lock -[coveralls-image]: https://img.shields.io/coveralls/auth0/lock.svg?style=flat-square -[coveralls-url]: https://coveralls.io/r/auth0/lock?branch=master -[david-image]: http://img.shields.io/david/auth0/lock.svg?style=flat-square -[david-url]: https://david-dm.org/auth0/lock -[license-image]: http://img.shields.io/npm/l/auth0-lock.svg?style=flat-square -[license-url]: https://github.com/auth0/lock/blob/master/LICENSE -[downloads-image]: http://img.shields.io/npm/dm/auth0-lock.svg?style=flat-square -[downloads-url]: https://npmjs.org/package/auth0-lock - -[lock-initialization]: /libraries/lock/v9/initialization -[lock-configuration]: /libraries/lock/v9/configuration -[application-types]: /libraries/lock/v9/types-of-applications -[display-modes]: /libraries/lock/v9/display-modes -[spa-notes]: /libraries/lock/v9/types-of-applications#single-page-app -[webapps-notes]: /libraries/lock/v9/types-of-applications#regular-webapp -[authentication-modes]: /libraries/lock/v9/authentication-modes -[popup-mode]: /libraries/lock/v9/authentication-modes#popup-mode -[redirect-mode]: /libraries/lock/v9/authentication-modes#redirect-mode -[ui-customization]: /libraries/lock/v9/ui-customization -[error-customization]: /libraries/lock/v9/customizing-error-messages -[i18n-notes]: /libraries/lock/v9/i18n -[events-notes]: /libraries/lock/v9/events -[development-notes]: https://github.com/auth0/lock -[release-process]: https://github.com/auth0/lock -[playground-url]: http://auth0.github.com/playground -[sending-authentication-parameters]: /libraries/lock/v9/sending-authentication-parameters -[migration-guide]: /libraries/lock/v9/migration-guide diff --git a/articles/libraries/lock/v9/migration-guide.md b/articles/libraries/lock/v9/migration-guide.md deleted file mode 100644 index 0603dcc871..0000000000 --- a/articles/libraries/lock/v9/migration-guide.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -section: libraries -description: Guide to migrate from Auth0 Widget to Auth0 Lock. ---- -# Lock: Migration Guide - -<%= include('../../../_includes/_version_warning_lock') %> - -This guide will walk you through the needed changes to migrate from **Auth0Widget** to **Auth0Lock**. - -## Initialization - -While with the legacy Widget you had to: - -```js -var widget = new Auth0Widget({ - domain: 'your-domain.auth0.com', - clientID: 'YOUR_CLIENT_ID', - callbackURL: 'http:://your-domain.com/your_callback' -}); -``` - -In the new Auth0Lock becomes: - -```js -var lock = new Auth0Lock('YOUR_CLIENT_ID', 'your-domain.auth0.com'); -``` - -::: note -All other options that used to be passed along on the initialization process have been moved to the [show API](#api). -::: - -To learn how and when to set the `callbackURL` in **Auth0Lock** please read [this guide][callbackurl-link]. - -For more information about Auth0Lock's initialization, check the [[Auth0Lock Initialization]] section. - -## API - -The legacy `.signin()` method has been renamed to `.showSignin()`. Same applies to `.signup()` as `.showSignup()` and `.reset()` as `.showReset()`. There is also a `.show()` method which uses account's default settings to resolve what should be displayed. - -The following example illustrates the main changes: - -```js -widget.signin({ - connections: [ - 'facebook', - 'google-oauth2', - 'twitter', - 'Username-Password-Authentication' - ] -}); -``` - -In the new Auth0Lock becomes: - -```js -lock.showSignin({ - connections: [ - 'facebook', - 'google-oauth2', - 'twitter', - 'Username-Password-Authentication' - ] -}); -``` - -::: note -Check the [API documentation][api-readme-url] section in the [README][readme-url] for a further walk through this methods. -::: - -Also, `Auth0Widget` callback order has changed: `onload` widget event has been removed as a callback and added as an event. The callback that was executed when the user has been signed in is now the second argument. For instance, this: - -```js -widget.signin({ - popup: true -}, null, function (err, profile) { - -}); -``` - -now is written as: - -```js -lock.showSignin({ - popup: true -}, function (err, profile) { - -}); -``` - -## Customization - -Some of the customization options have been renamed. You can check the [[Auth0Lock Customization]] section for a detailed specification on each allowed option. - -You can also follow here the most important breaking changes on namings: - - -Widget Name | Lock Name -------------------------------|------------------------------------------------------- -`callbackOnLocationHash` | `responseType` [1](#response-type-ref) -`showIcon` | Removed from API options [2](#show-icon-ref) -`standalone` | `closable` -`_avoidInitialFocus` | `focusInput` -`showSignup` | `disableSignupAction` -`showPassword` | `disableResetAction` -`forgotLink` | `resetLink` -`chrome` | Removed from API options [3](#chrome-ref) -`standalone` | `closable` -`enableReturnUserExperience` | `rememberLastLogin` -`enableADRealmDiscovery` | `integratedWindowsLogin` -`username_style` | `usernameStyle` -`userPwdConnectionName` | `defaultUserPasswordConnection` -`extraParams` | `authParams` - - 1: [`responseType`][responseType] can be either `token` (`callbackOnLocation: true`) or `code` (`callbackOnLocation: false`). - - 2: The `showIcon` option has been removed. When [`icon`][icon] property is provided it will be immediately displayed. In case you'd like to hide the default icon badge, the recommended way is by CSS customization. Check our [[UI customization]] page for that. - - 3: The `chrome` option has been removed. In case you'd like to hide the default icon badge, the recommended way is by CSS customization. Check our [[UI customization]] page for that. - - -::: note -The following options have been moved under `authParams` main property for a matter of semantics: `access_token`, `scope`, `protocol`, `device`, `request_id`, `connection_scopes`, `nonce`, `offline_mode` and `state`. -::: - -## Events - -Many of the event names changed. The general rule to apply for the proper handling is to replace the underscore with a single space. - -So, for example if you had `signin_ready` now it is `signin ready`. - -Also, the one named `transition_mode` has been deprecated and removed from the list of Events. - -For more information about events, check [Auth0 Lock Events](/libraries/lock/v9/events) section. - - -[readme-url]: /libraries/lock -[api-readme-url]:/libraries/lock#api -[responseType]: /libraries/lock/v9/customization#responsetype-boolean -[icon]: /libraries/lock/v9/customization#icon-string -[callbackurl-link]: /libraries/lock/v9/customization#callbackurl-string diff --git a/articles/libraries/lock/v9/selecting-the-connection-for-multiple-logins.md b/articles/libraries/lock/v9/selecting-the-connection-for-multiple-logins.md deleted file mode 100644 index 3ce903cd50..0000000000 --- a/articles/libraries/lock/v9/selecting-the-connection-for-multiple-logins.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -section: libraries -description: Describes different options for selecting the connection in Auth0 when there are multiple login options for Lock v9. ---- -# Selecting the connection in Auth0 for multiple login options - -<%= include('../../../_includes/_version_warning_lock') %> - -Auth0 allows you to offer your users multiple ways of authenticating. This is especially important with SaaS, multitenant apps in which a single app is used by many different organizations, each one potentially using different systems: LDAP, Active Directory, Google Apps, or username/password stores. - -![](/media/articles/hrd/sd4h-6wlwOsQA1PCQKLAmtQ.png) - -::: note -Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery". A pompous name for a simple problem. -::: - -## Option 1: programmatically - -When you initiate an authentication transaction with Auth0 you can optionally send a `connection` parameter. This value maps directly with any connection defined in your dashboard. - -If using the [Lock](/lock), this is as simple as writing: - -```js -auth0.show({connections: ['YOUR_CONNECTION']}); -``` - -Notice that this is equivalent of just navigating to: - -```text -https://${account.namespace}/authorize/ -?client_id=${account.clientId} -&response_type=code -&redirect_uri=${account.callback} -&state=OPAQUE_VALUE&connection=YOUR_CONNECTION -``` - -There are multiple practical ways of getting the `connection` value. Among the most common ones: - -* You can use vanity URLs: `https://{connection}.yoursite.com` or `https://www.yoursite.com/{connection}` -* You can just ask the user to pick from a list (notice [there's an API](/api/v1#!#get--api-connections) to retrieve all connections available) - -::: note -These two methods assume it is acceptable for your app to disclose the names of all companies you are connected to. Sometimes this is not the case. -::: - -* You could use non-human-readable connection names and use some external mechanism to map these to users (for example, through a primary verification, out of band channel for example). - -## Option 2: using email domains with Lock - -The [Lock](/libraries/lock) has built in functionality for identity provider selection. For social connections it will show logos for all those enabled in that particular app. - -An additional feature in the 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/hrd/k_LcfC8PHp.png) - -If a connection has this setup, then the password textbox gets disabled automatically when typing an e-mail with a mapped domain: - -![](/media/articles/hrd/R7mvAZpSnf.png) - -In the example above the domain `companyx.com` has been mapped to an enterprise connection. - -Notice that you can associate multiple domains to a single connection. - -## Option 3: adding custom buttons to Lock - -Using [Lock](/libraries/lock)'s [support for customization and extensibility](/libraries/lock/customization) it's also possible to add buttons for your Custom Social or Enterprise Connections. The following example (written in jQuery) adds a button for Azure AD to Lock: - -```js -var lock = new Auth0Lock(cid, domain); -lock.once('signin ready', function() { - var link = $('' + - 'Login with Fabrikam Azure AD'); - link.on('click', function() { - lock.getClient().login({ - connection: 'fabrikamdirectory.onmicrosoft.com' - }); - return false; - }); - - - $('.a0-iconlist', this.$container) - .append(link) - .removeClass('a0-hide'); -}); - -lock.show({ - connections: ['facebook', 'google-oauth2', 'windows-live'] -}); -``` - -This is useful when you want to give users a consistent login experience where they click on the connection they want to use. - -![](/media/articles/hrd/hrd-custom-buttons-lock.png) - -Lock's stylesheet contains the following provider icons which can be used when adding custom buttons: - -```text -.a0-amazon -.a0-aol -.a0-baidu -.a0-box -.a0-dropbox -.a0-dwolla -.a0-ebay -.a0-evernote -.a0-exact -.a0-facebook -.a0-fitbit -.a0-github -.a0-gmail -.a0-google -.a0-googleplus -.a0-guest -.a0-ie -.a0-instagram -.a0-linkedin -.a0-miicard -.a0-office365 -.a0-openid -.a0-paypal -.a0-planningcenter -.a0-renren -.a0-salesforce -.a0-sharepoint -.a0-shopify -.a0-soundcloud -.a0-stackoverflow -.a0-thecity -.a0-thirtysevensignals -.a0-twitter -.a0-vk -.a0-waad -.a0-weibo -.a0-windows -.a0-wordpress -.a0-yahoo -.a0-yammer -.a0-yandex -``` diff --git a/articles/libraries/lock/v9/sending-authentication-parameters.md b/articles/libraries/lock/v9/sending-authentication-parameters.md deleted file mode 100644 index 4e2aaac2e3..0000000000 --- a/articles/libraries/lock/v9/sending-authentication-parameters.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -section: libraries -description: Supported parameters that can be used with Lock V9. ---- -# Lock: Authentication Parameters - -<%= include('../../../_includes/_version_warning_lock') %> - -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 -lock.show({ - // ... other options ... - authParams: { - state: 'foo' - } -}); -``` - -The following parameters are supported: `access_token`, `scope`, `protocol`, `device`, `request_id`, `connection_scopes`, `nonce` and `state`. - -::: note -This would be analogous to trigger the login with `https://${account.namespace}/authorize?state=foo&...`. -::: - -## Supported parameters - -### scope {string} - -```js -lock.show({ - authParams: { - scope: 'openid email user_metadata app_metadata picture' - } -}); -``` - -There are different values supported for scope: - -* `scope: 'openid'`: _(default)_ 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). -* `scope: '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. -* `scope: 'openid {attr1} {attr2} {attrN}'`: If you want only specific user attributes to be part of the `id_token` (For example: `scope: 'openid name email picture'`). - -### connection_scopes {Object} - -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: - -```js -lock.show({ - authParams: { - connections: ['facebook', 'google-oauth2', 'twitter', 'Username-Password-Authentication', 'fabrikam.com'], - connection_scopes: { - '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. -::: - -### state {string} - -The `state` parameter is an arbitrary state value that will be mantained across redirects. It is useful to mitigate [CSRF attacks](http://en.wikipedia.org/wiki/Cross-site_request_forgery) and for any contextual information (such as a return url) that you might need after the authentication process is finished. - -[Click here to learn more about how to send/receive the state parameter.](/protocols/oauth-state) diff --git a/articles/libraries/lock/v9/ui-customization.md b/articles/libraries/lock/v9/ui-customization.md deleted file mode 100644 index 7488d92d54..0000000000 --- a/articles/libraries/lock/v9/ui-customization.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -section: libraries -description: Customizing how Lock with CSS and Javascript ---- -# Lock: Customize the look and feel - -<%= include('../../../_includes/_version_warning_lock') %> - -You can apply your own styles to the elements of the Lock. - -All CSS `class`es and `id`s are prefixed with `a0-` to avoid conflicts with your application's basic stylesheets. - -There are two ways to override the Lock's main styles: - -## CSS specification - -Prepend a `body` key in front of the customization CSS in order to win in CSS specification: - -```css -body #a0-lock { - /* your css rules */ -} -``` - -## Disabling animations - -Since all `Lock` animations are CSS animations the way to disable them is through CSS - -```css -#a0-lock * { - -webkit-animation: none !important; - animation: none !important; - -webkit-transition: none !important; - transition: none !important; -} -``` - -## Adding a new UI element using JavaScript - -This code adds a new button to the widget. Since the widget runs as part of the same DOM of the page, you can manipulate it in the way you want. - -![](/media/articles/libraries/lock/ui-customization/lock-add-btn.png) - -```js -widget.once('signin ready', function() { - var link = $('Login with SharePoint'); - link.appendTo('.a0-iconlist'); - link.on('click', function() { - widget.getClient().login({connection: 'your-sharepoint-connection-name'}); - }); -}); -``` - -Here is a fiddle to play around with it - -## Automatically logging in with "Windows Authentication" - -When Kerberos is available you can automatically trigger Windows Authentication. As a result the user will immediately be authenticated without having to click the **windows authentication** button. - -![](/media/articles/libraries/lock/ui-customization/windows-auth-button.png) - -```js -lock.getClient().getSSOData(true, function (err, ssoData) { - if (!err && ssoData && ssoData.connection) { - lock.getClient().login({ connection: ssoData.connection }); - } -}); -``` - -## Order of definition - -Auth0 Lock inserts it's CSS definitions in the `head` node of the HTML Document and it does this at the very end. So, in order to override the Lock's main styles you must insert your CSS in the `body` node, right after the ` - - - -``` - -Make sure to use the one that fits the best to your use case. - -## Theme examples - -### Reflex theme - -![](/media/articles/libraries/lock/ui-customization/reflex-theme.png) - -- **repo**: -- **demo**: - -### Gradient theme - -![](/media/articles/libraries/lock/ui-customization/gradient-theme.png) - -- **repo**: -- **demo**: diff --git a/articles/libraries/lock/v9/using-a-refresh-token.md b/articles/libraries/lock/v9/using-a-refresh-token.md deleted file mode 100644 index c001cb78cf..0000000000 --- a/articles/libraries/lock/v9/using-a-refresh-token.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -section: libraries -description: Getting and using a Refresh Token with Lock. ---- -# Lock: Refresh Tokens - -<%= include('../../../_includes/_version_warning_lock') %> - -Mostly when building mobile apps, we want to show the signin page only once and then leave the user logged in forever. For those cases, it makes sense to have a `refreshToken`. A `refreshToken` lets us get a new `id_token` (`JWT`) anytime we want. - -::: warning -This means that if the `refreshToken` gets compromised, unless we revoke that token, somebody would be able to get a new JWT forever. -::: - -## 1. Getting the Refresh Token - -In order to be able to get the Refresh Token, all we need to do is add the scope `offline_access` when calling the `showSignin` or `showSignup` method. Optionally, we can specify a `device` name so that the user knows which device has a Refresh Token created. If not set, it'll be automatically calculated for you. - -````js -lock.showSignin({ - authParams: { - scope: 'openid offline_access', - // The following is optional - device: 'Chrome browser' - } -}); -```` - -If using popup mode, use the `refresh_token` returned in the callback: - -```js -lock.showSignin({ - authParams: { - scope: 'openid offline_access' - } -}, function (err, profile, id_token, access_token, state, refresh_token) { - // store refresh_token -}); -``` - -## 2. Using the refreshToken - -Now, you can use the `refreshToken` to get a new JWT whenever you want: - -````js -lock.getClient().refreshToken(refresh_token, function (err, delegationResult) { - // Get here the new JWT via delegationResult.id_token -}); -```` diff --git a/articles/libraries/secure-local-development.md b/articles/libraries/secure-local-development.md new file mode 100644 index 0000000000..577adafce8 --- /dev/null +++ b/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/articles/libraries/when-to-use-lock.md b/articles/libraries/when-to-use-lock.md index aff4be966f..fba0c02d30 100644 --- a/articles/libraries/when-to-use-lock.md +++ b/articles/libraries/when-to-use-lock.md @@ -1,27 +1,30 @@ --- section: libraries -description: When should you use Lock, Auth0's drop-in authentication widget, and when should you use a custom UI with an Auth0 Library? This page will help you decide. +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 --- -# Lock vs. a Custom UI +# Universal Login Page Customization -<%= include('../_includes/_lock_auth0js_deprecations_notice') %> +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. -When adding Auth0 to your web apps, the best solution is to use Auth0's [universal login](/hosted-pages/login). Using universal login is an incredibly simple process, and prevents the dangers of cross-origin authentication. The login page uses the Lock Widget to allow your users to authenticate by default, but also has templates for Lock Passwordless and for a custom UI built with Auth0.js SDK. You can customize the page in the [Hosted Pages Editor](${manage_url}/#/login_page), and use any of the following to implement your authentication needs. +Universal Login is less complex than embedding the authentication process within your app. It also prevents the dangers of cross-origin authentication. -* Lock, Auth0's drop-in login and signup widget - * [Lock for Web](/libraries/lock) - * [Lock for iOS](/libraries/lock-ios) - * [Lock for Android](/libraries/lock-android) -* One of our libraries (along with a custom interface) - * [Auth0 SDK for Web](/libraries/auth0js) - * [Auth0 SDK for iOS](/libraries/auth0-swift) - * [Auth0 SDK for Android](/libraries/auth0-android) -* Or, a custom user interface that you have created directly tying into the [Authentication API](/auth-api). +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. -If universal login doesn't work for you, all of the above can be embedded in your own application and used in that way, as well. +* [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. +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 @@ -98,11 +101,6 @@ Below is a quick overview of reasons you might want to use Lock, versus using an No Yes - - Adapts to a simpler process for username/password and social provider authentication - No - Yes - Handles multiple databases or Active Directory connections No @@ -113,7 +111,7 @@ Below is a quick overview of reasons you might want to use Lock, versus using an ## Lock -**Lock** is an embeddable 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 is provided as a drop-in solution for [Web](/libraries/lock), as well as for native [iOS](/libraries/lock-ios) or [Android](/libraries/lock-android) apps. +**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) @@ -127,7 +125,7 @@ With **Lock**, you will be implementing a UI that: * Automatically accommodates internationalization * Provides instant password policy checking at sign up -Although you cannot alter Lock's behavior, you can configure several [basic options](/libraries/lock/customization) to make Lock look and behave differently. +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) @@ -135,7 +133,7 @@ Although you cannot alter Lock's behavior, you can configure several [basic opti Consider using **Lock** if: -* You like structure, look, and feel of **Lock** +* 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 @@ -143,13 +141,12 @@ Consider using **Lock** if: * User signup and password reset * Authentication using social providers * Avatars -* You want a login form that can be reused in multiple areas ## 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), or with native libraries for [iOS](/libraries/auth0-swift) or [Android](/libraries/auth0-android), 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. +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) @@ -160,11 +157,11 @@ Unlike with **Lock**, neither of these options includes a user interface. You wi 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 require add no additional weight. +* 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](/). These guides may further assist you in your decision about which to use for your specific app needs. +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/articles/link-accounts/index.md b/articles/link-accounts/index.md deleted file mode 100644 index 6c8f76a6f9..0000000000 --- a/articles/link-accounts/index.md +++ /dev/null @@ -1,324 +0,0 @@ ---- -title: Linking 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 -crews: crew-2 -toc: true ---- -# Linking User Accounts - -::: warning -We recently introduced some changes in Account Linking. For all the details see [Migration Guide: Account Linking and ID Tokens](/migrations/guides/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)). - -Note that Auth0 will treat 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 - -## The linking process - -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": "your@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 - -### Merging Metadata - -[Metadata](/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. You can find sample code for merging metadata before linking using this SDK [here](/link-accounts/suggested-linking#4-verify-and-merge-metadata-before-linking). - -## Use the Management API - -The Auth0 Management API provides the [Link a user account](/api/v2#!/Users/post_identities) endpoint, which can be invoked in two ways. - -1. With an Access Token that contains the `update:current_user_identities` scope, the `user_id` of the primary account as part of the URL, and the secondary account's ID Token in the payload: - - ```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\"}" - } - } - ``` - - 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. - - 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. - -2. With an Access Token that contains the `update:users` scope, the `user_id` of the primary account as part of the URL, and the `user_id` of the secondary account in the payload: - - ```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": "{\"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. So 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: - - ```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 in case you send the ID Token as part of the payload: - - 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. - - Note also that since the Access Token contains the `update:users` scope, it can be used to update the information of **any** user. Therefore this method is intended for use in server-side code only. - -## Use Auth0.js - -Instead of calling directly the API, 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). - -## Scenarios - -In this section we will see some scenarios that implement account linking: -* [Automatic account linking](#automatic-account-linking): automatically link accounts with the same e-mail address -* [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 e-mail address and prompt the user in your app to link them - -::: warning -For security purposes, link accounts **only if both e-mails are verified**. -::: - -### Automatic account linking - -You can implement automatic linking by setting up a [Rule](/rules) that will run upon user login and link accounts with the same e-mail address. - -The rule is an example of linking accounts in server-side code using the Auth0 Management API [Link a user account endpoint](/api/v2#!/Users/post_identities) where you have both the primary and secondary user IDs and an [Management API Access Token](/api/v2/tokens) with `update:users` scope. - -Note, that if the primary account changes during the authorization transaction (for example, the account the user has logged in with, becomes a secondary account to some other primary account), you could get an error in the Authorization Code flow or an `id_token` with the wrong `sub` claim in the token flow. To avoid this, set `context.primaryUser = 'auth0|user123'` in the rule after account linking. This will tell the authorization server to use the user with id `auth0|user123` for the rest of the flow. - -For a rule template on automatic account linking, see [Link Accounts with Same Email Address](https://github.com/auth0/rules/blob/master/rules/link-users-by-email.md). If you want to merge metadata as well, see [Link Accounts with Same Email Address while Merging Metadata](https://github.com/auth0/rules/blob/master/rules/link-users-by-email-with-metadata.md). - -### 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 follow the [Account Linking Using Client Side Code](/link-accounts/user-initiated-linking) tutorial or view the [Auth0 jQuery Single Page App Account Linking Sample](https://github.com/auth0/auth0-link-accounts-sample/tree/master/SPA) on Github for implementation details. - -### Suggested account linking - -As with automatic linking, in this scenario you will set up a [Rule](/rules) that will link accounts with the same verified e-mail address. However, instead of completing the link automatically on authentication, your app will first prompt the user to link their identities. - -![Sample linking suggestion](/media/articles/link-accounts/regular-web-app-suggest-linking.png) - -You can follow the [Account Linking Using Server Side Code](/link-accounts/suggested-linking) tutorial or view the [Auth0 Node.js Regular Web App Account Linking Sample](https://github.com/auth0/auth0-link-accounts-sample/tree/master/RegularWebApp) on Github for implementation details. - -## Unlinking accounts - -The Auth0 Management API V2 also provides an [Unlink a user account endpoint](/api/v2#!/Users/delete_provider_by_user_id) which can be used with either of these two **scopes**: - -* `update:current_user_identities`: when you call the endpoint from client-side code where you have an Access Token with this scope -* `update:users`: when you call the endpoint from server-side code where you have an Access Token with this scope - -```har -{ - "method": "DELETE", - "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID", - "httpVersion": "HTTP/1.1", - "headers": [{ - "name": "Authorization", - "value": "Bearer ACCESS_TOKEN" - }] -} -``` - -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 - -If your goal is to delete the secondary identity entirely, you must first unlink the accounts, and then delete the newly created secondary account. diff --git a/articles/link-accounts/suggested-linking/index.md b/articles/link-accounts/suggested-linking/index.md deleted file mode 100644 index 612e410efb..0000000000 --- a/articles/link-accounts/suggested-linking/index.md +++ /dev/null @@ -1,278 +0,0 @@ ---- -description: How to link user accounts using server-side code. -crews: crew-2 -toc: true ---- - -# Account Linking Using Server Side Code - -::: warning -We recently introduced some changes in Account Linking. For all the details see [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking). -::: - -In this tutorial, you will use server-side code to facilitate account linking on a regular web application. Rather than automating the entire account linking process, you're engaging the user and asking them for permission before proceeding. Your code will: - -1. Authenticate the user -2. Search for and identify users using their email addresses -3. Prompt the user to link their accounts -4. Verify and merge metadata -5. Link the accounts - -Additionally, this tutorial will show you how you can unlink accounts at a later time. - -You can find sample code for this tutorial in the [Auth0 Node.js Regular Web App Account Linking](https://github.com/auth0/auth0-link-accounts-sample/tree/master/RegularWebApp) repo on Github. - -## Step 1: Authenticate the user - -Start by logging in the user to your application. - -The recommended implementation is to use [universal login](/hosted-pages/login). You can find detailed guidance on how to do just that at our [Node.js Quickstart](/quickstart/webapp/nodejs). - -If you choose instead to embed the [Lock](/libraries/lock/v11) widget in your app, you can review the sample code for this tutorial in the [Auth0 Node.js Regular Web App Account Linking](https://github.com/auth0/auth0-link-accounts-sample/tree/master/RegularWebApp) repo on Github. - -If you don't use Lock at all, but call the Authentication API directly, follow the [Execute an Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant) tutorial. - -## Step 2: Search for users with identical email addresses - -During the post-login page load, your app invokes a custom endpoint that returns a list of users that could be linked together. This is done using the following code: - -```js -const ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn(); -const Auth0Client = require('../Auth0Client'); -const express = require('express'); -const router = express.Router(); - -router.get('/suggested-users',ensureLoggedIn, (req,res) => { - let suggestedUsers = []; - Auth0Client.getUsersWithSameVerifiedEmail(req.user._json) - .then(identities => { - suggestedUsers = identities; - }).catch( err => { - console.log('There was an error retrieving users with the same verified email to suggest linking',err); - }).then(() => { - res.send(suggestedUsers); - }); -}); -``` - -To get a list of all of the user records with the same email address, your app calls the 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 { - ... - getUsersWithSameVerifiedEmail(user) { - return new Promise((resolve, reject) => { - if (! user.email_verified){ - reject('User email is not verified'); - } - const reqOpts = { - url: 'https://${account.namespace}/api/v2/users-by-email', - headers: { - 'Authorization': 'Bearer ' + process.env.AUTH0_APIV2_TOKEN - }, - qs: { - email: user.email - } - }; - request(reqOpts, (error, response, body) => { - if (error) { - return reject(error); - } else if (response.statusCode !== 200) { - return reject('Error getting users: ' + response.statusCode + ' ' + body); - } else { - resolve(JSON.parse(body)); - } - }); - }); - } -} -``` - -## Step 3: Prompt the user to link accounts - -If Auth0 returns one or more records with matching email addresses, the user sees the list, as well as the following message prompting them to link the accounts: `We noticed there are other registered users with the same verified e-mail address as EMAIL_ADDRESS. Do you want to link the accounts?`. - -If the user wants to link a given account, they can click **Link** next to the appropriate account. - -![](/media/articles/link-accounts/regular-web-app-suggest-linking.png) - -## Step 4: Verify and merge metadata - -The user clicking on **Link** invokes your custom endpoint for account linking. However, before calling `linkAccounts`, you can verify or retrieve metadata from secondary accounts and merge them into the metadata fields for the primary account. After the accounts are linked, the metadata for the secondary accounts is discarded. - -Additionally, when calling `linkAccounts`, you can select the primary account identity. Your choice will depend on which set of attributes you want to retain in the user's profile. - -The following code snippet shows how you can implement both features. - -```js -const ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn(); -const Auth0Client = require('../Auth0Client'); -const express = require('express'); -const router = express.Router(); - -router.post('/link-accounts/:targetUserId', ensureLoggedIn, (req,res,next) => { - // Fetch target user to make verifications and merge metadata - Auth0Client.getUser(req.params.targetUserId) - .then( targetUser => { - // verify email (this is needed because targetUserId came from client side) - if(! targetUser.email_verified || targetUser.email !== req.user._json.email){ - throw new Error('User not valid for linking'); - } - //merge metadata - return _mergeMetadata(req.user._json,targetUser); - }) - .then(() => { - return Auth0Client.linkAccounts(req.user.id,req.params.targetUserId); - }) - .then( identities => { - req.user.identities = req.user._json.identities = identities; - res.send(identities); - }) - .catch( err => { - console.log('Error linking accounts!',err); - next(err); - }); -}); -``` - -In the example above, you'll notice that the email address is verified a second time. This is to ensure that `targetUserId` hasn't been tampered with on the client side. - -### Merging metadata - -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 -const _ = require('lodash'); -const auth0 = require('auth0')({ - token: process.env.AUTH0_APIV2_TOKEN -}); - -/* -* Recursively merges user_metadata and app_metadata from secondary into primary account. -* Data of primary user takes preponderance. -* Array fields are joined. -*/ -function _mergeMetadata(primaryUser, secondaryUser){ - 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); - - return Promise.all([ - auth0.users.updateUserMetadata(primaryUser.user_id, mergedUserMetadata), - auth0.users.updateAppMetadata(primaryUser.user_id, mergedAppMetadata) - ]).then(result => { - //save result in primary user in session - primaryUser.user_metadata = result[0].user_metadata; - primaryUser.app_metadata = result[1].app_metadata; - }); -} -``` - -## Step 5: Link accounts - -Once you've found the user accounts, prompted the user to merge the selected accounts, and verified/merged the metadata associated with the primary and secondary identities, you're ready to actually link the accounts. - -To link accounts, your app needs to call the Management API's [Link a User Account endpoint](/api/v2#!/Users/post_identities). You need to call the API using a [Management API Access Token](/api/management/v2/tokens) with the `update:users` scope. - -```js -const request = require('request'); - -class Auth0Client { - linkAccounts(rootUserId,targetUserId) { - - const provider = targetUserId.split('|')[0]; - const user_id = targetUserId.split('|')[1]; - - return new Promise((resolve, reject) => { - var reqOpts = { - method: 'POST', - url: 'https://${account.namespace}/api/v2/users/' + rootUserId +'/identities', - headers: { - 'Authorization': 'Bearer ' + process.env.AUTH0_APIV2_TOKEN - }, - json: { - provider, - user_id - } - }; - request(reqOpts,(error, response, body) => { - if (error) { - return reject(error); - } else if (response.statusCode !== 201) { - return reject('Error linking accounts. Status code: ' + response.statusCode + '. Body: ' + JSON.stringify(body)); - } else { - resolve(body); - } - }); - }); - } - ... -} - -module.exports = new Auth0Client(); -``` - -## Unlinking accounts - -If you need to unlink two or more user accounts, you can do so. - -First, you need to 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); - }); -}); -``` - -Then, call the Management API v2 [Unlink a User Account endpoint](/api/v2#!/Users/delete_provider_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(); -``` - -That's it, you are done! diff --git a/articles/link-accounts/user-initiated-linking/index.md b/articles/link-accounts/user-initiated-linking/index.md deleted file mode 100644 index e9e0a073e4..0000000000 --- a/articles/link-accounts/user-initiated-linking/index.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -description: How to provide a UI for the user to authenticate to their other accounts and link these to their primary account. -crews: crew-2 ---- - -# Account Linking Using Client Side Code - -::: warning -We recently introduced some changes in Account Linking. For all the details see [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking). -::: - -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 and can later on use a link or a button in order 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. - -The following steps implement this scenario for a Single Page Application (SPA). You can find the sample code at [User Initiated Account Linking within a Single Page App](https://github.com/auth0/auth0-link-accounts-sample/tree/master/SPA) on Github. - -## Step 1: Initial login - -Start by logging in the user to your application. - -The recommended implementation is to use [universal login](/hosted-pages/login). You can find detailed guidance on how to do just that at our [JavaScript Quickstart](/quickstart/spa/vanillajs). - -If you choose instead to embed the [Lock](/libraries/lock/v11) widget or the [auth0.js library](/libraries/auth0js/v9) in your app, you can review the sample code for this tutorial in the [Auth0 jQuery Single Page App Account Linking Sample](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/SPA) repo on Github. - -If you don't use Lock at all, but call the Authentication API directly, follow the [How to implement the Implicit Grant](/api-auth/tutorials/implicit-grant) tutorial. - -## Step 2: User initiates account linking - -Your SPA must provide a UI for the user to initiate a link to their other accounts (social, passwordless, and so on). For example, in the user's settings page. - -![SPA user setting's page](/media/articles/link-accounts/spa-user-settings.png) - -When the user clicks on any of the **Link Account** buttons, your app will trigger authentication to the account selected. After successful authentication, use the obtained token to link the accounts. - -### Handle the second authentication with Lock - -```js -/* -* Link Accounts. -*/ -function linkPasswordAccount(connection) { - localStorage.setItem('linking','linking'); - - // Instantiates Lock, to get a token that will be then used to - // link the account - - var opts = { - rememberLastLogin: false, - auth: { - responseType: 'token id_token', - }, - dict: { - signin: { - title: 'Link another account' - } - } - }; - - if (connection) { - opts.allowedConnections = [connection]; - } - - lock = new Auth0Lock( AUTH0_CLIENT_ID , AUTH0_DOMAIN, opts); - lock.show(); -} - -/* -* Handles the "authenticated" event for all Lock log-ins. -*/ -function lockAuthenticated(authResult) { - if (localStorage.getItem('linking') === 'linking') { - // The "Link Account" method first saves the "linking" item and then authenticates - // We identify that flow here, so after each subsequent log-in, we link the accounts - localStorage.removeItem('linking'); - linkAccount(authResult.idToken); - } else { - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - localStorage.setItem('user_id', authResult.idTokenPayload.sub); - reloadProfile(); - } -} -``` - -In the sample you can also find the code in order to handle the second authentication with Passwordless and SMS (see function `linkPasswordlessSMS`), Passwordless and email code (see `linkPasswordlessEmailCode`), or Passwordless and Magic Link (see `linkPasswordlessEmailLink`). - -## Step 3: Call the API to link accounts - -In the `linkAccount` function, call the Management API V2 [Link a user account endpoint](/api/v2#!/Users/post_identities). Authenticate with the API using the Access Token, and link using the primary user's ID and the secondary user's ID Token. - -```js -function linkAccount(secondaryIdToken) { - - // At this point you could fetch the secondary account's user_metadata for merging with the primary account. - // Otherwise, it will be lost after linking the accounts - - // Uses the access_token of the primary user as a bearer token to identify the account - // which will have the account linked to, and the id_token of the secondary user, to identify - // the user that will be linked into the primary account. - - var primaryAccessToken = localStorage.getItem('access_token'); - var primaryUserId = localStorage.getItem('user_id'); - - $.ajax({ - type: 'POST', - url: 'https://' + AUTH0_DOMAIN +'/api/v2/users/' + primaryUserId + '/identities', - data: { - link_with: secondaryIdToken - }, - headers: { - 'Authorization': 'Bearer ' + primaryAccessToken - } - }).then(function(identities){ - alert('linked!'); - reloadProfile(); - }).fail(function(jqXHR){ - alert('Error linking Accounts: ' + jqXHR.status + " " + jqXHR.responseText); - }); -} -``` - -If you wish to retain and merge the `user_metadata` from the secondary account, you must retrieve it before calling the API endpoint. It will be discarded when the accounts are linked. - -Also, you can select which identity will be used as the primary account and which as the secondary when calling the account linking. This choice will depend on which set of attributes you wish to retain in the primary profile. - -## Unlink accounts - -If you need to unlink two or more user accounts, you can do so. - -Call the Management API v2 [Unlink a User Account endpoint](/api/v2#!/Users/delete_provider_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); - }); -} -``` - -That's it, you are done! diff --git a/articles/login/embedded/index.md b/articles/login/embedded/index.md new file mode 100644 index 0000000000..a2f469081e --- /dev/null +++ b/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/articles/login/index.md b/articles/login/index.md new file mode 100644 index 0000000000..ec29764282 --- /dev/null +++ b/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/articles/login/spa/authenticate-with-cookies.md b/articles/login/spa/authenticate-with-cookies.md new file mode 100644 index 0000000000..aa00106d1a --- /dev/null +++ b/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/articles/logout/_includes/_logout-endpoint.md b/articles/logout/_includes/_logout-endpoint.md new file mode 100644 index 0000000000..e1ee68dda9 --- /dev/null +++ b/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/articles/logout/guides/logout-applications.md b/articles/logout/guides/logout-applications.md new file mode 100644 index 0000000000..2368fd165f --- /dev/null +++ b/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/articles/logout/guides/logout-auth0.md b/articles/logout/guides/logout-auth0.md new file mode 100644 index 0000000000..638f134afd --- /dev/null +++ b/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/articles/logout/guides/logout-idps.md b/articles/logout/guides/logout-idps.md new file mode 100644 index 0000000000..c62112ac76 --- /dev/null +++ b/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/articles/logout/guides/logout-saml-idps.md b/articles/logout/guides/logout-saml-idps.md new file mode 100644 index 0000000000..a2bf39e8c8 --- /dev/null +++ b/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/articles/logout/guides/redirect-users-after-logout.md b/articles/logout/guides/redirect-users-after-logout.md new file mode 100644 index 0000000000..1d7fc0ad91 --- /dev/null +++ b/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/articles/logout/index.md b/articles/logout/index.md index bdc6479a7a..55c25449b5 100644 --- a/articles/logout/index.md +++ b/articles/logout/index.md @@ -1,250 +1,45 @@ --- -description: How to log out a user and optionally redirect them to an authorized URL. -toc: true +description: Understand how logout works with Auth0. +topics: + - logout +contentType: index +useCase: + - manage-logout --- # Logout -When you're implementing the logout functionality for your app, there are typically three sessions layers you need to consider: +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: -- __Application Session__: The first 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, this is achieved by storing information inside a cookie. You need to log out the user from your application by clearing their session. +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. -- __Auth0 session__: Auth0 also keep 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. To log out a user from Auth0, you need to clear the single sign-on (SSO) cookie. +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. -- __Identity Provider session__: The last layer is the Identity Provider, such as 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. They may simply be asked to give permissions to share their information with Auth0 and in turn, your application. +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).) -This document explains how to log out a user from the Auth0 session and (optionally) from the Identity Provider session. Remember that you should handle the Application Session in your app! +## Quickstarts for logout functionality -## Log Out a User +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: -The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways: - -- Clear the SSO cookie in Auth0 -- Clear the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google) - -To force a logout, redirect the user to the following URL: - -```text -https://${account.namespace}/v2/logout -``` - -Redirecting the user to this URL clears all single sign-on cookies set by Auth0 for the user. - -Although this is not common practice, you can also force the user to log out of their identity provider. To do this, add a `federated` querystring parameter to the logout URL: - -```text -https://${account.namespace}/v2/logout?federated -``` - -The following identity providers support federated logout: - -* AOL -* Evernote -* Facebook -* Fitbit -* GitHub -* Google - * Apps - * OAuth 2.0 -* LinkedIn -* 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. You might find [this video](/videos/session-and-cookies) helpful. -::: - - -## Redirect Users After Logout - -To redirect a user after logout, add a `returnTo` querystring parameter with the target URL as the value. We suggest that you encode the target URL being passed in -- for example, to redirect the user to `http://www.example.com` after logout, you can make the following request: - -```text -https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com -``` - -You will need to 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: - -* For logout requests that do not include the `client_id` parameter, such as: - - ```text - https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com - ``` - - 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). See [Set the Allowed Logout URLs at the Tenant Level](#set-the-allowed-logout-urls-at-the-tenant-level) for more information. - -* For logout requests that include the `client_id` parameter, such as: - - ```text - https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com&client_id=CLIENT_ID - ``` - - 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`. See [Set the Allowed Logout URLs at the Application Level](#set-the-allowed-logout-urls-at-the-application-level) for more information. - -### Set the Allowed Logout URLs at the Tenant Level - -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) - -When providing the URL list, you can: - -* Specify multiple, valid, comma-separated URLs -* Use `*` as a wildcard for subdomains (such as `http://*.example.com`) - -### Set the Allowed Logout URLs at the Application Level - -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 (such as `http://*.example.com`) - -::: 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 `returnTo` parameter does not work with all social providers. Please check your social provider's settings to ensure that they will accept the `redirectTo` parameter. - -* The URLs provided to 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. Note, that the scheme and host parts, however, 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. -::: - -#### Facebook Users - -If you are using Facebook, please be aware of the additional requirements when triggering a logout. - -You will also need to encode the `returnTo` parameter. - -```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] -``` - -### Supported Providers - -Auth0 supports use of the [`logout` endpoint](/api/authentication?javascript#logout) with the following providers: - -- AOL -- Auth0 - - AD/LDAP -- Custom (Passport/WS-Fed/SAML) -- Facebook -- FitBit -- GitHub -- Google - - Apps - - OAuth2 -- LinkedIn -- Microsoft - - Active Directory (AD) - - Active Directory Federation Services (ADFS) - - Office 365 - - Windows Live -- OAuth - - 1.0 - - 2.0 -- Salesforce - - Salesforce Community - - Salesforce Sandbox -- Samlp -- Twitter -- Waad -- WS-Fed -- Yahoo -- Yammer - -## SAML Logout - -SAML logout is configured differently depending on whether Auth0 acts as the Service Provider (i.e. when you create a SAML **connection**) or when Auth0 acts as the Identity Provider (i.e. when you have an application with the SAML2 Web App addon). - -### Logout for Auth0 as SAML Service Provider - -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) as [described above](#log-out-a-user). - -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 might notice two `SingleLogoutService` bindings with the above URL. - -* The first is the **SAML Request Binding** (also known as the **Protocol Binding**), which is used for the transaction from Auth0 to the IdP. If the IdP provides a choice, select `HTTP-Redirect`. -* The second is the **SAML Response Binding**, which is 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. - -### 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. - -### Logout for Auth0 as SAML IdP - -When Auth0 is acting as a [SAML Identity Provider](/protocols/saml/saml-idp-generic), you can have the following scenarios: - -#### Single Logout Scenario - -If your Service Provider supports SAML Single Logout, you will need to 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 logout request will be sent to this endpoint and Auth0 starts the SAML SLO flow by notifying the existing session participants using a frontend channel. - -* 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. -* To send the SAML Logout response using `HTTP-Redirect` bindings (instead of the default `HTTP-POST`), you can set `binding` to `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 SP, the best thing to do is configure the redirect URL to `https://${account.namespace}/logout`. This won't notify other session participants that a logout was initiated, but it will at remove the session from Auth0. - -## Implementing in your Application - -For guidance and sample code on how to implement logout functionality in your application please refer to our [Quickstarts](/quickstarts): - -### Mobile / Native Apps +### Native/Mobile Apps * [Android](/quickstart/native/android/03-session-handling#log-out) * [Chrome Extension](/quickstart/native/chrome) * [Cordova](/quickstart/native/cordova) -* [Ionic](/quickstart/native/ionic) -* [Ionic 2+](/quickstart/native/ionic2) +* [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 +### Single-Page Apps * [Angular 2+](/quickstart/spa/angular2) -* [AngularJS](/quickstart/spa/angularjs) -* [Aurelia](/quickstart/spa/aurelia) -* [Cycle](/quickstart/spa/cyclejs#5-implement-the-logout) -* [Ember](/quickstart/spa/ember) * [JavaScript](/quickstart/spa/vanillajs) * [React](/quickstart/spa/react) * [Vue](/quickstart/spa/vuejs) -* [jQuery](/quickstart/spa/jquery) ### Web Apps * [ASP.NET (OWIN)](/quickstart/webapp/aspnet-owin/01-login#add-login-and-logout-methods) -* [ASP.NET (System.Web)](/quickstart/webapp/aspnet#logout) * [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) @@ -256,3 +51,14 @@ For guidance and sample code on how to implement logout functionality in your ap * [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/articles/logs/concepts/logs-admins-devs.md b/articles/logs/concepts/logs-admins-devs.md new file mode 100644 index 0000000000..802913210f --- /dev/null +++ b/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/articles/logs/guides/migrate-logs-v2-v3.md b/articles/logs/guides/migrate-logs-v2-v3.md new file mode 100644 index 0000000000..8c803ae79c --- /dev/null +++ b/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/articles/logs/guides/retrieve-logs-mgmt-api.md b/articles/logs/guides/retrieve-logs-mgmt-api.md new file mode 100644 index 0000000000..c8cec6a38d --- /dev/null +++ b/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/articles/logs/guides/view-log-data-dashboard.md b/articles/logs/guides/view-log-data-dashboard.md new file mode 100644 index 0000000000..fc0cbcaa41 --- /dev/null +++ b/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/articles/logs/index.md b/articles/logs/index.md index b81be1db3a..b8a85708f2 100644 --- a/articles/logs/index.md +++ b/articles/logs/index.md @@ -1,145 +1,29 @@ --- -description: How to view log data, lists log event types. +description: Understand how Auth0 logs work. url: /logs -crews: crew-2 +classes: topic-page +topics: + - logs +contentType: index +useCase: + - analyze-logs + - integrate-analytics --- - # Logs -Using the [Dashboard](${manage_url}), you can pull log data on actions performed by administrators using the Dashboard, and authentications made by your users. - -## How to View Log Data - -The **Logs** page of the [Dashboard](${manage_url}) displays all events that occur, including user authentication and administrative actions such as adding/updating Applications, Connections, and Rules. - -![](/media/articles/logs/dashboard-logs.png) - -Please note that administrative actions will show up in the logs as `API Operation` events. - -## Frequently Asked Questions - -### How long is log file data available? - -The length of time log data is stored varies depending on your plan. - -Plan | Log Retention ------|-------------- -Free | 2 days -Developer | 2 days -Developer Pro | 10 days -Enterprise | 30 days - -### How do I view or export log file data? - -If you would like to store log data longer than the time period offered by your subscription plan, we recommend you use the [Management API feature that allows you to retrieve the relevant data](api/management/v2#!/Logs/get_logs). Once you've retrieved your data, you can: - -* Store the data yourself -* Send the data to an external service such as Splunk (consider using the [Auth0 Logs to Splunk Extension](/extensions/splunk)) - -#### Retrieving logs from the Management API - -You can use the Management API v2 retrieve your logs. There are the two available endpoints, each providing slightly different quantities of information: - -* [/api/v2/logs](/api/v2#!/Logs/get_logs): Retrieves log entries that match the provided search criteria. If you do not provide any search criteria, you will get a list of all available entries; -* [/api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id): Retrieves the single log entry associated with the provided ID. - -## Log data event listing - -The following table lists the codes associated with the appropriate log events. - -| **Event Code** | **Event** | **Event Description** | **Additional Info** | -| --- | --- | --- | --- | -| `admin_update_launch` | Auth0 Update Launched | | -| `api_limit` | Rate Limit On API | The maximum number of requests to the API in given time has reached. | [Rate Limit Policy](/policies/rate-limits) | -| `cls` | Code/Link Sent | Passwordless login code/link has been sent | [Passwordless](/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](/passwordless) | -| `du` | Deleted User | User has been deleted. | [User Profile](/user-profile) | -| `f` | Failed Login | | | -| `fapi` | Failed API Operation | | | -| `fc` | Failed by Connector | | [Active Directory/LDAP Connector](/connector) | -| `fce` | Failed Change Email | Failed to change user email | [User Profile](/user-profile) | -| `fco` | Failed by CORS | Origin is not in the Allowed Origins list for the specified application | [Applications](/applications#application-settings) | -| `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](/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](/user-profile) | -| `fd` | Failed Delegation | Failed to generate delegation token | [Delegation Tokens](/tokens/delegation) | -| `fdu` | Failed User Deletion | | [User Profile](/user-profile) | -| `feacft` | Failed Exchange | Failed to exchange authorization code for Access Token | [Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant) -| `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) | -| `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 | | -| `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` | OTP Auth failed | One-time password authentication failed. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_auth_rejected` | OTP Auth rejected | One-time password authentication rejected. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_auth_succeed` | OTP Auth success | One-time password authentication success. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_enrollment_complete` | Guardian enrollment complete | | | -| `gd_module_switch` | Module switch | | | -| `gd_otp_rate_limit_exceed` | Too many failures | | | -| `gd_recovery_failed` | Recovery failed | Multifactor recovery code failed. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_recovery_rate_limit_exceed` | Too many failures | Multifactor recovery code has failed too many times. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_recovery_succeed` | Recovery success | Multifactor recovery code succeeded authorization. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_send_pn` | Push notification sent | Push notification for MFA sent successfully sent with Guardian. | [Auth0 Guardian](/multifactor-authentication/guardian) | -| `gd_send_sms` | SMS Sent | SMS for MFA sent successfully sent. | [Using SMS for MFA](/multifactor-authentication/guardian/admin-guide#support-for-sms) | -| `gd_start_auth` | Second factor started | Second factor authentication event started for MFA. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_start_enroll` | Enroll started | Multifactor authentication enroll has started. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_tenant_update` | Guardian tenant update | | [Auth0 Guardian](/multifactor-authentication/guardian) | -| `gd_unenroll` | Unenroll device account | Device used for second factor authentication has been unenrolled. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_update_device_account` | Update device account | Device used for second factor authentication has been updated. | [Multifactor Authentication](/multifactor-authentication) | -| `gd_user_delete` | User delete | Deleted multifactor user account. | [User Profile](/user-profile) | -| `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_ui` | Too Many Calls to /userinfo | Rate limit exceeded to `/limit_ui` endpoint | [API Rate Limit Policy](/policies/rate-limits) | -| `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) | -| `pwd_leak` | Breached password | | | -| `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](/user-profile) | -| `seacft` | Success Exchange | Successful exchange of authorization code for Access Token | [Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant) | -| `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) | -| `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 | Successfuly imported users | [User Import/Export](/extensions/user-import-export) | -| `sv` | Success Verification Email | | | -| `svr` | Success Verification Email Request | | | -| `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 | | | -| `ublkdu` | User login block released | User block setup by anomaly detection has been released | | -| `w` | Warnings During Login | | | - -### Tools to process logs - -* [Auth0 Logs Processor](https://www.npmjs.com/package/auth0-logs-processor) -* [GitHub Repo for the Auth0 Logs Processor](https://github.com/auth0/logs-processor) +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/articles/logs/references/log-data-retention.md b/articles/logs/references/log-data-retention.md new file mode 100644 index 0000000000..4ea7b2c72d --- /dev/null +++ b/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/articles/logs/references/log-event-filters.md b/articles/logs/references/log-event-filters.md new file mode 100644 index 0000000000..6faa84fbf8 --- /dev/null +++ b/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/articles/logs/references/log-event-type-codes.md b/articles/logs/references/log-event-type-codes.md new file mode 100644 index 0000000000..e7496892b8 --- /dev/null +++ b/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/articles/logs/references/query-syntax.md b/articles/logs/references/query-syntax.md new file mode 100644 index 0000000000..c8d5bfe1cb --- /dev/null +++ b/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/articles/logs/streams/amazon-eventbridge.md b/articles/logs/streams/amazon-eventbridge.md new file mode 100644 index 0000000000..7c9aa10283 --- /dev/null +++ b/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/articles/logs/streams/azure-event-grid.md b/articles/logs/streams/azure-event-grid.md new file mode 100644 index 0000000000..ae1f8b63aa --- /dev/null +++ b/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/articles/logs/streams/datadog.md b/articles/logs/streams/datadog.md new file mode 100644 index 0000000000..6cac684506 --- /dev/null +++ b/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/articles/logs/streams/http-event-to-slack.md b/articles/logs/streams/http-event-to-slack.md new file mode 100644 index 0000000000..2b245b2d37 --- /dev/null +++ b/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/articles/logs/streams/http-event.md b/articles/logs/streams/http-event.md new file mode 100644 index 0000000000..a12963907c --- /dev/null +++ b/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/articles/logs/streams/index.md b/articles/logs/streams/index.md new file mode 100644 index 0000000000..73403ee075 --- /dev/null +++ b/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/articles/metadata/apis.md b/articles/metadata/apis.md deleted file mode 100644 index a12c7573e3..0000000000 --- a/articles/metadata/apis.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: How to Work With User Metadata Using the Auth0 APIs -description: How to create and update metadata using the Auth0 APIs. -crews: crew-2 -toc: true ---- -# How to Create and Update User Metadata With the Auth0 APIs - -In this article, we will cover how you can create and update metadata using the [Authentication](/api/authentication) and [Management](/api/management/v2) APIs. - -## Authentication API - -When you use the Authentication API's [Signup endpoint](/api/authentication?shell#signup), you can create a new Database Connection user and set the `user_metadata` field. - -::: note -When setting the `user_metadata` field using the Authentication API's [Signup endpoint](/api/authentication?javascript#signup), you are limited a maximum of 10 fields and 500 characters. -::: - -## Management API - -Using [Auth0's Management APIv2](/api/management/v2), you can create a user and set both their `app_metadata` and `user_metadata` fields. You can also update these two fields. - -::: note -The Auth0 Management APIv2 token is required to call the Auth0 Management API. Learn more about [how to get a Management APIv2 Token](/api/management/v2/tokens). -::: - -### Set Metadata Fields 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" - } -} -``` - -You would 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": "" -} -``` - -### Retrieve User Metadata - -To retrieve a user's metadata make a `GET` request to the [Get User endpoint of the Management API](/api/management/v2#!/Users/get_users_by_id). - -Assuming you created the user as shown above with the following metadata values: - -```json -{ - "email": "jane.doe@example.com", - "user_metadata": { - "hobby": "surfing" - }, - "app_metadata": { - "plan": "full" - } -} -``` - -Make the following `GET` request: - -```har -{ - "method": "GET", - "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": [{ - "name": "fields", - "value": "user_metadata", - "comment": "" - }, - { - "name": "include_fields", - "value": "true", - "comment": "" - }], - "headersSize": -1, - "bodySize": -1, - "comment": "" -} -``` - -The response will be as follows: - -```json -{ - "user_metadata": { - "hobby": "surfing" - } -} -``` - -### Update User Metadata - -You can update a user's metadata by making a `PATCH` call to the [Update User endpoint of the Management API](/api/management/v2#!/Users/patch_users_by_id). - -Assuming you created the user as shown above 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)). -::: - -#### Merging - -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": "" -} -``` - -#### Deleting - -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": {} -} -``` diff --git a/articles/metadata/index.md b/articles/metadata/index.md deleted file mode 100644 index 621a114fa3..0000000000 --- a/articles/metadata/index.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -description: Auth0 allows you to store data related to each user that has not come from the identity provider as metadata -crews: crew-2 -toc: true ---- -# Metadata - -Auth0 allows you to store **metadata**, or data related to each user that has not come from the identity provider. There are two kinds of metadata: - -* **user_metadata**: stores user attributes (such as user preferences) that do not impact a user's core functionality; -* **app_metadata**: stores information (such as a user's support plan, 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. - -::: note -An authenticated user can modify data in their profile's `user_metadata`, but not in their `app_metadata`. -::: - -## How to Read, Create, or Edit Metadata - -There are two ways by which you can manage your user metadata: using Rules, or using the Auth0 APIs. - -### Use 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 refer to [User Metadata in Rules](/rules/current/metadata-in-rules). - -### Use the Auth0 APIs - -When you use the [Authentication API](/api/authentication), you can use the [Signup](/api/authentication?shell#signup) endpoint, in order to set the `user_metadata` for a user. Note though that this endpoint only works for database connections. - -For an example, refer to [Custom Signup > Using the API](/libraries/custom-signup#using-the-api). - -:::note -You can also use the [GET /userinfo endpoint](/api/authentication#get-user-info) in order to get a user's `user_metadata`. To do so, you first have to [write a Rule to copy `user_metadata` properties to the ID Token](/rules#copy-user-metadata-to-id-token). -::: - -You can use the [Management API](/api/management/v2) in order to retrieve, create, or update both the `user_metadata` and `app_metadata` fields at any point. - -| **Endpoint** | **Description** | -|--|--| -| [Search user by id](/api/management/v2#!/Users/get_users_by_id) | Use this if you want to search for a user based on Id. For an example request see [User Search](/users/search/best-practices#users-by-id). | -| [Search user by email](/api/management/v2#!/Users_By_Email/get_users_by_email) | Use this if you want to search for a user based on email. For an example request see [User Search](/users/search/best-practices#users-by-email).| -| [Get a list of users](/api/management/v2#!/Users/get_users) | Use this if you want to search for a list if users with other search criteria. For an example request see [User Search](/users/search/best-practices#users). See also [Search Metadata](#search-metadata) for a list of restrictions. | -| [Create User](/api/management/v2#!/Users/post_users) | Create a new user and (optionally) set metadata. For a body sample see [POST /api/v2/users](/api/management/v2#!/Users/post_users).| -| [Update User](/api/management/v2#!/Users/patch_users_by_id) | Update a user using a JSON object. For example requests see [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id).| - -:::note -For examples and more info you can also refer to [How to Create and Update User Metadata With the Auth0 APIs](/metadata/apis). -::: - -#### Search Metadata - -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. - -As for `user_metadata`, you can only search for profile-related information, such as -- `name` -- `nickname` -- `given_name` -- `family_name` - -## Metadata Usage - -Suppose 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" - } -} -``` - -::: note -Any valid JSON snippet can be used as metadata. -::: - -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](/rules) or via a call to the [Management API](/metadata/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" -``` - -::: note -With Management APIv1, all metadata was stored in the `metadata` field. Data stored in this field is now available under `app_metadata`. -::: - -### Rules on Naming Metadata Fields - -The following sections cover best practices when setting the names of your metadata fields. - -#### Avoid Periods and Ellipses - -Metadata field **names** must not contain a dot. For example, use of the following field name would return a Bad Request (400) error: - -```json -{ - "preference.color": "pink" -} -``` - -One way of handling this limitation is to nest attributes: - -```json -{ - "preference": { - "color": "pink" - } -} -``` - -Alternately, you can use any delimiter that is not `.` or `$`. - -However, the usage of the `.` delimiter is acceptable in the data **values** such as in the below example: - -```json -{ - "preference": "light.blue" -} -``` - -#### Avoid Dynamic Field Names - -Do not use dynamic field names. For example, instead of using the following structure: - -```json -"participants": { - "Alice" : { - "role": "sender" - }, - "Bob" : { - "role": "receiver" - } -} -``` - -Use this: - -```json -"participants": [ - { - "name": "Alice", - "role": "sender" - }, - { - "name" : "Bob", - "role": "receiver" - } -] -``` - -## Metadata Restrictions - -There are some restrictions when using metadata of which you should be aware: - -### Field Restrictions - -The following fields may not be stored in the `app_metadata` field: - -* `blocked` -* `clientID` -* `created_at` -* `email` -* `email_verified` -* `global_client_id` -* `globalClientID` -* `identities` -* `lastIP` -* `lastLogin` -* `metadata` -* `user_id` -* `loginsCount` - -### Metadata Size Limits - -Currently, Auth0 limits the total size of your user metadata to **16 MB**. However, when using Rules and/or the Management Dashboard, your metadata limits may be lower. - -When setting the `user_metadata` field with the [Authentication API Signup endpoint](/api/authentication?javascript#signup), your metadata is limited to a maximum of 10 fields and 500 characters. - -## Using Lock to Manage Metadata - -Users of the [Lock](/libraries/lock) widget are able to add new items to `user_metadata`, as well as read `user_metadata` after authentication. - -* For information on adding `user_metadata` on signup, please 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; - } -}); -``` - -::: note -For details on how to use Lock to authenticate users and access their profile information, check out the [Lock documentation](/libraries/lock). -::: - -## Metadata and Custom Databases - -If you are using a [custom database](/connections/database#using-your-own-user-store), the **app_metadata** field should be referred to as **metadata** in the scripts you run to manage your metadata. - -For example, you would *not* use this: - -```json -{ - "emails": "jane.doe@example.com", - "user_metadata": { - "hobby": "surfing" - }, - "app_metadata": { - "plan": "full" - } -} -``` - -Instead, you would use this: - -```json -{ - "emails": "jane.doe@example.com", - "user_metadata": { - "hobby": "surfing" - }, - "metadata": { - "plan": "full" - } -} -``` - -## Keep Reading - -::: next-steps -* [Updating Metadata with Auth0 APIs](/metadata/management-api) -* [User Data Storage Guidance](/user-profile/user-data-storage) -* [Change a User's Picture](/user-profile/user-picture#change-a-user-s-picture) -::: diff --git a/articles/metadata/lock.md b/articles/metadata/lock.md deleted file mode 100644 index 5de01c44e9..0000000000 --- a/articles/metadata/lock.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -description: How to read and update user metadata with Lock. -crews: crew-2 ---- - -# How to use Metadata with Lock Library - -This article describes how you can define and update the user's `user_metadata`, using Auth0's [Lock](/libraries/lock) library. If you are not familiar with `user_metadata`, refer to [User Metadata](/metadata). If you need more details on how to install, initialize and use Lock, refer to [Lock for Web](/libraries/lock). - -## 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-) - -## Read User Metadata - -You can read the user's `user_metadata` properties the same way you would for any user profile property. This example retrieves the value associated with `user_metadata.hobby`: - -```js -lock.getUserInfo(accessToken, function(error, profile) { - if (!error) { - document.getElementById('hobby').textContent = profile.user_metadata.hobby; - } -}); -``` - -::: note -For details on how to initialize `lock` refer to [new Auth0Lock(clientID, domain, options)](https://github.com/auth0/lock#new-auth0lockclientid-domain-options) -::: - -## Update User Metadata - -You can [update the metadata properties](/metadata/apiv2#update-user-metadata) with calls to the Auth0 Management API. To do so, make a `PATCH` call to the [Update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint. - - -Here is a sample request, that adds the user's home address as a second-level property: - -```har -{ - "method": "PATCH", - "url": "https://YOURACCOUNT.auth0.com/api/v2/users/user_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": "{\"user_metadata\": {\"addresses\": {\"home\": \"123 Main Street, Anytown, ST 12345\"}}}" - }, - "headersSize": -1, - "bodySize": -1, - "comment": "" -} -``` - -::: note -The Auth0 Management APIv2 token is required to call the Auth0 Management API. [Click here to learn more about how to get a Management APIv2 Token.](/api/management/v2/tokens) -::: diff --git a/articles/mfa/_includes/_authenticator-before-start.md b/articles/mfa/_includes/_authenticator-before-start.md new file mode 100644 index 0000000000..89d496c5ea --- /dev/null +++ b/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/articles/mfa/_includes/_configure-sns.md b/articles/mfa/_includes/_configure-sns.md new file mode 100644 index 0000000000..75d826d044 --- /dev/null +++ b/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/articles/mfa/_includes/_enable-push-notifications.md b/articles/mfa/_includes/_enable-push-notifications.md new file mode 100644 index 0000000000..82be4f2aea --- /dev/null +++ b/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/articles/mfa/_includes/_get_mfa_token.md b/articles/mfa/_includes/_get_mfa_token.md new file mode 100644 index 0000000000..eda25ae672 --- /dev/null +++ b/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/articles/mfa/_includes/_get_mfa_token_challenge.md b/articles/mfa/_includes/_get_mfa_token_challenge.md new file mode 100644 index 0000000000..b0d61e66c7 --- /dev/null +++ b/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/articles/mfa/_includes/_recovery_codes.md b/articles/mfa/_includes/_recovery_codes.md new file mode 100644 index 0000000000..e5f6ab8dc8 --- /dev/null +++ b/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/articles/mfa/_includes/_request_association.md b/articles/mfa/_includes/_request_association.md new file mode 100644 index 0000000000..7d7ce5babc --- /dev/null +++ b/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/articles/mfa/_includes/_successful_challenge.md b/articles/mfa/_includes/_successful_challenge.md new file mode 100644 index 0000000000..c68b5367db --- /dev/null +++ b/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/articles/mfa/_includes/_successful_confirmation.md b/articles/mfa/_includes/_successful_confirmation.md new file mode 100644 index 0000000000..1159ca96d2 --- /dev/null +++ b/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/articles/mfa/_includes/_test-setup.md b/articles/mfa/_includes/_test-setup.md new file mode 100644 index 0000000000..ea25a2a065 --- /dev/null +++ b/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/articles/mfa/concepts/guardian.md b/articles/mfa/concepts/guardian.md new file mode 100644 index 0000000000..65d97d5a10 --- /dev/null +++ b/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/articles/mfa/concepts/mfa-api.md b/articles/mfa/concepts/mfa-api.md new file mode 100644 index 0000000000..6154ac2805 --- /dev/null +++ b/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/articles/mfa/concepts/mfa-developer-resources.md b/articles/mfa/concepts/mfa-developer-resources.md new file mode 100644 index 0000000000..735ce8aee0 --- /dev/null +++ b/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/articles/mfa/concepts/mfa-factors.md b/articles/mfa/concepts/mfa-factors.md new file mode 100644 index 0000000000..26141b8f56 --- /dev/null +++ b/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/articles/mfa/concepts/step-up-authentication.md b/articles/mfa/concepts/step-up-authentication.md new file mode 100644 index 0000000000..ce09fe0084 --- /dev/null +++ b/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/articles/mfa/guides/a.json b/articles/mfa/guides/a.json new file mode 100644 index 0000000000..c7a8387871 --- /dev/null +++ b/articles/mfa/guides/a.json @@ -0,0 +1 @@ +{ "message_types": ["sms", "voice"] } \ No newline at end of file diff --git a/articles/mfa/guides/configure-cisco-duo.md b/articles/mfa/guides/configure-cisco-duo.md new file mode 100644 index 0000000000..a47cc6ee98 --- /dev/null +++ b/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/articles/mfa/guides/configure-email.md b/articles/mfa/guides/configure-email.md new file mode 100644 index 0000000000..0b8c75500f --- /dev/null +++ b/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/articles/mfa/guides/configure-otp.md b/articles/mfa/guides/configure-otp.md new file mode 100644 index 0000000000..2ac05eb434 --- /dev/null +++ b/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/articles/mfa/guides/configure-phone.md b/articles/mfa/guides/configure-phone.md new file mode 100644 index 0000000000..9b37a8fdd1 --- /dev/null +++ b/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/articles/mfa/guides/configure-push.md b/articles/mfa/guides/configure-push.md new file mode 100644 index 0000000000..4bed2fc849 --- /dev/null +++ b/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/articles/mfa/guides/configure-step-up-apis.md b/articles/mfa/guides/configure-step-up-apis.md new file mode 100644 index 0000000000..8b5357dc01 --- /dev/null +++ b/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/articles/mfa/guides/configure-step-up-web-apps.md b/articles/mfa/guides/configure-step-up-web-apps.md new file mode 100644 index 0000000000..af00fbc2ed --- /dev/null +++ b/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/articles/mfa/guides/customize-mfa-universal-login.md b/articles/mfa/guides/customize-mfa-universal-login.md new file mode 100644 index 0000000000..876b69c42d --- /dev/null +++ b/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/articles/mfa/guides/customize-phone-messages.md b/articles/mfa/guides/customize-phone-messages.md new file mode 100644 index 0000000000..a33701d54b --- /dev/null +++ b/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/articles/mfa/guides/enable-mfa.md b/articles/mfa/guides/enable-mfa.md new file mode 100644 index 0000000000..fc86a9e176 --- /dev/null +++ b/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/articles/mfa/guides/guardian/create-enrollment-ticket.md b/articles/mfa/guides/guardian/create-enrollment-ticket.md new file mode 100644 index 0000000000..f50d2e5fef --- /dev/null +++ b/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/articles/mfa/guides/guardian/guardian-android-sdk.md b/articles/mfa/guides/guardian/guardian-android-sdk.md new file mode 100644 index 0000000000..48f60e38c5 --- /dev/null +++ b/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/articles/mfa/guides/guardian/guardian-ios-sdk.md b/articles/mfa/guides/guardian/guardian-ios-sdk.md new file mode 100644 index 0000000000..125aa8a0c3 --- /dev/null +++ b/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/articles/mfa/guides/guardian/install-guardian-sdk.md b/articles/mfa/guides/guardian/install-guardian-sdk.md new file mode 100644 index 0000000000..a1fe64bcfc --- /dev/null +++ b/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/articles/mfa/guides/import-user-mfa.md b/articles/mfa/guides/import-user-mfa.md new file mode 100644 index 0000000000..963de16bd9 --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/authenticate.md b/articles/mfa/guides/mfa-api/authenticate.md new file mode 100644 index 0000000000..219932f6e9 --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/email.md b/articles/mfa/guides/mfa-api/email.md new file mode 100644 index 0000000000..4cd4ba8dbb --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/manage.md b/articles/mfa/guides/mfa-api/manage.md new file mode 100644 index 0000000000..128406fe8a --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md b/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md new file mode 100644 index 0000000000..61398e8c4b --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/otp.md b/articles/mfa/guides/mfa-api/otp.md new file mode 100644 index 0000000000..f2efd0e81a --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/phone.md b/articles/mfa/guides/mfa-api/phone.md new file mode 100644 index 0000000000..02ec707bba --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/push.md b/articles/mfa/guides/mfa-api/push.md new file mode 100644 index 0000000000..d2d0902bdd --- /dev/null +++ b/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/articles/mfa/guides/mfa-api/recovery-code.md b/articles/mfa/guides/mfa-api/recovery-code.md new file mode 100644 index 0000000000..038abaefc1 --- /dev/null +++ b/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/articles/mfa/guides/reset-user-mfa.md b/articles/mfa/guides/reset-user-mfa.md new file mode 100644 index 0000000000..fde72fc781 --- /dev/null +++ b/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/articles/mfa/index.md b/articles/mfa/index.md new file mode 100644 index 0000000000..a31faa4646 --- /dev/null +++ b/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/articles/mfa/references/guardian-error-code-reference.md b/articles/mfa/references/guardian-error-code-reference.md new file mode 100644 index 0000000000..696d3e70de --- /dev/null +++ b/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/articles/mfa/references/language-dictionary.md b/articles/mfa/references/language-dictionary.md new file mode 100644 index 0000000000..614f9d1c5f --- /dev/null +++ b/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/articles/mfa/references/mfa-widget-reference.md b/articles/mfa/references/mfa-widget-reference.md new file mode 100644 index 0000000000..edcdd1dce7 --- /dev/null +++ b/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/articles/mfa/references/troubleshoot-mfa.md b/articles/mfa/references/troubleshoot-mfa.md new file mode 100644 index 0000000000..be1bb19a8e --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-amazon-sns.md b/articles/mfa/send-phone-message-hook-amazon-sns.md new file mode 100644 index 0000000000..e5ad994552 --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-esendex.md b/articles/mfa/send-phone-message-hook-esendex.md new file mode 100644 index 0000000000..8292c86b70 --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-infobip.md b/articles/mfa/send-phone-message-hook-infobip.md new file mode 100644 index 0000000000..7922543369 --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-mitto.md b/articles/mfa/send-phone-message-hook-mitto.md new file mode 100644 index 0000000000..3398326f20 --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-telesign.md b/articles/mfa/send-phone-message-hook-telesign.md new file mode 100644 index 0000000000..1d13504eaa --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-twilio.md b/articles/mfa/send-phone-message-hook-twilio.md new file mode 100644 index 0000000000..6abffb4b49 --- /dev/null +++ b/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/articles/mfa/send-phone-message-hook-vonage.md b/articles/mfa/send-phone-message-hook-vonage.md new file mode 100644 index 0000000000..98a46e1a78 --- /dev/null +++ b/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/articles/microsites/add-login/add-login-native-mobile-app.md b/articles/microsites/add-login/add-login-native-mobile-app.md new file mode 100644 index 0000000000..13eb995054 --- /dev/null +++ b/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/articles/microsites/add-login/add-login-regular-web-app.md b/articles/microsites/add-login/add-login-regular-web-app.md new file mode 100644 index 0000000000..fcab4a04bb --- /dev/null +++ b/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/articles/microsites/add-login/add-login-single-page-app.md b/articles/microsites/add-login/add-login-single-page-app.md new file mode 100644 index 0000000000..7a63e2d626 --- /dev/null +++ b/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/articles/microsites/call-api/call-api-device.md b/articles/microsites/call-api/call-api-device.md new file mode 100644 index 0000000000..c6e23b60fc --- /dev/null +++ b/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/articles/microsites/call-api/call-api-m2m-app.md b/articles/microsites/call-api/call-api-m2m-app.md new file mode 100644 index 0000000000..5f8d1154f5 --- /dev/null +++ b/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/articles/microsites/call-api/call-api-native-mobile-app.md b/articles/microsites/call-api/call-api-native-mobile-app.md new file mode 100644 index 0000000000..d5442b350d --- /dev/null +++ b/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/articles/microsites/call-api/call-api-regular-web-app.md b/articles/microsites/call-api/call-api-regular-web-app.md new file mode 100644 index 0000000000..a13e6cdd73 --- /dev/null +++ b/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/articles/microsites/call-api/call-api-single-page-app.md b/articles/microsites/call-api/call-api-single-page-app.md new file mode 100644 index 0000000000..edaf4ea6e8 --- /dev/null +++ b/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/articles/microsites/manage-users/define-maintain-custom-user-data.md b/articles/microsites/manage-users/define-maintain-custom-user-data.md new file mode 100644 index 0000000000..64c9a50e4c --- /dev/null +++ b/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/articles/microsites/manage-users/manage-users-and-user-profiles.md b/articles/microsites/manage-users/manage-users-and-user-profiles.md new file mode 100644 index 0000000000..5e564f2bc4 --- /dev/null +++ b/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/articles/microsites/protect-api/protect-api.md b/articles/microsites/protect-api/protect-api.md new file mode 100644 index 0000000000..647d41f77d --- /dev/null +++ b/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/articles/migrations/guides/_forced-logouts.md b/articles/migrations/guides/_forced-logouts.md new file mode 100644 index 0000000000..91bbc59482 --- /dev/null +++ b/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/articles/migrations/guides/_get-token-auth0js.md b/articles/migrations/guides/_get-token-auth0js.md index 1f5b71c5ea..52d002f06e 100644 --- a/articles/migrations/guides/_get-token-auth0js.md +++ b/articles/migrations/guides/_get-token-auth0js.md @@ -9,7 +9,7 @@ 
             
-// get an ID token
+// get an ID Token
 var webAuth = new auth0.WebAuth({
   clientID: '${account.clientId}',
   domain: '${account.namespace}',
@@ -34,12 +34,12 @@ var auth0Manage = new auth0.Management({
     
    
       
             
-// get an access 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/˜',
+  audience: 'https://${account.namespace}/api/v2/',
   scope: '${scope}',
   responseType: 'token id_token'
 });
@@ -53,11 +53,11 @@ var auth0Manage = new auth0.Management({
       
    
         
      
           
    • 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/˜')
      • 
+          
    • 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
      •
    -
    \ No newline at end of file + diff --git a/articles/migrations/guides/_get-token-authorize.md b/articles/migrations/guides/_get-token-authorize.md index fbb0e1a09a..304e3c93b9 100644 --- a/articles/migrations/guides/_get-token-authorize.md +++ b/articles/migrations/guides/_get-token-authorize.md @@ -14,7 +14,7 @@ https://${account.namespace}/authorize? &response_type=id_token &client_id=${account.clientId} &redirect_uri=${account.callback} - &nonce=CRYPTOGRAPHIC_NONCE + &nonce=NONCE &state=OPAQUE_VALUE @@ -28,7 +28,7 @@ https://${account.namespace}/authorize? &response_type=token%20id_token &client_id=${account.clientId} &redirect_uri=${account.callback} - &nonce=CRYPTOGRAPHIC_NONCE + &nonce=NONCE &state=OPAQUE_VALUE @@ -36,9 +36,9 @@ https://${account.namespace}/authorize? -In order to get an Access Token that can access the Management API: +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 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: diff --git a/articles/migrations/guides/account-linking.md b/articles/migrations/guides/account-linking.md index 24760b1f95..c56e1766b1 100644 --- a/articles/migrations/guides/account-linking.md +++ b/articles/migrations/guides/account-linking.md @@ -1,20 +1,21 @@ --- -title: Migration Guide: Account Linking and ID Tokens 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 and ID Tokens +# 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](/link-accounts). +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/id-token) to [link and unlink user accounts](/link-accounts). This functionality is being deprecated. You will have to use [Access Tokens](/tokens/access-token) in all cases. - -The functionality is available and affected users are encouraged to migrate. However the ability to use ID Tokens will **not** be disabled in the foreseeable future so the mandatory opt-in date for this migration remains open. When this changes, customers will be notified beforehand. - -This article will help you migrate your implementation. 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 how you can use them in the account linking process. - -## Summary of changes +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: @@ -25,9 +26,13 @@ The changes in account linking are: - 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. +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. +::: -## Does this affect me? +## 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. @@ -76,23 +81,23 @@ There are several ways you can link and unlink accounts. Some change, some remai 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 + 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 + 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 -## How to link accounts +## 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 API +### 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. @@ -103,7 +108,7 @@ With this migration, you must get an Access Token (which must contain the `updat First, you must get an Access Token with the `update:current_user_identities` scope. ::: note -In the example that follows, we use the [Implicit Grant](/api-auth/tutorials/implicit-grant), the recommended OAuth 2.0 flow for client-side apps). You can get Access Tokens though for any application type (see [How to get an Access Token](/tokens/access-token#how-to-get-an-access-token)). +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' }) %> @@ -144,7 +149,7 @@ First, you must get an Access Token with the `update:current_user_identities` sc <%= include('./_get-token-auth0js.md', { scope: 'update:current_user_identities' }) %> -### Link any user account with the API +### 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. @@ -174,7 +179,7 @@ However, this migration does introduce an alternative to this. You still use an - 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. -## How to unlink accounts +## Unlink user accounts If you use ID Tokens in order to unlink accounts, then you must update your implementation to use Access Tokens. @@ -184,7 +189,7 @@ Use the sample script that follows as a guide. On the **Legacy (ID Token)** pane <%= 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_provider_by_user_id) endpoint of the Management API, using it in the `Authorization` header. +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.
    @@ -213,11 +218,29 @@ 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 -:::next-steps -- [Link User Accounts](/link-accounts) -- [Account Linking Using Server Side Code](/link-accounts/suggested-linking) -- [Account Linking Using Client Side Code](/link-accounts/user-initiated-linking) -- [Migration Guide: Management API and ID Tokens](/migrations/guides/calling-api-with-idtokens) -::: +- [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/articles/migrations/guides/calling-api-with-idtokens.md b/articles/migrations/guides/calling-api-with-idtokens.md index e2990d61ff..471a05cdc5 100644 --- a/articles/migrations/guides/calling-api-with-idtokens.md +++ b/articles/migrations/guides/calling-api-with-idtokens.md @@ -2,19 +2,30 @@ 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/id-token) 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. +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). +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. -However, customers are encouraged to migrate to Access Tokens. This article will help you with that. +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 [Account Linking](/link-accounts) process. +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? @@ -23,13 +34,15 @@ If you use ID Tokens to call any of the following endpoints, then you are affect | **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](/multifactor-authentication/guardian) MFA enrollments for a user | +| [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 [multifactor](/multifactor-authentication) provider settings for a user | +| [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](/link-accounts) from various identity providers | -| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_provider_by_user_id) | [Unlink user accounts](/link-accounts#unlinking-accounts) | +| [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). @@ -37,14 +50,14 @@ Note that the last two endpoints are used for Account Linking. To review these c ## Changes in scopes -The actions you can perform with the Management API depend on the [scopes](/scopes#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. +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_provider_by_user_id) | `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` | @@ -62,13 +75,13 @@ The Access Tokens used to access the Management API **must hold only one value a 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-client). 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 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-client). 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 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). @@ -109,7 +122,7 @@ On the `Legacy (ID Token)` script you can see an implementation of the old appro 
             
 POST https://${account.namespace}/oauth/token
-Content-Type: application/json
+Content-Type: application/x-www-form-urlencoded
 {
   "grant_type": "password",
   "username": "USERNAME",
@@ -125,7 +138,7 @@ Content-Type: application/json
       
             
 POST https://${account.namespace}/oauth/token
-Content-Type: application/json
+Content-Type: application/x-www-form-urlencoded
 {
   "grant_type": "password",
   "username": "USERNAME",
@@ -180,7 +193,5 @@ For a detailed overview of these changes and migration steps per use case, see [
 
 ## Keep reading
 
-:::next-steps
-- [How to get an Access Token](/tokens/access-token#how-to-get-an-access-token)
+- [Get Access Tokens](/tokens/guides/get-access-tokens)
 - [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
-:::
\ No newline at end of file
diff --git a/articles/migrations/guides/clickjacking-protection.md b/articles/migrations/guides/clickjacking-protection.md
new file mode 100644
index 0000000000..877e705f0c
--- /dev/null
+++ b/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/articles/migrations/guides/extensibility-node12.md b/articles/migrations/guides/extensibility-node12.md
new file mode 100644
index 0000000000..2ef5c6f878
--- /dev/null
+++ b/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/articles/migrations/guides/extensibility-node8.md b/articles/migrations/guides/extensibility-node8.md
deleted file mode 100644
index 9b7110f12b..0000000000
--- a/articles/migrations/guides/extensibility-node8.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-title: "Migration Guide: Extensibility and Node 8"
-description: This article covers the Auth0 features/modules affected, as well as our recommendations to ensure a smooth migration process.
-toc: true
----
-# Migration Guide: Extensibility and Node 8
-
-Beginning April 30, 2018, [Node.js v4 will be going out of long-term support (LTS)](https://github.com/nodejs/Release#release-schedule), which means that the Node.js development team will no longer be back-porting critical security fixes to this version and this _could_ expose your extensibility code to security vulnerabilities.
-
-As such, Auth0 will be migrating from Node 4 to Node 8.
-
-We will **NOT** be shutting down the Node 4 runtime after the April 30 LTS deadline. Your extensibility code will continue to run on Node 4, if you choose not to upgrade to Node 8 at this time. After April 30, you will assume the risk of potential security issues if you choose to continue with Node 4.
-
-In this document, we:
-
-* Provide recommendations on how you can ensure a smooth migration for your environment
-* Detail the specific modules effected
-
-## Summary of the migration
-
-The Webtask runtime powering the following Auth0 features utilize Node 4:
-
-* 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. **Additionally, your tenant will automatically be upgraded to use the Node 8 runtime on April 30, 2018.** This will ensure that any future extensibility code you author will be running on a secure runtime.
-
-Due to the end of long-term support (LTS) for Node 4, we will be migrating the Webtask runtime to use Node 8. As part of this migration, the Auth0 development team has performed extensive testing to detect any breaking changes proactively.
-
-However, there may be behavioral changes as a result of this migration. As such, we have provided a migration switch that allows you to control the migration of your environment to the new Webtask runtime using Node 8.
-
-### Important Dates
-
-* **2018 April 17**: The Webtask runtime using Node 8 becomes available to Auth0 customers
-* **2018 April 23**: All official Auth0 Extensions will be updated to run on Node 8 and available for you to upgrade in the **Installed Extensions** tab of the [Extensions page](${manage_url}/#/extensions)
-* **2018 April 30**: [Node 4 is no longer under long-term support (LTS)](https://github.com/nodejs/Release#release-schedule)
-* **2018 April 30**: Tenants with NO Extensibility code will be automatically be upgraded to use Node 8
-
-## How to enable the Node 8 runtime
-
-Node 8 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 8 runtime, test your setup, and switch your production tenant only when you have identified there are no breaking changes.
-:::
-
-## Whitelist the new URLs
-
-When you upgrade to Node 8, the URLs you use to access our extensions, change. The change is an `8` that is appened before the `webtask.io` part. So if you accessed an extension using the URL `https://${account.tenant}.us.webtask.io/dummy-extension-url`, when you upgrade to Node 8 the URL will be `https://${account.tenant}.us8.webtask.io/dummy-extension-url`.
-
-This is a breaking change for some extensions, that require whitelisting the URLs in order to properly work.
-
-The affected extensions are the [Delegated Administration Extension](/extensions/delegated-admin) and the [Single Sign-On (SSO) Dashboard](/extensions/sso-dashboard). If you use either, **you must whitelist the new URLs** both as Allowed Callback and as Allowed Logout URLs.
-
-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**.
-
-### Delegated Administration URLs
-
-The matrix that follows contains the updated URLs you must configure after you migrate to Node 8. The URL varies based on your location.
-
-| Location | Allowed Callback URL for Node 8 | Allowed Logout URL for Node 8 |
-| --- | --- | --- |
-| USA | `https://${account.tenant}.us8.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.us8.webtask.io/auth0-delegated-admin` |
-| Europe | `https://${account.tenant}.eu8.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.eu8.webtask.io/auth0-delegated-admin` |
-| Australia | `https://${account.tenant}.au8.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.au8.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}.us8.webtask.io/auth0-delegated-admin/login`
-- **Allowed Logout URLs**: `https://${account.tenant}.us8.webtask.io/auth0-delegated-admin`
-
-### SSO Dashboard URLs
-
-The matrix that follows contains the updated URLs you must configure after you migrate to Node 8. The URL varies based on your location.
-
-The login URL for **Admins**:
-
-| Location | Allowed Callback URL |
-| --- | --- |
-| USA | `https://${account.tenant}.us8.webtask.io/auth0-sso-dashboard/admins/login` |
-| Europe | `https://${account.tenant}.eu8.webtask.io/auth0-sso-dashboard/admins/login` |
-| Australia | `https://${account.tenant}.au8.webtask.io/auth0-sso-dashboard/admins/login` |
-
-The login URL for **Users**:
-
-| Location | Allowed Callback URL |
-| --- | --- |
-| USA | `https://${account.tenant}.us8.webtask.io/auth0-sso-dashboard/login` |
-| Europe | `https://${account.tenant}.eu8.webtask.io/auth0-sso-dashboard/login` |
-| Australia | `https://${account.tenant}.au8.webtask.io/auth0-sso-dashboard/login` |
-
-## How to ensure a stable migration
-
-As part of the process of introducing Node 8 in our Webtask runtime, we ran a number of tests to determine which modules are not forward-compatible from Node 4 to 8. Most customers _should_ be able to upgrade to Node 8 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, 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) and [Rules](/api/management/v2#!/Rules/get_rules) 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`.
-
-You will need to manually copy over any Hooks-related code that you use since they cannot be accessed via the Management API.
-
-### Migration assistance
-
-We have created a [migration assistant](https://github.com/auth0/webtask-migration-assistant) to help ease the copying of code between production and development tenants.
-
-Please be sure to test each script *individually* with its associated **Try** button. You may, however, test all rules simultaneously with the **Try All Rules With** button.
-
-In addition, test _logging in_ using the development tenant to ensure that all of the following items that you have set up work as expected:
-
-* Rules
-* Hooks
-* Database Connections
-* Custom Social Connections
-* Extensions
-
-## 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 8. The following table summarizes the changes.
-
-| Module name | Old version | New version |
-| - | - | - |
-| azure-storage | ~0.4.1 | ~2.2.1 |
-| couchbase | ~1.2.1 | ~2.3.5 |
-| jsonwebtoken | ~0.4.1^* | ~7.4.1 (w/ compatibility shim) |
-| knex | ~0.6.3 | ~0.13.0 |
-| mongo-getdb | ~1.2.0^* | ^2.2.0 |
-| mongodb | ~1.3.15^* | ^2.2.0 |
-| mysql | 2.0.0-alpha8^* | ^2.0.0 |
-| node-cassandra-cql | ^0.4.4 | ^0.5.0 |
-| request | ~2.27.0 | ~2.81.0 |
-| pg | ^4.3.0^* | ^4.5.7 |
-| bcrypt | ~0.8.5^* | ~0.8.7 |
-| xml2json | ~0.10.0^* | ~0.11.2 |
-
-^* These versions are no longer supported due to incompatibility with Node 8.
-
-### Pinned modules
-
-If you have manually pinned modules, you may need to manually update them so that your code runs with Node 8.
-
-For example, you must change
-
-`var mysql = require(‘mysql@2.0.0-alpha8’);`
-
-to
-
-`var mysql = require(‘mysql’);`
-
-or, if the module must be pinned to a specific version:
-
-`var mysql = require(‘mysql@2.0.0’);`
-
-### Behavioral and syntactic changes
-
-Some of the behavioral and syntactic changes in modules were not forward-compatible with Node 8.
-
-For example, the default encoding of the `crypto` module was changed from `binary` to `utf8`, and the use of `new Buffer()` has been deprecated in favor of `Buffer.from()`.
-
-Please consult Node.js' migration nodes for [v4 to v6](https://github.com/nodejs/node/wiki/Breaking-changes-between-v4-LTS-and-v6-LTS) and [v6 to v8](https://github.com/nodejs/node/wiki/Breaking-changes-between-v6-LTS-and-v8-LTS) for additional information.
-
-**To ensure that your Auth0 implementation functions as intended, please be sure to migrate to the Node 8 runtime before April 30 2018.**
diff --git a/articles/migrations/guides/facebook-graph-api-deprecation.md b/articles/migrations/guides/facebook-graph-api-deprecation.md
new file mode 100644
index 0000000000..39159f0b6e
--- /dev/null
+++ b/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/articles/migrations/guides/facebook-social-context.md b/articles/migrations/guides/facebook-social-context.md
new file mode 100644
index 0000000000..d3a06f3de5
--- /dev/null
+++ b/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/articles/migrations/guides/google_cloud_messaging.md b/articles/migrations/guides/google_cloud_messaging.md
new file mode 100644
index 0000000000..3b8e862174
--- /dev/null
+++ b/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/articles/migrations/guides/instagram-deprecation.md b/articles/migrations/guides/instagram-deprecation.md
new file mode 100644
index 0000000000..d801742b37
--- /dev/null
+++ b/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/articles/migrations/guides/legacy-lock-api-deprecation.md b/articles/migrations/guides/legacy-lock-api-deprecation.md
index f6a86ad95e..5398d83618 100644
--- a/articles/migrations/guides/legacy-lock-api-deprecation.md
+++ b/articles/migrations/guides/legacy-lock-api-deprecation.md
@@ -2,12 +2,19 @@
 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](https://auth0.com/blog/managing-and-mitigating-security-vulnerabilities-at-auth0/). That vulnerability resulted in the deprecation of two endpoints in the Auth0 API, and the libraries and SDKs which used those endpoints. Due to this vulnerability, those endpoints (and thus, the deprecated versions of the libraries) will be removed from service on **July 16, 2018**.
+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 notice. 
+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?
 
@@ -21,7 +28,7 @@ If you do not use the above libraries and do not specifically call the above end
 
 ### 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.
+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
 
@@ -29,7 +36,7 @@ Embedded login with Lock v11 and Auth0.js v9 now rely entirely on [cross-origin
 
 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-of-cross-origin-authentication), there are only two general implementations that can be recommended. 
+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. 
 
@@ -37,11 +44,13 @@ Because of these [cross-origin authentication issues](/cross-origin-authenticati
     * 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 prior to **July 16, 2018**, when they will be removed from service and those applications will cease to work correctly. There are two options for migration:
+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
 
@@ -50,11 +59,11 @@ Universal Login is **strongly** recommended for most use cases because it [offer
 * 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 functionality without relying on third-party cookies or restricting the domain of applications.
+* 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 [multifactor authentication](/multifactor-authentication).
+* Works with any type of Auth0 connection as well as multi-factor authentication (MFA).
 
 #### Universal Login migration guides
 
@@ -66,9 +75,9 @@ Universal Login is **strongly** recommended for most use cases because it [offer
  • - Migrate Single Page Apps with Embedded Lock to Universal Login + Migrate Single-Page Apps with Embedded Lock to Universal Login

    - This document provides instruction for single page apps which have embedded login (via the Lock widget) to migrate to Universal Login. + This document provides instruction for single-page apps which have embedded login (via the Lock widget) to migrate to Universal Login.

  • @@ -86,12 +95,6 @@ Embedded login (embedding Lock or a custom authentication UI) should be used onl #### Embedded login migration guides
      -
    • - Lock v11 Migration Guide -

      - This document presents an overview of the updates to Lock in version 11 and points to technology and version-specific tutorials to help you with your migration. -

      -
    • Auth0.js v9 Migration Guide

      @@ -100,7 +103,7 @@ Embedded login (embedding Lock or a custom authentication UI) should be used onl

    -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. +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 @@ -110,82 +113,63 @@ A few specific items are changing with the new versions / endpoints. If you use * [How to check for an existing session](#session-management) * [How to log users out](#how-to-log-users-out) -### How to get user info +## 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](/tokens/access-token#how-to-get-an-access-token) (obtained during login) instead of the [ID Token](/tokens/id-token) used by /tokeninfo. +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. +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 +#### 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 will be removed from service on **July 16, 2018**. The `getSSOData()` function will continue to work, but will behave differently, and in most cases, can be replaced with use of `checkSession()`. +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 +The `getSSOData()` and `checkSession()` functions should only be used from a Single-Page Application ::: -##### checkSession +##### 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 +##### getSSOData() -* The Auth0.js v9 `getSSOData()` function will continue to work, but it now [behaves differently than in the past](/libraries/auth0js/v9/migration-v8-v9#review-calls-to-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-client) endpoint, which will in turn result in the execution of [rules](/rules). +* 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 -In some multi-application scenarios, where a user logging out of one application needs to be logged out of other applications, an application may have been set up to periodically poll Auth0 using `getSSOData()` to see if a session existed, and if not, log the user out of the application. +<%= include('../../_includes/_checksession_polling') %> -Instead of doing this, applications should now use `checkSession()` instead of `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. - -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. +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-client) 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. +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/refresh-token/current#use-a-refresh-token) to renew their token. +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. -## Troubleshooting - -### How to tell if you have deprecated usage - -Please take a look at the [Deprecation Error Reference](/articles/errors/deprecation-errors) to assist with verifying that your application does, or does not, use deprecated features. +### Using Lock with AD/LDAP and Kerberos -### How to test whether you are ready before the removal of service date +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. -Auth0 has provided a toggle in the tenant settings in the [Dashboard](${manage_url}) to allow customers to turn off the legacy endpoints manually for their tenant ahead of the deprecation deadline of July 16, 2018. Navigate to the tenant settings screen, **Advanced** tab and scroll down to the block of migration toggles. +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: -Turn off the **Legacy Lock API** toggle to stop your tenant from being able to use those endpoints. This toggle allows you to test the removal of the deprecated endpoints with the ability to turn them back on if you encounter issues. +* Use `getSSOData()` to achieve an automatic login +* Use Lock and get the **Use Windows Authentication** button (log in with Kerberos). -::: note -Tenants created after Dec 27, 2017 were not allowed to begin usage of these deprecated features, and therefore do not have the Legacy Lock API toggle. -::: - -### Bookmarking the login page - -Bookmarking the Universal Login page is not supported. If a user bookmarks the login page and attempts to initiate authentication by going directly to the bookmarked URL instead of starting from the application, the following error message will be shown: `Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set`. - -### Fingerprinting error - -For any customers who have not quite finished migrating away from the above deprecated features, Auth0 has [implemented a temporary solution](/cross-origin-authentication/fingerprinting) to help mitigate the severity of the issues with the deprecated endpoints. This solution relies on "fingerprinting" checks on the successive calls in an authentication transaction. - -If any authentication requests are being rejected by the fingerprinting solution, they can be identified with the following query against logs: - -Description: "Unable to verify transaction consistency" +## Troubleshooting -Customers who have any transactions rejected by the fingerprinting checks should complete their upgrades to resolve the issue. +See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors. diff --git a/articles/migrations/guides/linkedin-api-deprecation.md b/articles/migrations/guides/linkedin-api-deprecation.md new file mode 100644 index 0000000000..011ba33906 --- /dev/null +++ b/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/articles/migrations/guides/liveid-api-deprecation.md b/articles/migrations/guides/liveid-api-deprecation.md new file mode 100644 index 0000000000..bdf60569cf --- /dev/null +++ b/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/articles/migrations/guides/management-api-v1-v2.md b/articles/migrations/guides/management-api-v1-v2.md new file mode 100644 index 0000000000..65ea5d6bfb --- /dev/null +++ b/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/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md b/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md new file mode 100644 index 0000000000..2af6b0ea4e --- /dev/null +++ b/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/articles/migrations/guides/migration-oauthro-oauthtoken.md b/articles/migrations/guides/migration-oauthro-oauthtoken.md index 57a477eb0f..cf4d290c1f 100644 --- a/articles/migrations/guides/migration-oauthro-oauthtoken.md +++ b/articles/migrations/guides/migration-oauthro-oauthtoken.md @@ -2,14 +2,21 @@ 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) and usage of the [oauth/ro](/api/authentication#resource-owner) endpoint will be deprecated at some point in the future. +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 guide is for users who 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. +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 @@ -29,10 +36,10 @@ Previously, the payload of a request to /oauth/ro looked similar to this: * 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#openid-connect-scopes), along with the scopes which you have defined in your [custom API](/api-auth/apis). +* 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. +* The `audience` parameter is optional. Here is an example of the payload of a request to /oauth/token: @@ -68,9 +75,9 @@ Responses from `oauth/ro` were similar in format to the following: } ``` -* 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) and optionally the [custom API](/api-auth/apis) if one was specified. +* 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. +* 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`: diff --git a/articles/migrations/guides/passwordless-start.md b/articles/migrations/guides/passwordless-start.md new file mode 100644 index 0000000000..690d1f5786 --- /dev/null +++ b/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/articles/migrations/guides/unpaginated-requests.md b/articles/migrations/guides/unpaginated-requests.md new file mode 100644 index 0000000000..6ee5a263c8 --- /dev/null +++ b/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/articles/migrations/guides/yahoo-userinfo-updates.md b/articles/migrations/guides/yahoo-userinfo-updates.md new file mode 100644 index 0000000000..33bd6ea68a --- /dev/null +++ b/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/articles/migrations/index.md b/articles/migrations/index.md deleted file mode 100644 index 38a9c7b9fb..0000000000 --- a/articles/migrations/index.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -toc: true -title: Auth0 Migrations -description: List of all the changes made on Auth0 platform that might affect customers ---- - -# Migrations - -Occasionally, Auth0 engineers must make breaking changes to the Auth0 platform, primarily for security reasons. If a vulnerability or other problem in the platform is not up to our high standards of security, we work to correct the issue. - -Sometimes a correction will cause a breaking change to customer's applications. Depending on the severity of the issue, we may have to make the change immediately. - -For changes that do not require immediate changes, we often allow a grace period to allow you time to update your applications. - -## Migration process - -The migration process is outlined below: - -1. We update the platform and add a new migration option for existing customers, allowing a grace period for opt-in. New customers are always automatically enrolled in all migrations. -2. After a certain period, the migration is enabled for all customers. This grace period varies based on the severity and impact of the breaking change, typically 30 or 90 days. - -During the grace period, customers are informed via dashboard notifications and emails to tenant administrators. You will continue to receive emails until the migration has been enabled on each tenant you administer. - -If you need help with the migration, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). - -## Active migrations - -Current migrations are listed below, newest first. - -For migrations that have already been enabled for all customers, see [Past Migrations](/migrations/past-migrations). - -### Node.js v8 for Webtask Runtime - -| Severity | Grace Period Start | Mandatory Opt-In| -| --- | --- | --- | -| High | 2018-04-17 | 2018-04-30 | - -The Webtask engine powering Auth0 extensibility points currently utilizes Node 4. Beginning **30 April 2018**, [Node.js v4 will no longer be under long-term support (LTS)](https://github.com/nodejs/Release#release-schedule). This means that critical security fixes will no longer be back-ported to this version. As such, Auth0 will be migrating the Webtask runtime from Node.js v4 to Node.js v8. - -On **17 April 2018** we will make the Node 8 runtime available for extensibility to all public cloud customers. You will be provided a migration switch that allows you to control your environment's migration to the new runtime environment. - -For more information on this migration and the steps you should follow to upgrade your implementation, see [Migration Guide: Extensibility and Node.js v8](/migrations/guides/extensibility-node8). - -### Introducing Lock v11 and Auth0.js v9 - -| Severity | Grace Period Start | Mandatory Opt-In| -| --- | --- | --- | -| Medium | 2017-12-21 | 2018-07-16 | - -We are continually improving the security of our service. As part of this, we are deprecating some endpoints (/usernamepassword/login and /ssodata) used by Lock.js v8, v9, and v10 and and auth0.js, v6, v7, and v8. - -Previously, these endpoints were planned to be removed from service on April 1, 2018. However, the Removal of Service date for those endpoints has been extended to **July 16, 2018**. - -Customers are still encouraged to migrate applications to the latest version of Lock 11 and Auth0.js 9 **as soon as possible** in order to ensure that applications continue to function properly. - -Please refer to our [Legacy Lock API Deprecation Guide](/migrations/guides/legacy-lock-api-deprecation) for instructions on upgrading your Auth0 implementation prior to **July 16, 2018**. - -#### 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 will be affected by these changes. - -We **recommend** that applications using [universal login](/hosted-pages/login) update. - -However, those who are using Lock or Auth0.js embedded within their applications are **required** to update, and applications which still use deprecated versions will cease to work after the removal of service date. - -Libraries and SDKs not explicitly named here are not affected by this migration. - -If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). - -### Deprecating the usage of ID Tokens on the Auth0 Management API - -| Severity | Grace Period Start | Mandatory Opt-In| -| --- | --- | --- | -| Medium | 2018-03-31 | - | - -For some use cases you can use [ID Tokens](/tokens/id-token) as credentials in order to call the [Management API](/api/management/v2). This functionality is being deprecated. - -This is used by the [Users](/api/management/v2#!/Users/get_users_by_id) and [Device Credentials](/api/management/v2#!/Device_Credentials/get_device_credentials) endpoints. - -List of affected endpoints: - -| **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](/multifactor-authentication/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 [multifactor](/multifactor-authentication) 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](/link-accounts) from various identity providers | -| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_provider_by_user_id) | [Unlink user accounts](/link-accounts#unlinking-accounts) | - -These endpoints can now accept regular [Access Tokens](/access-token). - -The functionality is available and affected users are encouraged to migrate. However the ability to use ID Tokens will not be disabled in the foreseeable future so the mandatory opt-in date for this migration remains open. When this changes, customers will be notified beforehand. - -For more information on this migration and the steps you should follow to upgrade your implementation, see the [Migration Guide: Management API and ID Tokens](/migrations/guides/calling-api-with-idtokens). - -#### Am I affected by the change? - -If you are currently using [ID Tokens](/tokens/id-token) to access any part of the Management API, your application will need to be updated. - -If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). - -## Upcoming migrations - -Based on customer feedback, we have adjusted our plans and will continue to maintain and support the below listed endpoints and features. - -We will publish guidance for each of the below scenarios on how to transition your applications to standards-based protocols. If we need to make security enhancements to any of these legacy endpoints which would require more urgency, we will promptly announce timeframes and guidelines for any required changes. - -### Resource Owner support for oauth/token endpoint - -Support was introduced for [Resource Owner Password](/api/authentication#resource-owner-password) to the [/oauth/token](/api/authentication#authorization-code) endpoint earlier this year. - -#### Am I affected by the change? - -If you are currently implementing the [/oauth/ro](/api/authentication#resource-owner) endpoint your application can be updated to use the [/oauth/token](/api/authentication#authorization-code) endpoint. For details on how to make this transition, see the [Migration Guide for Resource Owner Password Credentials Exchange](/migrations/guides/migration-oauthro-oauthtoken). - -If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). - -### API authorization with third-party vendor APIs - -The mechanism by which you get tokens for third-party / vendor APIs (for example AWS, Firebase, and others) is being changed. It will work the same as any custom API, providing better consistency. This new architecture will be available in 2018 and once it becomes available, the [/delegation](/api/authentication#delegation) endpoint will be officially deprecated. - -#### Am I affected by the change? - -If you are currently using [/delegation](/api/authentication#delegation) to provide third party authorization, your application will need to be updated once migration guides are available. - -If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). - -### Improved OpenID Connect interoperability in Auth0 - -The [userinfo](/api/authentication#get-user-info) endpoint is being updated to return [OIDC conformant user profile attributes](/user-profile/normalized/oidc). The most notable change is that `user_id` becomes `sub`. This will deprecate the [legacy Auth0 user profile](/user-profile/normalized/auth0) (in [userinfo](/api/authentication#get-user-info) and in [id tokens](/tokens/id-token)). - -#### Am I affected by the change? - -If you are currently using the [/userinfo](/api/authentication#get-user-info) endpoint or receiving ID Tokens, you are affected by this change and need to update your implementation so that it expects normalized OIDC conformant user profile attributes once migration guides are available. - -If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). diff --git a/articles/migrations/past-migrations.md b/articles/migrations/past-migrations.md index 26e091c811..5956128735 100644 --- a/articles/migrations/past-migrations.md +++ b/articles/migrations/past-migrations.md @@ -1,11 +1,39 @@ --- 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| @@ -52,7 +80,7 @@ The existing Auth0 CDN service is one of our older services. It was been built a ### Am I using the CDN? -If you use Lock (hosted by our CDN) in Europe or Australia, yes. +If you use Lock (hosted by our CDN) in Europe or Australia, yes. ### Do I need to do something? @@ -103,11 +131,11 @@ Even if you are not using Lock, the vulnerable reset flow can be accessed direct | --- | --- | --- | | 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](/tokens/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). +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. Please refer to https://auth0.com/docs/link-accounts 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 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}) @@ -117,7 +145,7 @@ If you need help with the migration, create a ticket in our [Support Center](${e | --- | --- | --- | | 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. +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"`. @@ -127,7 +155,7 @@ You could be impacted if you are currently using these exchanges and have Rules 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 +- `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). @@ -151,13 +179,13 @@ For more information, see: [Emails in Auth0](/email). | --- | --- | | 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. +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}/`. +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. @@ -169,9 +197,9 @@ You can use [jwt.io](https://jwt.io/) to decode the token to confirm the `iss` a | --- | --- | --- | --- | | 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. +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. +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). @@ -181,7 +209,7 @@ You will still have access to the Identity Provider Access Token in the `user` a 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 Token](/tokens/idp). +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. diff --git a/articles/monitoring/_includes/_monitor-private-cloud.md b/articles/monitoring/_includes/_monitor-private-cloud.md new file mode 100644 index 0000000000..a0dc01777f --- /dev/null +++ b/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/articles/monitoring/guides/check-external-services.md b/articles/monitoring/guides/check-external-services.md new file mode 100644 index 0000000000..3dfbf87d5f --- /dev/null +++ b/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/articles/monitoring/guides/check-status.md b/articles/monitoring/guides/check-status.md new file mode 100644 index 0000000000..98f4181a57 --- /dev/null +++ b/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/articles/monitoring/guides/monitor-applications.md b/articles/monitoring/guides/monitor-applications.md new file mode 100644 index 0000000000..f84e4eb665 --- /dev/null +++ b/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/articles/monitoring/guides/monitor-using-SCOM.md b/articles/monitoring/guides/monitor-using-SCOM.md new file mode 100644 index 0000000000..97918bb43f --- /dev/null +++ b/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/articles/monitoring/guides/send-events-to-keenio.md b/articles/monitoring/guides/send-events-to-keenio.md new file mode 100644 index 0000000000..22fc43d835 --- /dev/null +++ b/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/articles/monitoring/guides/send-events-to-segmentio.md b/articles/monitoring/guides/send-events-to-segmentio.md new file mode 100644 index 0000000000..51f8030308 --- /dev/null +++ b/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/articles/monitoring/guides/send-events-to-splunk.md b/articles/monitoring/guides/send-events-to-splunk.md new file mode 100644 index 0000000000..a805b82ebe --- /dev/null +++ b/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/articles/monitoring/guides/test-testall-endpoints.md b/articles/monitoring/guides/test-testall-endpoints.md new file mode 100644 index 0000000000..df71f9c74d --- /dev/null +++ b/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/articles/monitoring/guides/track-leads-salesforce.md b/articles/monitoring/guides/track-leads-salesforce.md new file mode 100644 index 0000000000..0c277f7219 --- /dev/null +++ b/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/articles/monitoring/guides/track-signups-salesforce.md b/articles/monitoring/guides/track-signups-salesforce.md new file mode 100644 index 0000000000..6120985e99 --- /dev/null +++ b/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/articles/monitoring/how-to-monitor-auth0.md b/articles/monitoring/how-to-monitor-auth0.md deleted file mode 100644 index 3b8c93749b..0000000000 --- a/articles/monitoring/how-to-monitor-auth0.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -description: How to use monitoring with an Auth0 account. -toc: true ---- - -# Monitor Auth0 - -If you are using the public cloud version of Auth0, we recommend subscribing to [Auth0 Status](http://status.auth0.com) for notifications regarding Auth0 service availability. The Auth0 DevOps team uses [Auth0 Status](http://status.auth0.com) for reports on current incidents. - -Current and historical uptime is available at [Auth0 Uptime](http://uptime.auth0.com). - -## Monitor your Auth0 account - -You can add Auth0 health probes to your monitoring infrastructure with the following endpoints: - -### The test endpoint - -The `test` endpoint checks the status of the core Auth0 authentication service. If the status is up, the endpoint returns a `200` status code; if is is not, it will return a `5xx` status code. - -```har -{ - "method": "GET", - "url": "https://${account.namespace}/test" -} -``` - -Additionally, this endpoint returns a JSON object: - -```json -{ - "clock": 1417220191640 -} -``` - -### The 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. - -```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 saying, `OK`. If any service is down, the response code from `/testall` will be `5xx`. - -If you've extended Auth0 through [rules](/rules) or [a custom database connection](/connections/database/mysql), you can build a synthetic transaction that exercises these capabilities using the [Resource Owner Password Grant](/api-auth/tutorials/password-grant). - -We recommend using an authentication flow that doesn't require a user interface (such as the **Resource Owner Password Grant**) so that you don't have to use a monitoring tool that is capable of mimicking the actions of a user. Many monitoring tools exist using this approach, including: - -* [New Relic](http://newrelic.com) -* [Pingdom](http://pingdom.com) - -## Monitor external services - -If you are seeing potential issues with your Auth0 service, but the monitoring endpoints and the [Auth0 Status page](https://status.auth0.com) aren't indicating any problems, check the status of any external services that you use alongside Auth0. - -* [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/) - -## Monitor a dedicated deployment - -Please see the [PSaaS Appliance](/appliance) pages for [information on monitoring a dedicated deployment](/appliance/monitoring). - -## Configure SCOM - -Auth0 can be monitored as a standard web application using System Center Operations Manager (SCOM) or any tool that supports synthetic transactions. - -We recommend adding SCOM probes for the `test` and `testall` endpoints, in addition to one for 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). - -To set up SCOM: - -1. Add a new SCOM instance using the **Add Monitoring Wizard**: - - * **Name**: a descriptive name for the SCOM instance - * **Description**: a description of what this SCOM instances monitors - * **Select destination management pack**: Default Management Pack - - ![ss-2014-11-21T15-44-34.png](/media/articles/monitoring/ss-2014-11-21T15-44-34.png) - - Click **Next** to continue. - -2. Click **Add** to enter the URLs you want SCOM to monitor. - - ![ss-2014-11-21T16-31-15.png](/media/articles/monitoring/ss-2014-11-21T16-31-15.png) - - Click **Next** to continue. - -3. You will be asked where you want to monitor from. Click **Add** to set up a location. In the pop-up dialog, search for **Internal location - Agent**. Select the appropriate address and click **Add**. Click **Ok** to finish selecting the location. - - ![ss-2014-11-21T16-32-25.png](/media/articles/monitoring/ss-2014-11-21T16-32-25.png) - - Click **Next** to continue. - -4. Set the frequency with which SCOM collects data from each endpoint: - - * **Test frequency**: 60 seconds - * **Performance data collection interval**: 60 seconds - * **Test time-out**: 30 seconds - - Additionally, under the *Alerts* section, **check** the box next to *HTTP status code* and set that to **Great than or equals 400**. - - ![ss-2014-11-21T16-33-51.png](/media/articles/monitoring/ss-2014-11-21T16-33-51.png) - - Click **Next** to continue. - -5. 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) - -Once you have finished configuring your SCOM instance, you can activity through the **Monitoring** tab: - -![ss-2014-11-25T17-20-47.png](/media/articles/monitoring/ss-2014-11-25T17-20-47.png) - -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) diff --git a/articles/monitoring/index.md b/articles/monitoring/index.md index 9aa852e88c..7fd1ac6b73 100644 --- a/articles/monitoring/index.md +++ b/articles/monitoring/index.md @@ -1,40 +1,46 @@ --- -title: Monitoring Auth0 -description: Monitoring Your Auth0 Implementation -classes: topic-page +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 -
    -
    -

    Monitor Your Auth0 Implementation

    -

    - Learn how to monitor your Auth0 implementation and track your Auth0 usage, as well as how to send logs to your choice of logging suite. -

    -
    - - \ No newline at end of file +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/articles/monitoring/sending-events-to-keenio.md b/articles/monitoring/sending-events-to-keenio.md deleted file mode 100644 index 88c1bdeb97..0000000000 --- a/articles/monitoring/sending-events-to-keenio.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -description: How to send events to Keen IO from Auth0. ---- -# Sending events to Keen IO from Auth0 - -[Keen IO](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. - -This example shows how you can very easily connect Auth0 to __Keen IO__ and stream `signup` events. - -Implementing this with Auth0 is very easy, only taking a few lines of code. - -![Keen IO Dataflow](/media/articles/tutorials/keen-io-dataflow.png) - -## Recording a SignUp event in Keen IO - -This rule checks whether the user has already signed up before or not. This is tracked by the `user.signedUp` property. If the property is present then we assume return immediately, otherwise we assume a new `signup`. - -```js -function(user, context, callback) { - - if(user.signedUp){ - return callback(null, user, context); - } - - var writeKey = 'YOUR KEEN IO WRITE KEY'; - var projectId = 'YOUR KEEN IO 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 + '?api_key=' + writeKey, - headers: { - '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); - }); -} -``` - -::: note -Notice that if all calls are successful, we signal the user as signed up. So next time we skip the entire rule. -::: - -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), [Rapleaf](http://rapleaf.com), [Parse](http://parse.com) diff --git a/articles/monitoring/sending-events-to-segmentio.md b/articles/monitoring/sending-events-to-segmentio.md deleted file mode 100644 index 2e1a879c0d..0000000000 --- a/articles/monitoring/sending-events-to-segmentio.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -description: How to send events to segment.io from Auth0 ---- -# Send Auth0 Events to Segment - -[Segment](http://segment.io/features) provides a large number of analytics-related functionality with a single, simple to use API. - -This example shows how you can connect Auth0 to Segment and stream `signup` and `login` events. You'll be using [Segment's Node.js library](https://github.com/segmentio/analytics-node) to record Auth0 data. - -![Segment Flow](/media/articles/monitoring/segment/segment-io-dataflow.png) - -## Find your Segment Write Key - -To configure this integration, you'll need your Segment **Write Key**. You can find this under **Settings** > **API**. - -![Segment API Keys](/media/articles/monitoring/segment/segment-3.png) - -## Record sign up and login events - -To record Auth0 signup and login events and send the information to Segment, you will create a [rule](/rules) implementing Segment's Node.js library. - -::: note -Be sure to add your **Write Key** to the [Global Configuration Object](/rules#using-the-configuration-object) prior to running your rule. -::: - -```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); - }); -} -``` - -## Check your integration - -To see if your integration works, you can check the Segment Debugger to see if your Auth0 events are appearing. - -![Segment Debugger](/media/articles/monitoring/segment/segment-14.png) diff --git a/articles/monitoring/sending-events-to-splunk.md b/articles/monitoring/sending-events-to-splunk.md deleted file mode 100644 index d018551b7c..0000000000 --- a/articles/monitoring/sending-events-to-splunk.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -description: How to send events from Auth0 to Spunk. ---- -# Sending Events from Auth0 to Splunk - -[Splunk](http://splunk.com) provides a platform to easily get insights into all the information generated by your IT infrastructure. - -This example shows how you can very easily connect Auth0 to Splunk and stream `signup` and `login` events with user contextual information. - -![](/media/articles/tutorials/splunk-dataflow.png) - -## Record a SignUp or Login Event in Splunk - -This [Auth0 rule](/rules) uses the [Splunk REST API](http://dev.splunk.com/view/rest-api-overview/SP-CAAADP8) to record `signup` and `login` events from users to your apps. This is tracked with the `signedUp` property. If the property is present, then we assume this is a `login` event. Otherwise we assume that this event is a new `signup`. - -You can send any number of properties. This sample sends contextual information like the user IP address (can be used for location), the application, the username, and so on. - -Splunk's API supports basic & token based auth. For simplicity, we use basic auth, with credentials in the rule. You can store these credentials securely in Auth0 using standard settings on the dashboard. - -When enabled, this rule will start sending events that will show up on Splunk's dashboard: - -![](/media/articles/scenarios/splunk/splunk-dashbaord.png) - -::: panel Securely Storing Credentials -This example has your Splunk credentials hard-coded into the rule, but if you prefer, you can store them instead in the `configuration` object (see the [Settings](${manage_url}/#/rules) under the list of your rules). This allows you to use those credentials in multiple rules if you require, and also prevents you from having to store them directly in the code. -::: - -```js -function(user, context, callback) { - user.app_metadata = user.app_metadata || {}; - var splunkBaseUrl = 'YOUR SPLUNK SERVER, like: https://your server:8089'; - - //Add any interesting info to the event - var 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 - }; - - request.post( { - url: splunkBaseUrl + '/services/receivers/simple', - auth: { - 'user': 'YOUR SPLUNK USER', - 'pass': 'YOUR SPLUNK PASSWORD', - }, - json: event, - qs: { - 'source': 'auth0', - 'sourcetype': 'auth0_activity' - } - }, function(e,r,b) { - if (e) return callback(e); - if (r.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); - }); - }); -} -``` - -::: note -Notice that if all calls are successful, we signal the user as signed up. So next time we record `login`. -::: - -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), [Rapleaf](http://rapleaf.com), [Parse](http://parse.com) diff --git a/articles/monitoring/track-signups-enrich-user-profile-generate-leads.md b/articles/monitoring/track-signups-enrich-user-profile-generate-leads.md deleted file mode 100644 index 8664908dbb..0000000000 --- a/articles/monitoring/track-signups-enrich-user-profile-generate-leads.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -description: How to track sign-ups, enrich user profiles and generate new leads. ---- - -# How to track Sign-ups, enrich User Profile and generate new Leads - -Upon a signup of a new user to a website with any social credential, we want to: - -1. Record a __SignUp__ event on [MixPanel](https://mixpanel.com). -2. __Augment the user profile__ with additional public information through [FullContact](http://www.fullcontact.com/). -3. Record the new signup as a __New Lead__ on [Salesforce](http://www.salesforce.com/) for follow-up. - -Implementing this with Auth0 is very easy. You just need 3 [Rules](/rules) in your pipeline: - -![](/media/articles/tutorials/signups.png) - -## 1. Recording a SignUp in MixPanel - -This first rule checks whether the user has already signed up. If they have, it simply skips everything. If not, it calls __MixPanel__ to record the event. In the example below we are simply using a property `application` that you can then use in MixPanel to filter information. But the full `context` and `user` properties are available as sources of more information (such as IP addresses, agent, and so on.). - -We also call this event `Sign Up`: - -```js -function (user, context, callback) { - - if(user.signedUp) return callback(null,user,context); - - var mixPanelEvent = { - "event": "Sign Up", - "properties": { - "distinct_id": user.user_id, - "token": YOUR_MIXPANEL_TOKEN, - "application": context.clientName - } - }; - - var base64Event = new Buffer(JSON.stringify(mixPanelEvent)).toString('base64'); - - request('http://api.mixpanel.com/track/?data=' + base64Event, - function(e,r,b){ - if(e) return callback(e); - return callback(null,user,context); - }); -} - -``` - -## 2.Augment User Profile with FullContact - -The 2nd step is to obtain more information about this user using their email address. __FullContact__ provides an API to retrieve public information about a user using the email as input. We store this additional information in a property called `fullContactInfo`: - -:::note -We are ignoring certain conditions that exist in the API and only doing this when there's a successful call (`statusCode=200`). -::: - -```js -function (user, context, callback) { - - if(user.signedUp) return callback(null,user,context); - - var fullContactAPIKey = 'YOUR FULLCONTACT API KEY'; - - if(user.email){ - request('https://api.fullcontact.com/v2/person.json?email=' + encodeURIComponent(user.email) + '&apiKey=' + fullContactAPIKey, - function(e,r,b){ - if(e) return callback(e); - if(r.statusCode===200){ - user.fullContactInfo = JSON.parse(b); - } - return callback(null, user, context); - }); - } - else{ - return callback(null, user, context); - } -} -``` - -## 3. Create a New Lead in Salesforce - -In the last step we record the information as a __New Lead__ in Salesforce, so the sales department can followup. This __Rule__ has some interesting things: - -1. The Salesforce REST API uses an OAuth `access_token`. We are using the OAuth2 `Resource Owner Password Credential Grant` to obtain such `access_token`. This is the `getToken` function hat uses credentials as input as opposed to an `API-KEY` as the previous rules. -2. We are just recording the user name and a fixed company name. We would of course us anything available in the enriched user profile we obtained in step 2, to record more information and have better context for the sales representative. -3. If everything went well, we use a __persistent__ property: `user.signedUp` and set it to `true`. So next time this same users logs in, none of these rules will do anything. - -```js -function (user, context, callback) { - - if(user.signedUp) return callback(null,user,callback); - - getAccessToken(SFCOM_CLIENT_ID, SFCOM_CLIENT_SECRET, USERNAME, PASSWORD, - function(e,r){ - if( e ) return callback(e); - - createLead(r.instance_url, r.access_token, function(e,result){ - if(e) return callback(e); - //Everyhting worked fine. We signal this signup was succesful. - user.persistent.signedUp = true; - return callback(null,user,context); - }); - }); - - function createLead(url,access_token, callback){ - - //Just a few fields. The Lead object is much richer - var data = { - LastName: user.name, - Company: 'Web channel signups' - }; - - request.post({ - url: url + "/services/data/v20.0/sobjects/Lead/", - headers: { - "Authorization": "OAuth " + access_token, - "Content-type": "application/json" - }, - body: JSON.stringify(data) - }, function(e,r,b){ - if(e) return callback(e); - return callback(null,b); - }); - } - - 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 - }}, function(e,r,b){ - if(e) return callback(e); - return callback(null,JSON.parse(b)); - }); - } -} -``` - -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), [Rapleaf](http://rapleaf.com) diff --git a/articles/monitoring/tracking-new-leads-in-salesforce-and-raplead.md b/articles/monitoring/tracking-new-leads-in-salesforce-and-raplead.md deleted file mode 100644 index 5865b036f2..0000000000 --- a/articles/monitoring/tracking-new-leads-in-salesforce-and-raplead.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -description: How to track new leads in Salesforce and augment user profile with Rapleaf. ---- - -# Tracking new leads in Salesforce, augmenting user profile with RapLeaf - -Upon a signup of a new user to a website with any social credential, we want to: - -1. __Augment the user profile__ with additional public information through [RapLeaf](http://www.rapleaf.com/). -2. Record the new signup as a __New Lead__ on [Salesforce](http://www.salesforce.com/) for follow-up. - -Implementing this with Auth0 is very easy. You just need 2 [Rules](/rules) in your pipeline: - -![](/media/articles/tutorials/rapleaf-salesforce.png) - -## 1. Augment User Profile with RapLeaf - -The 1st step is to obtain more information about this user using their email address. __RapLeaf__ provides an API to retrieve public information about a user using the email as input that is extremely easy to use. - -Once the call to RapLeaf completes, we store this additional information in a property called `rapLeafData`: - -:::note -We are ignoring certain conditions that exist in the API and only doing this when there's a successful call (`statusCode=200`). The entire rule is ignored if the user has already signed up (signaled by the `user.signedUp` property setup after recording a new lead in step 2 below). -::: - -```js -function (user, context, callback) { - - if(user.signedUp) return callback(null,user,callback); - - var rapLeafAPIKey = 'YOUR RAPLEAF API KEY'; - - if(user.email){ - request('https://personalize.rapleaf.com/v4/dr?email=' + - encodeURIComponent(user.email) + - '&api_key=' + rapLeafAPIKey, - function(e,r,b){ - if(e) return callback(e); - - if(r.statusCode===200){ - user.rapLeafData = JSON.parse(b); - } - - return callback(null,user,context); - }); - } - else { - return callback(null,user,context); - } -} -``` - -## 2. Create a New Lead in Salesforce - -In this second step we record the information as a __New Lead__ in Salesforce, so the sales department can followup. This __Rule__ has some interesting things: - -1. The Salesforce REST API uses an OAuth `access_token`. We are using the OAuth2 `Resource Owner Password Credential Grant` to obtain such `access_token`. This is the `getToken` function that uses credentials as input as opposed to an `API-KEY` as the previous rule. -2. We are just recording the user name and a fixed company name. We could of course use anything available in the enriched user profile we obtained in step 1, to record more information, and have better context for the sales representative. -3. If everything went well, we use a __persistent__ property: `user.signedUp` and set it to `true`. So next time this same users logs in, these rules will be skipped. - -```js -function (user, context, callback) { - - if(user.signedUp) return callback(null, user, callback); - - getAccessToken(SFCOM_CLIENT_ID, SFCOM_CLIENT_SECRET, USERNAME, PASSWORD, - function(err, response){ - if(err) return callback(err); - - createLead(response.instance_url, response.access_token, function(err, result){ - if(err) return callback(err); - //Everyhting worked fine. We signal this signup was successful. - user.persistent.signedUp = true; - return callback(null, user, context); - }); - }); - - function createLead(url, access_token, callback){ - - //Just a few fields. The Lead object is much richer. - var data = { - LastName: user.name, - Company: 'Web channel signups' - }; - - request.post({ - url: url + "/services/data/v20.0/sobjects/Lead/", - headers: { - "Authorization": "OAuth " + access_token, - "Content-type": "application/json" - }, - body: JSON.stringify(data) - }, function(err, response, body){ - if(err) return callback(err); - return callback(null,body); - }); - } - - //Helper function to get an access_token from Salesforce - 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 - }}, function(e,r,b){ - if(e) return callback(e); - return callback(null,JSON.parse(b)); - }); - } -} -``` -That's it! - -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) diff --git a/articles/multifactor-authentication/administrator/customizing-widget.md b/articles/multifactor-authentication/administrator/customizing-widget.md deleted file mode 100644 index 4daa025010..0000000000 --- a/articles/multifactor-authentication/administrator/customizing-widget.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -description: How to Customize the Guardian Widget ---- -# Customizing the Guardian Screen - -You may change the logo and the friendly name that is displayed to your users. To do so, make the appropriate changes to the Guardian page's settings on the **General** tab in [Tenant Settings](${manage_url}/#/tenant). You can also reach the Tenant Settings page by clicking on your tenant name on the top right of the page and then selecting **Settings** from the dropdown menu. - -![](/media/articles/mfa/guardian-logo-and-name-settings.png) - -* **Friendly Name**: the name of the app that you want displayed to users -* **Logo URL**: the URL that points to the logo image you want displayed to users - -## Customizing the Guardian Landing Page - -### Activate the Hosted Page - -Customizing the content of the Guardian widget page is possible in the [Guardian Multifactor Hosted Page](${manage_url}/#/guardian_mfa_page) by toggling __Customize Guardian Page__. - -![](/media/articles/mfa/guardian-mfa-hosted-page.png) - -### Theming Options - -There are a few theming options for 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 - 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 - theme: { - icon: 'https://example.com/assets/logo.png', - primaryColor: 'blue' - }, -``` - -### Rendering "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 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). diff --git a/articles/multifactor-authentication/administrator/disabling-mfa.md b/articles/multifactor-authentication/administrator/disabling-mfa.md deleted file mode 100644 index 0f91dea20c..0000000000 --- a/articles/multifactor-authentication/administrator/disabling-mfa.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -description: How to Disable Guardian and the other types of MFA. ---- -# Disable Guardian and other MFA - -Multifactor Authentication with Push Notifications (Guardian) and SMS can be disabled from the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. Toggle the slider to disable each type. - -![Toggle Guardian](/media/articles/mfa/disable-guardian.png) - -A confirmation popup will appear confirming that you understand all customizations will be lost and that this action cannot be reverted. - -## Disable Google Authenticator or Duo - -To disable Google Authenticator or Duo, click on the configure link on the bottom of the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard, which will bring you to the [MFA configuration page for Google Authenticator and Duo](${manage_url}/#/multifactor). Then toggle the slider to disable the MFA type you wish to disable. - -![Toggle Other](/media/articles/mfa/disable-google-auth-duo.png) - -A confirmation popup will appear confirming that you understand all customizations will be lost. diff --git a/articles/multifactor-authentication/administrator/guardian-enrollment-email.md b/articles/multifactor-authentication/administrator/guardian-enrollment-email.md deleted file mode 100644 index 7626f634c8..0000000000 --- a/articles/multifactor-authentication/administrator/guardian-enrollment-email.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -description: Send an enrollment email (Guardian) ---- -# Sending a Guardian Enrollment Email to a User - -With this, an administrator can send an email to a user with a link for registering their device with Guardian. - -To send this email: - -1. Find and select the user in the [Users](${manage_url}/#/users) section of the dashboard. -2. Click on the **Actions** button on the top right of the screen. -3. Select **Send Enrollment Email (Guardian)** from the dropdown. - - ![](/media/articles/mfa/guardian-send-enrollment-email.png) - -The user will receive an enrollment email at their registered email address. - - ![](/media/articles/mfa/enrollment-email.png) - -Administrators can also [customize the email template](/email/templates) for the enrollment emails. - -## Restricting user-initiated enrollments - -Some organizations may want to only allow users to enroll a device with Guardian via an enrollment email, and prevent users from self-enrolling upon first sign in. This is possible using the _selfServiceEnrollment_ property on a Guardian rule. When set to true, or when the property is not set, the user may self-enroll. When set to false, the user may only enroll their device via an enrollment email. - -To edit the rule, go to the **Multifactor Auth** section and edit appropriately. - -```js -function (user, context, callback) { - - context.multifactor = { - provider: 'guardian', - selfServiceEnrollment: false, - }; - - callback(null, user, context); -} -``` diff --git a/articles/multifactor-authentication/administrator/guardian-for-select-clients.md b/articles/multifactor-authentication/administrator/guardian-for-select-clients.md deleted file mode 100644 index be8a633bc0..0000000000 --- a/articles/multifactor-authentication/administrator/guardian-for-select-clients.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -description: Guardian for Select Applications ---- -# Customize MFA for Select Applications - -Once you have enabled either MFA option, you will be presented with the **Customize MFA** code snippet that allows advanced configuration of Guardian's behavior via [Rules](/rules). One option is to apply Guardian authentication only to a subset of your applications. - -By default, Auth0 enables Guardian for all applications. - -```js -function (user, context, callback) { - - var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; - - // Apply Guardian only for the specified applications - if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { - context.multifactor = { - provider: 'guardian', //required - }; - } - - callback(null, user, context); -} -``` - -If you choose to selectively apply multifactor authentication, you simply set the appropriate `clientID` values, and the code will be executed as part of a [Rule](/rules) whenever a user logs in. - -Once you have finished making your desired changes, click **Save**. diff --git a/articles/multifactor-authentication/administrator/guardian-for-select-users.md b/articles/multifactor-authentication/administrator/guardian-for-select-users.md deleted file mode 100644 index 971dead311..0000000000 --- a/articles/multifactor-authentication/administrator/guardian-for-select-users.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -description: Guardian for Select Users ---- -# Customize MFA for Select Users - -Once you have enabled either MFA option, you will be presented with the **Customize MFA** code snippet that allows advanced configuration of Guardian's behavior via [Rules](/rules). One option is to apply Guardian authentication only to a subset of your applications. - -By default, Auth0 enables Guardian for all applications. - -```js -function (user, context, callback) { - - var USERS_WITH_MFA = ['REPLACE_WITH_YOUR_USER_ID']; - - // Apply Guardian only for the specified users - if (USERS_WITH_MFA.indexOf(user.user_id) !== -1) { - context.multifactor = { - provider: 'guardian' - }; - } - - callback(null, user, context); -} -``` - -If you choose to selectively apply multifactor authentication, you simply set the appropriate `user_id` values, and the code will be executed as part of a [Rule](/rules) whenever a user logs in. - -Once you have finished making your desired changes, click **Save**. diff --git a/articles/multifactor-authentication/administrator/guardian-logs.md b/articles/multifactor-authentication/administrator/guardian-logs.md deleted file mode 100644 index f24252843c..0000000000 --- a/articles/multifactor-authentication/administrator/guardian-logs.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -description: Guardian Logging ---- -# Tracking your Users' MFA Events - -In the [Logs](${manage_url}/#/logs) section of the dashboard, you can see the various events related to your users signing up and signing in using MFA. - -![](/media/articles/mfa/logs.png) - -Here are all the possible events related to MFA: - -| Event Type | Description | -| --- | --- | -| `gd_unenroll` | When a device account is deleted | -| `gd_update_device_account` | When a device account is updated | -| `gd_send_pn` | When a push notification is sent | -| `gd_send_sms` | When a SMS is sent | -| `gd_start_auth` | Start second factor authentication | -| `gd_start_enroll` | Second factor auth enrollment is started | -| `gd_module_switch` | When changing feature config | -| `gd_tenant_update` | When tenant info has been updated | -| `gd_user_delete` | When calling (user delete => unenroll) | -| `gd_auth_failed` | When second factor login has failed | -| `gd_auth_succeed` | When second factor authentication has succeeded | -| `gd_recovery_succeed` | Recovery succeeded | -| `gd_recovery_failed` | Failed recovery | -| `gd_otp_rate_limit_exceed` | When One Time Password fails validation because rate limit is exceeded | -| `gd_recovery_rate_limit_exceed` | When recovery validation fails because rate limit is exceeded | - -These events can also be searched using the [Management APIv2](/api/management/v2#!/Logs) using [query string syntax](/api/management/v2/query-string-syntax). You can search criteria using the `q` parameter or you can search by a specific log ID. - -## Examples searching with the `q` parameter - -To see the events for users who are enrolling with MFA: - -`type: gd_start_enroll` - -To see all the times an SMS is sent: - -`type: gd_send_sms` diff --git a/articles/multifactor-authentication/administrator/index.md b/articles/multifactor-authentication/administrator/index.md deleted file mode 100644 index de0d47ba03..0000000000 --- a/articles/multifactor-authentication/administrator/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -description: How to enable and use Push Notifications and SMS for Guardian MFA. ---- - -# Guardian for Administrators - -Guardian is Auth0's multifactor authentication solution that provides a simple and secure way to implement MFA. When using Guardian with Auth0, users will be prompted for additional authentication from the Guardian mobile application, helping to provide a more secure login. - -This page contains information on how to enable and configure Guardian as an administrator. Information geared toward developers and users can be found under [additional documents](#additional-documents). - -## Guardian Basics -* [Guardian Push Notifications](/multifactor-authentication/administrator/push-notifications) -* [Guardian SMS Notifications](/multifactor-authentication/administrator/sms-notifications) - * [Configuring your Twilio Account](/multifactor-authentication/administrator/twilio-configuration) - * [Customize your text messages](/multifactor-authentication/administrator/sms-templates) -* [Turning off Guardian](/multifactor-authentication/administrator/disabling-mfa) - -## Managing Users -* [Applying Guardian to Specific Users](/multifactor-authentication/administrator/guardian-for-select-users) -* [Sending Guardian Enrollment Emails](/multifactor-authentication/administrator/guardian-enrollment-email) -* [Resetting Guardian Credentials](/multifactor-authentication/administrator/reset-user) -* [Guardian logs](/multifactor-authentication/administrator/guardian-logs) - -## Customization -* [Customize the Guardian Widget](/multifactor-authentication/administrator/customizing-widget) -* [Advanced Customization of the Guardian Widget](https://github.com/auth0/auth0-guardian.js/tree/master/example) -* [Customizing Guardian Rules and Behavior](/multifactor-authentication/custom) - - -## Additional Documents -* [Guardian for Developers](/multifactor-authentication/developer) -* [Guardian for Users](/multifactor-authentication/guardian/user-guide) diff --git a/articles/multifactor-authentication/administrator/push-notifications.md b/articles/multifactor-authentication/administrator/push-notifications.md deleted file mode 100644 index 90694a12c5..0000000000 --- a/articles/multifactor-authentication/administrator/push-notifications.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -description: How to enable and use push notifications for Guardian. ---- -# Guardian Push Notifications - -To enable Push Notifications for Guardian for your users, go to the [Multifactor Auth](${manage_url}/#/guardian) section of the Auth0 dashboard. Then toggle the **Push Notification** slider to enable it. - -![](/media/articles/mfa/guardian-dashboard.png) - -New users signing up will be prompted to download the Guardian app from either the App Store or Google Play. Once they indicate that they downloaded the app, a code will appear. They will have five minutes to scan the code with the app before it expires. After the code has been successfully scanned, users will see a confirmation screen which includes a recovery code. They need to have this recovery code to login without their mobile device. If they lose both the recovery code and their mobile device, you will need to [reset their MFA](#reset-an-mfa-for-a-user). Then they will receive a push notification to their device and they will be logged in. - -Users that were previously registered before you enabled MFA will need to complete the same process as new users on their next login. diff --git a/articles/multifactor-authentication/administrator/reset-user.md b/articles/multifactor-authentication/administrator/reset-user.md deleted file mode 100644 index 68c1c21288..0000000000 --- a/articles/multifactor-authentication/administrator/reset-user.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -description: Reset a User's MFA ---- -# Resetting a User's multifactor account - -If a user has lost their mobile device they can use their recovery code to log in. If they do not have recovery code, they will need their tenant administrator to reset their multifactor. - -To reset a user's multifactor authentication: - -1. Find and select the user in the [Users](${manage_url}/#/users) section of the dashboard. -2. Once you have selected the affected user, click on the **Actions** button on the top right of the screen. -3. Select **Reset Multifactor Authentication** from the dropdown. -4. There will be a pop up box to confirm your decision. Click **YES, RESET IT** to reset the user's MFA. - - ![](/media/articles/mfa/reset-mfa.png) - -The next time the user logs in they will need to setup their MFA just like a new user. diff --git a/articles/multifactor-authentication/administrator/sms-notifications.md b/articles/multifactor-authentication/administrator/sms-notifications.md deleted file mode 100644 index 5421a85c58..0000000000 --- a/articles/multifactor-authentication/administrator/sms-notifications.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -description: How to enable and use push notifications for Guardian. ---- -# SMS notifications - -You can enable SMS messages to use as a form of multifactor authentication. This is also under the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. By toggling the **SMS** slider, you can enable using SMS for sign in and sign up for your application. SMS can be used as your only form of MFA or in addition to Push Notifications. - -Your users must have a device capable of using SMS to use this option. If your users are unable to always receive SMS messages (such as when traveling), they will be unable sign up with SMS and unable to log in without the recovery code. - -When your users sign up with SMS, they enter their phone number's country code and mobile phone number. - -![](/media/articles/mfa/sms.png) - -After sign up, they receive a six digit code to their phone. They need to enter this code into the box, and then they will get a recovery code. They will need this code to login if they do not have their device. If they have lost their recovery code and device, you will need to [reset the user's MFA](/multifactor-authentication/administrator/reset-user). diff --git a/articles/multifactor-authentication/administrator/sms-templates.md b/articles/multifactor-authentication/administrator/sms-templates.md deleted file mode 100644 index ecea14b661..0000000000 --- a/articles/multifactor-authentication/administrator/sms-templates.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -description: Customize SMS Messages ---- - -# Customize SMS Messages - -To customize the SMS messages sent by Auth0 during enrollment (when associating a device to Guardian) or verification (when an authentication message is sent to the device), do the following: - -First, go to ([Multifactor Auth With Guardian](${manage_url}/#/guardian), then click on the **SMS** box to configure your SMS settings. - -![](/media/articles/mfa/sms-config.png) - -You have two fields to customize your messages: -* **Enrollment Template**: the message sent by Auth0 during device enrollment. -* **Verification Template**: the message sent by Auth0 to verify the possession of the device. - -[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: -* `code`: The Enrollment/Verification code. -* `requestInfo.lang`: The browser language (ie, `es-AR,es;q=0.8`, `en-US,en`, and so on.). -* `tenant.friendlyName`: The **Friendly Name** set in [Tenant Settings](${manage_url}/#/tenant). diff --git a/articles/multifactor-authentication/administrator/twilio-configuration.md b/articles/multifactor-authentication/administrator/twilio-configuration.md deleted file mode 100644 index ea2d015252..0000000000 --- a/articles/multifactor-authentication/administrator/twilio-configuration.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -description: Configuring Twilio for Guardian ---- - -# Configuring Twilio for Guardian SMS - -When initially setting up SMS, you have up to 100 SMS to be used for testing. This limit can be removed by setting up a Twilio account. To prevent malicious login attempts, your users will always be limited to up to 10 SMS/Hour (replenishing one message an hour, up to 10). - -Click on the **SMS** box to configure your SMS settings. - -![](/media/articles/mfa/sms-config.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 an SMS to the user. You may also need to enable permissions for your [geographic region](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work). - -## 2. Configure the connection - -Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields. - -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 of the SMS. You may also configure this in Twilio. - -* If you choose **Use Copilot **, you will need to enter a [Copilot SID](https://www.twilio.com/docs/api/rest/sending-messages-copilot). - -Click **SAVE**. diff --git a/articles/multifactor-authentication/api/_authenticator-before-start.md b/articles/multifactor-authentication/api/_authenticator-before-start.md deleted file mode 100644 index 282bd635df..0000000000 --- a/articles/multifactor-authentication/api/_authenticator-before-start.md +++ /dev/null @@ -1,6 +0,0 @@ -## Before you start - -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. -* Create a rule that sets Guardian as the MFA provider. For more information, see [Guardian for Administrators](/multifactor-authentication/administrator). \ No newline at end of file diff --git a/articles/multifactor-authentication/api/challenges.md b/articles/multifactor-authentication/api/challenges.md deleted file mode 100644 index 6aab03043c..0000000000 --- a/articles/multifactor-authentication/api/challenges.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Associate a New Authenticator for Use with Multifactor Authentication -description: How to associate a new authenticator for use with MFA using the new MFA API endpoints ---- -# Multifactor Authentication Challenges - -You can trigger MFA challenges for enrolled authenticators by calling the `/mfa/challenge` endpoint. - -## OTP Challenges - -To trigger an OTP challenge, make the appropriate `POST` call to `mfa/challenge`. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/mfa/challenge", - "postData": { - "mimeType": "application/json", - "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"challenge_type\": \"otp\", \"mfa_token\": \"Fe26.2**05...\" }" - } -} -``` - -If successful, you'll receive the following response: - -```json -{ - "challenge_type": "otp" -} -``` - -Proceed with the authentication process as usual. - -## OOB Challenges - -To trigger an OOB challenge, make the appropriate `POST` call to `mfa/challenge`. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/mfa/challenge", - "postData": { - "mimeType": "application/json", - "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"challenge_type\": \"oob\", \"authenticator_id\": \"sms|dev_s...O\", \"mfa_token\": \"Fe26.2**05...\" }" - } -} -``` - -If successful, you'll receive the following response, as well as an SMS message containing the required six-digit code: - -```json -{ - "challenge_type": "oob", - "oob_code": "asdae35fdt5...oob_code_redacted", - "binding_method": "prompt" -} -``` - -Proceed with the authentication process as usual. - -## Posting the MFA Responses - -You can post MFA OTP or MFA OOB responses using the `/oauth/token` endpoint. \ No newline at end of file diff --git a/articles/multifactor-authentication/api/faq.md b/articles/multifactor-authentication/api/faq.md deleted file mode 100644 index 27c7f6d579..0000000000 --- a/articles/multifactor-authentication/api/faq.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Multifactor Authentication API FAQ -description: Frequently asked questions about MFA and its API ---- - -# FAQ: MFA and the MFA API - -The following is a list of frequently-asked questions about multifactor authentication (MFA) and Auth0's MFA API. - -## When can I self-associate authenticators during the authorization process? - -You can self-associate authenticators if you don't have any active authenticators. If there are one or more active authenticators, you cannot self-associate a new authenticator. - -## With push notifications, why do I get two authenticators instead of one? - -Push notifications have two authenticators. One to trigger the push notification and the other for a time-based one-time password (TOTP). The TOTP authenticator lets you authenticate if you are offline or can't receive the push notification. - -## Why can I associate more than one authenticator with a particular end user? - -Associating multiple authenticators with a user can provide flexibility for the user. - -For example, a user may enable push notifications on their phone and TOTP codes on their computer. If the user is unable to use one of the devices, they can use the other (and not have to rely on the recovery code). - -## When should I use self-association during authorization vs. association outside the authorization process? - -You can self-associate during the authorization process if there are no active authenticators. Associating authenticators outside the authorization process (generally used to add additional authenticators) requires additional programming, such as the use of [rules](/rules). - -## What happens if I delete an authenticator? - -If you delete an authenticator and have multiple authenticators associated, you can use the remaining authenticators. - -If you delete a push authenticator, the associated one-time password (OTP) authenticator is also deleted. If you delete the OTP authenticator, the associated push authenticator is deleted. - -Recovery codes can only be deleted by an administrator using the [Management API](/multifactor-authentication/api/manage#delete-authenticators). - -## If I'm using Guardian, what happens if I delete one of the authenticators? - -Guardian behaves as you'd expect when deleting authenticators. If you delete the push notification authenticator, Guardian removes both it and the OTP authenticator. \ No newline at end of file diff --git a/articles/multifactor-authentication/api/index.md b/articles/multifactor-authentication/api/index.md deleted file mode 100644 index bf554533f5..0000000000 --- a/articles/multifactor-authentication/api/index.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Multifactor Authentication API -description: Overview of available multifactor authentication APIs ---- - -# Multifactor Authentication API - -The Multifactor Authentication (MFA) API endpoints allow you to enforce MFA when users interact with [the Token endpoints](/api/authentication#get-token), as well enroll and manage user authenticators. - -## Multifactor authentication with the Token endpoint - -We have expanded MFA support on the Token endpoints to cover the following use cases: - -* Use MFA with the [password](/api-auth/grant/password), [password-realm](/api-auth/grant/password#realm-support), and [refresh-token](/tokens/refresh-token/current#use-a-refresh-token) grants. -* Completion of first-time enrollment by users during authentication. -* Selection of the desired MFA authenticator by the user before they execute the MFA challenge. - -### More information - -* [Manually triggering MFA challenges](/multifactor-authentication/api/challenges) -* [Using one-time passwords as the MFA challenge](/multifactor-authentication/api/otp) -* [Using SMS messages as the MFA challenge](/multifactor-authentication/api/oob) -* [Tutorial: How to use MFA with the Resource Owner Password Grant](/api-auth/tutorials/multifactor-resource-owner-password) - -## Enrollment and management of user authenticators - -The MFA Associate API allows you to create, read, update, and delete authenticators. You can use this API to power user interfaces where users can manage MFA enrollments, or add and remove authenticators. - -This enables users to enroll more than one device and select a fallback MFA mechanism in case the primary one is not available. For example, your user might use OTP when their SMS network is not present or unresponsive. - -Check out [Manage Authenticators](/multifactor-authentication/api/manage) for more on listing or deleting authenticators. - -<%= include('./_authenticator-before-start') %> - -If you are using the MFA API in conjunction with the [Token endpoint](/api/authentication#get-token), you must meet the requirements of the corresponding grant. - -## Limitations - -* The MFA API is designed to work with the Guardian Provider. Support for other providers will be provided in future releases. - -* Support for authenticator selection is currently limited to the Token Endpoint. Auth0 is working to extend support to [Hosted MFA Pages](/hosted-pages/guardian. If users have more than one authenticator enrolled, the most-recently enrolled option will be used by the Hosted MFA Pages. \ No newline at end of file diff --git a/articles/multifactor-authentication/api/manage.md b/articles/multifactor-authentication/api/manage.md deleted file mode 100644 index 09bffa67aa..0000000000 --- a/articles/multifactor-authentication/api/manage.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Manage the Authenticators for Multifactor Authentication -description: How to manage your MFA authenticators ---- - -# Manage the Authenticators - -Auth0 provides several API endpoints to help you manage the authenticators you're using with an application for multifactor authentication (MFA). - -## Before you start - -The MFA endpoints require an [Access Token](/tokens/access-token) with: - -- `audience`: Set to `https://${account.namespace}/mfa` -- `scope`: Include `enroll` for enrollment, `read:authenticators` to list authenticators, and `remove:authenticators` to delete authenticators. - -For example: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "headers": [{ - "name": "Content-Type", "value": "application/json" - }], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"password\",\"username\": \"user@example.com\",\"password\": \"pwd\",\"audience\": \"https://${account.namespace}/mfa\", \"scope\": \"enroll read:authenticators remove:authenticators\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\"}" - } -} -``` - -## List Authenticators - -To get a list of the authenticators you've associated and can be used with your tenant, you can make the appropriate call to the `/mfa/authenticators` endpoint: - -```har -{ - "method": "GET", - "url": "https://${account.namespace}/mfa/authenticators", - "headers": [{ - "name": "Authorization", - "value": "Bearer ACCESS_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_channel": "sms", - "id": "sms|dev_sEe99pcpN0xp0yOO", - "name": "+1123XXXXX", - "active": true - } -] -``` - -## Delete Authenticators - -To delete an authenticator you've associated, send a delete request to the `/mfa/authenticators/AUTHENTICATOR_ID` endpoint (be sure to replace `AUTHENTICATOR_ID` with your authenticator ID). - -```har -{ - "method": "DELETE", - "url": "https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID", - "headers": [{ - "name": "Authorization", - "value": "Bearer ACCESS_TOKEN" - }] -} -``` - -If the authenticator was deleted, a 204 response is returned. diff --git a/articles/multifactor-authentication/api/oob.md b/articles/multifactor-authentication/api/oob.md deleted file mode 100644 index b2cd5210ef..0000000000 --- a/articles/multifactor-authentication/api/oob.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Associate an Out-of-Band Authenticator -description: Configure your application so users can self-associate out-of-band (OOB) authenticators. ---- - -# Associate an Out-of-Band Authenticator - -In this tutorial, you'll learn how to configure your application so users can self-associate out-of-band (OOB) authenticators. - -<%= include('./_authenticator-before-start') %> - -## 1. Get the MFA token - -When a user begins the authorization process without an active authenticator associated with their account, they will trigger the following MFA response when calling the `/oauth/token` endpoint: - -```json -{ - "error": "mfa_required", - "error_description": "Multifactor authentication required", - "mfa_token": "Fe26...Ha" -} -``` - -In the next step, use the MFA token (`mfa_token`) instead of the standard access token to request association of a new authenticator. - -## 2. Request association of the authenticator - -Next, make a `POST` request to the `/mfa/associate` endpoint to request association of your authenticator. Remember to use the MFA token from the previous step. - -To associate an authenticator where the challenge type is an SMS message containing a code the user provides, make the following `POST` request to the `/mfa/associate` endpoint. Be sure to replace the placeholder values in the payload body shown below as appropriate. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/mfa/associate", - "headers": [{ - "name": "Authorization", - "value": "Bearer MFA_API_ACCESS_TOKEN" - }], - "postData": { - "mimeType": "application/json", - "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"sms\"], \"phone_number\": \"+11...9\" }" - } -} -``` - -If successful, you'll receive a response like this: - -```json -{ - "authenticator_type": "oob", - "oob_channel": "sms", - "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ], - "oob_code": "ata6daXAiOi..." -} -``` - -### Recovery Codes - -If this is the first time you're associating an authenticator, you'll notice your response includes `recovery_codes`. This is used to access your account in the event that you lose access to the account or device used for your second factor authentication. These are one-time usable codes, and new ones are generated as necessary. - -## 3. Confirm the authenticator association - -Once you've associated an authenticator, **you must use it at least once to confirm the association**. - -You can check if an authenticator has been confirmed by calling the [`mfa/authenticators` endpoint](/multifactor-authentication/api/manage#list-authenticators). If confirmed, the value of `active` is `true`. - -To confirm the association of an authenticator using SMS messages for the MFA challenge, make a `POST` request to the `oauth/token` endpoint. Be sure to replace the placeholder values in the payload body shown below as appropriate. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "postData": { - "mimeType": "application/json", - "text": "{ \"client_id\": [\"YOUR_CLIENT_ID\"], \"grant_type\": \"http://auth0.com/oauth/grant-type/mfa-oob\", \"mfa_token\": \"YOUR_MFA_TOKEN\", \"oob_code\": \"ata...i0i\", \"binding_code\": \"000000\" }" - } -} -``` - -If your call was successful, you'll receive a response like this: - -``` -{ - "access_token": "eyJ...i", - "expires_in": 600, - "scope": "enroll read:authenticators remove:authenticators", - "token_type": "Bearer" -} -``` - -At this point, your authenticator is fully associated and ready to be used. \ No newline at end of file diff --git a/articles/multifactor-authentication/api/otp.md b/articles/multifactor-authentication/api/otp.md deleted file mode 100644 index 173d98add6..0000000000 --- a/articles/multifactor-authentication/api/otp.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Associate a One-Time Password Authenticator -description: Configure your application so users can self-associate one-time password (OTP) authenticators. ---- - -# Associate a One-Time Password Authenticator - -In this tutorial, you'll learn how to configure your application so users can self-associate one-time password (OTP) authenticators. - -<%= include('./_authenticator-before-start') %> - -## 1. Get the MFA Token - -When a user begins the authorization process without an active authenticator associated with their account, they will trigger the an `mfa_required` error when calling the `/oauth/token` endpoint. For example: - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"password\",\"username\": \"user@example.com\",\"password\": \"pwd\",\"audience\": \"https://someapi.com/api\", \"scope\": \"read:sample\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\"}" - } -} -``` - -The `mfa_required` error will look like this: - -```json -{ - "error": "mfa_required", - "error_description": "Multifactor authentication required", - "mfa_token": "Fe26...Ha" -} -``` - -In the next step, use the `mfa_token` value instead of the standard Access Token to request association of a new authenticator. - -## 2. Request association of the authenticator - -Next, make a `POST` request to the `/mfa/associate` endpoint to request association of your authenticator. Remember to use the `mfa_token` from the previous step. - -To associate an authenticator where the challenge type is an OTP code the user provides, make the following `POST` request to the `/mfa/associate` endpoint. Be sure to replace the placeholder values in the payload body shown below as appropriate. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/mfa/associate", - "headers": [{ - "name": "Authorization", - "value": "Bearer ACCESS_TOKEN" - }], - "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...period=30", - "recovery_codes": [ "N3B...XC"] -} -``` - -In the next step, you'll need the one-time password (`otp`), which can be obtained by using the `barcode_uri` to generate a QR code that can be scanned by the OTP generator of your choice (such as Guardian). - -You might also consider displaying the `secret` in plain text so that your users can copy and paste it directly into the OTP generator (this is especially helpful for users on desktop applications). - -### Recovery Codes - -If this is the first time you're associating an authenticator, you'll notice that your response includes `recovery_codes`. This is used to access your account in the event that you lose access to the account or device used for your second factor authentication. These are one-time usable codes, and new ones are generated as necessary. - -## 3. Confirm the authenticator association - -Once you've associated an authenticator, **you must use it at least once to confirm the association**. - -You can check if an authenticator has been confirmed by calling the [`mfa/authenticators` endpoint](/multifactor-authentication/api/manage#list-authenticators). If confirmed, the value of `active` is `true`. - -To confirm the association of an authenticator using OTP, make a `POST` request to the `oauth/token` endpoint with the `otp` (from the previous step after turning the `barcode_uri` into a QR code). - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "postData": { - "mimeType": "application/json", - "text": "{ \"client_id\": [\"YOUR_CLIENT_ID\"], \"grant_type\": \"http://auth0.com/oauth/grant-type/mfa-otp\", \"mfa_token\": \"YOUR_MFA_TOKEN\", \"otp\": \"000000\" }" - } -} -``` - -If the call was successful, you'll receive a response like this: - -``` -{ - "access_token": "eyJ...d", - "expires_in": 600, - "scope": "enroll read:authenticators remove:authenticators", - "token_type": "Bearer" -} -``` - -At this point, your authenticator is fully associated and ready to be used. \ No newline at end of file diff --git a/articles/multifactor-authentication/custom/custom-landing.md b/articles/multifactor-authentication/custom/custom-landing.md deleted file mode 100644 index 0322c8245b..0000000000 --- a/articles/multifactor-authentication/custom/custom-landing.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Configuring Custom Multifactor Authentication -url: /multifactor-authentication/custom -description: Examples for configuring custom MFA implementations. ---- -# Configuring Custom MFA - -You may configure [rules](/rules) for custom MFA processes, which allow you to define the conditions that will trigger additional authentication challenges, such as changes in geographic location or logins from unrecognized devices. - -## Implementing 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. - -### Change the frequency of authentication requests - -When using the Guardian multi-factor application, by default users are given the option to be remembered and skip MFA for a period of 30 days. To disable this choice for users, set the `allowRememberBrowser` field to `false`. - -For other types of MFA, users are remembered for 30 days by default, or when `allowRememberBrowser` is explicitly set to `true`. You can disable this by setting `allowRememberBrowser` to `false`. - -Note that some older rules may use the field `ignoreCookie` here. While deprecated, that field will still function as expected, and will force multifactor authentication at every login. - -```JS -function (user, context, callback) { - - if (conditionIsMet()){ - context.multifactor = { - allowRememberBrowser: false, - provider: 'guardian' - }; - } - - callback(null, user, context); -} -``` - -### Access from an extranet - -You can have Auth0 request MFA from 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: 'guardian', - - // optional, defaults to true. Set to false to force Guardian authentication every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false - }; - } - - callback(null, user, context); -} -``` - -### Access from a different device or location - -If the user makes a request from an IP address that Auth0 has not already associated with them, you can configure Auth0 to request MFA. - -```js -function (user, context, callback) { - - var deviceFingerPrint = getDeviceFingerPrint(); - user.app_metadata = user.app_metadata || {}; - - if (user.app_metadata.lastLoginDeviceFingerPrint !== deviceFingerPrint) { - - user.app_metadata.lastLoginDeviceFingerPrint = deviceFingerPrint; - - context.multifactor = { - allowRememberBrowser: false, - provider: 'guardian' - }; - - auth0.users.updateAppMetadata(user.user_id, user.app_metadata) - .then( function() { - callback(null, user, context); - }) - .catch( function(err) { - callback(err); - }); - } else { - callback(null, user, context); - } - - function getDeviceFingerPrint() { - - var shasum = crypto.createHash('sha1'); - shasum.update(context.request.userAgent); - shasum.update(context.request.ip); - return shasum.digest('hex'); - - } -} -``` - -## Use a Custom MFA Service - -If you are using an MFA provider that does not have Auth0 built-in support or if you are using a service you have created, you can use the [redirect](/rules/redirect) protocol for the integration. - -By using the redirect protocol, you interrupt the authentication transaction and redirect the user to a specified URL where they are asked for MFA. If authentication is successful, Auth0 will continue processing the request. - -Some MFA options you can implement using the redirect protocol include: - -* A one-time code sent via SMS -* A personally identifying question (such as about the user's parents, childhood friends, and so on) -* Integration with specialized providers, such as those that require hardware tokens - -To use the redirect protocol, edit the `URL` field: - -```JS -function (user, context, callback) { - - if (condition() && context.protocol !== 'redirect-callback'){ - context.redirect = { - url: 'https://your_custom_mfa' - }; - } - - if (context.protocol === 'redirect-callback'){ - //TODO: handle the result of the MFA step - } - - callback(null, user, context); -} -``` - -## Additional Notes - -* A tutorial is available on using MFA with the [Resource Owner](/api-auth/tutorials/multifactor-resource-owner-password) endpoint. -* If you are using MFA for database connections that use Popup Mode, set `sso` to `true` when defining the options in [auth0.js](/libraries/auth0js) or [Lock](/libraries/lock). If you fail to do this, users will be able to log in without MFA. -* If you are using MFA after an authentication with one or more social providers, you may 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). diff --git a/articles/multifactor-authentication/developer/custom-enrollment-ticket.md b/articles/multifactor-authentication/developer/custom-enrollment-ticket.md deleted file mode 100644 index 021a24da44..0000000000 --- a/articles/multifactor-authentication/developer/custom-enrollment-ticket.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -description: Describes how to create an enrollment ticket from api ---- -# Custom Enrollment - -In addition to [directly sending emails to enroll users](/multifactor-authentication/administrator/guardian-enrollment-email), 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 Guardian [Hosted Page](${manage_url}/#/guardian_mfa_page) to customize the Guardian widget's appearance: - -```html - - - - 2nd Factor Authentication - - - - - - - -
    -
    -

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

    -
    - - -
    -
    -
    -
    - - - - - - -``` - -Since this hosted page is used for displaying the Guardian widget in both enrollment and standard multifactor login scenarios, it's important to note that the existence of the `ticket` variable can be used to determine which scenario is being used, and to control the content accordingly. - -For example, the following code could be used to used to alter the message: - -```html -{% if ticket %} -

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

    -{% else %} -

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

    -{% endif %} -```` - -Note that this conditional logic around the existence of the `ticket` variable is also used in the initialization of the `Auth0MFAWidget` above. - -## Keep reading - -::: next-steps -* [Sending Guardian Enrollment Emails](/multifactor-authentication/administrator/guardian-enrollment-email) -::: diff --git a/articles/multifactor-authentication/developer/index.md b/articles/multifactor-authentication/developer/index.md deleted file mode 100644 index eb1f48b360..0000000000 --- a/articles/multifactor-authentication/developer/index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Developer Documentation for Guardian -url: /multifactor-authentication/developer -description: Developer Documentation for Guardian ---- - -# Developer Resources for Guardian - -At Auth0, we believe in giving developers the tools they need to get their jobs done. With Guardian, developers are able to customize their users' experience, and even build their own applications on top of our multifactor capabilities. - -## Getting started with Guardian within your Application -Most often, administrators will [manage multifactor configuration for an application](multifactor-authentication/guardian/admin-guide). For more advanced use cases, Guardian provides developers the ability to control user access directly. -* [Example Application using Guardian for Multifactor Authentication](https://github.com/auth0/guardian-example) -* [How to do 'Step-Up' Authentication with Guardian](/multifactor-authentication/developer/step-up-with-acr) - -## Customize the Guardian Widget -Use our Guardian client libraries to apply the look-and-feel of your organization. -* [Client library for Auth0 Guardian](https://github.com/auth0/auth0-guardian.js) -* [Creating a Custom Guardian Widget](https://github.com/auth0/auth0-guardian.js/tree/master/example) - -## Manage Enrollments -Directly customize the enrollment process for your users. -* [Custom enrollment](/multifactor-authentication/developer/custom-enrollment-ticket) - -## Build Custom Mobile Applications -Developers can build custom _white-label_ Guardian-like applications, or add multifactor functionality into their own applications. -* [Getting Started with Guardian for Android](/multifactor-authentication/developer/libraries/android) -* [Getting Started with Guardian for iOS](/multifactor-authentication/developer/libraries/ios) diff --git a/articles/multifactor-authentication/developer/libraries/android/index.md b/articles/multifactor-authentication/developer/libraries/android/index.md deleted file mode 100644 index 9d5b186a7d..0000000000 --- a/articles/multifactor-authentication/developer/libraries/android/index.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: Getting Started with Guardian for Android -url: /multifactor-authentication/developer/libraries/android -description: Installation, usage, and configuration options guide for Guardian for Android ---- - -# Guardian for Android -The [Guardian for Android Software Development Kit](https://github.com/auth0/Guardian.Android) allows developers to create Android apps with Guardian functionality, providing easy and secure access to multifactor authentication with push notifications. For example, this toolkit gives you the power to build a 'white label' version of the Guardian application for your users, using your own look-and-feel. - -More information can be found on Guardian [here](/multifactor-authentication/guardian). For general multifactor discussion, read more [here](/multifactor-authentication). - -Get started using Guardian for Android below, or, if you're looking for a specific document, try the listing of [additional documents](#additional-documents) related to Guardian for Android. - -## Requirements - -Android API level 15+ is required in order to use the Guardian Android SDK. - -## Installation - -Guardian is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To start using *Guardian* add these lines to your `build.gradle` dependencies file: - -```gradle -compile 'com.auth0.android:guardian-sdk:0.2.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). -::: - -After adding your Gradle dependency, make sure to remember to sync your project with Gradle files. - -## Dashboard Settings - -To enable Guardian Push Notifications for your users, go to the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. Then toggle the **Push Notification** slider to enable it. - -![](/media/articles/mfa/guardian-dashboard.png) - -## SNS configuration - -For your native application to receive push notifications from Guardian, you will need to override the default SNS settings. Follow the instructions [here](/multifactor-authentication/developer/sns-configuration). - -## Using 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, "gcmToken", "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 `gcmToken` 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 `gcmToken` is the token for Google's GCM push notification service. See the [docs](https://developers.google.com/cloud-messaging/android/client#sample-register) for more information about the GCM token. - -### Unenroll - -To disable multifactor 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 will receive a GCM push notification every time the user needs multifactor authentication. - -Guardian provides a method to parse the `Bundle` received from GCM and return a `Notification` instance ready to be used. - -```java -// at the GCM listener you receive a Bundle -@Override -public void onMessageReceived(String from, Bundle data) { - Notification notification = Guardian.parseNotification(data); - 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 easily 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 optionally add a 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<> ...) -``` - - - -## Additional Documents - -* [Configuring Amazon SNS with Guardian](/multifactor-authentication/developer/sns-configuration) -* [Getting Started with Google Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html) diff --git a/articles/multifactor-authentication/developer/libraries/ios/index.md b/articles/multifactor-authentication/developer/libraries/ios/index.md deleted file mode 100644 index 06617842c4..0000000000 --- a/articles/multifactor-authentication/developer/libraries/ios/index.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -title: Getting Started with Guardian for iOS -url: /multifactor-authentication/developer/libraries/ios -description: Installation, usage, and configuration options guide for Guardian for iOS ---- - -# Guardian for iOS -The [Guardian for iOS Software Development Kit](https://github.com/auth0/GuardianSDK.iOS) allows developers to create iOS apps with Guardian functionality, providing easy and secure access to multifactor authentication with push notifications. For example, this toolkit gives you the power to build a 'white label' version of the Guardian application for your users, using your own look-and-feel. - -More information can be found on Guardian [here](/multifactor-authentication/guardian). For general multifactor discussion, read more [here](/multifactor-authentication). - -Get started using Guardian for iOS below, or, if you're looking for a specific document, try the listing of [additional documents](#additional-documents) related to Guardian for iOS. - -## Requirements - -The Guardian iOS SDK requires iOS 9.3+ and Swift 3. - -## Installation - -### 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" -``` - -## Dashboard Settings - -To enable Guardian Push Notifications for your users, go to the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. Then toggle the **Push Notification** slider to enable it. - -![](/media/articles/mfa/guardian-dashboard.png) - -## SNS configuration - -For your native application to receive push notifications from Guardian, you will need to override the default SNS settings. Follow the instructions [here](/multifactor-authentication/developer/sns-configuration). - -## 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 successfuly allowed - case .failure(let cause): - // something failed, check cause to see what went wrong - } - } -``` - -### Reject a login request - -To deny an authentication request just call `reject` instead. You can also send a 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 successfuly 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 - } - } -``` - -## Additional Documents - -* [Configuring Amazon SNS with Guardian](/multifactor-authentication/developer/sns-configuration) -* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html) diff --git a/articles/multifactor-authentication/developer/sns-configuration.md b/articles/multifactor-authentication/developer/sns-configuration.md deleted file mode 100644 index 3a546ed7ff..0000000000 --- a/articles/multifactor-authentication/developer/sns-configuration.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: Describes how to configure Amazon SNS with Guardian Multifactor ---- -# Configuring Amazon SNS - -In order to receive push notifications from Guardian, it's necessary to override Guardian's default SNS settings. - -To do this, go to the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard and click on the **Push Notifications** box. - -![Push Notifications](/media/articles/mfa/push-notification-config.png) - -Enable the switch to use a custom app and provide the following values for your configuration: - -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 [Google Cloud Messaging Service](http://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html). - -Then click **SAVE**. - -## Keep reading - -::: next-steps -* [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 Google Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html) -::: diff --git a/articles/multifactor-authentication/developer/step-up-authentication/index.md b/articles/multifactor-authentication/developer/step-up-authentication/index.md deleted file mode 100644 index 9cb6aaba7b..0000000000 --- a/articles/multifactor-authentication/developer/step-up-authentication/index.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Step-up Authentication -description: Describes using acr_values and acr claims to perform step-up authentication with Auth0 ---- -# 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 multifactor authentication. - -You can add step-up authentication to your app with Auth0's extensible multifactor authentication support. Your app can verify that the user has logged in using multifactor 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](/scopes), [Access Tokens](/tokens/access-token) and [rules](/rules). - -::: 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](/multifactor-authentication/developer/step-up-authentication/step-up-for-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/id-token). 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](/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps). - -## Keep reading - -::: next-steps -* [Step-up Authentication for Web Apps](/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps) -* [Step-up Authentication for APIs](/multifactor-authentication/developer/step-up-authentication/step-up-for-apis) -* [Authentication policy definitions](http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#rfc.section.4) -::: diff --git a/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-apis.md b/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-apis.md deleted file mode 100644 index a8a69440d6..0000000000 --- a/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-apis.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: Step-up Authentication for APIs -description: Describes how an API can check if a user has logged in with Multifactor Authentication by examining their Access Token -toc: true ---- -# 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 may be allowed to transfer money only after they have confirmed their identity using Multifactor Authentication (MFA). - -When your audience is an API, you can implement step-up authentication with Auth0 using [scopes](/scopes), [Access Tokens](/tokens/access-token) and [rules](/rules). In this article we will explain how you can do that and use a sample implementation to go through the process step-by-step. - -## How to check the Access Token - -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. In order to transfer money to another account the Access Token should contain the `transfer:funds` scope. - -A sample flow for this example is the following: -1. The user logs in to the application using username/password authentication. The standard login gives to this user the ability to interact with their API and fetch their balance. This means that the Access Token that the app receives after the user authentication contains the scope like `view:balance` -1. The application sends a request to the API to retrieve the balance, using the Access Token as credentials -1. The API validates the token and sends the balance info to the application -1. Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction. The application sends a request to the API using the same Access Token -1. The API validates the token and denies access since it's missing the required scope `transfer:funds` -1. The application 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 this scope is generated and sent to the application as part of the response -1. The application sends again the transfer funds request using the new Access Token, which includes the `transfer:funds` scope. -1. The API validates the token, discards it (thereby treating it like a single-use token) and proceeds with the operation - -Note that the API needs to do more validations than just check the scope. These are: -- Verify the token's signature. The signature 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: `exp` (when the token expires), `iss` (who issued the token), `aud` (who is the intented recipient of the token) - -For details on how to do these validations, see the [Verify Access Tokens for Custom APIs](/api-auth/tutorials/verify-access-token) article. - -## Example - -In this section we will see how you would implement the scenario described in the previous paragraph. - -### Before you start - -This tutorial assumes that you have already done the following: - -- [Register an application](/applications#how-to-configure-an-application). For the purposes of this example we'll be using a single-page web app -- [Create a database connection](${manage_url}/#/connections/database) -- [Register the API](/apis#how-to-configure-an-api-in-auth0). It should include two scopes: `view:balance` and `transfer:funds` -- [Enable Multifactor Authentication](/multifactor-authentication). For the purposes of this example we'll be using [Guardian push notifications](/multifactor-authentication/administrator/push-notifications) - - -### 1. Create the rule - -First we will create a rule that will challenge the user to authenticate with MFA when the `transfer:funds` scope is requested. - -Go to [Dashboard > Multifactor Auth](${manage_url}/#/guardian) and modify the script as follows. - -```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: 'guardian', - allowRememberBrowser: false - }; - } - } - - callback(null, user, context); -} -``` - -The `CLIENTS_WITH_MFA` variable holds the Cliend 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 that the authentication request asked for. 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 [Guardian](/multifactor-authentication/guardian). - -### 2. Configure your application - -Next you need to configure your application to send the appropriate authentication request, depending on the action that the user wants to perform. Notice that the only difference between the two authentication requests (with or without MFA) is the scope `transfer:funds`. - -
    -
    - -
    -
    -
    - 
    -        
-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=CRYPTOGRAPHIC_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=CRYPTOGRAPHIC_NONCE
-  &state=OPAQUE_VALUE
-        
-
    -
    -
    -
    - -- Set `audience` to the **Identifier** of your API (find it at [API Settings](${manage_url}/#/apis/)). We set ours to `https://my-banking-api` -- The `response_type` is set to `id_token token` so we get both an ID Token and an Access Token in the response -- Set `client_id` to the Client ID of your application (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)) -- Set the `redirect_uri` to the URL of your application that Auth0 should redirect back to after authentication (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)) -- Set `nonce` to a 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` -- Set `state` 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 your API - -Finally, you need to make your API validate the incoming token and check the authorized permissions. - -For the purposes of this example we will configure two endpoints for our API: -- `GET /balance`: used to retrieve the current balance -- `POST /transfer`: used to transfer funds - -We will be using 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 provide 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. - -```text -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 singing 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 will happen: -1. The endpoint will call the `checkJwt` middleware -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 Access Token. 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 -1. `jwtAuthz` will check if the scope that the endpoint requires is part of the Access Token - -That's it, you're done! Now your application allows access to different types of resources using a stronger mechanism to perform certain high-value transactions. - -## Keep reading - -::: next-steps -* [Overview of Access Tokens](/tokens/access-token) -* [Overview of rules](/rules) -* [Overview of scopes](/scopes) -* [How to verify Access Tokens](/api-auth/tutorials/verify-access-token) -* [Step-up Authentication for Web Apps](/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps) -::: diff --git a/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps.md b/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps.md deleted file mode 100644 index 337c26aa9e..0000000000 --- a/articles/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: Step-up Authentication for Web Apps -description: Describes how to check if a user has logged in your web app with Multifactor Authentication by examining their ID Token -toc: true ---- -# 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 Multifactor Authentication (MFA). - -When a user logs in you can get an [ID Token](/tokens/id-token) which is a [JSON Web Token](/jwt) that contains information relevant to the user's session, in the form of claims. - -The claim that is relevant to this scenario is `amr`. If it contains the value `mfa` then you know that the user has authenticated using MFA. Note the following: -- `amr` **must** be present in the ID Token's payload (if you log in with username/password the claim will not be included in the payload) -- `amr` **must** contain the value `mfa` (`amr` can contain claims other than `mfa`, so its existence is not a sufficient test, its contents must be examined for the value `mfa`) - -If the token shows that the user has not authenticated with MFA, then you can trigger again authentication, and using a rule, trigger MFA. Once the user provides the second factor, a new ID Token, that contains the `amr` claim, is generated and sent to the app. - -## How to check the ID Token for MFA - -In order to check if a user logged in with MFA follow these steps: - -1. Retrieve the ID Token -1. Verify the token's signature. The signature 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. -1. Validate the standard claims: `exp` (when the token expires), `iss` (who issued the token), `aud` (who is the intented recipient of the token) -1. Verify that the token contains the `amr` claim. - - If `amr` **is not** in the payload or it does not contain the value `mfa`, the user did not log in with MFA - - If `amr` **is** in the payload and it contains the value `mfa`, then the user logged in with MFA - -For more information on the signature verification and claims validation, see [ID Token](/tokens/id-token). - -## Sample payloads - -In the snippet below you can see how an ID Token's payload is if the user has authenticated with MFA, and how it is if 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": 1522838197,
-  "exp": 1522874197
-}
-        
-
    -
    -
    -
    - -## Example - -Let's say that you have a web app that authenticates users with username and password. When a user wants to access a specific screen with sensitive information, for example, one that displays salary data, you want the user to authenticate with another factor, for example [Guardian push notifications](/multifactor-authentication#mfa-using-push-notifications-auth0-guardian-). - -### Before you start - -This tutorial assumes that you have already done the following: - -- [Register an application](/applications#how-to-configure-an-application). For the purposes of this example we'll be using a regular web app -- [Create a database connection](${manage_url}/#/connections/database) -- [Enable Multifactor Authentication](/multifactor-authentication). For the purposes of this example we'll be using [Guardian push notifications](/multifactor-authentication/administrator/push-notifications) - -### 1. Create the rule - -First we will create a rule that will challenge the user to authenticate with MFA when the web app asks for it. - -Go to [Dashboard > Multifactor Auth](${manage_url}/#/guardian) and modify the script as follows. - -```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: 'guardian', - allowRememberBrowser: false - }; - } - } - - callback(null, user, context); -} -``` - -The `CLIENTS_WITH_MFA` variable holds the Cliend 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 exists only if the web app included it in the authentication request, using the request parameter `acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor`. The web app will only include this parameter in the authentication request (as we will see in a while) if the user tries to access salary information and has not authenticated with MFA. In this case we ask for MFA using [Guardian](/multifactor-authentication/guardian) by setting the `context.multifactor` property to the appropriate value. - -### 2. Configure your application - -If the user tries to access the salary information screen, then the web app must check the ID Token claims for MFA. If the user has already authenticated with MFA, then the screen is displayed, otherwise the web app sends a new authentication request to Auth0. This time the request parameter `acr_values` is included so the rule we saw in the previous paragraph triggers MFA. Once the user authenticates, a new token is sent to the app. - -#### Check the ID Token - -The web app must validate the token as described in [How to check the ID Token for MFA](#how-to-check-the-id-token-for-mfa). - -In this example, we do these validations, using the [JSON Web Token Sample Code](https://github.com/auth0/node-jsonwebtoken). - -The code verifies the token's signature (`jwt.verify`), decodes the token, and checks whether the payload contains `amr` and if it does whether it contains the value `mfa`. The results are logged 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'); - }); -``` - -#### Ask for MFA - -If the output of the previous validations is that the user has not authenticated with MFA, then you must trigger authentication again. The request will include the `acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor` parameter, which as a result will trigger the rule we wrote at [the first step](#1-create-the-rule). - -Our web app uses the [Authorization Code Grant](/api-auth/tutorials/authorization-code-grant) 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 Guardian, the web app receives in the response the authorization code which must be exchanged for the new ID Token, using the [Token endpoint](/api/authentication#authorization-code). For more details, and sample requests, see [Exchange the Authorization Code for a Token](/api-auth/tutorials/authorization-code-grant#2-exchange-the-authorization-code-for-an-access-token). - -That's it, you are done! - -## Keep reading - -::: next-steps -* [Overview of ID Tokens](/tokens/id-token) -* [Overview of JSON Web Tokens](/jwt) -* [OpenID specification](http://openid.net/specs/openid-connect-core-1_0.html) -* [Step-up Authentication for APIs](/multifactor-authentication/developer/step-up-authentication/step-up-for-apis) -::: diff --git a/articles/multifactor-authentication/duo/admin-guide.md b/articles/multifactor-authentication/duo/admin-guide.md deleted file mode 100644 index 6df80ed0e8..0000000000 --- a/articles/multifactor-authentication/duo/admin-guide.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Information for how to use Duo Security for administrators. ---- - -# Duo for Administrators - -## Enabling Duo for MFA - -To turn on Duo for two-step verification, first visit the [Multifactor Auth](${manage_url}/#/guardian) page from the dashboard. Then click on the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Then you can use the slider to turn on Duo. - -![](/media/articles/mfa/toggle-duo.png) - -::: note -If you enable Duo while using another provider for MFA, all other providers will be disabled. All customizations and enrolled users in other MFA will be lost. Be careful as this action cannot be reverted. -::: - -### Customize Duo - -After you toggle the slider to enable using Duo, a portal displays a code editing textbox containing the following code snippet for you to use: - -```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 = { - //required - provider: 'duo', - ikey: 'DIXBMN...LZO8IOS8', - skey: 'nZLxq8GK7....saKCOLPnh', - host: 'api-3....049.duosecurity.com', - - // optional, defaults to true. Set to false to force DuoSecurity every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false, - - // optional. Use some attribute of the profile as the username in DuoSecurity. This is also useful if you already have your users enrolled in Duo. - // username: user.nickname, - - // optional. Admin credentials. If you provide an Admin SDK type of credentials. auth0 will update the realname and email in DuoSecurity. - // admin: { - // ikey: 'DIAN...NV6UM', - // skey: 'YL8OVzvoeeh...I1uiYrKoHvuzHnSRj' - // }, - }; - // } - } - - callback(null, user, context); -} -``` - -#### Changing the Required Fields - -Required fields that you **must** replace to use Duo are: `ikey`, `skey` and `host`. - -1. To get these fields first [login to your Duo account](https://admin.duosecurity.com/login). - -2. Click on the **Applications** section from the sidebar. - -3. Then click on the button to **Protect an Application**. - -4. Find the **Auth API** option from the list and then click **Protect this Application**. - -5. Then you will be brought to the **Auth API** page under your Appications, you should see a **Details** section. - -6. Under the **Details** section you will see: - -* **Integration key** - use this for your `ikey` field -* **Secret key** - use this for your `skey` field -* **API hostname** - use this for your `host` field - -Replace the three fields in the code snippet. For more details about editing the other parts of this code snippet, [see Duo for Developers](/multifactor-authentication/duo/dev-guide#other-customizations). - -When you have finished editing the code snippet based on the requirements of your app, click **Save**. - -## Editing a User's Settings - -If you need to change the settings for logging in with Duo for one of your users or if a user has lost their mobile device, you will need to edit User setting on the Duo site. - -1. Visit [Duo.com](https://duo.com/) and login to your account. -2. Click **Users** from the sidebar. -3. Find the desired user and click their username. -4. From a User page you can edit their settings. - -## Disabling Duo - -Duo can be disabled from the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard then by clicking the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Toggle the slider button to disable Duo, then a confirmation popup will appear. - -By disabling Duo you will lose all customizations, but your previously enrolled users will still be visible in your Duo settings. diff --git a/articles/multifactor-authentication/duo/dev-guide.md b/articles/multifactor-authentication/duo/dev-guide.md deleted file mode 100644 index f704210fd0..0000000000 --- a/articles/multifactor-authentication/duo/dev-guide.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -description: Information for how to use Duo Security for developers. ---- - -# Duo for Developers - -## Enabling Duo for MFA - -To turn on Duo for two-step verification, first visit the [Multifactor Auth](${manage_url}/#/guardian) page from the dashboard. Then click on the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Then you can use the slider to turn on Duo. - -![](/media/articles/mfa/toggle-duo.png) - -### Customize Duo - -After you toggle the slider to enable using Duo, a portal displays a code editing textbox containing the following code snippet for you to use: - -```JS -function (user, context, callback) { - - var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; - // run only for the specified clients - 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 = { - //required - provider: 'duo', - ikey: 'DIXBMN...LZO8IOS8', - skey: 'nZLxq8GK7....saKCOLPnh', - host: 'api-3....049.duosecurity.com', - - // optional, defaults to true. Set to false to force DuoSecurity every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false, - - // optional. Use some attribute of the profile as the username in DuoSecurity. This is also useful if you already have your users enrolled in Duo. - // username: user.nickname, - - // optional. Admin credentials. If you provide an Admin SDK type of credentials. auth0 will update the realname and email in DuoSecurity. - // admin: { - // ikey: 'DIAN...NV6UM', - // skey: 'YL8OVzvoeeh...I1uiYrKoHvuzHnSRj' - // }, - }; - // } - } - - callback(null, user, context); -} -``` - -### Changing the Required Fields - -Required fields that you **must** replace to use Duo are: `ikey`, `skey` and `host`. - -1. To get these fields first [login to your Duo account](https://admin.duosecurity.com/login). - -2. Click on the **Applications** section from the sidebar. - -3. Then click on the button to **Protect an Application**. - -4. Find the **Auth API** option from the list and then click **Protect this Application**. - -5. Then you will be brought to the **Auth API** page under your Appications, you should see a **Details** section. - -6. Under the **Details** section you will see: - -* **Integration key** - use this for your `ikey` field -* **Secret key** - use this for your `skey` field -* **API hostname** - use this for your `host` field - -Replace the three fields in the code snippet, and click **SAVE**. - -[Click here to learn more about Duo's Auth API](https://duo.com/docs/authapi) - -## Other Customizations - -### Use Duo only for Specified Users - -#### Based on your Application -To use Duo for logins only for the specified applications, replace `REPLACE_WITH_YOUR_CLIENT_ID` field with the Client ID of the application you wish to use. You can find your Client ID(s) under the [Applications](${manage_url}/#/applications) section of the dashboard and then clicking the application you wish to use. - -To use Duo for users of all your applications, you can comment or remove the sections regarding `CLIENTS_WITH_MFA`. - -#### Specify users to use MFA -To only use Duo for MFA on users that have `user_metadata.use_mfa === true` uncomment this if block. This field can be updated using the [Management APIv2](/api/management/v2#!/Users/patch_users_by_id). - -### Setting `allowRememberBrowser: false` -If `allowRememberBrowser: true` is set, or if the field is left unset, then users will not have to login with Duo everytime they login. The browser will save a cookie that will persist for 30 days and this cannot be undone. - -### Changing the Username sent to Duo -To use a specific attribute of the profile as the username in DuoSecurity, uncomment `username: user.nickname` and change it to the attribute you wish to use. This is also useful if you already have your users enrolled in Duo. - -### Setting Admin Credentials -If you provide an Admin SDK type of credentials then Auth0 will update the realname and email in Duo. To do this, replace the `ikey` and `skey` with the integration key and secret key. diff --git a/articles/multifactor-authentication/duo/duo-landing.md b/articles/multifactor-authentication/duo/duo-landing.md deleted file mode 100644 index a3b805a031..0000000000 --- a/articles/multifactor-authentication/duo/duo-landing.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Duo Security with Auth0 -description: Links to documentation on using Duo with Auth0 for each user type. -url: /multifactor-authentication/duo ---- - -# Duo Security - -Duo Security is a vendor of cloud-based two-factor authentication services. If you have an account with Duo it is easy to integrate Duo's two-factor authentication into your Auth0 application. - -**Click the link below that most fits your role to learn more:** - -[Duo Security for Administrators](/multifactor-authentication/duo/admin-guide) - this page explains how to setup using Duo, how to reset accounts and how to disable using Duo. - -[Duo Security for Developers](/multifactor-authentication/duo/dev-guide) - this page explains how to enable using Duo for two-factor auth and details on how to configure it to meet your needs. - -[Duo Security for Users](/multifactor-authentication/duo/user-guide) - this page is for users logging into your application using Duo. It also has troubleshooting tips for any issues they may encounter. diff --git a/articles/multifactor-authentication/duo/user-guide.md b/articles/multifactor-authentication/duo/user-guide.md deleted file mode 100644 index a25eab2f49..0000000000 --- a/articles/multifactor-authentication/duo/user-guide.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -description: Information for how to use Duo Security for users. ---- - -# How to Use Duo - -Duo is a service and has a mobile app used for two-factor authentication when logging into an application, which helps create a more secure login. With two-factor authentication you will always need your mobile device when you log in. - -This page will help to explain how to sign up and log in using Duo. - -## Signing Up - -After entering your username and password see [Duo's Enrollment Guide](https://guide.duo.com/enrollment) for help with the sign up process. - -## Logging In - -When you are logging in, first enter you username and password. Then you will see a page to choose how to use Duo to complete your login. - -![](/media/articles/mfa/duo-login.png) - -### Send me a Push -If you choose this option, you must have the Duo App installed on your device. The app will send you a push notification, choose Accept to login. - -### Call me -If you choose this option, you will recieve an automated call from Duo. Answer the call and press any key to finish logging in. - -### Enter a Passcode -If you choose this option, you must have the Duo App installed on your device. Open the app on your device and then click on the key icon next to the name of the application you are logging into. This will reveal a six-digit code, enter this passcode and then click **Log In** to continue. - -## Troubleshooting - -### If you do not have your mobile device - -If you have lost your phone and are unable to finish the two-step authentication you will need to contact your system administrator for help accessing your account. - -### If you forgot your password - -If you forgot your password when you are trying to login, click **Don't remember your password?** underneath the login. Enter your email to receive an email that will contain a link to reset your password. - -### Additional Help - -For other issues/questions regarding Duo [see here.](https://guide.duo.com) - - diff --git a/articles/multifactor-authentication/google-auth/admin-guide.md b/articles/multifactor-authentication/google-auth/admin-guide.md deleted file mode 100644 index 63685199da..0000000000 --- a/articles/multifactor-authentication/google-auth/admin-guide.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -description: Using Google Authenticator with Auth0 for administrators ---- - -# Google Authenticator for Administrators - -## Enabling Google Authenticator for MFA - -To turn on Google Authenticator for two-step verification, first visit the [Multifactor Auth](${manage_url}/#/guardian) page from the dashboard. Then click on the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Then you can use the slider to turn on Google Authenticator. - -![](/media/articles/mfa/toggle-google-auth.png) - -::: note -If you enable Google Authenticator while using another provider for MFA, all other providers will be disabled. All customizations and enrolled users in other MFA will be lost. Be careful as this action cannot be reverted. -::: - -## Google Authenticator Supported Devices - -Your users must have a supported device to use the Google Authenticator app. If some of your users have an unsupported device type, they may be able to use Auth0's Guardian app instead of Google Authenticator. [Click here for information on using Guardian.](/multifactor-authentication/guardian/admin-guide) - -| **OS** | **Google Authenticator** | -| --- | --- | -| **iOS** | Requires iOS 5.0 or later | -| **Android** | Requires Android version 2.1 or later | -| **Windows** | Unsupported | -| **Blackberry** | Requires OS 4.5-7.0 | -| **Other** | Unsupported | - -## Customize Google Authenticator - -Once you have turned on Google Authenticator, the portal displays a code editing textbox containing the following code snippet for you to use: - -```JS -function (user, context, callback) { - // Uncomment the following to skip MFA when impersonating a user - // if (user.impersonated) { return callback(null, user, context); } - - var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; - // run only for the specified clients - if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { - // uncomment the following if clause in case you want to request a second factor only from users that have app_metadata.use_mfa === true - // if (user.app_metadata && user.app_metadata.use_mfa){ - context.multifactor = { - provider: 'google-authenticator', - // issuer: 'Label on Google Authenticator App', // optional - // key: 'YOUR_KEY_HERE', // optional, the key to use for TOTP. by default one is generated for you - - // optional, defaults to true. Set to false to force Google Authenticator every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false, - }; - // } - } - - callback(null, user, context); -} -``` - -When you have finished editing the code snippet based on the requirements of your app, click **Save**. - -::: panel Screen customization -At this time Google Authenticator does not allow any customizations to the look and feel of the Google Authenticator screens. For other customization options [see Auth0 Guardian](/multifactor-authentication/administrator#customization). -::: - -## Reset a MFA for a User - -If a user has lost their mobile device, you as an administrator will need to reset their MFA. - -To reset a user's MFA: - -1. Find and select the user in the [Users](${manage_url}/#/users) section of the dashboard. -2. Once you have selected the affected user click on the **Actions** button on the top right of the screen. -3. Select **Reset Multi Factor (Google)** from the dropdown. -4. There will be a pop up box to confirm your decision, click **YES, RESET IT** to reset the user's MFA. - -![](/media/articles/mfa/reset-google-mfa.png) - -The next time the user logs in they will need to resetup their MFA just like a new user. - -## Disabling Google Authenticator - -Google Authenticator can be disabled from the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard then by clicking the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Toggle the slider button to disable Google Authenticator, then a confirmation popup will appear. - -By disabling a type of MFA you will lose all customizations. diff --git a/articles/multifactor-authentication/google-auth/dev-guide.md b/articles/multifactor-authentication/google-auth/dev-guide.md deleted file mode 100644 index 3f99a1b29d..0000000000 --- a/articles/multifactor-authentication/google-auth/dev-guide.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -description: Using Google Authenticator with Auth0 for developers ---- - -# Google Authenticator for Developers - -## Enabling Google Authenticator for MFA - -To turn on Google Authenticator for two-step verification, first visit the [Multifactor Auth](${manage_url}/#/guardian) page from the dashboard. Then click on the link to use a different provider. - -![](/media/articles/mfa/change-provider.png) - -Then you can use the slider to turn on Google Authenticator. - -![](/media/articles/mfa/toggle-google-auth.png) - -## Customize Google Authenticator - -Once you have turned on Google Authenticator, the portal displays a code editing textbox containing the following code snippet for you to use: - -```JS -function (user, context, callback) { - - var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; - // run only for the specified clients - 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: 'google-authenticator', - // issuer: 'Label on Google Authenticator App', // optional - // key: 'YOUR_KEY_HERE', // optional, the key to use for TOTP. by default one is generated for you - - // optional, defaults to true. Set to false to force Google Authenticator every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false - }; - // } - } - - callback(null, user, context); -} -``` - -When you have finished editing the code snippet based on the requirements of your app, click **Save**. - -::: panel Screen customization -At this time Google Authenticator does not allow any customizations to the look and feel of the Google Authenticator screens. For other customization options [see Auth0 Guardian](/multifactor-authentication/administrator#customization). -::: - -### Configuring Google Authenticator for Select Users - -You may choose to enable Google Authenticator only for select users. Within the Customize MFA code snippet, you may include the conditions for Google Authenticator is enabled. - -For example, suppose you want to *omit* MFA for all users signing in from the `foo.com` domain. - - -```js -function (user, context, callback) { - - if (context.connection !== 'foo.com'){ - context.multifactor = { - provider: 'google-authenticator', //required - }; - } - - callback(null, user, context); -} -``` - -Once you have finished making your desired changes, click **SAVE** so that they persist. diff --git a/articles/multifactor-authentication/google-auth/google-landing.md b/articles/multifactor-authentication/google-auth/google-landing.md deleted file mode 100644 index 4f91b187de..0000000000 --- a/articles/multifactor-authentication/google-auth/google-landing.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Multifactor Authentication - Google Authenticator -description: Links to Google Authentication with Auth0 documentation for each type of user role. -url: /multifactor-authentication/google-authenticator ---- - -# Google Authenticator - -Google Authenticator is a mobile application made by Google that implements two-step verification. Authenticator provides a six to eight digit one-time password which users must provide in addition to their username and password to log into an application. - -**Click the link below that most fits your role to learn more:** - -[Google Authenticator for Administrators](/multifactor-authentication/google-auth/admin-guide) - this page explains how to enable/disable using Google Authenticator, how to reset accounts, supported devices and customization. - -[Google Authenticator for Developers](/multifactor-authentication/google-auth/dev-guide) - this page explains how to enable Google Authenticator and details on how to configure it to meet your needs. - -[Google Authenticator for Users](/multifactor-authentication/google-auth/user-guide) - this page is for users logging into your application using Google Authenticator. It also has troubleshooting tips for any issues they may encounter. diff --git a/articles/multifactor-authentication/google-auth/user-guide.md b/articles/multifactor-authentication/google-auth/user-guide.md deleted file mode 100644 index a310fbeb64..0000000000 --- a/articles/multifactor-authentication/google-auth/user-guide.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -description: How to sign-up and login using the Google Authenticator app. ---- - -# How to Use Google Authenticator - -Google Authenticator is a mobile app used for two-factor authentication when logging into an application, which helps create a more secure login. With two-factor authentication you will always need your mobile device when you log in. - -This page will help to explain how to sign up and log in using the Google Authenticator app. - -## Download the Google Authenticator App - -### Android -Requirements: Must be running Android version 2.1 or later. - -To download the app: - -1. Visit [Google Play](https://play.google.com/store). -2. Search for Google Authenticator. -3. Download and install the application. - -### iOS -Requirements: Must have iOS 5.0 or later. In addition, in order to set up the app on your iPhone using a QR code, you must have a 3G model or later. - -To download the app: - -1. Visit the [iTunes App Store](https://itunes.apple.com/us/genre/ios/id36). -2. Search for Google Authenticator. -3. Download and install the application. - -### Blackberry - -Requirements: Must have OS 4.5-7.0. In addition, make sure your BlackBerry device is configured for US English -- you might not be able to download Google Authenticator if your device is operating in another language. - -To download the app: - -1. Open the web browser on your BlackBerry. -2. Visit [m.google.com/authenticator](https://m.google.com/authenticator). -3. Download and install the application. - -## Sign Up as a New User - -If you do not have an existing account, you will need to sign up to create one. Click the **SIGN UP** button and enter your email and create a password. - -![](/media/articles/mfa/sign-up.png) - -You will need to download Google Authenticator app. - -A code will appear, and you will have five minutes to scan the code before it expires. After scanning the code, you will get a six digit code to enter. Once you enter this code you will be logged in. - -![](/media/articles/mfa/google-code.png) - -## Logging in - -After entering your username and password, you will be prompted for a six digit code. Open the Google Authenticator app on your mobile device to find the correct code. If you use Google Authenticator for other applications as well, make sure you are using the code for the current application. After entering the six digit code you will be logged in. - -## Troubleshooting - -### If you do not have your mobile device - -If you have lost your phone and are unable to finish the two-step authentication you will need to contact your system administrator for help accessing your account. - -### If you forgot your password - -If you forgot your password when you are trying to login, click **Don't remember your password?** underneath the login. Enter your email to receive an email that will contain a link to reset your password. - -### Transaction Expiration - -For logging in with Google Authenticator, there is a timeout that occurs with the passcode where it will expire. Try logging in again if you do not see a refreshed passcode in the app. - -### Additional Help - -For other issues/questions regarding Google Authenticator, see: [Install Google Authenticator](https://support.google.com/accounts/answer/1066447). diff --git a/articles/multifactor-authentication/guardian/admin-guide.md b/articles/multifactor-authentication/guardian/admin-guide.md deleted file mode 100644 index 80f6a7fb98..0000000000 --- a/articles/multifactor-authentication/guardian/admin-guide.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -description: How to enable and use Push Notifications and SMS for Guardian MFA. -toc: true ---- - -# Guardian for Administrators - -Guardian is Auth0's multifactor authentication (MFA) application that provides a simple, safe way for you to implement MFA. The Guardian app is used for two-factor authentication when logging into an application, which helps create a more secure login. With two-factor authentication your users will always need their mobile device in order to login. - -This page explains how to enable and use Push Notifications and SMS for MFA for signing in your users. - -For more information on Guardian, how to download the app, and common questions, see: [How to Use the Guardian App](/multifactor-authentication/guardian/user-guide). - -## Support for Push Notifications - -To enable Push Notifications MFA for sign in and sign up for your application by your users, go to the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. Then toggle the **Push Notification** slider to enable it. - -![Dashboard > Guardian](/media/articles/mfa/guardian-dashboard.png) - -For your users to utilize this type of MFA, they will need a supported mobile device. The device must have either the Guardian app installed, the Google Authenticator app installed, or an app that supports scanning Time-based One-time Password (TOTP) codes to use with Guardian. Here are the available options: - -| **OS** | **Guardian** | **Google Authenticator** | -| --- | --- | --- | -| **iOS** | Requires iOS 9.0 or later| Requires iOS 5.0 or later | -| **Android** | Requires Android API version 18 or later| Requires Android version 2.1 or later | -| **Windows** | Guardian codes are supported using the Microsoft Authenticator app available for Windows 10 Mobile and Windows Phone 8/8.1 | Unsupported | -| **Blackberry** | Must use a TOTP scanning app | Requires OS 4.5-7.0 | -| **Other** | Must use a TOTP scanning app | Unsupported | - -::: note -For more information on using the Google Authenticator app, refer to [Google Authenticator](/multifactor-authentication/google-authenticator). -::: - -New users signing up will be prompted to download the Guardian app from either the App Store or Google Play. Once they indicate that they downloaded the app, a code will appear. They will have five minutes to scan the code with the app before it expires. After the code has been successfully scanned, users will see a confirmation screen which includes a recovery code. They need to have this recovery code to login without their mobile device. If they lose both the recovery code and their mobile device, you will need to [reset their MFA](#reset-an-mfa-for-a-user). Then they will receive a push notification to their device and they will be logged in. - -Users that were previously registered before you enabled MFA will need to complete the same process as new users on their next login. - -## Support for SMS - -You can enable SMS messages to use as a form of multifactor authentication. This is also under the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. By toggling the **SMS** slider, you can enable using SMS for sign in and sign up for your application. SMS can be used as your only form of MFA or in addition to Push Notifications. - -Your users must have a device capable of using SMS to use this option. If your users are unable to always receive SMS messages (such as when traveling), they will be unable sign up with SMS and unable to login without the recovery code. - -When your users sign up with SMS, they enter their phone number's country code and mobile phone number. - -![](/media/articles/mfa/sms.png) - -After sign up, they receive a six digit code to their phone. They need to enter this code into the box, and then they will get a recovery code. They will need this code to login if they do not have their device. If they have lost their recovery code and device, you will need to [reset the user's MFA](#reset-an-mfa-for-a-user). - -::: panel Rate Limits - -Each hour, any given user is allotted a maximum of ten failed SMS attempts. After that, Auth0 considers all OTP codes invalid, and any additional attempts to log in results in a `Too Many Attempts` error. - -More specifically, this means that if someone enters in the code incorrectly ten or more times within an hour, they will need to wait six minutes to gain another attempt. If the user attempts another code before sufficient time has elapsed, Auth0 considers all OTP codes invalid (even if they aren't expired). -::: - -### Configuring Guardian SMS with Twilio - -When initially setting up SMS, you have up to 100 SMS to be used for testing. This limit can be removed by setting up a Twilio account. To prevent malicious login attempts, your users will always be limited to up to 10 SMS/Hour (replenishing one message an hour, up to 10). - -Click on the **SMS** box to configure your SMS settings. - -![](/media/articles/mfa/sms-config.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 an SMS to the user. You may also need to enable permissions for your [geographic region](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work). - -#### 2. Configure the connection - -Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields. - -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 of the SMS. You may also configure this in Twilio. - -* If you choose **Use Copilot **, you will need to enter a [Copilot SID](https://www.twilio.com/docs/api/rest/sending-messages-copilot). - -Click **SAVE**. - -## Customize MFA for Select Users - -Once you have enabled either MFA option, you will be presented with the **Customize MFA** code snippet that you can edit to ensure that MFA is applied to the appropriate Applications. By default, Auth0 enables Guardian for all accounts. - -```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: 'guardian', //required - - // optional, defaults to true. Set to false to force MFA authentication every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - 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 **Customize MFA** snippet 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. See [here](/multifactor-authentication/custom#change-the-frequency-of-authentication-requests) for details - -Once you have finished making your desired changes, click **Save**. - -## Customizing the Guardian Screen - -You may change the logo and the friendly name that is displayed to your users. To do so, make the appropriate changes to the Guardian page settings on the [Tenant Settings](${manage_url}/#/tenant) page. You may also reach the **Tenant Settings** page by clicking on your tenant name on the top right of the page and then selecting **Settings** from the dropdown menu that appears. - -![](/media/articles/mfa/guardian-logo-and-name-settings.png) - - * **Friendly Name**: the name of the app that you want displayed to users - * **Logo URL**: the URL that points to the logo image you want displayed to users - -Auth0 recommends using a logo image that is at least 100x100 pixels, although an image that is 200x200 pixels ensures quality viewing in devices with Retina or high DPI displays. - -## Tracking your Users MFA Events - -In the [Logs](${manage_url}/#/logs) section of the dashboard, you can see the various events related to your users signing up and signing in using MFA. - -![](/media/articles/mfa/logs.png) - -Here are all the possible events related to MFA: - -| Event Type | Description | -| --- | --- | -| `gd_unenroll` | When a device account is deleted | -| `gd_update_device_account` | When a device account is updated | -| `gd_send_pn` | When a push notification is sent | -| `gd_send_sms` | When a SMS is sent | -| `gd_sms_failure` | When a SMS failed to be sent. It usually means a configuration mistake for Twilio provider. You can check the provider error message and code as part of the details. | -| `gd_start_auth` | Start second factor authentication | -| `gd_start_enroll` | Second factor auth enrollment is started | -| `gd_enrollment_complete` | Second factor enrollment has been completed | -| `gd_module_switch` | When changing feature config | -| `gd_tenant_update` | When tenant info has been updated | -| `gd_user_delete` | When calling (user delete => unenroll) | -| `gd_auth_failed` | When second factor login has failed | -| `gd_auth_succeed` | When second factor authentication has succeeded | -| `gd_recovery_succeed` | Recovery succeeded | -| `gd_recovery_failed` | Failed recovery | -| `gd_otp_rate_limit_exceed` | When One Time Password fails validation because rate limit is exceeded | -| `gd_recovery_rate_limit_exceed` | When recovery validation fails because rate limit is exceeded | - -These events can also be searched using the [Management APIv2](/api/management/v2#!/Logs) using [query string syntax](/api/management/v2/query-string-syntax). You can search criteria using the `q` parameter or you can search by a specific log ID. - -### Examples searching with the `q` parameter - -To see the events for users who are enrolling with MFA: - -`type: gd_start_enroll` - -To see all the times an SMS is sent: - -`type: gd_send_sms` - -## Reset an MFA for a User - -If a user has lost their mobile device, they will need their recovery code to be able to log in. If they have also lost their recovery code, you, as an administrator, will need to reset their MFA. - -To reset a user's MFA: - -1. Find and select the user in the [Users](${manage_url}/#/users) section of the dashboard. -2. Once you have selected the affected user, click on the **Actions** button on the top right of the screen. -3. Select **Reset Multifactor Authentication** from the dropdown. -4. There will be a pop up box to confirm your decision. Click **YES, RESET IT** to reset the user's MFA. - - ![](/media/articles/mfa/reset-mfa.png) - -The next time the user logs in they will need to re-setup their MFA just like a new user. - -## Disabling Guardian and other MFA - -Guardian, and other types of MFA, can be disabled from the [Multifactor Auth](${manage_url}/#/guardian) section of the dashboard. Toggle the button to disabled for the type of MFA you wish to turn off. A confirmation popup will appear. - -By disabling a type of MFA, you will un-enroll all your current users of that type of MFA. They will be asked to re-enroll next time they try to login. This action cannot be reverted. diff --git a/articles/multifactor-authentication/guardian/dev-guide.md b/articles/multifactor-authentication/guardian/dev-guide.md deleted file mode 100644 index 49011428f6..0000000000 --- a/articles/multifactor-authentication/guardian/dev-guide.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -description: How to implement multifactor authentication with Guardian. ---- - -# Developer Guide to Configuring Guardian - -Guardian is Auth0's multifactor authentication (MFA) application that provides a simple, safe way for you to implement MFA. The Guardian app is currently available for mobile devices running iOS or Android. - -For applications where Guardian MFA is enabled, the user will be required to sign in **and** confirm the login with a verified mobile device. You can find additional information on user login and sign-up process and common user questions at: [How to Use the Guardian App](/multifactor-authentication/guardian/user-guide). - -## Implementing Multifactor Authentication - -Within Auth0, you may implement MFA via the [Multifactor Auth](${manage_url}/#/guardian) page of the Management Dashboard. - -![](/media/articles/mfa/guardian-dashboard.png) - -::: panel MFA options -Auth0 provides [built-in support](/multifactor-authentication) for MFA using Google Authenticator or Duo. You may choose to use either of these providers, in lieu of Guardian, or any code generator application, on the **Multifactor Auth** page of the Management Dashboard. -::: - -### Configuring Guardian in the Management Dashboard - -The first thing you will do when setting up Guardian is to decide whether you would like MFA to occur via push notifications, SMS, or both. - -* **Push Notifications**: the user receives, via the Guardian app, a push notification that requires their input prior to gaining access to the app. Or, instead, if the user chooses, they can use the Google Authenticator app in a similar way. -* **SMS**: the user receives, via SMS, a code that they are required to enter prior to gaining access to the app. - -To enable either Push Notifications or SMS verification, move the appropriate slider to the right. - -![](/media/articles/mfa/guardian-both.png) - -Once you have enabled either option, you will be presented with the **Customize MFA** code snippet that is applied automatically as a new [Rule](/rules). This rule will be executed in Auth0 as part of the transaction everytime a user authenticates to your application. By default, Auth0 enables Guardian for everything, but you may edit the rule so that MFA is applied only to some applications or users, as shown below. - - -```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: 'guardian', //required - - // optional, defaults to true. Set to false to force MFA authentication every time. - // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details - allowRememberBrowser: false - }; - // } - //} - - callback(null, user, context); -} -``` - -If you choose to selectively apply MFA, you will need the appropriate `clientID` values, and the code is executed as part of a [Rule](/rules) whenever a user logs in. - -More specifically, you will uncomment and populate the following line of the Customize MFA snippet with the appropriate application's client IDs: - -```js -var CLIENTS_WITH_MFA = ['REPLACE_WITH_CLIENT_ID']; -``` - -Once you have finished making your desired changes, click "Save" so that they persist. - -### Configuring Guardian for Select Users - -You may choose to enable Guardian only for select users. Within the Customize MFA code snippet, you may include the conditions for when Guardian is enabled. - -For example, suppose you want to disable MFA for all users signing in from the `foo.com` domain. - - -```js -function (user, context, callback) { - - if (context.connection !== 'foo.com'){ - context.multifactor = { - provider: 'guardian', //required - }; - } - - callback(null, user, context); -} -``` - -Once you have finished making your desired changes, click **Save** so that they persist. - -### Customizing the Guardian Screen - -You may change the logo and the friendly name that is displayed to your users. To do so, make the appropriate changes to the Guardian page settings on the [Tenant Settings](${manage_url}/#/tenant) page. You may also reach the **Tenant Settings** page by clicking on your tenant name on the top right of the page and then selecting **Settings** from the dropdown menu that appears. - -![](/media/articles/mfa/guardian-logo-and-name-settings.png) - -* **Friendly Name**: the name of the app that you want displayed to the users; -* **Logo URL**: the URL that points to the logo image you want displayed to your users. - -Auth0 recommends using a logo image that is at least 100x100 pixels, though an image that is 200x200 pixels ensures quality viewing in devices with Retina or high DPI displays. - -## Tracking and Searching MFA Events - -All MFA related events are recorded for audit purposes. For example, each time a new user enrolls with a form of MFA enabled, an **Enroll started** event is triggered. - -![](/media/articles/mfa/log-example.png) - -You can view events in the [Logs](${manage_url}/#/logs) sections of the dashboard. - -![](/media/articles/mfa/logs.png) - -Here are all the possible events related to MFA: - -| Event Name | Description | -| --- | --- | -| `gd_unenroll` | When a device account is deleted | -| `gd_update_device_account` | When a device account is updated | -| `gd_send_pn` | When a push notification is sent | -| `gd_send_sms` | When a SMS is sent | -| `gd_sms_failure` | When a SMS failed to be sent. It usually means a configuration mistake for Twilio provider. You can check the provider error message and code as part of the details. | -| `gd_start_auth` | Start second factor authentication | -| `gd_start_enroll` | Second factor auth enrollment is started | -| `gd_module_switch` | When changing feature config | -| `gd_tenant_update` | When tenant info has been updated | -| `gd_user_delete` | When calling (user delete => unenroll) | -| `gd_auth_failed` | When second factor login has failed | -| `gd_auth_succeed` | When second factor authentication has succeeded | -| `gd_recovery_succeed` | Recovery succeeded | -| `gd_recovery_failed` | Failed recovery | -| `gd_otp_rate_limit_exceed` | When One Time Password fails validation because rate limit is exceeded | -| `gd_recovery_rate_limit_exceed` | When recovery validation fails because rate limit is exceeded | - -These events can also be searched using the [Management APIv2](/api/management/v2#!/Logs) using [query string syntax](/api/management/v2/query-string-syntax). You can search criteria using the `q` parameter or you can search by a specific log ID. diff --git a/articles/multifactor-authentication/guardian/index.md b/articles/multifactor-authentication/guardian/index.md deleted file mode 100644 index 46f01b31f0..0000000000 --- a/articles/multifactor-authentication/guardian/index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Auth0 Guardian -description: Links to Guardian documentation for each type of Guardian user role. ---- - -# Auth0 Guardian - -Guardian is Auth0's multifactor authentication solution that provides a simple and secure way to implement MFA. When using Guardian with Auth0, users will be prompted for additional authentication from the Guardian mobile application, helping to provide a more secure login. - -**To learn more, click the link below that most suits your role:** - -[Guardian for Administrators](/multifactor-authentication/administrator) - information on how to enable and configure Guardian. - -[Guardian for Developers](/multifactor-authentication/developer) - learn how to customize Guardian to your needs, and use multifactor within your applications. - -[Guardian for Users](/multifactor-authentication/guardian/user-guide) - this page is for users logging into your application using Guardian, Google Authenticator or SMS. It also has troubleshooting tips for any issues they may encounter. diff --git a/articles/multifactor-authentication/guardian/user-guide.md b/articles/multifactor-authentication/guardian/user-guide.md deleted file mode 100644 index 29af26598f..0000000000 --- a/articles/multifactor-authentication/guardian/user-guide.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -description: How to sign-up and login using the Guardian app. -toc: true ---- -# How to Use the Guardian App - -Guardian is an app that can be downloaded from the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833) or from [Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian). The Guardian app is used for two-factor authentication when logging into an application, which helps create a more secure login. With two-factor authentication you will always need your mobile device when you log in. - -This page will help to explain how to sign up and log in using the Guardian app and using other forms of two-factor authentication. - -## Enroll for MFA - -Enrolling for MFA is a separate, distinct step from the initial sign-up for Auth0. Typically, the user is prompted to enroll the first time they attempt to sign-in to an application protected by MFA. Additionally, administrators have the ability to [invite users to enroll](multifactor-authentication/administrator/guardian-enrollment-email). - -If you choose to enroll from the Guardian widget, then following your initial authentication you will see the option to download the Auth0 Guardian app from the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833) or from [Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian). - -Underneath that, there is the option to use [Google Authenticator](#google-authenticator) or [SMS](#sms) depending on the application's settings. - -![Guardian widget enroll](/media/articles/mfa/choose-mfa.png) - -Choose the type of two-factor to use: the Guardian app, the Google Authenticator app, or an SMS. - -### Guardian - -To use the Guardian app, first download either the [iOS](https://itunes.apple.com/us/app/auth0-guardian/id1093447833) or [Android](https://play.google.com/store/apps/details?id=com.auth0.guardian) app depending on the type of device you have. Once you have Guardian downloaded, click **I've already downloaded it**. - -Next, a code will appear, you will have five minutes to scan the code before it expires. Open the Guardian app and scan the code. - -![Guardian code](/media/articles/mfa/guardian-code.png) - -After the code has been successfully scanned, you will see a confirmation screen which includes a recovery code. If for some reason you do not have your mobile device, you will need this recovery code to login. Make sure to take note of this code and keep it somewhere safe. Check the box that you have recorded the code, and then you are logged in. - -![Guardian recover code](/media/articles/mfa/guardian-recover-code.png) - -::: panel Passphrase for Android Users -After first enrolling using the Guardian app for Android, you will be required to create a passphrase. This recovery passphrase will not be required every time you use the app, but could be required when your lock screen security options have been changed. You can use the suggested passphrase or create your own. - -
    Android Passphrase Example
    -::: - - -### Google Authenticator - -If you would prefer to use the Google Authenticator app, click on the link for Google Authenticator. You will need to download Google Authenticator for [Android](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) or [iOS](https://itunes.apple.com/us/app/google-authenticator/id388497605). - -A code will appear, and you will have five minutes to scan the code before it expires. After scanning the code, you will get a six digit code to enter. Once you enter this code, you will see a confirmation screen which has a recovery code. If for some reason you do not have your mobile device, you will need this recovery code to login. Make sure to take note of this code and keep it somewhere safe. Check the box that you have recorded the code, and then you are logged in. - -![Google Authenticator code](/media/articles/mfa/google-code.png) - -For more information about Google Authenticator, see [Install Google Authenticator](https://support.google.com/accounts/answer/1066447). - -### SMS - -Depending on the applications settings, SMS may be an option to use for two-factor authentication. Click on the the **SMS** link after entering your email and password. - -Then select your phone number's country code and enter your mobile phone number. You must be able to receive SMS to your device to use this option. - -![SMS enroll](/media/articles/mfa/sms.png) - -Then you should receive a six digit code in a message to your phone. Enter this code into the box. Then you will see a recovery code, make sure to note this code as you will need it to login if you do not have your device. Check the box that you have recorded the code, and then you are all set and logged in. - -## Log in - -Depending on the type of two-factor authentication you chose when you were signing up, this will affect how you login. - -### Guardian - -After entering your username and password, a push notification will be sent to the Guardian app on your mobile device. This notification is a login request, it includes the application name, the OS and browser of the request, the location and the date of the request. If you recognize this request as your own, tap the **Allow** button. You should now be logged in. - -If you are not currently connected to the internet on your mobile device to receive push notifications, you can enter the OTP (One-time password) manually by clicking "enter the code". - -![Enter code at Guardian widget](/media/articles/mfa/guardian-enter-code.png) - -To find this code, go into the Guardian app on your device, and click on the application you are trying to log into. Then you should see information on your last sign in and a 6-digit code at the bottom which is your OTP. - -
    Lock-iOS
    - -Enter this code to finish signing in. - -::: panel Rate Limits - -Each hour, you are allotted a maximum of ten failed SMS attempts. After that, Auth0 considers all OTP codes invalid, and any additional attempts to log in results in a `Too Many Attempts` error. - -More specifically, this means that if you enter in the code incorrectly ten or more times within an hour, you will need to wait six minutes to gain another attempt. If you attempt another code before sufficient time has elapsed, Auth0 will consider any OTP code you enter as invalid (even if they aren't expired). -::: - -If you do not have your mobile device available to you during sign in, you can enter the recovery code that was given when you signed up by clicking the "Use the Recovery Code" link. - -### Google Authenticator - -After entering your username and password, you will be prompted for a six digit code. Open the Google Authenticator app on your mobile device to find the correct code. If you use Google Authenticator for other applications as well, make sure you are using the code for the current application. After entering the six digit code you will be logged in. - -If you do not have your mobile device available to you during sign in, you can enter the recovery code that was given when you signed up by clicking the "Use Recovery Code" link. - -### SMS - -After entering you enter your email and password, a SMS message will be sent to the phone number you entered when you signed up. Enter the six digit code from the message into the box to complete your login. - -If you do not have your mobile device available to you during sign in, you can enter the recovery code that was given when you signed up by clicking the "Use Recovery Code" link. - -## Troubleshooting - -### If you do not have your mobile device or it is turned off - -If you have lost your device you can finish the two-step authentication with the recovery code from when you signed up. After entering your email and password to login, click the link that says "Use the recovery code" to access your account without using your device. - -If you don't have your recovery code you will not be able to login. Contact your system administrator for help accessing your account. - -### If you forgot your password - -If you forgot your password when you are trying to login, click **Don't remember your password?** underneath the login. Enter your email to receive an email that will contain a link to reset your password. - -### If your OTP is not being accepted - -If the 6-digit code in the Guardian or the Google Authenticator app are being rejected for sign in, first check that you are selecting the right application from the list on the landing page of each application. You should see the name of the application and the email you are using for sign in, make sure these are correct. - -If you know you are selecting the correct connection, make sure that your mobile device's clock settings are correct. One-time passwords are generated using Coordinated Universal Time(UTC) so your device time must be correct to generate the correct OTP. - -### Transaction Expiration - -For all types of multifactor authentication types there is a five minute expiration. Check the timestamp on the messages to see if it is still valid when trying to login. If it has been longer than five minutes, you will need to try to login again and get a new code or notification. - -If using SMS, make sure you are not [exceeding rate limits](#sms-rate-limits). - -### If you did not receive a SMS - -If you did not receive your six digit code via SMS, check that the phone number you entered is correct. If it is the correct number, make sure you have a cellular signal. If you still are not receiving the messages, check with your service provider to confirm that messages are not getting blocked. - -### SMS Rate Limits - -If you attempt to send more than ten SMS to your device within an hour, you will see an error message about a rate limit exception. If you have exceeded the limit of ten, you will need to wait at least an hour from your first SMS send to send another message. Each hour after the first attempt you will gain one more message request maxing out at ten requests. diff --git a/articles/multifactor-authentication/index.md b/articles/multifactor-authentication/index.md deleted file mode 100644 index 077fb1de81..0000000000 --- a/articles/multifactor-authentication/index.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Multifactor Authentication in Auth0 -description: The basics of multifactor authentication and the different methods of implementing it with Auth0. -url: /multifactor-authentication ---- - -# Multifactor Authentication in Auth0 - -Multifactor Authentication (MFA) is a method of verifying a user's identity by requiring them to present more than one piece of identifying information. This method provides an additional layer of security, decreasing the likelihood of unauthorized access. The type of information required from the user is typically two or more of the following: - -* **Knowledge**: Something the user knows (such as a password) -* **Possession**: Something the user has (such as a cell phone) -* **Inheritance**: Something the user is (such as a fingerprint or retina scan) - -## Implementing MFA with Auth0 - -Auth0 supports the following methods of implementing MFA: - -1. [Push Notifications (Auth0 Guardian)](/multifactor-authentication#mfa-using-push-notifications-auth0-guardian-) - Auth0's mobile application Guardian sends push notifications for MFA -2. [SMS (Auth0 Guardian)](/multifactor-authentication#mfa-with-sms) - Verification by sending a six-digit code via SMS -3. Support for one-time password authentication services [Google Authenticator](/multifactor-authentication#mfa-using-google-authenticator) and [Duo Security](/multifactor-authentication#mfa-using-duo-security). -4. [Configuring rules for custom processes](/multifactor-authentication#mfa-using-custom-rules) - such as Contextual MFA, which allows you to define the conditions that will trigger additional authentication challenges, such as changes in geographic location or logins from unrecognized devices. -5. Using a [custom provider](/multifactor-authentication#mfa-using-a-custom-provider), such as **Yubikey**. - -## MFA using Push Notifications (Auth0 Guardian) - -
    Guardian Push Screenshot
    - -Guardian is Auth0's MFA application. It is a frictionless approach to implementing MFA for your apps, and provides a full MFA experience without requiring integration with third-party utilities. - -[Click here to learn more about enabling push notifications with Guardian](/multifactor-authentication/guardian) - -## MFA with SMS - -
    MFA SMS Screenshot
    - -Auth0 supports sending an SMS with a one-time password code to be used for another step of verification. - -[Click here to learn more about enabling SMS](/multifactor-authentication/guardian/admin-guide#support-for-sms) - -## MFA Using Google Authenticator - -
    Screenshot of Google Authenticator
    - -Google Authenticator is a mobile app that generates 2-step verification codes. This creates a one-time use password that is used as the second factor after your user has attempted to log in with their Google credentials. - -[Click here to learn more about enabling Google Authenticator](/multifactor-authentication/google-authenticator) - -## MFA Using Duo Security - -
    DUO Screenshot
    - -Duo Security allows you to request either of the following as your second factor once the user has provided their initial login credentials: - -* A user response to a push notification sent to the appropriate device -* A passcode provided to the user via SMS - -[Click here to learn more about enabling Duo](/multifactor-authentication/duo) - -## MFA Using Custom Rules - -You may [configure rules](/rules) for custom MFA processes, which allow you to define the conditions that will trigger additional authentication challenges, such as changes in geographic location or logins from unrecognized devices. - -[Click here for sample code snippets](/multifactor-authentication/custom) to assist you in building your rules here. - -## MFA Using a Custom Provider - -For a detailed look at implementing a custom MFA provider, see [Multifactor Authentication with YubiKey-NEO](/multifactor-authentication/yubikey) as an introduction. - -## User-initiated MFA - -For details on how to implement user-initiated MFA, so you can flag users for MFA as part of the user creation/login process, refer to [User-Initiated Multifactor Authentication](/multifactor-authentication/user-initiated-mfa). diff --git a/articles/multifactor-authentication/touchid.md b/articles/multifactor-authentication/touchid.md deleted file mode 100644 index 3fa009783f..0000000000 --- a/articles/multifactor-authentication/touchid.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Links to documentation for Touch ID. ---- -# Touch ID Settings - -Below you can find useful links in our documentation to handle Touch ID within Auth0. - -- [Authenticate users with Touch ID in iOS](/connections/passwordless/ios-touch-id-swift) -- [Touch ID Authentication](/libraries/lock-ios/touchid-authentication) -- [Passwordless authentication using Touch ID & JWT](https://github.com/auth0/TouchIDAuth) -- [Touch ID and React Native](https://auth0.com/blog/2015/04/03/using-touchid-for-authentication-in-your-react-native-app/) diff --git a/articles/multifactor-authentication/user-initiated-mfa.md b/articles/multifactor-authentication/user-initiated-mfa.md deleted file mode 100644 index 2a10875b63..0000000000 --- a/articles/multifactor-authentication/user-initiated-mfa.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: User-Initiated Multifactor Authentication (MFA) -description: How to set up user-initiated multifactor authentication -toc: true ---- -# User-Initiated Multifactor Authentication - -In this tutorial, we will show you how to implement and enable user-initiated multifactor authentication (MFA). We will cover how to: - -* Enable MFA using Auth0's Management Dashboard -* Programmatically flag new users for MFA -* Set the users up to initiate MFA enrollment when logging in for the first time. - -## Enable Multifactor Authentication - -You can enable Multifactor Authentication (MFA) using the Dashboard. - -Log in to your Auth0 account and navigate to the [**Multifactor Auth** page of the Management Dashboard](${manage_url}/#/guardian). - -![](/media/articles/mfa/mfa-home.png) - -You'll have the option to enable MFA that uses either **Push Notifications** or **SMS**. You can also use both. Click the slider(s) next to the option(s) you want enabled. - -Once you've enabled one or more types of MFA, you'll see the **Customize MFA** section, which is a text editor that allows you to write the code to determine when MFA is necessary. The code runs as part of your [rules](/rules) whenever a user logs in. - -![](/media/articles/mfa/mfa-template.png) - -To help you get started, you'll see a template you can modify. Additional templates that implement various MFA features are available under **Templates**, which is located to the top right of the code editor. - -As an example, the follow code snippet calls for MFA when: - -* The application specified is used -* The user's `app_metadata` has a `use_mfa` flag set to `true` - -Finally, if the two parameters above are met, MFA occurs every login. - -```js -function (user, context, callback) { - - // run only for the specified applications - var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; - - if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { - if (user.app_metadata && user.app_metadata.use_mfa){ - - context.multifactor = { - // required - provider: 'guardian', - - // set to false to force Guardian authentication every login - allowRememberBrowser: false - }; - } - } - - callback(null, user, context); -} -``` - -## Flag New Users for MFA - -In this step, we'll add functionality within the user creation/login process that flags users for MFA. - -You'll need to [get an Access Token](/api/management/v2/tokens) to call the [Management API](/api/management/v2) during the user creation process. The only scope that you need to grant to the issued token is `update:users_app_metadata`. - -Using this token, you can place a flag on app_metadata that indicates whether MFA is needed whenever that user logs in. More specifically, you'll be programmatically setting their the user's `app_metadata` field with `use_mfa = true`. - -You can do this by making the appropriate `PATCH` call to the [Update a User endpoint of the Management API](/api/management/v2#!/Users/patch_users_by_id). Note that the body of the call omits most of the extra details (such as email and phone number) you might need to include. - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/api/v2/users/USER_ID", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [{ - "name": "Authorization", - "value": "Bearer MGMT_API_ACCESS_TOKEN" - }], - "queryString": [], - "postData": { - "mimeType": "application/json", - "text": "{ \"blocked\": false, \"email_verified\": false, \"email\": \"\", \"verify_email\": false, \"phone_number\": \"\", \"phone_verified\": false, \"verify_phone_number\": false, \"password\": \"\", \"verify_password\": false,\"user_metadata\": {},\"app_metadata\": { \"use_mfa\": true }, \"connection\": \"\", \"username\": \"\",\"client_id\": \"DaM8...rdyX\"}" - }, - "headersSize": -1, - "bodySize": -1, - "comment": "" -} -``` - -## Initiate Guardian Enrollment - -In this step, we'll initiate Guardian Enrollment for users who have been flagged for MFA. Note that you can use any MFA provider that integrates with Auth0 -- you do not necessarily have to use Guardian. - -You'll need to [get an Access Token](/api/management/v2/tokens) to call the [Management API](/api/management/v2). The only scope that you need to grant to the issued token is `create:guardian_enrollment_tickets`. You might consider adding both scopes to the Access Token when you make the initial request in the [previous step](#flag-new-users-for-mfa) in lieu of making two separate requests, each resulting in a token with a different scope. - -You can enroll a user in Guardian MFA by making the appropriate `POST` call to the [Create a Guardian Enrollment Ticket endpoint of the Management API](/api/management/v2#!/Guardian/post_ticket). - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/api/v2/guardian/enrollments/ticket", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [{ - "name": "Authorization", - "value": "Bearer MGMT_API_ACCESS_TOKEN" - }], - "queryString": [], - "postData": { - "mimeType": "application/json", - "text": "{ \"user_id\": \"\", \"email\": \"\", \"send_mail\": false }", - "headersSize": -1, - "bodySize": -1, - "comment": "" - } -} -``` diff --git a/articles/multifactor-authentication/yubikey.md b/articles/multifactor-authentication/yubikey.md deleted file mode 100644 index 3f43e3f260..0000000000 --- a/articles/multifactor-authentication/yubikey.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -description: How to implement Multifactor Authentication Using YubiKey NEO. -toc: true ---- -# Multifactor Authentication with YubiKey NEO - -This tutorial shows you how to implement Multifactor Authentication (MFA) using [YubiKey NEO](https://www.yubico.com/products/yubikey-hardware/yubikey-neo/). - -Implementing MFA using YubiKey NEO requires use of the following Auth0 features for the described reasons: - -| Feature | Usage | -| - | - | -| [Webtask](https://webtask.io) | Hosts the website where the user undergoes the second authentication factor using YubiKey | -| The [Redirect Protocol](/rules/redirect) | Redirects the user to the website that performs the second authentication factor using YubiKey | -| [Rule](/rules) | Evaluates whether the conditions you set for triggering MFA have been met or not | - -In this tutorial, we will walk you through the configuration required for the Webtask, redirect protocol, and rules. - -## Configure the Webtask - -The first thing we'll do is create the website where the user completes the second authentication step using YubiKey. We'll use a Webtask, which allows you to run code using the Auth0 sandbox, to host the site. More specifically, the Webtask will: - -* **Render** the UI with the `otpForm` function -* **Capture** the YubiKey NEO code and validate it using the Yubico API -* **Return** the result of the validation to Auth0 -- if successful, Auth0 continues to process the login transaction - -### Step 1: Create the Webtask Code - -Webtask runs code you provide, so we'll begin by creating the code needed. We've provided you with a [fully-functional sample](https://github.com/auth0/rules/blob/master/redirect-rules/yubico-mfa.md), which you need to save locally in a file called `yubico-mfa-wt.js`. - -Within the code provided is a redirect URL to Auth0. It contains querystring parameters called `id_token` and `state`. The `id_token` parameter is used to transfer information back to Auth0. The `state`parameter is used to protect against CSRF attacks. - -No actual key values are hard-coded into the Webtask code. Your Yubico Client ID and Secret values are referred to using `context.data.yubico_clientid` and `context.data.yubico_secret`. These parameters are securely embedded in the Webtask token when you created the Webtask. - -### Step 2: Initialize the Webtask CLI - -Now that we have the code for our Webtask, we'll need to create the Webtask itself. We do this using the Webtask CLI. - -To use the Webtask CLI, you'll need to install it using instructions that can be found under [Tenant Settings > Webtasks](${manage_url}/#/tenant/webtasks) on the Auth0 Dashboard. - -![](/media/articles/mfa/yubi-1.png) - -Once you've installed the Webtask CLI, run the following code after you've replaced the placeholders with your Yubico Client ID and Secret values (make sure that the Webtask CLI can access to location where you have your `yubico-mfa-wt.js` file): - -```txt -wt create --name yubikey-mfa --secret yubikey_secret={YOUR YUBIKEY SECRET} --secret yubikey_clientid={YOUR YUBIKEY CLIENT ID} --secret returnUrl=https://${account.namespace}/continue --profile {WEBTASK PROFILE} yubico-mfa-wt.js -``` - -::: note -You can get your `WEBTASK PROFILE` value (needed for the-p parameter shown at the end of the code above) in **Step 2** of the Webtask installation instructions shown on the [Tenant Settings > Webtasks](${manage_url}/#/tenant/webtasks) page. -::: - -Running the `create` command as shown above will generate a URL that looks like this: - -```txt -https://sandbox.it.auth0.com/api/run/${account.tenant}/yubikey-mfa?webtask_no_cache=1 -``` - -Keep a copy of this URL. - -## Create the Rule - -This sample uses a single rule that handles: - -* The initial redirect to the Webtask -* The returned result - -Here is what the rule looks like: - -```js -function (user, context, callback) { - var jwt = require('jsonwebtoken@5.7.0'); - var yubikey_secret = configuration.YUBIKEY_SECRET; - - //Returning from OTP validation - if(context.protocol === 'redirect-callback') { - var decoded = jwt.verify( - context.request.query.id_token, - new Buffer(yubikey_secret,'base64') - ); - if (!decoded) { return callback(new Error('Invalid OTP')); } - if (decoded.status !== 'OK') { return callback(new Error('Invalid OTP Status')); } - - return callback(null,user,context); - } - - //Trigger MFA - context.redirect = { - url: configuration.WEBTASK_URL + "?user=" + user.name - }; - - callback(null,user,context); -} -``` - -You also need to create two new settings on [Rules](${manage_url}/#/rules): - -* One using `WEBTASK_URL` as the key, and the URL returned by the `create` command as the value. -* Another using `YUBIKEY_SECRET` as the key, and `{YOUR YUBIKEY SECRET}` passed to `create` as the value. - -::: note -The returning section of the rule validates the JWT issued by the Webtask. This prevents the result of the MFA part of the transaction from being tampered with because the payload is digitally signed with a shared secret. -::: - -Some notes regarding the rule code: - -* The `context.redirect` statement instructs Auth0 to redirect the user to the Webtask URL instead of calling back to the app -* The return is indicated by the `protocol` property of the `context` object -* The section handling the return validates the JWT issued by the Webtask to ensure that the result of MRA hasn't been tampered by an unauthorized party - -You'll [create the rule using the Management Dashboard](${manage_url}/#/rules). - -![](/media/articles/mfa/yubi-2.png) - -Click **Create Your First Rule** (or **Create Rule** if you've already created rules before). Choose **empty rule**. - -![](/media/articles/mfa/yubi-3.png) - -You'll see the following editor window where you can paste in the rule code above. - -![](/media/articles/mfa/yubi-4.png) - -You can test your code for correctness using **Try This Rule**. When done, click **Save** to proceed. - -You also need to create two new Settings for your [Rules](${manage_url}/#/rules): - -| Setting | Value | -| - | - | -| `WEBTASK_URL` | The URL you saved after running the `CREATE` command in the Webtask CLI | -| `YUBIKEY_SECRET` | Your YubiKey client secret | - -With these settings, you can access the provded values in your rules code using the configuration global object (such as `configuration.WEBTASK_URL`). - -![](/media/articles/mfa/yubi-5.png) - -With this rule in place, the user will be redirected to the Webtask after every login. They will see the following prompt for their second factor: - -![](/media/articles/mfa/yubico-mfa.png) - -### Customize the Rule - -You can add logic to the rule to determine which conditions the challenge will be triggered based on: - -You can add logic to the rule to set the conditions under which the MFA challenge will be triggered. Some examples include: - -* The IP address or location of the user -* The application the user is logging into -* The type of authentication used (such as AD, LDAP, or Social) - -## Keep Reading - -::: next-steps -* [Rules](/rules) -* [Multi-factor in Auth0](/multifactor-authentication) -* [Auth0 Webtask](https://webtask.io/) -::: diff --git a/articles/onboarding/appliance-sprint.md b/articles/onboarding/appliance-sprint.md index 4be0f84ad8..1beb874949 100644 --- a/articles/onboarding/appliance-sprint.md +++ b/articles/onboarding/appliance-sprint.md @@ -2,8 +2,15 @@ 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. @@ -48,4 +55,4 @@ The following sections describe what happens during each step of the PSaaS Appli ## What's next? -Once the PSaaS Appliance is deployed, an Auth0 Customer Success Manager will work with you to complete the rest of the [Sprint onboarding program](https://auth0.com/docs/onboarding/sprint) - the end result being a joint success plan to drive value throughout the subscription lifecycle. +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/articles/onboarding/cloud-sprint.md b/articles/onboarding/cloud-sprint.md deleted file mode 100644 index 7384806f9b..0000000000 --- a/articles/onboarding/cloud-sprint.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -sitemap: false -description: An overview of the steps in the Cloud Sprint onboarding program. ---- - -# Cloud Sprint - -## Auth0 Customer Onboarding Program - -Cloud Sprint is Auth0’s onboarding program for enterprise customers. It helps you achieve value quickly with your Auth0 enterprise cloud subscription. The 6 steps in the onboarding program set both you and Auth0 up for success. - -## Cloud Sprint Overview - -![Cloud Sprint Program Overview](/media/articles/onboarding/cloud-sprint-program-overview.png) - -[Download the Cloud Sprint PDF here.](/media/articles/onboarding/cloud-sprint-onboarding.pdf) - -Hours allocated as consulting, are delivered by our services team of system architects and software engineers for the purpose of guiding you through the common technical requirements, questions, advice and best practices to get successfully started with Auth0. - -If you have complex requirements needing deeper consulting and advice from our experts than the time allocated here will allow then ask your Sales Executive about purchasing [Professional Services](/services) hours. These hours can be used for services including: -- Systems architecture design consulting -- Software development assistance related to integration of your application to Auth0 -- Data migration from 3rd party/proprietary databases -- Performance & load testing - -## Cloud Sprint: Details & Resources - -### Step 1. Welcome & Orientation - -**When?** This session is generally booked within 5 days of signing your subscription agreement. - -**What?** Our Customer Success team are devoted to learning more about your business and what you want to achieve with Auth0. In this short, casual session our Customer Success Managers will ask lots of questions and do lots of listening. - -[Cloud Sprint - Get Started Form](https://docs.google.com/a/auth0.com/forms/d/1R0vq5DQxdbgdE0kkJPcruKXiFdZpddLV_P5wlTQwOfE/viewform) - Spend 5 minutes to fill out this form. This can help speed up the process of your subscription being applied your correct Auth0 account or help us provision a new one so you can access it ASAP! - -[Auth0 support resources and guidance for enterprise customers.](/onboarding/enterprise-support) - Already developing? No need to wait, you can plug in to our support resources immediately! - -### Step 2. Technical Discovery & Guidance - -**When?** This session is generally booked within 14 days of signing your subscription agreement. - -**What?** The goal of this technical session is to send you forward on the best path. It’s an opportunity for our Customer Success Engineers to understand your software architecture and integration plans and for your team to ask questions or seek advice. - -[Common Architecture and Scenarios](/architecture-scenarios) - Quick guidance on common Business Scenarios and Application Configurations and the things you need to know to get started. - -[Auth0 Learn Resources](https://auth0.com/learn/) - Explore these resources for guidance on topics including Refresh Tokens, 2FA, implementing SSO and migrating existing user data. - -### Step 3. Management Dashboard Guidance -**When?** You can access self service resources immediately. A live session is generally booked soon after the Technical Discovery & Guidance session. - -**What?** The goal of this light technical session is to familiarize your team with the Auth0 Management Dashboard to understand both some of the administrative elements (such as setting up new Dashboard Admin users) as well as functional elements. - -[Comprehensive Dashboard Walkthrough](https://youtu.be/hkMHBXRImPk?t=8m9s) - This 40 minute video walks you through many elements of the Auth0 Dashboard in a practical manner. - -### Step 4. Customer Integration -**When?** Varies by customer and project. - -**What?** This is where it all comes together and your team integrates Auth0 with your application/project. Our support resources are always there to help and our Customer Success Managers will be following your progress and removing any blockers. - -[Auth0 support resources and guidance for enterprise customers.](/onboarding/enterprise-support) - Our support resources are there to help during implementation and integration. - -### Step 5. Integration Best Practice Review -**When?** Soon after your initial implementation or integration and before you move to beta/UAT or production. - -**What?** In this technical session, our Customer Success Engineers will review your implementation and integration to ensure best practices are applied. This often includes reviewing rules you’ve written, how you’re calling our APIs and answering any questions you may have. - -[Auth0 Learn Resources](https://auth0.com/learn/) - Explore these resources for guidance on topics including Refresh Tokens, 2FA, implementing SSO and migrating existing user data. - -Pre-Production Checklist: This list will walk through basic checks to make in Auth0 to ensure a smooth production launch (Coming soon). - -### Step 6. Achieve First Value Goal -**When?** 30-45 days after signing your subscription agreement. - -**What?** Ultimately, this is the goal our team will be focused on moving towards as the outcome of the onboarding process. It’s something we’ll agree on with you in Step 1. diff --git a/articles/onboarding/enterprise-support.md b/articles/onboarding/enterprise-support.md index 39587737cd..1a2979c5fe 100644 --- a/articles/onboarding/enterprise-support.md +++ b/articles/onboarding/enterprise-support.md @@ -1,7 +1,15 @@ --- toc: true section: appliance -description: Outlines the Auth0 enterprise support options, definitions, coverage offered and procedures to follow for the best support experience. +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 @@ -14,7 +22,7 @@ Refer to your subscription agreement to confirm which support offering is includ 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 __Customer Success Manager__: Your Auth0 Customer Success 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 Customer Success Manager. +- 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) @@ -73,9 +81,9 @@ 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: (http://status.auth0.com) - * EU Region: (http://status.eu.auth0.com) - * APAC Region: (http://status.au.auth0.com) + * 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 @@ -106,10 +114,10 @@ To speed resolution, please provide the following when logging an issue: * 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](/har) +* HTTP trace in the form of a [HAR file](/troubleshoot/guides/generate-har-files) -*For PSaaS Appliance Customers*: +*For Private Cloud Customers*: -* PSaaS Appliance version/build number (top left hand corner of configuration screen on config tenant, such as https://yourmanage.yourdomain.com/configuration#/) +* 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/articles/onboarding/sprint.md b/articles/onboarding/sprint.md deleted file mode 100644 index 598a4aad4b..0000000000 --- a/articles/onboarding/sprint.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -sitemap: false -description: An overview of Auth0’s onboarding program for enterprise customers. ---- -# Auth0 Sprint Onboarding - -Sprint is Auth0’s enterprise customer onboarding program. It helps you achieve value quickly by ensuring your setup for success with your Auth0 subscription. - -All customer's who subscribe to a qualifying 12 month+ subscription agreement obtained through our enterprise sales team will be offered access to Sprint Onboarding. However, the engagement varies slightly based on your subscription value, additions and support option. - -## Sprint Onboarding Overview - -### Goal - -During the onboarding process, the Auth0 Customer Success Team’s goal is to fulfill our obligation to: - -* Have your subscription tenant correctly provisioned and setup in our systems (including the [PSaaS Appliance deployment project](/onboarding/appliance-sprint) in the case of on-premise/private-cloud managed service customers) -* Receive information from you that our Customer Success Managers will use to engage with you, measure success and manage your subscription throughout its various lifecycles -* Provide information to you around accessing and utilizing informational, training and support resources to meet your success goals -* Offer high level initial technical architecture guidance and plug you in to our Professional Services offerings if deeper guidance or hands-on development/implementation assistance is desired - -The outcome of these obligations is a Success Plan that will be co-managed by your lead contact and the Auth0 Customer Success Management team. - -### Sprint Onboarding Activities by Subscription - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Sprint StarterSprint BusinessSprint Jumpstart
    Qualifying CustomersEnterprise planEnterprise plan over USD$25k annual subscriptionEnterprise plan with Jumpstart or Preferred Support additions
    Customer Success engagementCustomer Success teamAllocated Customer Success ManagerAllocated Customer Success Manager
    Orientationdelivered via online assetsLive 1:1 orientation session* and online assetsLive 1:1 orientation session* and online assets
    Architecture guidanceDelivered via online assets and webinarsDelivered via online assets and webinars, with CSM able to co-ordinate other limited guidanceDelivered in Jumpstart services engagement
    Auth0 foundations trainingDelivered via online assets and webinarsDelivered via online assets and webinars, with CSM able to co-ordinate other limited trainingDelivered in Jumpstart services engagement
    Auth0 advanced trainingLimited online assets and optional Services Engagement for additional feeLimited online assets and optional Services Engagement for additional feeLimited online assets and optional Services Engagement for additional fee
    Success PlanTemplated, self-serve. Completed plan reviewed with Customer Success TeamCustom, built in consultation with Success ManagerCustom, built in consultation with Success Manager
    - -* *Live sessions are delivered remotely via web conference.* - -### Timing - -The Sprint program isn’t bound by a specific time restriction, but rather it’s considered completed on delivery of the obligations and the Success Plan. For customers with a Cloud subscription, this usually takes between 1 and 3 weeks. For customers with an on-premise or private cloud managed service it can take up to 6 weeks. Sprint onboarding ends when the final Success Plan is shared with you. - -### What happens next? - -At the conclusion of the Sprint program, our Customer Success Management team will continue to monitor your progress against the Success Plan and work with you throughout different stages of the subscription lifecycle or when things are not moving to plan. This can mean a number of different activities and interactions depending on where you’re at in the development lifecycle and based on your subscription. - -Aside from engagement with our Customer Success Management team, you’ll have many other resources to move you along the journey as introduced to you in the Sprint program - this includes our support team, community forums, documentation, videos and webinars. - -The table below outlines examples of the different ongoing engagement delivered by the Customer Success Management team based on your subscription. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Enterprise planEnterprise plan over USD$25k annual subscriptionEnterprise plan over USD$100k annual subscription
    Customer Success engagementCustomer Success team, predominantly digital engagementAllocated Customer Success ManagerAllocated Customer Success Manager with small subscriber management ratio and more strategic engagement
    Pre-launch best practices reviewdelivered via online assetsLive 1:1 session* and online assetsLive 1:1 session* and online assets
    Success Plan management and reviewWhen off planAt key subscription milestones, annual reviews and when off planOngoing with allocated Customer Success Manager
    Executive business reviewsNAAnnualQuarterly or as required
    - -* *Live sessions are delivered remotely via web conference.* diff --git a/articles/policies/billing.md b/articles/policies/billing.md index 08b284aad0..2de85a2518 100644 --- a/articles/policies/billing.md +++ b/articles/policies/billing.md @@ -1,6 +1,13 @@ --- 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 @@ -79,22 +86,35 @@ 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 username/password, a passwordless connection or any social provider in the last 30 days, counted per application. +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. -For example, if a person logs in to Application 1 through Facebook, then logs in to Application 2 through Google and then logs in to Application 2 using username/password, that would count as 3 active users, even if it's just one individual. +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, rather than per active user/per app. +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/articles/policies/dashboard-authentication.md b/articles/policies/dashboard-authentication.md index 4b219958e6..23d1a8d253 100644 --- a/articles/policies/dashboard-authentication.md +++ b/articles/policies/dashboard-authentication.md @@ -1,33 +1,38 @@ --- 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. -## Multifactor Authentication +## Multi-factor Authentication -You can enable multifactor authentication for logging in to the dashboard with your account. +You can enable multi-factor authentication for logging in to the dashboard with your account. -To enable multifactor authentication for 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 **Multifactor** section. +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.](/multifactor-authentication) +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 Multifactor +### Unenrolling a Device from Multi-factor -To stop using multifactor authentication to log in to your dashboard: +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 **Multifactor** section and click the **REMOVE** button next to the enrolled device. -3. To verify this request you will need to login once more with multifactor authentication. - -If you have lost your device after enrolling in MFA or are having trouble logging in after enabling MFA, [click here for troubleshooting tips.](/multifactor-authentication/guardian/user-guide#troubleshooting) +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 @@ -39,4 +44,4 @@ 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 grandfathered and allowed to continue. +Any accounts with special dashboard authentication implemented before the effective date of this policy shall be allowed to continue. diff --git a/articles/policies/data-export.md b/articles/policies/data-export.md index 45f2d66948..e4442cef34 100644 --- a/articles/policies/data-export.md +++ b/articles/policies/data-export.md @@ -1,9 +1,17 @@ --- 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. +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 @@ -13,6 +21,6 @@ You can use our [Import/Export Extension](/extensions/user-import-export) to exp 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](/api/management/v2/user-search) as well as the [query syntax](/api/management/v2/query-string-syntax) that can be used +* 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/articles/policies/data-transfer.md b/articles/policies/data-transfer.md index fd9b19cd9e..e3cd3206a9 100644 --- a/articles/policies/data-transfer.md +++ b/articles/policies/data-transfer.md @@ -1,10 +1,18 @@ --- 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 Cloud and PSaaS Appliance customers. +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. @@ -14,5 +22,6 @@ If you are opting to move out from our service, then you might want to check [th * 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/articles/policies/endpoints.md b/articles/policies/endpoints.md index 5d564a4adb..0ad9cc03ba 100644 --- a/articles/policies/endpoints.md +++ b/articles/policies/endpoints.md @@ -1,25 +1,32 @@ --- description: Lists all the endpoints used by Auth0 public cloud service. +topics: + - auth0-policies + - endpoints +contentType: + - reference +useCase: + - support --- -# Endpoints used by Auth0 public cloud service +# Auth0 Public Cloud Service Endpoints The following endpoints are used by Auth0 public cloud service: -## US Region +## United States Region * https://manage.auth0.com * https://auth0.com -* https://login.auth0.com -* https://cdn.auth0.com -* https://{YOUR ACCOUNT}.auth0.com -* https://{YOUR ACCOUNT}.guardian.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 -## EU & AU Regions +## 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}.[eu|au].guardian.auth0.com +* https://{YOUR ACCOUNT}.guardian.[eu|au].auth0.com diff --git a/articles/policies/entity-limits.md b/articles/policies/entity-limits.md new file mode 100644 index 0000000000..24f00d44c1 --- /dev/null +++ b/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/articles/policies/index.md b/articles/policies/index.md index 78c5d18d69..f404b79512 100644 --- a/articles/policies/index.md +++ b/articles/policies/index.md @@ -1,6 +1,12 @@ --- url: /policies -description: This page lists all of Auth0's established operational policies. +description: List of all of Auth0's established operational policies. +topics: + - auth0-policies +contentType: + - index +useCase: + - support --- # Operational Policies @@ -15,5 +21,6 @@ Auth0 has established the following operational policies. - [Penetration Testing](/policies/penetration-testing) - [Migrations](/migrations) - [Rate Limits](/policies/rate-limits) -- [Restoration of a Deleted Tenant](/policies/restore-deleted-tenant) -- [Support Requests](/policies/requests) \ No newline at end of file +- [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/articles/policies/legacy-rate-limits.md b/articles/policies/legacy-rate-limits.md new file mode 100644 index 0000000000..a1ddda609d --- /dev/null +++ b/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/articles/policies/load-testing.md b/articles/policies/load-testing.md index a9a89d2ae2..fe8a00fbdb 100644 --- a/articles/policies/load-testing.md +++ b/articles/policies/load-testing.md @@ -1,64 +1,71 @@ --- description: This page details Auth0's Load Testing Policy. +topics: + - auth0-policies + - load-testing + - testing +contentType: + - reference +useCase: + - support --- - # Load Testing Policy -Load testing against the Auth0 production cloud service is not permitted at any time, as stated in our [Terms of Service](https://auth0.com/terms). - -Customers who have purchased an enterprise support plan that includes load testing may request one load test (with up to 2 repeats) to conduct load testing against an Auth0 test instance. For load tests that require more than 100 RPS a separate environment will have to be created and it will have a different time schedule than normal load tests. +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. -## How to request +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. -* Customers must file a load testing request in writing, via the [Auth0 support center](${env.DOMAIN_URL_SUPPORT}). -* Requests must be filed at least two (2) weeks in advance of the desired test date. -* Requests must be approved in writing before any load/performance testing is conducted. +::: 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. +::: -* Customers must have configured their own email provider within the Auth0 dashboard (Email -> Providers) before a load testing request will be approved. +## How to request -## Test windows -Approved load testing windows are subject to availability of testing windows on a first-come first-served basis. Customers are encouraged to submit requests well in advance of the 2-week advance notice period. +Customers must file a load testing request via the Auth0 Support Center. Under the Issue typefield, select Public Cloud Support Incident. -Testing windows will have a scheduled start and end time assigned by Auth0 and all testing must begin and complete during the window. +To be considered for approval, the request must: -It is common for an initial load test to experience some unexpected issues, resulting in a need for repeat tests. Customers should plan in advance and allow sufficient time for repeat tests before any planned golive. +* 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 information: + +The load testing request must include the following: * A description of the test to be done -* The Auth0 tenant to be used during the test +* 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 Auth0 features, such as rules, email, used during the test -* The Auth0 API endpoints to be used +* 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. The justification should include the size of the target user population and realistic estimates of logins per hour to justify TPS numbers. +* 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 -## Test requirements -Note that load testing will require customer to: +## 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 -## Limitations -Auth0 reserves the right to reject or request modifications to load test plans. - -A load testing approval will specify pre-arranged dates/times in which load testing can be performed. All load testing must be limited to those pre-arranged dates/times. Load testing windows will be a maximum of 2 hours in duration. Failure to abide by this policy may result in temporary blocking of access to an tenant until the issue is remediated. - -## Effectivity -This policy is effective April 4, 2016 - - - +## 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/articles/policies/penetration-testing.md b/articles/policies/penetration-testing.md index d5d65b7b50..850efd2fc0 100644 --- a/articles/policies/penetration-testing.md +++ b/articles/policies/penetration-testing.md @@ -1,15 +1,27 @@ --- description: This page details Auth0's Penetration Testing Policy. +topics: + - auth0-policies + - penetration-testing + - testing +contentType: + - reference +useCase: + - support --- # Penetration Testing Policy -::: warning -This policy is effective August 1, 2017. -::: +**This policy is effective July 1, 2019.** -While conducting a security test of your own application it is **not** permitted to directly test Auth0 infrastructure (such as `tenant.auth0.com`) without prior approval. Please notify us in advance via the [Auth0 support center](${env.DOMAIN_URL_SUPPORT}). Auth0 requires at least **1 week** (7 days) notice prior to the test's planned start date. +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**. -Please provide the following information in the support ticket: +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 @@ -17,13 +29,20 @@ Please provide the following information in the support ticket: 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 +* 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 SaaS Appliance 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 with your support request. +## Private Cloud customers -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. +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 [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/articles/policies/rate-limits-auth-api.md b/articles/policies/rate-limits-auth-api.md new file mode 100644 index 0000000000..546658f45a --- /dev/null +++ b/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/articles/policies/rate-limits-mgmt-api.md b/articles/policies/rate-limits-mgmt-api.md new file mode 100644 index 0000000000..6c8340b61b --- /dev/null +++ b/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/articles/policies/rate-limits.md b/articles/policies/rate-limits.md index d20e785ff9..3c86e92079 100644 --- a/articles/policies/rate-limits.md +++ b/articles/policies/rate-limits.md @@ -1,284 +1,79 @@ --- -title: Rate Limit Policy For Auth0 APIs -description: This page details Auth0's Rate Limit Policy with hitting Auth0 API endpoints. -toc: true +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 For Auth0 APIs +# Rate Limit Policy -To ensure the quality of Auth0's services, the Auth0 APIs are subject to rate limiting. +Actions such as rapidly updating configuration settings, aggressive polling, or making highly concurrent API calls may result in your app being rate limited. -::: note -If you are looking for information on the rate limits on user logins, refer to [Rate Limits on User/Password Authentication](/connections/database/rate-limits). -::: +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. -## Limits +## API endpoint limits -Depending on the API endpoint, the request limit and the rate limit window in which the request limit resets, varies. +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. -Each endpoint is configured with a bucket that defines: +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. -- the request limit, and -- the rate limit window (per second, per minute, per hour, and so on) - -```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. - -::: warning -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. -::: - -## Exceeding the Rate Limit - -If you exceed the provided rate limit for a given API endpoint, you will receive a response with [HTTP Status Code 429 (Too Many Requests)](http://tools.ietf.org/html/rfc6585#section-4). You can refer to the [HTTP Response Headers](#http-response-headers) for more information on the rate limits applicable to that endpoint. +If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed. -Actions such as rapidly updating configuration settings, aggressive polling, or making highy concurrent API calls may result in your app being rate limited. +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. -If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed. +### Review HTTP response headers -## 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. +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. -## Endpoints with Rate Limits - -::: note -If you are using an API endpoint **not** listed below and you receive rate limit headers as part of your response, please see the page on [Anomaly Detection](/anomaly-detection) for additional information. -::: - -### Management API v2 +### Handle rates limitations in code -The rate limits for this API defer depending on whether your tenant is free or paid, production or not. +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. -::: note -- The tenants that have no credit card associated in the [Dashboard](${manage_url}/#/tenant/billing/payment) are free. -- 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. -::: +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. -The following rate limits apply: +## Database login limits -- For all __free tenants__, usage of the Management API is restricted to 2 requests per second (and bursts up to 10 requests). This policy goes into effect on __Tuesday, September 12 at 1PM PT__. -- For __non-production tenants__ of enterprise customers, usage of the Management API is restricted to 2 requests per second (and bursts up to 10 requests). This policy goes into effect on __Tuesday, September 19 at 1PM PT__. -- For __paid__ tenants, usage of the Management API is restricted to 50 requests per second. +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). -The aforementioned rate limits include calls made via [Rules](/rules). +## SMS/Voice message limits for multi-factor authentication -Note, that the limit is set by tenant and not by endpoint. +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). -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). +## 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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    EndpointGETPOSTDELETEPATCH
    Application Grants/client-grants/client-grants/client-grants/{id}/client-grants/{id}
    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
    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
    +| 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` | -### Authentication API +### Limits for production tenants of paying customers -The following Auth0 Authentication API endpoints return rate limit-related headers. +| Endpoint | Path | Limited By | Rate Limit | +| - | - | - | - | +| Get Token | `/oauth/token` | Any native social login request | 50 per minute with bursts up to 500 requests | -::: warning -Auth0 reserves the right to modify the rate limits at any time. For the up-to-date information on rate limits, please review the headers returned from rate limited endpoints. -::: +### 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 | - - - - - - - - - - - - - - - - - - - - - - -
    EndpointPathLimited ByAffected TenantsRate Limit
    User Profile/tokeninfo (legacy)IPAll800 requests per minute
    /userinfoUser IDAll5 requests per minute with bursts of up to 10 requests
    Delegated Authentication (legacy)/delegationUser ID and IPAll1 request per minute with bursts of up to 10 requests
    (any request)Free (*)10 requests per second
    Change Password/dbconnections/change_passwordUser ID and IPAll1 request per minute with bursts of up to 10 requests
    Get Passwordless Code or Link/passwordless/startIPAll50 requests per hour
    Get Token/oauth/token(any request)Free30 requests per second
    Cross Origin Authentication/co/authenticate(any request)Free5 requests per second
    Authentication/usernamepassword/login(any request)Free5 requests per second
    Resource Owner (legacy)/oauth/ro(any request)Free10 requests per second
    Json Web Token Keys/.well-known/jwks.json(any request)Free20 requests per second
    +## Keep reading -:::note -(*) In all instances above, **Free** includes tenants on the Free plan, as well as the non-production tenants of enterprise customers. -::: +* [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/articles/policies/requests.md b/articles/policies/requests.md deleted file mode 100644 index 4d2df15835..0000000000 --- a/articles/policies/requests.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -description: The following is a list of requests Auth0 currently doesn't 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 \ No newline at end of file diff --git a/articles/policies/restore-deleted-tenant.md b/articles/policies/restore-deleted-tenant.md index 3664ed2502..a9e135d7c6 100644 --- a/articles/policies/restore-deleted-tenant.md +++ b/articles/policies/restore-deleted-tenant.md @@ -1,31 +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 -The following policy governs requests for restoration of Auth0 tenants that were previously deleted. - -::: note -If you are considering deleting your tenant, please see our [Resetting/Deleting Tenant](/tutorials/delete-reset-tenant) page for alternative options. +::: warning +**Deleted tenants cannot be restored** and the **tenant name may not be used again** when creating new tenants. ::: -A customer may request a tenant restoration if the tenant was deleted by human error and restoration is critical for the continuity of customer's operations. Please note that before deleting a tenant, from the Auth0 Dashboard, a warning explains that this cannot be undone. However, in some cases we might opt for support this kind of request. - -## Considerations - -* We support tenant restoration for all paying customers. - -* Tenant restoration is not supported for non-paying customers. - -* The restoration can take up to seven days, for paying customers. - -* Tenant restoration will be allowed if the request is made before 20 days have passed from the date the tenant was deleted. - -## How to request - -* Customers must file a tenant restoration request in writing, via the [Auth0 support center](${env.DOMAIN_URL_SUPPORT}) or via email. - -* Please specify the name that the deleted tenant had and the region where it belonged. +**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. -* A member of the Auth0 team will respond your request. +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/articles/policies/unsupported-requests.md b/articles/policies/unsupported-requests.md new file mode 100644 index 0000000000..793fd7ff2f --- /dev/null +++ b/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/articles/pre-deployment/how-to-run-test.md b/articles/pre-deployment/how-to-run-test.md index c5525bda2d..f06bf5038a 100644 --- a/articles/pre-deployment/how-to-run-test.md +++ b/articles/pre-deployment/how-to-run-test.md @@ -1,10 +1,20 @@ --- -description: How to run the Auth0 Pre-Deployment Tests to ensure that your Applications are production-ready +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 Pre-Deployment Test +# How to Run the Production Checks -The Pre-Deployment Tests are available via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}). +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) @@ -12,45 +22,48 @@ 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 Pre-Deployment Tests, and click on the **gear icon** located in the top right-hand corner of its box. +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 tests run. +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-clients.png) +![](/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 test results. +When the test is complete, your screen will automatically refresh to display your check results. ![](/media/articles/support/pre-deployment-tests/results.png) -There are three types of test results: Required, Recommended, and Best Practices. + +## Production Check Results + +There are three types of check results: Required, Recommended, and Best Practices. | Result Type | Description | | ----------- | ----------- | -| Required | These tests check to see if you are missing any steps you **must** complete before deploying to Production, otherwise you'll see errors. | -| Recommended | These tests check to 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 check using automates tests. We list areas of possible concern, and we suggest that you review your implementation to see if you're compliant with Auth0 recommendations. | +| 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 test: Passed, Failed, Unable to Verify. +The following are possible results for your check: Passed, Failed, Unable to Verify. -Under each set of test results, Auth0 tells you how many tests your Application passed, as well as how many tests your Applications failed. +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 Applications **failed** one or more tests, Auth0 provides you: +If your Application **failed** one or more checks, Auth0 provides: -* The name of the test -* Information on what the test is looking for -* Details on the error thrown to and retrieved by the test -* Hyperlink to the appropriate area where you can make the required fixes so that your Application passes the test +* 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 tests that your Application **passed** are grouped together at the bottom of the results set. You can view the name of and information about the test, 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). \ No newline at end of file +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/articles/pre-deployment/index.html b/articles/pre-deployment/index.html index fe4f063178..d3f15af976 100644 --- a/articles/pre-deployment/index.html +++ b/articles/pre-deployment/index.html @@ -1,27 +1,36 @@ --- classes: topic-page -title: Pre-Deployment Tests +title: Production Checks +topics: + - pre-deployment + - pre-deployments-tests + - tests + - production-checks +contentType: + - index +useCase: + - support ---
    -

    Pre-Deployment Tests

    +

    Production Checks

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

    • - How to Run the Pre-Deployment Tests + How to Run the Production Checks

      - Run the pre-deployment tests against one or more applications to see if they're production-ready or not. + Run the production checks against one or more applications to see if they're production-ready or not.

    • - Pre-Deployment Test Results + Production Check Results

      - View your results to see any outstanding required and recommended tasks, as well changes you can make to ensure that you comply with best practices. + Production checks fall into the following categories:

      • @@ -35,6 +44,12 @@

        Pre-Deployment Tests

      • +
    • + How to Read Your Results Set +

      + View your results to see any outstanding required and recommended tasks, as well as changes you can make to ensure that you comply with best practices. +

      +
    • Pre-Launch Tips

      diff --git a/articles/pre-deployment/prelaunch-tips.md b/articles/pre-deployment/prelaunch-tips.md index d4092eacdd..c82eac9222 100644 --- a/articles/pre-deployment/prelaunch-tips.md +++ b/articles/pre-deployment/prelaunch-tips.md @@ -1,6 +1,15 @@ --- -title: Pre-launch Tips +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 @@ -33,9 +42,9 @@ Here is a list of tips our customers have found most useful when first getting s * Adequately protect any client secret values. -* Check your [grant types](/applications/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. +* 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](/metadata) confirm that this is data that users should be able to change on their own (eg. not “payment status”). +* 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. @@ -49,7 +58,7 @@ Here is a list of tips our customers have found most useful when first getting s * 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 [FAQ about API tokens](/api/management/v2/tokens#frequently-asked-questions). +* 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. diff --git a/articles/pre-deployment/tests/best-practice.md b/articles/pre-deployment/tests/best-practice.md index b61ec70bf2..ff5bd52ff9 100644 --- a/articles/pre-deployment/tests/best-practice.md +++ b/articles/pre-deployment/tests/best-practice.md @@ -1,17 +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 --- -# Pre-Deployment Tests: Best Practices +# 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](${manage_url}/#/anomaly) capability and configuration | -| 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 | If not using Delegation, set the Allowed Apps and APIs field of your Application Settings to the current Client ID | -| SSO Timeout Values | Review the default [SSO cookie timeout values](${manage_url}/#/account/advanced) and ensure it aligns with your requirements | +| [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 match those 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 | \ No newline at end of file +| 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/articles/pre-deployment/tests/recommended.md b/articles/pre-deployment/tests/recommended.md index 0684ff3b2d..77969efda4 100644 --- a/articles/pre-deployment/tests/recommended.md +++ b/articles/pre-deployment/tests/recommended.md @@ -1,23 +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 --- -# Pre-Deployment Tests: Recommended Fixes +# Production Checks: Recommended Fixes -The following tests check to see if you've completed all recommendations (which are optional) for successful deployment to Production. +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 testing output. +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. ::: -| Test | Description | +| Check | Description | | ---- | ----------- | -| [Customer Error Page](/hosted-pages/custom-error-pages) Configured | [Configure a Custom Error Page](${manage_url}/#/account) with your application-specific details and corporate branding | -| Customize [Guardian Multifactor Page](/hosted-pages/guardian) | If you're using Guardian Multifactor Authentication, [configure a Custom Hosted Page for Guardian Multifactor](${manage_url}/#/guardian_mfa_page) with your application details and corporate branding | -| Customize [Login Page](/hosted-pages/login) | [Configure a Custom Hosted Page for Universal Login](${manage_url}/#/login_page) with your application details and corporate branding | -| Customize [Password Reset Page](/hosted-pages/password-reset) | [Configure a Custom Hosted Page for Password Reset](${manage_url}/#/password_reset) with your application details and corporate branding | -| [Email Templates](/email/custom) Configured | [Configure custom email templates](${manage_url}/#/emails) with your application specific details and corporate branding | -| Enable [MFA for Tenant Administrators](/tutorials/manage-dashboard-admins) | [Enable multifactor authentication](${manage_url}/#/account/admins) for tenant administrators | -| [Guardian Multifactor](/multifactor-authentication) or other Multifactor Authentication Providers | Consider [multifactor authentication](${manage_url}/#/guardian) as part of the authentication strategy | -| [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 Applications | -| Use RS256 Instead of HS256 | Set the JSONWebToken [Signature Algorithm](/apis#signing-algorithms) to RS256 instead of HS256 | \ No newline at end of file +| [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/articles/pre-deployment/tests/required.md b/articles/pre-deployment/tests/required.md index c41654a9a5..848f2ea432 100644 --- a/articles/pre-deployment/tests/required.md +++ b/articles/pre-deployment/tests/required.md @@ -1,21 +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 --- -# Pre-Deployment Tests: Required Fixes +# Production Checks: Required Fixes -The following tests check to see if you've completed all requirements for successful deployment to Production. +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 testing output. +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. ::: -| Test | Description | +| Check | Description | | ---- | ----------- | -| [Allowed Callback Urls](tutorials/redirecting-users) Not Localhost | Validates the [Application Allowed Callback URLs do not point to localhost](${manage_url}/#/applications), 127.0.0.1, and so on | -| Configure [Guardian SMS Provider](/multifactor-authentication/administrator/twilio-configuration) (Dependency: Guardian is Configured) | Ensures that [Twilio SMS is configured](${manage_url}/#/guardian) if you're using Guardian MFA | -| Configure Tenant Environment Tag | Ensures the [tenant environment tag is set](${env.DOMAIN_URL_SUPPORT}/tenants/public) appropriately to Production, Staging or Development | -| [Email Provider](/email/providers) Configured | Verifies that the [custom email provider has been configured](${manage_url}/#/emails/provider) | -| [Social Connections](/connections/social/devkeys) Auth0 Dev 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 | \ No newline at end of file +| [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/articles/private-cloud/add-ons.md b/articles/private-cloud/add-ons.md new file mode 100644 index 0000000000..5e5ec04cab --- /dev/null +++ b/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/articles/private-cloud/custom-domain-migration.md b/articles/private-cloud/custom-domain-migration.md new file mode 100644 index 0000000000..7922c55bae --- /dev/null +++ b/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/articles/private-cloud/index.md b/articles/private-cloud/index.md new file mode 100644 index 0000000000..044901fc2b --- /dev/null +++ b/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/articles/private-cloud/managed-private-cloud/index.md b/articles/private-cloud/managed-private-cloud/index.md new file mode 100644 index 0000000000..085561e65e --- /dev/null +++ b/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/articles/private-cloud/managed-private-cloud/raci.md b/articles/private-cloud/managed-private-cloud/raci.md new file mode 100644 index 0000000000..8c343a461b --- /dev/null +++ b/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/articles/private-cloud/managed-private-cloud/zones.md b/articles/private-cloud/managed-private-cloud/zones.md new file mode 100644 index 0000000000..d7452081aa --- /dev/null +++ b/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/articles/private-cloud/onboarding/index.md b/articles/private-cloud/onboarding/index.md new file mode 100644 index 0000000000..d3dbb390a2 --- /dev/null +++ b/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/articles/private-cloud/onboarding/managed-private-cloud/index.md b/articles/private-cloud/onboarding/managed-private-cloud/index.md new file mode 100644 index 0000000000..68f9de8246 --- /dev/null +++ b/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/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md b/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md new file mode 100644 index 0000000000..ad68965f76 --- /dev/null +++ b/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/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md b/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md new file mode 100644 index 0000000000..a86e9c3097 --- /dev/null +++ b/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/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md b/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md new file mode 100644 index 0000000000..ecc40318ff --- /dev/null +++ b/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/articles/private-cloud/onboarding/private-cloud.md b/articles/private-cloud/onboarding/private-cloud.md new file mode 100644 index 0000000000..807ed16c83 --- /dev/null +++ b/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/articles/private-cloud/standard-private-cloud/index.md b/articles/private-cloud/standard-private-cloud/index.md new file mode 100644 index 0000000000..39b3ccb2c8 --- /dev/null +++ b/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/articles/product-lifecycle/index.md b/articles/product-lifecycle/index.md new file mode 100644 index 0000000000..c2e91485da --- /dev/null +++ b/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/articles/product-lifecycle/migration-process.md b/articles/product-lifecycle/migration-process.md new file mode 100644 index 0000000000..8443e5a533 --- /dev/null +++ b/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/articles/product-lifecycle/migrations.md b/articles/product-lifecycle/migrations.md new file mode 100644 index 0000000000..253d55524d --- /dev/null +++ b/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/articles/product-lifecycle/product-release-stages.md b/articles/product-lifecycle/product-release-stages.md new file mode 100644 index 0000000000..f663e50032 --- /dev/null +++ b/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/articles/protocols/index.html b/articles/protocols/index.html index a941168404..18daba8d31 100644 --- a/articles/protocols/index.html +++ b/articles/protocols/index.html @@ -4,6 +4,17 @@ 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 ---
      @@ -15,7 +26,7 @@

      Protocols

      - Auth0 implements proven, common and popular identity protocols used in consumer oriented web products (OAuth 2.0, OpenID Connect) and in enterprise deployments (SAML, WS-Federation, LDAP). + 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).

        @@ -26,23 +37,23 @@

        Protocols

      • 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. + 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.

      • diff --git a/articles/protocols/ldap/index.md b/articles/protocols/ldap/index.md index 9ec15d5774..03aaf00b10 100644 --- a/articles/protocols/ldap/index.md +++ b/articles/protocols/ldap/index.md @@ -1,5 +1,12 @@ --- description: Details about the LDAP protocol and how it is used by Auth0. +topics: + - protocols + - ldap +contentType: + - concept +useCase: + - development --- # LDAP diff --git a/articles/protocols/oauth2/index.md b/articles/protocols/oauth2/index.md index a14182b73c..528c308a9a 100644 --- a/articles/protocols/oauth2/index.md +++ b/articles/protocols/oauth2/index.md @@ -1,37 +1,36 @@ --- 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 +# OAuth 2.0 Authorization Framework -[OAuth 2.0](https://oauth.net/2/) is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials. +[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. -## Overview - -According to [OAuth‘s website](http://oauth.net/about/) the protocol is not unlike a valet key. - -> Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything. - -To get access to the protected resources OAuth 2.0 uses **Access Tokens**. An Access Token is a string representing the granted permissions. +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)](/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. - -::: note -Auth0 also generates opaque Access Tokens for the (deprecated) [Management API v1](/api/management/v1). +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 2.0 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 levels of authorization: reading contacts (scope `read:contacts`), creating contacts (scope `create:contacts`) and deleting contacts (scope `delete:contacts`). When an application asks the API to create a new contact, then the Access Token should contain the `create:contacts` scope. In a similar fashion, in order to delete existing contacts, the Access Token should contain the `delete:contacts` scope. +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 +## OAuth roles In any OAuth 2.0 flow we can identify the following roles: @@ -43,8 +42,7 @@ In any OAuth 2.0 flow we can identify the following roles: - **Authorization Server**: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0. - -## Protocol Flow +## 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. @@ -62,31 +60,29 @@ We will now have a more detailed look on how the protocol works. As we will see 1. Provided that the Access Token is valid, the Resource Server serves the Application's request. - -## Authorization Grant Types +## 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](/api-auth/grant/authorization-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](/api-auth/grant/authorization-code-pkce). +- [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](/api-auth/grant/implicit): used by JavaScript-centric apps (Single Page Applications) executing on the user's browser. +- [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](/api-auth/grant/client-credentials): used for machine-to-machine communication. +- [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 endpoints OAuth 2.0 utilizes two endpoints: the **Authorization** endpoint and the **Token** endpoint. -### Authorization 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 will redirect 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 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. @@ -95,27 +91,27 @@ The request parameters of the Authorization endpoint are: - `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 +#### 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 later can be exchanged with an Access Token), while for **Implicit** grant it will issue an **Access Token**. +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**. -::: panel Authorization Code vs Access Token -An authorization code is an opaque string, meant to be exchanged with an Access Token at the [token endpoint](#token-endpoint). An Access Token is an opaque string (or a [JWT](/jwt) in Auth0 implementation) that denotes who has authorized which permissions (scopes) to which application. -::: +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). -In order to inform the authorization server which grant type to use, the `response_type` request parameter is used: +To inform the authorization server which grant type to use, the `response_type` request parameter is used as follows: -- For **Authorization Code** grant set `response_type=code`. This way the response will include an authorization code. +- For **Authorization Code** grant, use `response_type=code` to include an authorization code. -- For **Implicit** grant set `response_type=token`. This way the response will include an Access Token. An alternative is to set `response_type=id_token token`. In this case the response will include both an Access Token and an ID Token. +- 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**. For more information refer to [OpenID Connect](/protocols/oidc) and [ID Token](/tokens/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 +#### 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 it can take the following values: +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. @@ -139,7 +135,7 @@ The [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/spe 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 by 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. Hence, after the HTML is loaded by the browser, a redirection to the `redirect_uri` is done. +- `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: @@ -150,26 +146,26 @@ The [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/spe
        - +
        ``` -- `web_message`: This response mode is defined by 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). +- `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 +### Token endpoint -The Token endpoint is used by the application in order to get an [Access Token](/tokens/access-token) or a [Refresh Token](/tokens/refresh-token). It is used by all grant types, except for [Implicit](/api-auth/grant/implicit) grant (since an Access Token is issued directly). +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](/api-auth/grant/authorization-code) grant, the application exchanges the authorization code it got from the Authorization endpoint for an Access Token. +- 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](/api-auth/grant/client-credentials) and [Resource Owner Password Credentials](/api-auth/grant/password) grants, the application authenticates using a set of credentials and then gets 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 -::: next-steps * [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) -* [More docs on API Authorization](/api-auth) -* [Read about the state parameter and how it can help you mitigate CSRF attacks](/protocols/oauth2/oauth-state) -::: +* [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/articles/protocols/oauth2/mitigate-csrf-attacks.md b/articles/protocols/oauth2/mitigate-csrf-attacks.md new file mode 100644 index 0000000000..28dc65952a --- /dev/null +++ b/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/articles/protocols/oauth2/oauth-state.md b/articles/protocols/oauth2/oauth-state.md index 1ca9a66f25..4667907642 100644 --- a/articles/protocols/oauth2/oauth-state.md +++ b/articles/protocols/oauth2/oauth-state.md @@ -1,74 +1,51 @@ --- -title: The State Parameter -description: Explains how to use the state parameter in authentication requests to help prevent CSRF attacks. +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 --- -# The State Parameter +# State Parameter -The `state` parameter is an authentication parameter used to help mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery). +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. -A CSRF attack can occur when a malicious program causes a user's web browser to perform an unwanted action on a trusted site that the user is currently authenticated. This type of attack specifically target 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. +## CSRF attacks -For the most basic cases the `state` parameter should be a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) as shown in the example below. **But this field can also be a [Base64](https://en.wikipedia.org/wiki/Base64) encoded json object that can hold multiple values [such as a return URL](/tutorials/redirecting-users).** +The primary reason for using the `state` parameter is to mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery). -## How to use the state parameter +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. -By using the state parameter to hold a value for verification, malicious requests can be denied. +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). -![](/media/articles/protocols/CSRF_Diagram.png) +![Diagram of CSRF attack](/media/articles/protocols/CSRF_Diagram.png) -::: note -Depending on the application type or framework this may be included for the developer. Also the exact structure of the requests may differ. +::: warning +The cookie in which the `state` value is stored should be signed to prevent attackers to forge it. ::: -1. Before redirecting a request to the [IdP](/identityproviders), have the application generate a random string. +## Redirect users -``` -xyzABC123 -``` +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). -2. Save this string to a variable in [web storage](/security/store-tokens#web-storage-localstorage-sessionstorage-). +## Limitations -``` -auth0-authorize = xyzABC123 -``` - -3. Encode this value and set it as the `state` parameter in the request. - -``` -// Encode the String -var encodedString = Base64.encode(string); -tenant.auth0.com/authorize?...&state=encodedString -``` - -4. 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. - -``` -/login/callback?...&state=encodedString -``` - -5. Decode the returned `state` value and compare it to the one you stored earlier. If the values match, then approve the request, else deny it. - -``` -// Decode the String -var decodedString = Base64.decode(encodedString); -if(decodedString == auth0-authorize) { - // Authorized request -} else { - // Request Denied -} -``` - -### Getting the `state` value in a rule - -If you need to access the `state` value within a rule you must take in consideration that, depending on the type of connection used, it might come either in the body of the request or in the query string. Keeping that in mind, it can be accessed using the following: - -```js -var state = context.request.query.state || context.request.body.state; -``` +* 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 -::: next-steps -* [Protecting against other common threats](/security/common-threats) -::: +* [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/articles/protocols/oauth2/redirect-users.md b/articles/protocols/oauth2/redirect-users.md new file mode 100644 index 0000000000..5ccdcadfa4 --- /dev/null +++ b/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/articles/protocols/oidc/identity-providers/okta.md b/articles/protocols/oidc/identity-providers/okta.md index cb377dd1d7..b0e4ca230e 100644 --- a/articles/protocols/oidc/identity-providers/okta.md +++ b/articles/protocols/oidc/identity-providers/okta.md @@ -1,10 +1,19 @@ --- 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 identity provider. +This article walks you through configuring Okta for use as an OpenID Connect (OIDC) identity provider. ## 1. Create an Okta Application @@ -51,7 +60,7 @@ Auth0 supports creating custom OpenID Connections by using the [Custom Social Co - __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`; +- __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) { @@ -163,3 +172,7 @@ function(accessToken, ctx, cb) { 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/articles/protocols/oidc/index.md b/articles/protocols/oidc/index.md index 6fd500a81d..1c0ecdbdf1 100644 --- a/articles/protocols/oidc/index.md +++ b/articles/protocols/oidc/index.md @@ -1,16 +1,28 @@ --- +url: /protocols/oidc title: OpenID Connect -description: What is the OpenID Connect protocol and how it works +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)](/jwt), which you can obtain using flows conforming to the OAuth 2.0 specifications. +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 [JSON Web Token (JWT)](/jwt). You'll receive an Access Token and, if requested, an ID Token. +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 the Protocol Works +## 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: @@ -21,15 +33,22 @@ Let's use the example we mentioned earlier, signing into Auth0 using your Google ## Access Tokens -[Access Tokens](/tokens/access-token) 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 authorized to access the API and perform specific actions (as specified by the scopes that have been granted). +[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)](/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. +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](/jwt#payload), which are statements (such as name or email address) about an entity (typically, the user) and additional metadata. +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](/tokens/id-token#add-custom-claims). +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/articles/protocols/oidc/openid-connect-discovery.md b/articles/protocols/oidc/openid-connect-discovery.md index 1ecaa9b7ab..8f2a93e9ca 100644 --- a/articles/protocols/oidc/openid-connect-discovery.md +++ b/articles/protocols/oidc/openid-connect-discovery.md @@ -1,59 +1,72 @@ --- -description: How to use OpenID Connect discovery with Auth0. +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 --- -# OpenID Connect Discovery +# Configure Applications with OpenID Connect Discovery -Auth0 exposes OIDC discovery documents (`https://${account.namespace}/.well-known/openid-configuration`). These can be used to automatically configure applications. +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) -## How to use it - 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 + ```cs + app.UseCookieAuthentication(new CookieAuthenticationOptions + { + AuthenticationType = CookieAuthenticationDefaults.AuthenticationType + }); + + app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions { - // OPTIONAL: you can read/modify the claims that are populated based on the JWT - SecurityTokenValidated = context => + Authority = "https://${account.namespace}/", + ClientId = "{YOUR_AUTH0_CLIENT_ID}", + SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType, + ResponseType = "token", + Notifications = new OpenIdConnectAuthenticationNotifications { - // add Auth0 access_token as claim - var accessToken = context.ProtocolMessage.AccessToken; - if (!string.IsNullOrEmpty(accessToken)) + // OPTIONAL: you can read/modify the claims that are populated based on the JWT + SecurityTokenValidated = context => { - context.AuthenticationTicket.Identity.AddClaim(new Claim("access_token", accessToken)); - } + // 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); + return Task.FromResult(0); + } } - } -}); -``` + }); + ``` + +## Use RSA algorithm for JWTs -## Notes on this middleware -Currently, the OpenID Connect middleware does not support JWT tokens signed with symmetric keys. Make sure you configure your app to use the RSA algorithm using public/private keys: +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: +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`. -![](/media/articles/oidc-rs256-owin/rsa256.png) +![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 -With this setting, Auth0 will issue JWT tokens signed with your private signing key. Your app will verify them with your public signing key. +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) diff --git a/articles/protocols/saml/adfs.md b/articles/protocols/saml/adfs.md index 089206860a..1651e92e6f 100644 --- a/articles/protocols/saml/adfs.md +++ b/articles/protocols/saml/adfs.md @@ -1,175 +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 --- -# ADFS SAML Connection +# Set Up an ADFS SAML Connection -Auth0 allows you to create a custom SAML connection to Microsoft's Active Directory Federation Services. In addition to getting a bit more flexibility when configuring your mappings, the SAML Connection allows you identity provider-initiated flows (this is something that you cannot do with WS-Fed). +Create a custom SAML connection to Microsoft's Active Directory Federation Services (ADFS) to get more flexibility when configuring your mappings. -## Step 1: Configure ADFS +To create the custom connection, you will need to: -To get your ADFS server ready, you'll 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. -1. Add a relying party trust -2. Edit your claim issuance policy -3. Obtain your federation metadata -4. Export the signing certificate to upload to Auth0 +The following sections will guide you through this process. -### Add a Relying Party Trust - -Begin by launching your instance of ADFS. Start the **Add Relying Party Trust** wizard. - -![](/media/articles/protocols/saml-adfs/saml1.png) - -On the **Welcome** page, choose **Claims aware** and click **Start**. - -![](/media/articles/protocols/saml-adfs/saml2.png) - -You'll see the **Select Data Source** page at this point. Select **Enter data about the relying party manually** and click Next to proceed. - -![](/media/articles/protocols/saml-adfs/saml3.png) - -On the **Specify Display Name** page, provide a descriptive name for your relying party (the typical format is `urn:auth0:${account.namespace}`) and a brief description under **Notes**. Click **Next**. - -![](/media/articles/protocols/saml-adfs/saml4.png) - -Next up is the **Configure Certificate** page. For now, we will skip this step, so click **Next** to proceed. - -![](/media/articles/protocols/saml-adfs/saml5.png) - -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 at a later point. Click **Next**. - -![](/media/articles/protocols/saml-adfs/saml6.png) +## Configure ADFS -On the **Configure Identifiers** page, indicate that the **Relying party trust identifier** is `urn:auth0:${account.namespace}` (or whatever value you used as the display name when you started using the wizard). Click **Next**. - -![](/media/articles/protocols/saml-adfs/saml7.png) - -On the **Choose Access Control Policy** page, select **Permit everyone** and click **Next**. - -![](/media/articles/protocols/saml-adfs/saml8.png) - -Finally, review the settings you provided on the **Ready to Add Trust** page and click **Next** to save your information. - -![](/media/articles/protocols/saml-adfs/saml9.png) +### Add a Relying Party Trust -If you were successfully, you'll see a message indicating such on the **Finish** page. Make sure that the **Configure claims issuance policy for this application** checkbox is selected, and click **Close**. +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. -![](/media/articles/protocols/saml-adfs/saml10.png) +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 -Immediately after you've closed out of the Add Relying Party Trust wizard, you'll see the **Edit Claim Issuance Policy** window pop up. - -![](/media/articles/protocols/saml-adfs/saml11.png) - -Click **Add Rule...** to launch the wizard. Use **Send LDAP Attributes as Claims** for your **Claim rule template**, and click **Next** to proceed. - -![](/media/articles/protocols/saml-adfs/saml12.png) - -Provide a value for the **Claim rule name**, such as LDAP Attributes (it can be anything you want). Choose **Active Directory** as your **Attribute Store**. Map your LDAP attributes to outgoing claim types as shown below. The only mandatory mapping you need is for the email address, but you can add as many as you'd like. Click **Finish**. - -![](/media/articles/protocols/saml-adfs/saml13.png) - -Back on the **Edit Claim Issuance Policy** window, click **Apply**. +After you close the **Add Relying Party Trust** wizard, the **Edit Claim Issuance Policy** window appears. -![](/media/articles/protocols/saml-adfs/saml14.png) +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: -You can now exit out of this window. + | LDAP Attribute | Outgoing Claim | + | - | - | + | E-Mail-Addresses | E-Mail Address | + | Display-Name | Name | + | User-Principal-Name | Name ID | + | Given-Name | Given Name | + | Surname | Surname | -### Obtain the Federation Metadata + ::: 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. + ::: -To get your Federation Metadata, navigate to the following URL: + You can add additional claim mappings if necessary. See [Connect Your Application to Microsoft ADFS](/connections/enterprise/adfs#add-additional-ldap-attributes) for details. -`https://your-server/FederationMetadata/2007-06/FederationMetadata.xml` - -Your file will looking something like this: - -![](/media/articles/protocols/saml-adfs/saml21.png) - -Save the file for later use. +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 at a later point. - -Using the left-hand navigation pane, go to **ADFS > Service > Certificates**. Select the **Token-signing** certificate, and right click to select **View Certificate**. - -![](/media/articles/protocols/saml-adfs/saml15.png) - -On the **Details** tab, click **Copy to File...**. - -![](/media/articles/protocols/saml-adfs/saml16.png) - -This launches the Certificate Export Wizard. Click **Next** to proceed. - -![](/media/articles/protocols/saml-adfs/saml17.png) - -Choose **Base-64 encoded X.509 (.CER)** as the format you'd like to use. Click **Next**. - -![](/media/articles/protocols/saml-adfs/saml18.png) - -Provide the location to where you want the certificate exported. Click **Next**. - -![](/media/articles/protocols/saml-adfs/saml19.png) - -Verify that the settings for your certificate are correct. If they are, click **Finish** to proceed with the export process. - -![](/media/articles/protocols/saml-adfs/saml20.png) - -## Step 2: Configure Auth0 - -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. - -::: note -The sign in and sign out URLs are usually in the form of `https://your.adfs.server/adfs/ls`. -::: - -Click **Save**. - -## Step 3: Edit the Relying Party Trust - -Once you have set the required parameters for creating your Auth0 connection and clicked **Save**, you'll see a page with instructions on creating a new relying party trust in ADFS. You'll need the following parameters: - -| Parameter | Sample Value | -| - | - | -| Post-back URL | `https://{yourAuth0accountdomain}/login/callback}/login/callback?connection={your new SAML connection}` | -| Entity ID | `urn:auth0:account:connection` | - -The set of instructions presented to you after you've created your new connection will also have the exact values required for your Auth0 account/connection. - -In the ADFS console, go to **ADFS > Relying Party Trusts** using the left-hand navigation pane. Select the relying party trust you created in step 1 and click **Properties** (located on the right-hand navigation pane). +Finally, you'll need to export the signing certificate from the ADFS console to upload it to Auth0. -![](/media/articles/protocols/saml-adfs/saml22.png) +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**. -Switch over to the **Identifiers** tab, and populate the **Relying Party Identifier** with the **Entity ID** value. Be sure to click **Add** to add the identifier to your list. +## Create a SAML connection with Auth0 as the service provider -![](/media/articles/protocols/saml-adfs/saml23.png) +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. -Switch over to the **Endpoints** tab, and select the placeholder URL you provided earlier. Click **Edit...**. + The sign in and sign out URLs are usually in the form of `https://your.adfs.server/adfs/ls`. -![](/media/articles/protocols/saml-adfs/saml24.png) +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. -Populate the **Trusted URL** with the **Post-back URL** value. + 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 -![](/media/articles/protocols/saml-adfs/saml25.png) +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. -Click **OK**. Finally, click **Apply** and exit the Properties window. +## Optional: Enable sign requests -### Map Your Claims +Optionally, you can sign your SAML requests to the ADFS server. -You can add additional claims mappings if necessary; for assistance on which LDAP attributes map to which Outgoing Claim Type, see [Connect Your App to ADFS](/connections/enterprise/adfs). +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. -## Step 4: Enable and Test Your Integration. +## Enable and test your integration -Before you can test your Auth0-ADFS integration, you'll need to make sure that you've completed the following steps: +Before you test your integration, make sure that you've completed the following steps: -1. [Create a user](/tutorials/creating-users-in-the-management-portal) for your newly-created Connection. -2. [Enable your Connection](/applications/connections) for at least one Application. +* Create a user on the IdP that you can use to test your new connection. +* [Enable your Connection](/connections) for at least one application. -To test your connection, navigate to **Connections > Enterprise > ADFS**. Click the ADFS row (or the hamburger icon to the right) to bring up a list of your ADFS connections. Identify the one you're testing, and click the **play** button to test the connection. +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. -## Troubleshooting +## Keep reading -If you have any issues with your SAML ADFS configuration, please see our [troubleshooting docs](/protocols/saml/saml-configuration/troubleshoot). +* [Troubleshooting SAML Configuration](/protocols/saml/saml-configuration/troubleshoot) diff --git a/articles/protocols/saml/identity-providers/index.md b/articles/protocols/saml/identity-providers/index.md new file mode 100644 index 0000000000..6b88cd5e80 --- /dev/null +++ b/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/articles/protocols/saml/identity-providers/okta.md b/articles/protocols/saml/identity-providers/okta.md index c25fd3111f..aa6b9c3a9b 100644 --- a/articles/protocols/saml/identity-providers/okta.md +++ b/articles/protocols/saml/identity-providers/okta.md @@ -2,100 +2,44 @@ 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 -This article walks you through configuring Okta for use 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 -Log in to your Okta account. If you don't already have one, you will need to create one. - -On the general Okta dashboard, click **Admin**. This takes you to the Okta Admin Dashboard. - -![Okta Dashboard](/media/articles/saml/identity-providers/okta/okta-dashboard.png) - -Using the list of shortcuts at the right-hand side of the screen, click **Add Applications**. - -![Okta Admin Dashboard](/media/articles/saml/identity-providers/okta/okta-admin-dashboard.png) - -On the *Add Application* page, select **Create New App**. - -![Create New Okta App](/media/articles/saml/identity-providers/okta/create-new-app.png) - -On the *Create a New Application Integration* pop-up window, select the **Platform** for your application, and choose **SAML 2.0** as the *Sign on method*. Click **Create** to proceed. - -![Create New app Integration](/media/articles/saml/identity-providers/okta/new-app-integration.png) - -You will now create your SAML integration. On the *General Settings* page, provide the following: - -* **App name**; -* **App logo** (optional); -* **App visibility**: select whether you want your users to see your application icon and in what settings. - -![SAML Integration General Settings](/media/articles/saml/identity-providers/okta/saml-general-settings.png) - -Click **Next** to proceed. - -Next, you will see the *SAML Settings* page. Enter the following values into the appropriate fields: - -* **Single sign on URL**: `https://${account.namespace}/login/callback` -* **Audience URI (SP Entity ID)**: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` - -![SAML Integration Configure SAML](/media/articles/saml/identity-providers/okta/saml-settings.png) - -You will also need to add the following *Attribute Statement*: - -* **Name**: email -* **Name format** (optional): Unspecified -* **Value**: <%= "${user.email}" %> - -At this point, you can click **Preview the SAML Assertion** to generate XML you can use to verify that your provided settings are correct. - -Click **Next** to proceed. - -Lastly, answer *Are you a customer or partner?* by selecting **I'm an Okta customer adding an internal app**. Click **Finish**. - -![SAML Integration Feedback](/media/articles/saml/identity-providers/okta/okta-support.png) - -You'll be directed to the *Sign On* page for your newly-created app. Click on **View Setup Instructions** to complete the process. - -![Okta App Sign On](/media/articles/saml/identity-providers/okta/view-setup-instructions.png) - -Take note of the **Identity Provider Single Sign-On URL**, and download a copy of the X.509 certificate. - -![Configuration Information](/media/articles/saml/identity-providers/okta/config-info.png) +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 Identity Provider** and click the **plus** icon to launch the dialog window that allows you to create a new Connection. - -![List of Auth0 Connections](/media/articles/saml/identity-providers/okta/enterprise-connections.png) - -When prompted, click **Create New Connection.** - -![Create New Auth0 Connection](/media/articles/saml/identity-providers/okta/create-new-connection.png) +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. -![Configure New Auth0 Connection](/media/articles/saml/identity-providers/okta/configure-new-connection.png) - 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. -![Configuration Values](/media/articles/saml/identity-providers/okta/configured-connection.png) - Click **Save** to persist your changes and proceed. -In the next dialog 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 Admin Instructions](/media/articles/saml/identity-providers/okta/admin-settings.png) +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 @@ -103,21 +47,15 @@ Now that you've created and configured your Connection, you'll need to enable ac Using the [Management Dashboard](${manage_url}), go to the [Applications](${manage_url}/#/applications) to see the list of Applications associated with your Auth0 account. -![Auth0 Applications](/media/articles/saml/identity-providers/okta/clients.png) - 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. -![Enable Connection for an Application](/media/articles/saml/identity-providers/okta/enable-connection.png) - ## 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** -> **SAMLP Identity Provider**. On the row associated with Okta, click the **play** icon to *Try* your Connection. - -![Test Okta Connection](/media/articles/saml/identity-providers/okta/test.png) +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. @@ -127,27 +65,14 @@ The **Try** button works for users logged in to Auth0 dashboard. You can't send ## IdP Initiated SignOn -**Beginning with auth0.js v9.3.4, you must [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** - -<%= include('../../../_includes/_deprecate-impersonation.md') %> - -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` +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. -Lastly, you'll need to select the Application to which the Auth0 redirects after it validates the SAML Response. - -Go to **Connections** -> **Enterprise** -> **SAMLP Identity Provider**. On the row associated with Okta, click **Settings**, and switch to the **IdP-Initiated SSO** screen. - -Set the **Default Application** and indicate that the **Response Protocol** is *SAML*. - -![Enable IDP](/media/articles/saml/identity-providers/okta/enable-idp-connection.png) - -Click **Save**. +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 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. - +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/articles/protocols/saml/identity-providers/onelogin.md b/articles/protocols/saml/identity-providers/onelogin.md index d84fc40c07..373d099c62 100644 --- a/articles/protocols/saml/identity-providers/onelogin.md +++ b/articles/protocols/saml/identity-providers/onelogin.md @@ -1,141 +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 --- -# Configuring OneLogin as an Identity Provider +# Configure OneLogin as an Identity Provider -## Configure app on OneLogin dashboard +In this article, we will cover how you can configure OneLogin for use with Auth0 as a SAML Identity Provider. -Go to [OneLogin](https://www.onelogin.com/) dashboard and click on **Apps** > **Add Apps**. +## Step 1: Configure OneLogin -![](/media/articles/saml/identity-providers/onelogin/onelogin-add-app.png) +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**. -Search for *saml* and select **SAML Test Connector (IdP w/attr)** +## Step 2: Configure the connection using the Auth0 dashboard -![](/media/articles/saml/identity-providers/onelogin/onelogin-search-app.png) +At this point, you will configure the integration from the Auth0 side. -Change the **Display Name** of your app if you wish and click **SAVE**. +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. -![](/media/articles/saml/identity-providers/onelogin/onelogin-save-app.png) +You will be prompted to provide the appropriate configuration settings for this Connection. -Go to the **SSO** tab and copy the values of **SAML 2.0 Endpoint (HTTP)** and **SLO Endpoint (HTTP)**. Click on the *View Details* link at the **X.509 Certificate** field. +The only mandatory fields are as follows: -![](/media/articles/saml/identity-providers/onelogin/onelogin-copy-values.png) +* **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. -Download the X.509 certificate: `onelogin.pem`. +Click **Save** to persist your changes and proceed. -![](/media/articles/saml/identity-providers/onelogin/onelogin-download-cert.png) +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. -## Configure connection on Auth0 dashboard +### Auth0 configuration values -Go to [Auth0 dashboard > Connections > Enterprise > SAMLP Identity Provider](${manage_url}/#/connections/enterprise) and click **Create New** (plus icon) - -![](/media/articles/saml/identity-providers/onelogin/auth0-new-samlp.png) - -Set a **Connection Name** (such as onelogin-customer) and copy the **SAML 2.0 Endpoint (HTTP)** on the **Sign In URL** input, and the **SLO Endpoint (HTTP)** on the **Sign Out URL** input. Upload the `onelogin.pem` certificate. - -![](/media/articles/saml/identity-providers/onelogin/auth0-set-values.png) - -Click on **SAVE**. You will get a dialog with a **Continue** button and a link, both will take you to the following instructions: - -![](/media/articles/saml/identity-providers/onelogin/auth0-instructions.png) - -The information here is what the OneLogin admin needs to finish the configuration of the SAML application. +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` -Copy the values of the **post-back URL** and the **Entity ID** and head back to your [OneLogin](https://www.onelogin.com/) app. At the **Configuration** tab copy the **post-back URL** on the **ACS (Consumer) URL** input, the **Entity ID** on the **Audience** input, and set a valid regular expression on the **ACS (Consumer) URL Validator** input (such as `[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)`). +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: -![](/media/articles/saml/identity-providers/onelogin/onelogin-set-values.png) +| Auth0 value | OneLogin configuration field | +| - | - | +| Post-back URL | ACS (Consumer) URL **and** Recipient | +| Entity ID | Audience | -## Testing +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@:%_\+.~#?&//=]*)`) -If you do not already have a user on OneLogin go at the **Users** tab and add one. Also, your new Auth0 SAMLP connection should be associated with an App, otherwise you will get an `invalid_request: the connection was disabled` error. +## Step 3: Test your connection -We are now set to test the connection! On your **SAMLP Identity Provider** connection click the **Try** button. +Before testing your connection: -![](/media/articles/saml/identity-providers/onelogin/auth0-try-conn.png) +* 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) -You are redirected to a page informing you that the connection works. Well done! +At this point, you are set to test the connection! Next to your **SAML** connection, click the **Try** button. -![](/media/articles/saml/identity-providers/onelogin/auth0-try-result.png) +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 Auth0 dashboard. You can't send this to an anonymous user (such as a customer). If you don't have a OneLogin user, read the following section to configure Idp Initiated SignOn so the customer can try on their portal. -::: +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. -## IdP Initiated SignOn - -**Beginning with auth0.js v9.3.4, you must [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** - -<%= include('../../../_includes/_deprecate-impersonation.md') %> - -OneLogin has an Application Portal / Launcher for their users. If you want to support that, you will have to change the **SAML Consumer URL** in OneLogin dashboard to be: - -* SAML Consumer URL: `https://${account.namespace}/login/callback?connection=onelogin-customer` +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. +::: -Where `onelogin-customer` is the connection name you assigned in Auth0 dashboard. +## IdP-initiated sign on -Also, you have to pick the application to redirect after the SAML assertion is consumed. You can find this in the **Connection > IdP Initiated SSO tab**. +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. -![](/media/articles/saml/identity-providers/onelogin/idp-initiated-sso.png) +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 information. Go to [Auth0 dashboard > Users](${manage_url}/#/users) and check your login. It should look like that: +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. -![](/media/articles/saml/identity-providers/onelogin/user-without-mappings.png) +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. -You have to edit the mappings in the Auth0 connection, along with the parameters in the OneLogin dashboard in order to map the information. Let's see how we could add the `EmailAddress` information to our login. +### User profile attributes -::: panel EmailAddress -Before you map the `EmailAddress` information, you have to add it as a custom parameter to the OneLogin dashboard. Use `EmailAddress` as __Field name__ and `Email` as __Value__. You can find details on the steps [here](#customize-the-user-profile). Save your changes and test the connection via Auth0 dashboard. Check that the `EmailAddress` is included in the attributes and the value is correct. You are now ready to proceed with mapping the information. -::: +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. -Go to the __Settings__ of your [SAMLP Identity Provider](${manage_url}/#/connections/enterprise) and navigate to the tab __Mappings__. Copy the mappings below and paste it in the text box. +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. -```javascript -{ - "email": "EmailAddress" -} -``` +In order to do so, navigate to the OneLogin dashboard and edit your app. -![](/media/articles/saml/identity-providers/onelogin/edit-mappings.png) +On the __Parameters__ tab, click __Add Parameter__. -Save your changes and try your connection again. Once you have successfully logged in, go to [Auth0 dashboard > Users](${manage_url}/#/users) and check your login. It should look like that: +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__. -![](/media/articles/saml/identity-providers/onelogin/user-with-mappings.png) +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 -`. -## Customize the User Profile +At the text box, set the value to `{firstname} {lastname}`. Click __Save__. -Some times 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. +At this point, we're ready to test our changes. -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. +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`. -In order to do so navigate to the OneLogin dashboard and edit your app. +::: 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). +::: -At the __Parameters__ tab click the __Add Parameter__ link. +### Add new parameter to the SAML assertion -![](/media/articles/saml/identity-providers/onelogin/custom-attr-01.png) +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. -At the popup set a name for your new custom attribute at the __Field name__ text box. Make sure you check the __Include in SAML assertion__ flag. Click __Save__. +### OneLogin configuration -![](/media/articles/saml/identity-providers/onelogin/custom-attr-02.png) +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`. -The new attribute you created is displayed. Click on the __Value__ field, currently displaying `- No default -`. +You can find details on the steps needed to customize the user profile [in the section above](#customize-the-user-profile). -Click on the __Value__ dropdown menu and select `- Macro -`. +Once you've made your changes, save them, and test your connection once again. -![](/media/articles/saml/identity-providers/onelogin/custom-attr-03.png) +Now, review your Auth0 user, making sure that the `EmailAddress` information is now included and that the value is correct. -At the text box set the value to `{firstname} {lastname}`. Click __Save__. +### Auth0 mappings -![](/media/articles/saml/identity-providers/onelogin/custom-attr-04.png) +You are now ready to proceed with mapping the user information fields in Auth0. -Let's test this. Go back to [Auth0 dashboard > Connections > Enterprise > SAMLP Identity Provider](${manage_url}/#/connections/enterprise) and on your __SAMLP Identity Provider__ connection click the __Try__ button. The result should include the new attribute `FullName`. +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. -![](/media/articles/saml/identity-providers/onelogin/custom-attr-05.png) +```javascript +{ + "email": "EmailAddress" +} +``` -You can find more information on _Attribute Macros_ at the [OneLogin Help Center](https://support.onelogin.com/hc/en-us/articles/201174464-Attribute-macros). +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/articles/protocols/saml/identity-providers/ping7.md b/articles/protocols/saml/identity-providers/ping7.md index 7cdd7ca25f..1165cfb3d1 100644 --- a/articles/protocols/saml/identity-providers/ping7.md +++ b/articles/protocols/saml/identity-providers/ping7.md @@ -1,111 +1,69 @@ --- title: PingFederate -description: How to configure PingFederate 7 as an identity provider. +description: How to configure PingFederate as an identity provider. +topics: + - saml + - identity-providers + - pingfederate +contentType: + - how-to +useCase: + - add-idp --- -# Configuring PingFederate 7 as an Identity Provider +# Configure PingFederate as an Identity Provider -Most options are the default values. You will just need to press __Next__ in most screens. If metadata import fails for some reason, keep these values at hand. These are the most important configuration parameters: +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-Redirect__ binding for SAML Request * __HTTP-POST__ binding for SAML Response -If you want **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`. - -**Beginning with auth0.js v9.3.4, you must also [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** - -<%= include('../../../_includes/_deprecate-impersonation.md') %> - -### 1. Download Auth0 Metadata File - -Download the metadata file from [here](https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME). This will be used in [step 3](#3-configure-the-__sp-connection__) and it is used to automatically import information about your partner. - -### 2. Create a new __SP Connection__ - -Login to _PingFederate_ as an administrator (the URL would be something like __https://{your ping server}:{port}/pingfederate/app__). Select __Create New__ from the __SP Connections__ section on the left: - -![](/media/articles/saml/identity-providers/ping7/ping-1.png) - -### 3. Configure the __SP Connection__ - -Select the __Browser SSO Profles__ as the __Connection Type__: - -![](/media/articles/saml/identity-providers/ping7/ping-2.png) - -Select __Browser SSO__ as the __Connection Options__: - -![](/media/articles/saml/identity-providers/ping7/ping-3.png) - -Upload the [__metadata file__](https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME) you downloaded in step 1. The __Entity ID__, __Connection Name__ and the __Base URL__ will be automatically completed based on the information from the metadata file. You can also complete other relevant information from your partner: - -![](/media/articles/saml/identity-providers/ping7/ping-4.png) - -### 4. Configure __Browser SSO__ - -Select __SP-Initiated SSO__ and __SP-Initiated SLO__ in __SAML Profiles__: - -![](/media/articles/saml/identity-providers/ping7/ping-5.png) - -Move on to the __Assertion Creation__ section and click on __Configure Assertion__: - -![](/media/articles/saml/identity-providers/ping7/ping-6.png) - -You can leave all defaults for the next two screens. Move on to the __IdP Adapter Mapping__ section: - -![](/media/articles/saml/identity-providers/ping7/ping-7.png) -![](/media/articles/saml/identity-providers/ping7/ping-8.png) - -The last step is to add an __IdP Adapter Mapping__. This is where users will actually be authenticated. Likely, you already have one configured in your _PingFederate_ installation. Select one, or add a new one. - -In principle, [Auth0](http://auth0.com) only requires the __NameIdentifier__ claim. All other attributes will be passed further to the end application. - -![](/media/articles/saml/identity-providers/ping7/ping-9.png) - -In this example, we are just using the `username` from a simple HTML IdP Adapter. No __Issuance Criteria__ are being used. - -![](/media/articles/saml/identity-providers/ping7/ping-10.png) - -### 5. Configure __Protocol Settings__ - -All important values for __Protocol Settings__ are imported from the __Metadata File__. You should see the __Assertion Consumer Service URL__: - -![](/media/articles/saml/identity-providers/ping7/ping-11.png) +::: 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`. +::: -And the Sign-Out URLs. Just click __Next__ to the __Allowable SAML Bindings__ section. +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. -![](/media/articles/saml/identity-providers/ping7/ping-12.png) +2. Sign on to your PingFederated account and select **Create New** from the **SP Connections** section. -Leave __POST__ and __Redirect__ enabled: +3. Configure the __SP Connection__. -![](/media/articles/saml/identity-providers/ping7/ping-13.png) + - Select the __Browser SSO Profiles__ as the __Connection Type__. + - Select __Browser SSO__ as the __Connection Options__. -Make sure __SAML Assertion__ is always signed and move on to the end of this section. +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. -![](/media/articles/saml/identity-providers/ping7/ping-14.png) +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. Configure __Credentials__ +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. -This is the last step for configuring __Browser SSO__. On __Digital Signature Settings__, select your signing certificate and make sure you check the option to include it in the `` element: + ::: note + Auth0 only requires the __NameIdentifier__ claim. All other attributes will be passed further to the end application. + ::: -![](/media/articles/saml/identity-providers/ping7/ping-15.png) +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. -The last two options to configure are the certificate used to sign incoming requests. Auth0 will not sign `SAMLRequests` by default. For some reason, there's no way around this setting. -Download the Auth0 certificate and upload it here. +8. Leave __POST__ and __Redirect__ enabled. Make sure __SAML Assertion__ is always signed. -![](/media/articles/saml/identity-providers/ping7/ping-16.png) -![](/media/articles/saml/identity-providers/ping7/ping-17.png) +9. Configure __Credentials__. On __Digital Signature Settings__, select your signing certificate and make sure you check the option to include it in the `` element. -### 7. Activation of the __SP Connection__ +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. -In the last step, you'll see the summary of all your previous settings and an option to set is as __Active__ or __Inactive__: + ::: note + Auth0 signs `SAMLRequests` by default; you can change that when you configure the connection. + ::: -![](/media/articles/saml/identity-providers/ping7/ping-18.png) +11. Review your settings and set as __Active__ or __Inactive__. -In any case, make sure your click the button __Save__ at the bottom of the screen. +12. Click __Save__ at the bottom of the screen. You should see the new SP Connection on the __Main__ screen. -You are done! You should see the new SP Connection on the __Main__ screen: +## Keep reading -![](/media/articles/saml/identity-providers/ping7/ping-19.png) +* 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/articles/protocols/saml/identity-providers/salesforce.md b/articles/protocols/saml/identity-providers/salesforce.md index 2e8381d907..35bbe93e2b 100644 --- a/articles/protocols/saml/identity-providers/salesforce.md +++ b/articles/protocols/saml/identity-providers/salesforce.md @@ -1,87 +1,87 @@ --- -description: How to configure Auth0 to use SalesForce as an identity provider. +description: How to configure Auth0 to use Salesforce as an identity provider. +topics: + - saml + - identity-providers + - salesforce +contentType: + - how-to +useCase: + - add-idp --- -# SAML SSO with SalesForce +# Configure Salesforce as an Identity Provider -This article describes how to configure Auth0 to use **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. +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. +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. 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. +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**. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-1.png) 5. Create an Identity Provider by clicking **Enable Identity Provider**. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-2.png) 6. Select the default certificate and click **Save**. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-3.png) 7. Click **Download Certificate** to download the Identity Provider certificate. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-4.png) 8. Click **Download Metadata** to download the Identity Provider metadata. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-5.png) ## 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. +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 **SAMLP Identity Provider** +2. Click on **SAML** 3. Click on **Create New Connection** -4. In the **Create SAMLP Identity Provider connection** window, enter the following information into the **Configuration** tab: +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: + **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. + where "{sf-account-name}" is your Salesforce account domain name. **Sign Out URL:** enter the same URL that was entered for Sign In URL. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-6.png) - **Certificate:** The certificate downloaded from SalesForce is in .crt format. Convert this certificate to .pem format with the following command. + **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 on **SAVE**. -7. Click on **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. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-7.png) +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 +## 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. +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. Click on **Setup** in upper right. -3. Click on **Manage Apps** on the left. -4. Click on **Connected Apps**. -5. Create a new Connected App and fill out the following fields: +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` @@ -95,34 +95,31 @@ In this step, you will configure SalesForce with the metadata from Auth0 so it c 6. Click **Save** to complete the configuration of the IDP. -## 4. Grant Privileges to Users in SalesForce +## 4. Grant Privileges to Users in Salesforce -1. Open **[SalesForce.com](http://salesforce.com)** and click **Setup**. -2. Under **Manage Users**, click on **Profiles**. +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. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-9.png) - 7. Click **Save**. 8. Under **Manage Users**, click **Users**. 9. Click **Edit** to edit your test user and set the profile to **Standard User**. - ![](/media/articles/saml/identity-providers/salesforce/salesforceidp-10.png) ::: 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. +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 +## 5. Test the connection to the Salesforce IDP -In this step, you will test the SAML configuration between Auth0 and SalesForce. +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. +* 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 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. @@ -132,10 +129,10 @@ 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: [Troubleshooting with HAR files](/har). +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. +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). +Make sure that the user's profile in Salesforce has permission to login via the Salesforce IDP (See section 4 above). diff --git a/articles/protocols/saml/identity-providers/siteminder.md b/articles/protocols/saml/identity-providers/siteminder.md index 97edfc582b..f8a0765b73 100644 --- a/articles/protocols/saml/identity-providers/siteminder.md +++ b/articles/protocols/saml/identity-providers/siteminder.md @@ -1,15 +1,25 @@ --- title: SiteMinder description: How to configure SiteMinder as an identity provider. +topics: + - saml + - identity-providers + - siteminder +contentType: + - how-to +useCase: + - add-idp --- -# Configuring SiteMinder as an Identity Provider +# Configure SiteMinder as an Identity Provider -Most options are the default values. These are the most important configuration parameters you will need: +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-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. @@ -20,24 +30,18 @@ Provide an appropriate name for this Service Provider. We suggest using: * __Name:__ `${account.tenant}` -![](/media/articles/saml/identity-providers/siteminder/siteminder-users.png) - ### 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` in the example blow: - -![](/media/articles/saml/identity-providers/siteminder/siteminder-nameids.png) +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 for this configuration screen: +Use the following values when prompted: * __SP ID:__ `urn:auth0:${account.tenant}` * __SAML Version:__ `2.0` * __Skew Time:__ `30 seconds` -![](/media/articles/saml/identity-providers/siteminder/siteminder-general.png) - ### 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: @@ -45,20 +49,14 @@ The __Assertion Consumer Service URL__ is the location where SiteMinder will POS * __Assertion Consumer Service:__ `https://${account.namespace}/login/callback` * __HTTP-Post__: `checked` -![](/media/articles/saml/identity-providers/siteminder/siteminder-sso.png) - ### 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`, `e-mail 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: - -![](/media/articles/saml/identity-providers/siteminder/siteminder-attributes.png) +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 +### 6. Enter the Single Sign-Out URL * __SLO Location URL:__ `https://${account.namespace}/logout` -![](/media/articles/saml/identity-providers/siteminder/siteminder-slo.png) - ### 7. Optional Assertion Encryption The Service Provider supports encryption of Assertions. @@ -70,6 +68,4 @@ To use this option, do the following to download the Service Provider public key 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__. - -![](/media/articles/saml/identity-providers/siteminder/siteminder-encryption.png) +Download the desired certificate and add it to the SiteMinder __Policy Server Keystore__. \ No newline at end of file diff --git a/articles/protocols/saml/identity-providers/ssocircle.md b/articles/protocols/saml/identity-providers/ssocircle.md index 558d6f0ba1..b5b1f0448e 100644 --- a/articles/protocols/saml/identity-providers/ssocircle.md +++ b/articles/protocols/saml/identity-providers/ssocircle.md @@ -1,11 +1,19 @@ --- -title: SAML SSO with SSOCircle as an Identity Provider -description: How to configure an application to use Auth0 for SAML Single Sign On (SSO), authenticating users against SSOCircle +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 --- -# SAML SSO with SSOCircle as an Identity Provider +# Configure SSOCircle as an Identity Provider -This tutorial will create a sample application that uses Auth0 for SAML Single Sign On (SSO), authenticating users against identity provider **SSOCircle**. +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. @@ -15,37 +23,31 @@ As of July 8, 2016, SSOCircle supports integration via [manual configuration usi Navigate to [SSOCircle's IDP page](https://idp.ssocircle.com/) to see the metadata required for integration. You will be shown an XML file. -![Metadata XML Display](/media/articles/saml/identity-providers/ssocircle/metadata-xml.png) - 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. -![HTTP Redirect URL for Sign On](/media/articles/saml/identity-providers/ssocircle/metadata-snippet1.png) - 2. The Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type. -![HTTP Redirect URL for Log Out](/media/articles/saml/identity-providers/ssocircle/metadata-snippet2.png) - [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. Configuring Auth0 +## 2. Configure an enterprise connection in Auth0 In this step, you will configure the integration from the Auth0 side. -While logged in to the [Auth0 Management Dashboard](${manage_url}), navigate to the [Enterprise Connections](${manage_url}/#/connections/enterprise) page. To the right of **SAMLP Identity Provider**, click **+** to create a new Enterprise Connection. - -![Auth0 Create Enterprise Connection Screen](/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png) +To do so, see [Connect Your App to SAML Identity Providers](/connections/enterprise/saml). -You will be presented with a pop-up window titled **Create SAMLP Identity Provider Connection**. Enter the following information into the appropriate fields on the **Configuration** tab: +While setting up your connection, make sure you use the following settings: -* **Connection Name:** the name of your connection -* **Email Domains:** if you are using Lock, the email domain name(s) for the users that will be logging in via this Connection (for example `auth0.com`) -* **Sign In URL:** the location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata -* **Sign Out URL:** the Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata -* Upload the **SSOCircle CA Certificate** you saved in [step 1](#1-obtain-the-ssocircle-metadata) as the **X509 Signing Certificate**. +| 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. | -Finally, click on the **Mappings** tab and use the following JSON to properly map SAML attributes from SSO Circle: +When setting up mappings, use the following JSON to properly map SAML attributes from SSO Circle, and click **Save**: ```json { @@ -55,23 +57,11 @@ Finally, click on the **Mappings** tab and use the following JSON to properly ma } ``` -Click **Save**. - -![Auth0 Configure SSOCircle Connection Screen](/media/articles/saml/identity-providers/ssocircle/configure-ssocircle-connection.png) - -At this point, you will see a pop-up window that presents you with two options. If you are an administrator with the necessary privileges for configuring the integration, click **Continue**. If not, forward the link indicated to the person who will be completing this process. - -![Prompt if Administrator](/media/articles/saml/identity-providers/ssocircle/is-admin.png) - -If you click **Continue**, you will be shown the SAML Identity Provider Configuration information. At the bottom of this information is a URL that will provide you with the necessary metadata for your integration with SSOCircle. Copy this URL. - -![SAML Configuration Info Display](/media/articles/saml/identity-providers/ssocircle/saml-config-info.png) - ::: 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 @@ -79,46 +69,32 @@ 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. -![SSOCircle User Profile](/media/articles/saml/identity-providers/ssocircle/user-profile.png) - In the navigation bar, click **Manage Metadata**. -![Manage Metadata Screen](/media/articles/saml/identity-providers/ssocircle/manage-provider-metadata.png) - 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**. @@ -126,33 +102,15 @@ 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. -![](/media/articles/saml/identity-providers/ssocircle/enable-connection.png) - ## 5. Test the Auth0-SSOCircle Connection In this step, you will test to make sure the SAML configuration between Auth0 and SSOCircle is working. -While logged in to the [Auth0 Management Dashboard](${manage_url}), navigate to the [Enterprise Connections](${manage_url}/#/connections/enterprise) page and click the **SAMLP Identity Provider** row. +To test your connection, see [Test Enterprise Connections](/dashboard/guides/connections/test-connections-enterprise). -![Auth0 Create Enterprise Connection Screen](/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png) +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. -To test, click the **triangle** next to the Connection you created earlier. - -![Connection Options Screen](/media/articles/saml/identity-providers/ssocircle/test-connection.png) - -You should be redirected from Auth0 to the SSOCircle login page. Log in with the credentials you provided when creating the SSOCircle account. - -![Login Screen](/media/articles/saml/identity-providers/ssocircle/login.png) - -You may receive a window that says, "Your session has timed out." If so, click the **Return to Login page** link below this message. - -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) - -At this point, 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 SSOCircle IDP to Auth0. - -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 @@ -191,7 +149,7 @@ 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. +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. @@ -199,8 +157,6 @@ Open the `hello-saml.html` file with a web browser. You should see a white page Click **Login**. The **Auth0 Lock** Widget will appear. -![](/media/articles/saml/identity-providers/ssocircle/lock.png) - ::: 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. ::: @@ -211,7 +167,7 @@ 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**. +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) diff --git a/articles/protocols/saml/idp-initiated-sso.md b/articles/protocols/saml/idp-initiated-sso.md index 26b817a908..bf2e5617b9 100644 --- a/articles/protocols/saml/idp-initiated-sso.md +++ b/articles/protocols/saml/idp-initiated-sso.md @@ -1,26 +1,54 @@ --- -title: IdP-Initiated SSO -description: How to setup SAML Identity Provider initiated SSO. +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 SSO +# IdP-Initiated Single Sign-On -**Beginning with auth0.js v9.3.4, you must [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** +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. -<%= include('../../_includes/_deprecate-impersonation.md') %> +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. -![](/media/articles/protocols/saml/idp-init-sso.png) +![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. 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. +**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](/scopes) for the ID Token sent. Note that it is possible to set multiple scopes. +* `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: @@ -29,4 +57,35 @@ Example Query String: ## 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` \ No newline at end of file +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/articles/protocols/saml/index.html b/articles/protocols/saml/index.html index e0d9524c97..7be7d02149 100644 --- a/articles/protocols/saml/index.html +++ b/articles/protocols/saml/index.html @@ -3,13 +3,19 @@ section: articles classes: topic-page title: SAML +topics: + - saml +contentType: + - index +useCase: + - add-idp ---

        SAML

        - Documentation on SAML protocol. + Documentation on SAML protocol.

        @@ -36,13 +42,13 @@

        SAML

        Supported SAML Options and Bindings
      • - Special Configuration Scenarios: IdP-Initiated SSO, Signing and Encrypting SAML Requests + Special Configuration Scenarios: IdP-Initiated Single Sign-on (SSO), Signing and Encrypting SAML Requests
      • Customize SAML Assertions
      • - Select Between Multiple Identity Providers + Select Between Multiple Identity Providers
      • Logout @@ -70,13 +76,13 @@

        SAML

      • SAML Applications

        - This page lists SAML Configurations for various SSO integrations including Google Apps, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday and Pluralsight. + This page lists SAML Configurations for various Single Sign-on (SSO) integrations including Atlassian, G Suite, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday, and Pluralsight.

      • SAML and Active Directory Federation Services

        - How to configure a SAML connection for use with ADFS. + How to configure a SAML connection for use with Microsoft Active Directory Federations Services (ADFS).

      • @@ -95,7 +101,7 @@

        SAML

        PingFederate 7
      • - SalesForce + Salesforce
      • SiteMinder diff --git a/articles/protocols/saml/saml-apps/_header.md b/articles/protocols/saml/saml-apps/_header.md index fd42bcb7e1..d3708bc803 100644 --- a/articles/protocols/saml/saml-apps/_header.md +++ b/articles/protocols/saml/saml-apps/_header.md @@ -2,4 +2,4 @@ ## SAML Configuration -Use the following SAML configuration: +Use the following SAML configuration: diff --git a/articles/protocols/saml/saml-apps/atlassian.md b/articles/protocols/saml/saml-apps/atlassian.md new file mode 100644 index 0000000000..7d2bae9c92 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/cisco-webex.md b/articles/protocols/saml/saml-apps/cisco-webex.md index 66a4f7f11d..4c32cef3d7 100644 --- a/articles/protocols/saml/saml-apps/cisco-webex.md +++ b/articles/protocols/saml/saml-apps/cisco-webex.md @@ -1,9 +1,18 @@ --- 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')} +<%= include('./_header') %> ```json { diff --git a/articles/protocols/saml/saml-apps/datadog.md b/articles/protocols/saml/saml-apps/datadog.md index 8485577480..45b50ab027 100644 --- a/articles/protocols/saml/saml-apps/datadog.md +++ b/articles/protocols/saml/saml-apps/datadog.md @@ -1,9 +1,17 @@ --- title: Datadog SAML Configuration description: Datadog SAML Configuration +topics: + - saml + - identity-providers + - datadog +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -21,6 +29,6 @@ ${include('./_header')} } ``` -**Callback URL**: `https://app.datadoghq.com/account/saml/assertion` +The **Callback URL** is `https://app.datadoghq.com/account/saml/assertion`. -Notice that Datadog has an option to automatically provision new users. Check [here](http://docs.datadoghq.com/guides/saml/) for more details. +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/articles/protocols/saml/saml-apps/egencia.md b/articles/protocols/saml/saml-apps/egencia.md index f7fac4b336..6fbc053c54 100644 --- a/articles/protocols/saml/saml-apps/egencia.md +++ b/articles/protocols/saml/saml-apps/egencia.md @@ -1,9 +1,17 @@ --- title: Egencia SAML Configuration description: Egencia SAML Configuration +topics: + - saml + - identity-providers + - egencia +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json @@ -22,4 +30,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://www.egencia.com/auth/v1/artifactConsumer`. +The **Callback URL** is `https://www.egencia.com/auth/v1/artifactConsumer`. diff --git a/articles/protocols/saml/saml-apps/eloqua.md b/articles/protocols/saml/saml-apps/eloqua.md index 2902ab862d..cabc886eb5 100644 --- a/articles/protocols/saml/saml-apps/eloqua.md +++ b/articles/protocols/saml/saml-apps/eloqua.md @@ -1,9 +1,17 @@ --- 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')} +<%= include('./_header') %> ```json @@ -24,7 +32,7 @@ ${include('./_header')} ``` -The **Callback URL** is `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. diff --git a/articles/protocols/saml/saml-apps/freshdesk.md b/articles/protocols/saml/saml-apps/freshdesk.md index 6c98f88387..5e528c57ff 100644 --- a/articles/protocols/saml/saml-apps/freshdesk.md +++ b/articles/protocols/saml/saml-apps/freshdesk.md @@ -1,29 +1,39 @@ --- title: Freshdesk SAML Configuration description: Freshdesk SAML Configuration +topics: + - saml + - identity-providers + - freshdesk +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= 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}.freshdesk.com", - "mappings": { - "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", - "given_name": "User.FirstName", - "family_name": "User.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" - ] + "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" + ] } ``` -With the following callback: - -`https://{FD Domain}.freshdesk.com/login/saml` +The **Callback URL** is `https://{FD Domain}.freshdesk.com/login/saml`. diff --git a/articles/protocols/saml/saml-apps/github-cloud.md b/articles/protocols/saml/saml-apps/github-cloud.md new file mode 100644 index 0000000000..fdd173f9e9 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/github-server.md b/articles/protocols/saml/saml-apps/github-server.md new file mode 100644 index 0000000000..4495d0bca6 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/google-apps.md b/articles/protocols/saml/saml-apps/google-apps.md index b1a10ee92c..1bb7255078 100644 --- a/articles/protocols/saml/saml-apps/google-apps.md +++ b/articles/protocols/saml/saml-apps/google-apps.md @@ -1,9 +1,17 @@ --- -title: Google Apps SAML Configuration -description: Google Apps SAML Configuration +title: G Suite SAML Configuration +description: G Suite SAML Configuration +topics: + - saml + - identity-providers + - g-suite +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -24,4 +32,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs`. +The **Callback URL** is `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs`. diff --git a/articles/protocols/saml/saml-apps/heroku.md b/articles/protocols/saml/saml-apps/heroku.md index 6fb7efc36e..2cefaeeea2 100644 --- a/articles/protocols/saml/saml-apps/heroku.md +++ b/articles/protocols/saml/saml-apps/heroku.md @@ -1,18 +1,26 @@ --- -description: How to SSO with Heroku. +description: Learn how to configure Single Sign-on (SSO) with Heroku. +topics: + - saml + - identity-providers + - heroku +contentType: + - how-to +useCase: + - add-idp --- -# Configure SSO with Heroku +# Configure Single Sign-on with Heroku ::: note -You must have administrative rights to your organization account on Heroku to configure SSO. Organization accounts are included with Heroku Enterprise plans. +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 SSO so that your users can log into Heroku using any of Auth0's supported [identity providers](/identityproviders). +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. +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) @@ -23,7 +31,7 @@ You will need the following two parameters from this section to integrate with A ## 2. Register Heroku with Auth0 -Log in to your [Auth0 Dashboard](${manage_url}/#/applications) and select the [application](/applications) for which you want to enable SSO with Heroku. Go to the __Addons__ section of your Application, and enable __SAML2 Web App__: +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) diff --git a/articles/protocols/saml/saml-apps/hosted-graphite.md b/articles/protocols/saml/saml-apps/hosted-graphite.md index 2079bb828c..cbeb6da827 100644 --- a/articles/protocols/saml/saml-apps/hosted-graphite.md +++ b/articles/protocols/saml/saml-apps/hosted-graphite.md @@ -1,9 +1,17 @@ --- title: Hosted Graphite SAML Configuration description: Hosted Graphite SAML Configuration +topics: + - saml + - identity-providers + - hosted-graphite +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -15,4 +23,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/`. +The **Callback URL** is `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/`. diff --git a/articles/protocols/saml/saml-apps/index.md b/articles/protocols/saml/saml-apps/index.md index 7612c9d4a2..472ae21b8d 100644 --- a/articles/protocols/saml/saml-apps/index.md +++ b/articles/protocols/saml/saml-apps/index.md @@ -1,32 +1,43 @@ --- -title: SAML Configurations for SSO Integrations -description: This page lists SAML Configurations for various SSO integrations including Google Apps, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday, Pluralsight and Workpath. +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 SSO Integrations

        +

        SAML Configurations for Single Sign-on Integrations

        - This page lists SAML Configurations for various SSO 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/articles/protocols/saml/saml-apps/litmos.md b/articles/protocols/saml/saml-apps/litmos.md index f50d8a870b..756f9ca3b4 100644 --- a/articles/protocols/saml/saml-apps/litmos.md +++ b/articles/protocols/saml/saml-apps/litmos.md @@ -1,9 +1,17 @@ --- title: Litmos SAML Configuration description: Litmos SAML Configuration +topics: + - saml + - identity-providers + - litmos +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -29,9 +37,7 @@ ${include('./_header')} } ``` -## Application Callback URL - -`https://{YOUR DOMAIN}.litmos.com/integration/samllogin` +The **Callback URL** is `https://{YOUR DOMAIN}.litmos.com/integration/samllogin`. ## Sample SAML diff --git a/articles/protocols/saml/saml-apps/pluralsight.md b/articles/protocols/saml/saml-apps/pluralsight.md index ff3c559404..ea769d56c2 100644 --- a/articles/protocols/saml/saml-apps/pluralsight.md +++ b/articles/protocols/saml/saml-apps/pluralsight.md @@ -1,9 +1,17 @@ --- title: Pluralsight SAML Configuration description: Pluralsight SAML Configuration +topics: + - saml + - identity-providers + - pluralsight +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json @@ -26,4 +34,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://prod-pf.pluralsight.com/sp/ACS.saml2`. +The **Callback URL** is `https://prod-pf.pluralsight.com/sp/ACS.saml2`. diff --git a/articles/protocols/saml/saml-apps/sprout-video.md b/articles/protocols/saml/saml-apps/sprout-video.md index 4a1be81e92..fd4ada302c 100644 --- a/articles/protocols/saml/saml-apps/sprout-video.md +++ b/articles/protocols/saml/saml-apps/sprout-video.md @@ -1,9 +1,17 @@ --- title: Sprout Video SAML Configuration description: Sprout Video SAML Configuration +topics: + - saml + - identity-providers + - sprout-video +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { diff --git a/articles/protocols/saml/saml-apps/tableau-online.md b/articles/protocols/saml/saml-apps/tableau-online.md new file mode 100644 index 0000000000..685f3b65b4 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/tableau-server.md b/articles/protocols/saml/saml-apps/tableau-server.md index 31dfe97335..e299a22d92 100644 --- a/articles/protocols/saml/saml-apps/tableau-server.md +++ b/articles/protocols/saml/saml-apps/tableau-server.md @@ -1,9 +1,17 @@ --- title: Tableau Server SAML Configuration description: Tableau Server SAML Configuration +topics: + - saml + - identity-providers + - tableau +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -28,4 +36,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html`. +The **Callback URL** is `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html`. diff --git a/articles/protocols/saml/saml-apps/workday.md b/articles/protocols/saml/saml-apps/workday.md index a419536df7..1e3f3f6970 100644 --- a/articles/protocols/saml/saml-apps/workday.md +++ b/articles/protocols/saml/saml-apps/workday.md @@ -1,9 +1,17 @@ --- title: Workday SAML Configuration description: Workday SAML Configuration +topics: + - saml + - identity-providers + - workday +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -15,6 +23,7 @@ ${include('./_header')} "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", @@ -23,4 +32,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://impl.workday.com//fx/home.flex`. +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/articles/protocols/saml/saml-apps/workpath.md b/articles/protocols/saml/saml-apps/workpath.md index 14b01d88dc..60e2f170b2 100644 --- a/articles/protocols/saml/saml-apps/workpath.md +++ b/articles/protocols/saml/saml-apps/workpath.md @@ -1,9 +1,13 @@ --- title: Workpath SAML Configuration description: Workpath SAML Configuration +contentType: + - how-to +useCase: + - add-idp --- -${include('./_header')} +<%= include('./_header') %> ```json { @@ -16,4 +20,4 @@ ${include('./_header')} } ``` -The **Callback URL** is `https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}`. +The **Callback URL** is `https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}`. diff --git a/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md b/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md index 111a85349c..999e7a133b 100644 --- a/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md +++ b/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md @@ -1,5 +1,11 @@ --- - description: How to configure Auth0 for use as a SAML service AND identity provider +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 @@ -10,11 +16,11 @@ Auth0 provides a non-exhaustive [list of SAML-compliant providers](/samlp-provid ::: 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 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: +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). diff --git a/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md b/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md index e9d234fb48..56178f72e1 100644 --- a/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md +++ b/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md @@ -1,22 +1,28 @@ --- - description: How to configure Auth0 for use as a SAML identity provider +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**. +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. -## SSO Integrations with Built-in Auth0 Support +## Single Sign-on Integrations with Built-in Auth0 Support -For some 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**. +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: + 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 @@ -28,7 +34,7 @@ For some SSO Integrations that support SAML, the configuring Auth0 is done using * Egnyte * New Relic * Office 365 -* SalesForce +* Salesforce * SharePoint * Slack * SpringCM diff --git a/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md b/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md index 774b3379f6..7ed558c5f6 100644 --- a/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md +++ b/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md @@ -1,11 +1,17 @@ --- - description: How to configure Auth0 for use as a SAML service provider +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**. +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. @@ -21,7 +27,7 @@ Finally, you'll configure the Identity Provider (IdP) portion of your SAML setup * [Okta](/okta) * [OneLogin](/onelogin) * [Ping7](/ping7) -* [SalesForce](/saml/identity-providers/salesforce) +* [Salesforce](/saml/identity-providers/salesforce) * [SiteMinder](/siteminder) * [SSOCircle](/ssocircle) diff --git a/articles/protocols/saml/saml-configuration/deprovision-users.md b/articles/protocols/saml/saml-configuration/deprovision-users.md index 8db6662bfd..08d1523ec3 100644 --- a/articles/protocols/saml/saml-configuration/deprovision-users.md +++ b/articles/protocols/saml/saml-configuration/deprovision-users.md @@ -1,5 +1,12 @@ --- - description: Best practices on deprovision users of your SAML integration +description: Best practices on deprovision users of your SAML integration +topics: + - saml +contentType: + - how-to + - concept +useCase: + - add-idp --- # Deprovision Users diff --git a/articles/protocols/saml/saml-configuration/design-considerations.md b/articles/protocols/saml/saml-configuration/design-considerations.md index 16b90cc51b..68ac4fbf90 100644 --- a/articles/protocols/saml/saml-configuration/design-considerations.md +++ b/articles/protocols/saml/saml-configuration/design-considerations.md @@ -1,10 +1,16 @@ --- - description: Things to consider when designing your SAML integration +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 SSO, it's important to consider: +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; @@ -16,11 +22,11 @@ Regardless of how you implement SAML SSO, it's important to consider: * 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 additonal attributes are then sent to the application (in addition to any added by the identity provider) the next time the user logs in. + * 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 retreives any missing information from another source. With the two sets of information, the application creates a local user 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. diff --git a/articles/protocols/saml/saml-configuration/index.md b/articles/protocols/saml/saml-configuration/index.md index d24841f101..0c6ff2b5b3 100644 --- a/articles/protocols/saml/saml-configuration/index.md +++ b/articles/protocols/saml/saml-configuration/index.md @@ -1,10 +1,17 @@ --- 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: +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. @@ -13,7 +20,7 @@ Auth0 supports the SAML protocol and can serve as the identity provider, the ser ## 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. +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. @@ -23,7 +30,7 @@ Once the user is authenticated, Auth0 returns a SAML assertion to the applicatio ## SAML Service Providers -Applications, especially custom ones, can authenticate users against an external IdP using protocols such as OpenID Connect 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. +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) @@ -44,7 +51,7 @@ The following documentation cover the different aspects of SAML configuration: * [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](/protocols/saml/saml-configuration/selecting-between-multiple-idp) +* [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/articles/protocols/saml/saml-configuration/logout.md b/articles/protocols/saml/saml-configuration/logout.md index 696ea8ef08..efc2414f46 100644 --- a/articles/protocols/saml/saml-configuration/logout.md +++ b/articles/protocols/saml/saml-configuration/logout.md @@ -1,22 +1,42 @@ --- -description: How to log out of SAML providers +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 --- -# Logout +# Log Users Out of Auth0 as the SAML Identity Provider -When integrating with a SAML provider, there are many ways to implement logout or user session termination. +When integrating with a SAML identity provider, there are many ways to implement logout or *user session termination*. -::: note -Please see [Logout](/logout) for additional information. -::: +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. -## Auth0 as SAML Identity Provider +## Logout scenarios -If Auth0 acts as the identity provider, you'll need to specify a logout URL for your Auth0 Application's addon: +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: + +4. In the **Settings** editor, uncomment the `logout` portion and update it with your callback URL: ```json "logout": { @@ -24,9 +44,11 @@ If Auth0 acts as the identity provider, you'll need to specify a logout URL for } ``` + 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 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`: +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": { @@ -43,3 +65,12 @@ By default, SAML logout responses are sent using the **HTTP-POST** protocol bind }, "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/articles/protocols/saml/saml-configuration/saml-assertions.md b/articles/protocols/saml/saml-configuration/saml-assertions.md index b3d28355b6..797c742986 100644 --- a/articles/protocols/saml/saml-configuration/saml-assertions.md +++ b/articles/protocols/saml/saml-configuration/saml-assertions.md @@ -1,10 +1,17 @@ --- - description: How to customize SAML assertions +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. +You can customize your SAML assertions, as well as the SAML and WS-Fed protocol parameters. ## Auth0 as the Identity Provider @@ -12,7 +19,7 @@ To customize your SAML assertions when Auth0 acts as the identity provider, you ### Use the Application Addon -To customize your SAML assertion using the application addon, 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: +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; @@ -26,6 +33,10 @@ You can use rules to add more extensive or dynamic customizations to the SAML re 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 @@ -36,7 +47,7 @@ function (user, context, callback) { // if available, use upn as NameID if (user.upn) { context.samlConfiguration.mappings = { - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "upn" + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "upn" // use user.upn as the value } } @@ -49,13 +60,9 @@ function (user, context, callback) { ```js function (user, context, callback) { user.user_metadata = user.user_metadata || {}; - user.user_metadata.color2 = "purple"; + user.user_metadata.color = "purple"; context.samlConfiguration.mappings = { - //Attribute already in user_metadata - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "user_metadata.color", - - //Attribute dynamically added to user_metadata above - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "user_metadata.color", + "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); } @@ -69,7 +76,7 @@ The following is a list of customization options for your SAML assertions. * **recipient** (string): The recipient of the SAML Assertion (SubjectConfirmationData). Default is `AssertionConsumerUrl` on SAMLRequest or Callback URL if no SAMLRequest was sent. -* **mappings** (Array): The mappings between Auth0 profile and the output attributes on the SAML Assertion. Default mapping is shown above. +* **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. @@ -77,15 +84,15 @@ The following is a list of customization options for your SAML assertions. * **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. +* **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 `sha1` and it could be `sha256`. +* **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). +* **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. @@ -93,8 +100,18 @@ The following is a list of customization options for your SAML assertions. * **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**: Default is `urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified`. +* **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"`. -* **typedAttributes**: 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` +* **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 -* **includeAttributeNameFormat**: 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 + ``` + "-----BEGIN PUBLIC KEY-----\nMIGf...bpP/t3\n+JGNGIRMj1hF1rnb6QIDAQAB\n-----END PUBLIC KEY-----\n" + ``` diff --git a/articles/protocols/saml/saml-configuration/selecting-between-multiple-idp.md b/articles/protocols/saml/saml-configuration/selecting-between-multiple-idp.md deleted file mode 100644 index b822eae0f2..0000000000 --- a/articles/protocols/saml/saml-configuration/selecting-between-multiple-idp.md +++ /dev/null @@ -1,11 +0,0 @@ ---- - description: How to use Home Realm Discovery with SAML ---- - -# Select from Multiple Identity Providers - -If you need to use Home Realm Discovery, which is basically selecting between multiple Auth0 Connections (each of which represents a different identity provider), [you can do so programmatically](/hrd) by: - -* Specifying the Connection in the call invoking authentication; -* Specifying the email domain(s) for each Connection in the Connection Settings page of the Auth0 Dashboard; -* Adding custom buttons to the Lock widget so that users choose the Connection they want to use. diff --git a/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md index 56c7a05fbb..09ec481adf 100644 --- a/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md +++ b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md @@ -1,14 +1,17 @@ --- - description: Setting up IdP-initiated SSO + description: Learn to set up IdP-initiated Single Sign-on (SSO) + topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp --- -# Special Configuration Scenarios: IdP Initiates SSO +# Special Configuration Scenarios: IdP-Initiated Single Sign-On -**Beginning with auth0.js v9.3.4, you must [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** - -<%= include('../../../../_includes/_deprecate-impersonation.md') %> - -Many instructions for setting up a SAML federation begin with SSO initiated by the service provider: +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. @@ -32,20 +35,20 @@ For example, an organization might set up a portal to ensure that users navigate 3. If successfully authenticated, the user clicks on the appropriate link; 4. The user is redirected to the service provider with a SAML assertion. -## Auth0 as Service Provider Where IdP Initiates SSO +## Risks of Using an IdP-Initiated SSO Flow -If Auth0 acts as the service provider, you need to make the following changes to support IdP-initiated SSO: +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. -* Ensure the IdP includes the Connection parameter in the assertion consumer service (ACS) URL. -* When configuring the Connection, use the IdP-initiated tab to specify the following: +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. - 1. The application to which the user gets redirected after IdP login; - 2. The protocol to be used between Auth0 and the application when Auth0 forwards the results of the user authentication to the client application; - 3. Query parameters to pass to the app. +## 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 need to make the following changes to support IdP-initiated 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: @@ -57,5 +60,7 @@ If Auth0 acts as the identity provider, you need to make the following changes t ```text https://${account.namespace}/samlp - /${account.clientId}?RelayState=http://FINAL_DESTINATION_URL + /${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/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md index 841c134a65..d27d7e9011 100644 --- a/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md +++ b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md @@ -1,15 +1,22 @@ --- 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. +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 a [Application](/protocols/saml/saml-configuration/auth0-as-identity-provider). +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 exisiting SAML integration, not configuring an integration from scratch. +The instructions below assume that you're altering specific settings for an existing SAML integration, not configuring an integration from scratch. ## Scenarios diff --git a/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md index c91e222ce8..dc76d7a160 100644 --- a/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md +++ b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md @@ -1,12 +1,26 @@ --- 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. +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: -## Sign the SAML Authentication Request +- 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: @@ -14,36 +28,120 @@ If Auth0 is the SAML **service provider**, you can sign the authentication reque 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 +#### 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`. -```har +::: 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 { - "method": "PATCH", - "url": "https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [{ - "name": "Authorization", - "value": "Bearer MGMT_API_ACCESS_TOKEN" - }], - "queryString": [], - "postData": { - "mimeType": "application/json", - "text": "{ \"name\": \"CONNECTION_NAME\", \"options\": \"{\"validation\": \"object\", \"passwordPolicy\": \"\", \"password_history\": \"object\", \"password_no_personal_info\": \"object\", \"password_dictionary\": \"object\", \"deflate\": \"false\",}\" }" - }, - "headersSize": -1, - "bodySize": -1, - "comment": "" + { + "options" : { + [...], // all the other connection options + "deflate": false + } } ``` -## Sign the SAML Authentication Responses/Assertions +### 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. -If Auth0 is the SAML **identity provider**, it can sign responses/assertions with its private key and provide the service provider with the public key/certificate necessary to validate the signature. +::: 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}): @@ -51,51 +149,107 @@ To retrieve the certificate you need to send to your IdP from the [Management Da 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. -Next, you'll need make sure that the SAML assertion is *not* signed (you can sign either the assertion or the response, but not both). Here's how to unsign the SAML Assertion: +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. By default, `signResponse` is true. As such, uncomment this line and set the value to `false`. Your SAML assertion will no longer be signed. +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: -## Receive Signed SAML Authentication Requests +```json +{ + [...], // other settings + "signResponse": true +} +``` -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. +#### Change the signing key for SAML responses -To configure signature validation, you'll need to download the service provider's public key and store the value in the `signingCert` key. You can find the `signingCert` field in the [Management Dashboard](${manage_url}) by going to **Applications** > **Addons** > **SAML2 WEB APP** > **Settings**. +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: -## Receive Signed SAML Authentication Responses +```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); +} +``` -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. +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. -You will then need to configure Auth0 to validate the responses' signatures by: +### Receive Signed SAML Authentication Requests -* 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**) +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. -Auth0 can accept a signed response for the assertion, the response, or both. +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**. -## Send Encrypted SAML Authentication Assertions +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 public key/certificate from the service provider. +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: -Here is a sample snippet of Rules code. +```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) { - - context.samlConfiguration = (context.samlConfiguration || {}); - context.samlConfiguration.encryptionPublicKey = "-----BEGIN PUBLIC KEY-----\nMIGf...bpP/t3\n+JGNGIRMj1hF1rnb6QIDAQAB\n-----END PUBLIC KEY-----\n"; - context.samlConfiguration.encryptionCert = "-----BEGIN CERTIFICATE-----\nMII...u84\n-----END CERTIFICATE-----\n"; - + // 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); } ``` -## Receive Encrypted SAML Authentication Assertions +The following algorithms are used: -If Auth0 is the SAML **service provider**, it may need to receive encrypted assertions from an identity provider. To do this, you must provide Auth0's public key and certificate to the IdP. The IdP encrypts the SAML assertion using the public key and sends it to Auth0, which decrypts it using the private key. +* 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 -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. +## Working with certificates as strings -Navigate to the section titled **Encrypted Assertions** and download the certificate in the format requested by the IdP. +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/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md b/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md index 06ad26aa58..64d9449197 100644 --- a/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md +++ b/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md @@ -1,10 +1,17 @@ --- - description: Supported SAML bindings and options +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: +Auth0 supports the following SAML bindings: * HTTP Redirect * HTTP POST diff --git a/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md index 9f38616b8c..39fa5e5c5b 100644 --- a/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md +++ b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md @@ -1,11 +1,18 @@ --- 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: +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. @@ -24,7 +31,7 @@ In this case, the user successfully logs in with the idp, but a successful login * Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process. - * If you've enabled [multifactor authentication](/multifactor-authentication), disable it temporarily to make sure that it is not 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: @@ -68,7 +75,7 @@ In this case, the user successfully logs in with the idp, a successful login eve * 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](/har). To analyze the HTTP trace: +* 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/). @@ -78,7 +85,7 @@ In this case, the user successfully logs in with the idp, a successful login eve * 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 inforation. 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: + * 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. @@ -86,7 +93,7 @@ In this case, the user successfully logs in with the idp, a successful login eve 3. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/). - 4. Remve the SAML response at the beginning, as well as anything beginning with `&RelayState=` at the end. + 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: diff --git a/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md index 7d3792d62b..b80302d710 100644 --- a/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md +++ b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md @@ -1,14 +1,21 @@ --- 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: +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 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. @@ -30,11 +37,11 @@ Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). ![](/media/articles/protocols/saml/saml-configuration/check-connection-settings.png) -Check and confirm the following with the IdP adminstrator: +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 authention. +* 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. +* 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 @@ -45,7 +52,7 @@ If Auth0's logs don't show a successful login event, there is probably an issue ### Check the SAML Authentication Assertion -Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/har) and analyzing the HTTP trace. +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 @@ -64,7 +71,7 @@ You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyz After retrieving and decoding the SAML message, check the following fields: -Field | Description +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. (``). @@ -88,7 +95,7 @@ Check to see if the user's Auth0 profile populated correctly: ### 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. +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**. @@ -125,7 +132,7 @@ The two most common causes for this issue are: ### Check the SAML Assertion -Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/har) and analyzing the HTTP trace. +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 @@ -144,7 +151,7 @@ You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyz After retrieving and decoding the SAML message, check the following fields: -Field | Description +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. (``). @@ -156,7 +163,7 @@ Certificate | Compare the certificate sent to the one that you provided to the a ### Check the ID Token -If your authorization flow uses an OIDC-conformant protocol, you can [capture a HAR trace](/har) and view it using [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). +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: @@ -166,7 +173,7 @@ If your authorization flow uses an OIDC-conformant protocol, you can [capture a 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. +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 @@ -178,12 +185,28 @@ If you're using an IdP-initiated flow (for example, the user starts at the ident * 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 **Open ID Connect**); + * 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. + * 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 [multifactor authentication](/multifactor-authentication), disable it temporarily to make sure that it is not 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/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md b/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md index c3b72ead17..6f438059d8 100644 --- a/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md +++ b/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md @@ -1,10 +1,19 @@ --- 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. +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 @@ -22,7 +31,7 @@ This message indicates that the Application doesn't have an active Connection as 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#how-to-configure-an-application) before proceeding). +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 @@ -32,15 +41,26 @@ This message indicates that the Application doesn't have an active Connection as } ``` -This error appears if you haven't provided the necessary information to support IdP-initiated login flows. +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. +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. @@ -64,7 +84,7 @@ Make sure that the identity provider sends the correct `audience` value in the S ## 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. +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 @@ -72,3 +92,11 @@ One common error is specifying the incorrect response protocol on the IdP-Initia 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/articles/protocols/saml/saml-configuration/troubleshoot/index.md b/articles/protocols/saml/saml-configuration/troubleshoot/index.md index 851a6839d8..044c1a5c7c 100644 --- a/articles/protocols/saml/saml-configuration/troubleshoot/index.md +++ b/articles/protocols/saml/saml-configuration/troubleshoot/index.md @@ -1,15 +1,23 @@ --- -description: How to troubleshoot SAML-related configuration issues +description: Describes troubleshooting for SAML configuration issues. toc: true +topics: + - saml + - sso +contentType: + - index + - reference +useCase: + - add-idp --- -# Troubleshooting +# 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. +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 siutations that will be referred to later in this guide. +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?** @@ -28,7 +36,7 @@ When troubleshooting, it's important that all parties involved are using the sam 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 meaninful to outsourced SaaS applications. + * 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?** @@ -43,24 +51,23 @@ When troubleshooting, we recommend beginning by gathering information that helps 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 approaches -* [SAML Troubleshooting When Auth0 is the Service Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp) - -* [SAML Troubleshooting When Auth0 is the Identity Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp) +* [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 browswer has enabled JavaScript and cookies. +* 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 SSO URL (indicating a network connectivity issue). +* 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 assitance from Auth0 by opening up a ticket in the Support Center. Be sure to include the following information: +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 @@ -69,14 +76,13 @@ If the troubleshooting steps listed above don't solve the issue you're seeing, p 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?) +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](/har) +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 -::: next-steps * [Common SAML Errors](/protocols/saml/saml-configuration/troubleshoot/common-saml-errors) -::: + diff --git a/articles/protocols/saml/saml-idp-eloqua.md b/articles/protocols/saml/saml-idp-eloqua.md index dd8ffb3ac1..89817dd1d3 100644 --- a/articles/protocols/saml/saml-idp-eloqua.md +++ b/articles/protocols/saml/saml-idp-eloqua.md @@ -1,5 +1,13 @@ --- 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 @@ -83,17 +91,13 @@ Login to Eloqua with Auth0 should be enabled now. You can sign in to Eloqua with ### 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. +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 -**Beginning with auth0.js v9.3.4, you must [enable the impersonation flags](/user-profile/user-impersonation#enable-impersonation) to use IdP-initiated login.** - -<%= include('../../_includes/_deprecate-impersonation.md') %> - 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/articles/protocols/saml/saml-idp-generic.md b/articles/protocols/saml/saml-idp-generic.md index fb5b6617d4..5c5576a8e3 100644 --- a/articles/protocols/saml/saml-idp-generic.md +++ b/articles/protocols/saml/saml-idp-generic.md @@ -2,10 +2,16 @@ 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. +These instructions explain how to configure Auth0 to serve as an Identity Provider in a SAML federation. ## 1. Obtain Information from the Service Provider @@ -17,18 +23,18 @@ In this section you will configure Auth0 to serve as an Identity Provider. You w 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/application-settings). +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, scroll down to the **CERTIFICATES** section and click on the **DOWNLOAD CERTIFICATES** 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. +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. Scroll down further to the **ENDPOINTS** section and click on **SAML**. Copy the contents of the **SAML Protocol URL** field and save it as you will need to provide it to the Service Provider. +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. +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) @@ -67,7 +73,7 @@ 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 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. +- 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. diff --git a/articles/protocols/saml/saml-sp-generic.md b/articles/protocols/saml/saml-sp-generic.md index de0ce0850e..2a110ab059 100644 --- a/articles/protocols/saml/saml-sp-generic.md +++ b/articles/protocols/saml/saml-sp-generic.md @@ -1,11 +1,17 @@ --- 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. +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. @@ -19,7 +25,7 @@ There are **5 sections**, including a troubleshooting section at the end. 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 an SSO URL. +* **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. @@ -30,15 +36,14 @@ 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. -2. In the list of options below "Connections", click on **"Enterprise"** -3. In the middle of the screen, click on **"SAMLP Identity Provider"** -4. Click on the blue **"Create New Connection"** button +1. In the list of options below "Connections", click on **"Enterprise"**. +1. Click on the **"Create Connection"** button. -In the **"Create SAMLP Identity Provider"** connection window, enter the following information into the **Configuration** tab. +In the **"New SAML Connection"** window, enter the following information: - **Connection Name:** You can enter any name, such as `SAML-SP`. -- **Email Domains:** 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. If you leave this field blank, users with any email domain can use the IDP. +- **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. @@ -51,29 +56,25 @@ You can ignore the rest of the fields for now. Click on the blue **"SAVE"** button at the bottom. -Here is an example of what the filled-out screen would look like: (you should have filled out the Email domains field as well with your specific test user's email domain) - -![](/media/articles/saml/saml-sp-generic/saml-sp-generic1.png) - -After pressing the **"SAVE"** button, A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it) +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. +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 to which the Identity Provider will sent Authentication Assertions 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 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__. +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. +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 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 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 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`. @@ -92,9 +93,15 @@ If the Identity Provider does not support uploading a metadata file, you can con 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 +* 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 DOMAIN]/login/callback?connection=TestSP`. +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: @@ -118,11 +125,11 @@ In this section, you will test to make sure the SAML configuration between Auth0 * 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. +* 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 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. +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. @@ -130,7 +137,7 @@ This means the SAML connection from Auth0 Service Provider to Identity Provider 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. +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: @@ -141,9 +148,9 @@ Here is a sample of the **It Works** screen: 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. +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. +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. @@ -166,10 +173,8 @@ We currently support the following algorithms for processing XML Digital Signatu * 'http://www.w3.org/2000/09/xmldsig#rsa-sha1' * 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' - * 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha512' * Digest * 'http://www.w3.org/2000/09/xmldsig#sha1' * 'http://www.w3.org/2001/04/xmlenc#sha256' - * 'http://www.w3.org/2001/04/xmlenc#sha512' diff --git a/articles/protocols/saml/saml2webapp-tutorial.md b/articles/protocols/saml/saml2webapp-tutorial.md index 641e8940f7..26cc31a6f7 100644 --- a/articles/protocols/saml/saml2webapp-tutorial.md +++ b/articles/protocols/saml/saml2webapp-tutorial.md @@ -1,10 +1,17 @@ --- 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. +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 @@ -21,7 +28,7 @@ You can configure a SAML2 Web Application for use with an Auth0 Application via ![](/media/articles/protocols/saml/saml2-web-app/configure-addon.png) -5. To enable the Addon from the Auth0 side, you will need to provide you **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: +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 { @@ -69,3 +76,7 @@ Click **Save** when done. 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/articles/protocols/saml/samlp-providers.md b/articles/protocols/saml/samlp-providers.md index d4047124d8..b42a172665 100644 --- a/articles/protocols/saml/samlp-providers.md +++ b/articles/protocols/saml/samlp-providers.md @@ -1,9 +1,15 @@ --- 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. +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 diff --git a/articles/protocols/saml/samlp.md b/articles/protocols/saml/samlp.md index 46f7ffa405..3b32321d29 100644 --- a/articles/protocols/saml/samlp.md +++ b/articles/protocols/saml/samlp.md @@ -1,13 +1,20 @@ --- title: SAML description: SAML Identity Provider Configuration +topics: + - saml + - samlp +contentType: + - reference +useCase: + - add-idp --- # SAML Identity Provider Configuration -## Common settings: +## Common settings -These are the parameters used to configure a SAML Identity Provider: +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): @@ -26,7 +33,7 @@ These are the parameters used to configure a SAML Identity Provider: ``` ::: note -You need to replace the `ACCESS_TOKEN` header value, with a Management APIv2 Token. For information on how to do that refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens). +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`: @@ -44,13 +51,19 @@ If dynamically setting the value isn't possible, then set as either `HTTP-Redire * 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. -## Encrypted Assertions: +## Signed assertions -Optionally, assertions can be encrypted. Use this public key to configure the IdP: [CER](https://${account.namespace}/cer) | [PEM](https://${account.namespace}/pem) | [PKCS#7](https://${account.namespace}/pb7) +By default, SAML assertions for IdP connections are signed, which we recommend. You can use the following public keys to configure the IdP: -## IdP-Initiated SSO +* [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) -[Click here to learn more about IdP-Initiated SSO](/protocols/saml/idp-initiated-sso) +## IdP-initiated Single Sign-on + +[Click here to learn more about IdP-Initiated Single Sign-on (SSO)](/protocols/saml/idp-initiated-sso) ## Metadata diff --git a/articles/protocols/saml/samlsso-auth0-to-auth0.md b/articles/protocols/saml/samlsso-auth0-to-auth0.md index 1d6bf4404f..6440d44a11 100644 --- a/articles/protocols/saml/samlsso-auth0-to-auth0.md +++ b/articles/protocols/saml/samlsso-auth0-to-auth0.md @@ -1,11 +1,18 @@ --- -description: Learn how to use SAML 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. +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. +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. @@ -82,7 +89,7 @@ Next, create a user to use in testing the SAML SSO sequence. ## 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 single sign on via the SAML protocol. +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. @@ -102,7 +109,7 @@ In the **"Create SAMLP Identity Provider"** connection window, enter the followi **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. +**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**). @@ -118,33 +125,35 @@ You can ignore the rest of the fields for now. After pressing the **"SAVE"** button, A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it) -Click on the **"CONTINUE"** button. +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) is displayed. 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). +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. +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. +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 SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`. +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 for the Auth0 tenant 1 (service provider side of the federation. It will look something like the following with your tenant name in place of the 'xxxxx': +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. +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. +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**. @@ -167,9 +176,9 @@ In this section you will go back and add some information about the Service Prov 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. +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. The new line 2 should look something like: +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" @@ -183,7 +192,7 @@ 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 tenant 2. +Log in with the credentials for the user you created above. ![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-13.png) @@ -207,13 +216,17 @@ Make sure you are logged into the **Tenant 1 Auth0 dashboard**. * 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 returned at the end of the authentication sequence. +* 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. @@ -221,8 +234,6 @@ Make sure you are logged into the **Tenant 1 Auth0 dashboard**. * Scroll down to the section near the bottom where it says **"ENTERPRISE"**. -![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-17.png) - * 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 @@ -237,13 +248,11 @@ In this section, you will test to make sure the SAML configuration between Auth0 ![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-15.png) -* You will first see a Lock login widget appear that is triggered by the Service Provider. Enter the username of the test tenant you created earlier. - -You will then be redirected to the Lock login widget of the Identity Provider. Login with the credentials for the test user you created. +* 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. +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. @@ -285,9 +294,9 @@ Create an HTML page and insert the following HTML and javascript code: ``` -Make sure you replace **YOUR-APP-CLIENT-ID** with the actual value of the app you registered in step 7 above. You can also replace **audience** with the value appropriate for your Application -- however, for the purposes of this test, a placeholder will work. +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. -The client ID for your application 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"**. @@ -310,16 +319,12 @@ If you have other connections turned on for your application, your **Auth0 Lock 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. -* You will be redirected to the Identity Provider to log in. - -Note that whether you are prompted for credentials at this point depends on whether you still have an active session at the 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. -Upon successful authentication, you will be redirected to the callback URL specified in the HTML file (jwt.io). - ## 10. Troubleshooting This section has a few ideas for things to check if your sample doesn't work. diff --git a/articles/protocols/ws-fed/index.md b/articles/protocols/ws-fed/index.md index 0ec3e1d7d9..bff4091e38 100644 --- a/articles/protocols/ws-fed/index.md +++ b/articles/protocols/ws-fed/index.md @@ -1,5 +1,12 @@ --- description: The WS-Federation protocol and how it is used in Auth0. +topics: + - saml + - ws-federation +contentType: + - how-to +useCase: + - add-idp --- # WS-Federation @@ -20,16 +27,19 @@ You can find all available options for configuring WS-Federation under the [adva You will need to configure the **Relying Party**, which can be done using the following metadata endpoint: ```text -https://${account.namespace}/wsfed/${account.clientId}/FederationMetadata/2007-06/FederationMetadata.xml +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 SAML token, as well as other lower-level WS-Fed and SAML-P settings. +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 enpoint, you can use the following (optional) parameters: +When redirecting your users to your WS-Fed endpoint, you can use the following (optional) parameters: -* **wreply**: Callback URL -* **wctx**: Your application's state -* **whr**: The name of the connection (to skip the login page) +* `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: @@ -39,16 +49,28 @@ https://${account.namespace}/wsfed/${account.clientId}?whr=google-oauth2 ## Identity Providers -If you're using using Auth0 with an identity provider that utilizes the WD-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. +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 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. +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/articles/quickstart/_includes/_auth0-angular-install.md b/articles/quickstart/_includes/_auth0-angular-install.md new file mode 100644 index 0000000000..4dd7e6ae4a --- /dev/null +++ b/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/articles/quickstart/_includes/_auth0-react-classes-info.md b/articles/quickstart/_includes/_auth0-react-classes-info.md new file mode 100644 index 0000000000..babc55253a --- /dev/null +++ b/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. +::: \ No newline at end of file diff --git a/articles/quickstart/_includes/_auth0-react-install.md b/articles/quickstart/_includes/_auth0-react-install.md new file mode 100644 index 0000000000..3a0ce623ed --- /dev/null +++ b/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 or Higher-Order Components. \ No newline at end of file diff --git a/articles/quickstart/_includes/_auth0-vue-install.md b/articles/quickstart/_includes/_auth0-vue-install.md new file mode 100644 index 0000000000..c2cc9be635 --- /dev/null +++ b/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/articles/quickstart/_includes/_configure_auth0_interactive.md b/articles/quickstart/_includes/_configure_auth0_interactive.md new file mode 100644 index 0000000000..1fd292508a --- /dev/null +++ b/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/articles/quickstart/backend/_includes/_api_auth_preamble.md b/articles/quickstart/backend/_includes/_api_auth_preamble.md index b046b18eaf..b599c18174 100644 --- a/articles/quickstart/backend/_includes/_api_auth_preamble.md +++ b/articles/quickstart/backend/_includes/_api_auth_preamble.md @@ -1,4 +1,6 @@ -## Add API Authorization -To restrict access to the resources served by your API, check the incoming requests for valid authorization information. -The authorization information is stored in the Access Token created for the user and needs to be sent in the `Authorization` header. To see if the token is valid, check it against the [JSON Web Key Set (JWKS)](/jwks) for your Auth0 account. To learn more about validating Access Tokens, read the [Verify Access Tokens tutorial](/api-auth/tutorials/verify-access-token). \ No newline at end of file +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) for your Auth0 account. To learn more about validating Access Tokens, see Validate Access Tokens. diff --git a/articles/quickstart/backend/_includes/_api_create.html b/articles/quickstart/backend/_includes/_api_create.html index 3d99f1e125..32e85b9c9d 100644 --- a/articles/quickstart/backend/_includes/_api_create.html +++ b/articles/quickstart/backend/_includes/_api_create.html @@ -1,7 +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.

        +

        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.

        +

        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/articles/quickstart/backend/_includes/_api_create_new.md b/articles/quickstart/backend/_includes/_api_create_new.md index 6a57ef8b24..5e1ef09c11 100644 --- a/articles/quickstart/backend/_includes/_api_create_new.md +++ b/articles/quickstart/backend/_includes/_api_create_new.md @@ -1,5 +1,16 @@ -## Create a Resource Server (API) +## Configure Auth0 APIs -In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. For **Signing Algorithm**, select **RS256**. +### Create an API -![Create API](/media/articles/api-auth/create-api.png) \ No newline at end of file +In the 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/articles/quickstart/backend/_includes/_api_create_new_2.md b/articles/quickstart/backend/_includes/_api_create_new_2.md index 244b2485a1..ea482527b1 100644 --- a/articles/quickstart/backend/_includes/_api_create_new_2.md +++ b/articles/quickstart/backend/_includes/_api_create_new_2.md @@ -1,5 +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**. +In the 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/articles/quickstart/backend/_includes/_api_jwks_description.md b/articles/quickstart/backend/_includes/_api_jwks_description.md index 25049661b9..21e2fd0987 100644 --- a/articles/quickstart/backend/_includes/_api_jwks_description.md +++ b/articles/quickstart/backend/_includes/_api_jwks_description.md @@ -1,5 +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. You can access this public key [here](https://${account.namespace}/.well-known/jwks.json). +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) format, and can be accessed here. +<% if (typeof sampleLink == 'string') { %> ::: note -We recommend using the default RS256 signing algorithm for your API. If you need to use the HS256 algorithm, see the [HS256 integration sample](${sampleLink}). +We recommend using the default RS256 signing algorithm for your API. If you need to use the HS256 algorithm, see the HS256 integration sample. ::: +<% } %> diff --git a/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md b/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md index a27211ec1f..f5a8fb5a20 100644 --- a/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md +++ b/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md @@ -1 +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 +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. \ No newline at end of file diff --git a/articles/quickstart/backend/_includes/_api_scope_description.md b/articles/quickstart/backend/_includes/_api_scope_description.md index 4b416a19e3..c96d202f18 100644 --- a/articles/quickstart/backend/_includes/_api_scope_description.md +++ b/articles/quickstart/backend/_includes/_api_scope_description.md @@ -1,3 +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 authenitcation 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). \ No newline at end of file +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. diff --git a/articles/quickstart/backend/_includes/_api_scopes_access_resources.md b/articles/quickstart/backend/_includes/_api_scopes_access_resources.md index aa2d96b7b2..83005290e6 100644 --- a/articles/quickstart/backend/_includes/_api_scopes_access_resources.md +++ b/articles/quickstart/backend/_includes/_api_scopes_access_resources.md @@ -1,8 +1,8 @@ -Scopes let you define which resources can be accessed by the user with a given Access Token. For example, you might choose to give the read access to the `messages` resource if a user has the manager access level, and a write access to that resource if they have the administrator access level. +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. -To configure scopes, in your Auth0 dashboard, in the [APIs](${manage_url}/#/apis) section, click the **Scopes** tab. Configure the scopes you need. +You can define allowed permissions in the **Permissions** view of the Auth0 Dashboard's APIs section. -![Configure Scopes](/media/articles/server-apis/configure-scopes.png) +![Configure Permissions](/media/articles/server-apis/configure-permissions.png) ::: note This example uses the `read:messages` scope. diff --git a/articles/quickstart/backend/_includes/_api_troubleshooting.md b/articles/quickstart/backend/_includes/_api_troubleshooting.md new file mode 100644 index 0000000000..0d74782006 --- /dev/null +++ b/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 + +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 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/articles/quickstart/backend/_includes/_api_using.md b/articles/quickstart/backend/_includes/_api_using.md index e23c24ed79..e8ef53ce4f 100644 --- a/articles/quickstart/backend/_includes/_api_using.md +++ b/articles/quickstart/backend/_includes/_api_using.md @@ -1,4 +1,6 @@ -## Calling the API from your application + + +## 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. @@ -12,55 +14,55 @@ You can call the API from your application by passing an Access Token in the `Au } ``` -The exact implementation 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) - -## Obtaining an Access Token for testing +## Obtaining an Access Token -If you want to test your API outside your application, for example from the command line or a tool like Postman, you can obtain an Access Token using the [Authentication API Debugger Extension](/extensions/authentication-api-debugger) or from the **Test** tab in your [API settings](${manage_url}/#/apis). +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: -You can also obtain an Access Token using [cUrl](https://curl.haxx.se/) by using the [Client Credentials](/api/authentication#client-credentials) or [Resource Owner Password](api/authentication#resource-owner-password) authorization flows. +* Single-Page Applications +* Mobile / Native Application -**1. Using Client Credentials** +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. To do that, register a Machine to Machine Application, 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 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/json" } + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } ], "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"audience\": \"YOUR_API_IDENTIFIER\"}" + "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" + } + ] } } ``` -When using the Client Credentials flow, you will need to register a [Machine to Machine Application](/applications). You should then subsequently use the **Client ID** and **Client Secret** of this Machine to Machine Application when making the request shown above and pass those along in the `client_id` and `client_secret` parameters respectively. - :::note -Auth0 customers are billed based on the number of Client Credential 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. +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. ::: -**2. Using Resource Owner Password** - -```har -{ - "method": "POST", - "url": "https://${account.namespace}/oauth/token", - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"password\",\"username\": \"user@example.com\",\"password\": \"pwd\",\"audience\": \"YOUR_API_IDENTIFIER\", \"scope\": \"read:messages\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\"}" - } -} -``` +For testing purposes, you can also get an Access Token from the **Test** tab in your API settings. ## Test Your API @@ -97,7 +99,7 @@ This time the API will return a successful response: **2. Testing the scoped endpoint** -To test the endpoint that require a scope, pass the Access Token containing the correct scope as a Bearer token in the Authorization header: +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 { @@ -115,4 +117,4 @@ If the required scope is present, the API call is successful: 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) +![Response for forbidden scoped API request](/media/articles/server-apis/using/private-scoped-forbidden.png) \ No newline at end of file diff --git a/articles/quickstart/backend/_includes/_call_api.md b/articles/quickstart/backend/_includes/_call_api.md index db8a5936ad..93bea21fc7 100644 --- a/articles/quickstart/backend/_includes/_call_api.md +++ b/articles/quickstart/backend/_includes/_call_api.md @@ -1,6 +1,8 @@ -## 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 lab in your [API settings](${manage_url}/#/apis). +### 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. ![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png) diff --git a/articles/quickstart/backend/_thirdPartyApi.md b/articles/quickstart/backend/_thirdPartyApi.md index f8a12791b9..7601de9aa1 100644 --- a/articles/quickstart/backend/_thirdPartyApi.md +++ b/articles/quickstart/backend/_thirdPartyApi.md @@ -17,7 +17,7 @@ Each integration is different and requires different parameters and configuratio ## 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](/). +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. You can download your favorite library from any of the Quickstarts. ## 3. You are done! diff --git a/articles/quickstart/backend/aspnet-core-webapi-v1_1/01-authorization.md b/articles/quickstart/backend/aspnet-core-webapi-v1_1/01-authorization.md deleted file mode 100644 index ea712f830b..0000000000 --- a/articles/quickstart/backend/aspnet-core-webapi-v1_1/01-authorization.md +++ /dev/null @@ -1,193 +0,0 @@ ---- -title: Authorization -name: Shows how to secure your API using the standard JWT middeware -description: Shows how to secure your API using the standard JWT middeware. -budicon: 500 ---- - -<%= include('../../../_includes/_package', { - org: 'auth0-samples', - branch: 'v1', - repo: 'auth0-aspnetcore-webapi-samples', - path: 'Quickstart/01-Authorization', - requirements: [ - '.NET Core 1.1', - 'ASP.NET Core 1.1', - 'Microsoft.AspNetCore.Authentication.JwtBearer 1.1.1', - 'Visual Studio 2017 (Optional)', - 'Visual Studio Code (Optional)' - ] -}) %> - -<%= include('../../../_includes/_api_auth_intro') %> - -This Quickstart will guide you through the various tasks related to using Auth0-issued Access Tokens to secure your ASP.NET Core Web API. - -## Seed and Samples - -If you would like to follow along with this Quickstart you can download the [seed project](https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/v1/Quickstart/00-Starter-Seed). The seed project is just a basic ASP.NET Web API with a simple controller and some of the NuGet packages which will be needed included. It also contains an `appSettings.json` file where you can configure the various Auth0-related settings for your application. - -The final project after each of the steps is also available in the [Quickstart folder of the Samples repository](https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/v1/Quickstart). You can find the final result for each step in the relevant folder inside the repository. - -<%= include('../_includes/_api_create_new_2') %> - -Also, update the `appsettings.json` file in your project with the correct **Domain** and **API Identifier** for your API, such as - -```json -{ - "Auth0": { - "Domain": "${account.namespace}", - "ApiIdentifier": "${apiIdentifier}" - } -} -``` - -<%= include('../_includes/_api_auth_preamble') %> - -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 with the standard ASP.NET Core JWT middleware - -## Install Dependencies - -To use Auth0 Access Tokens with ASP.NET Core you will use the JWT Middleware. Add the `Microsoft.AspNetCore.Authentication.JwtBearer` package to your application. - -```text -Install-Package Microsoft.AspNetCore.Authentication.JwtBearer -``` - -## Configuration - -<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/v1/Samples/hs256' }) %> - -The ASP.NET Core JWT middleware will handle downloading the JSON Web Key Set (JWKS) file containing the public key for you, and will use that to verify the `access_token` signature. - -To add the JWT middleware to your application's middleware pipeline, go to the `Configure` method of your `Startup` class and add a call to `UseJwtBearerAuthentication` passing in the configured `JwtBearerOptions`. The `JwtBearerOptions` needs to specify your Auth0 API Identifier as the `Audience`, and the full path to your Auth0 domain as the `Authority`: - -```csharp -// Startup.cs - -public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) -{ - loggerFactory.AddConsole(Configuration.GetSection("Logging")); - loggerFactory.AddDebug(); - - var options = new JwtBearerOptions - { - Audience = Configuration["Auth0:ApiIdentifier"], - Authority = $"https://{Configuration["Auth0:Domain"]}/" - }; - app.UseJwtBearerAuthentication(options); - - app.UseMvc(); -} -``` - -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 only need to decorate your controller action with the `[Authorize]` attribute: - -```csharp -// Controllers/ApiController.cs - -[Route("api")] -public class ApiController : Controller -{ - [HttpGet] - [Route("private")] - [Authorize] - public IActionResult Private() - { - return Json(new - { - Message = "Hello from a private endpoint! You need to be authenticated to see this." - }); - } -} -``` - -## Configuring 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. - -<%= include('../_includes/_api_scopes_access_resources') %> - -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 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. If it does then the Authorization Requirement is met. - -```csharp -// HasScopeRequirement.cs - -public class HasScopeRequirement : AuthorizationHandler, IAuthorizationRequirement -{ - private readonly string issuer; - private readonly string scope; - - public HasScopeRequirement(string scope, string issuer) - { - this.scope = scope; - this.issuer = issuer; - } - - 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 == issuer)) - return Task.CompletedTask; - - // Split the scopes string into an array - var scopes = context.User.FindFirst(c => c.Type == "scope" && c.Issuer == issuer).Value.Split(' '); - - // Succeed if the scope array contains the required scope - if (scopes.Any(s => s == scope)) - context.Succeed(requirement); - - return Task.CompletedTask; - } -} -``` - -Next, you can define a policy for each of the scopes in your application in the `ConfigureServices` method of your `Startup` class: - -```csharp -// Startup.cs - -public void ConfigureServices(IServiceCollection services) -{ - // Add framework services. - services.AddMvc(); - - string domain = $"https://{Configuration["Auth0:Domain"]}/"; - services.AddAuthorization(options => - { - options.AddPolicy("read:messages", - policy => policy.Requirements.Add(new HasScopeRequirement("read:messages", domain))); - }); -} -``` - -To secure the API endpoint, 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, passing `read:messages` as the `policy` parameter. - -```csharp -// Controllers/ApiController.cs - -[Route("api")] -public class ApiController : Controller -{ - [HttpGet] - [Route("private-scoped")] - [Authorize("read:messages")] - public IActionResult 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." - }); - } -} -``` - -## Further Reading - -* To learn how you can call your API from applications, please refer to the [Using your API section](/quickstart/backend/aspnet-core-webapi/v1/02-using). - -* If your experience problems with your API, please refer to the [Troubleshooting section](/quickstart/backend/aspnet-core-webapi/v1/03-troubleshooting). diff --git a/articles/quickstart/backend/aspnet-core-webapi-v1_1/02-using.md b/articles/quickstart/backend/aspnet-core-webapi-v1_1/02-using.md deleted file mode 100644 index ca1c2ad208..0000000000 --- a/articles/quickstart/backend/aspnet-core-webapi-v1_1/02-using.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Using your API -description: This tutorial will show you how to use your API -budicon: 500 ---- - -<%= include('../_includes/_api_using') %> \ No newline at end of file diff --git a/articles/quickstart/backend/aspnet-core-webapi-v1_1/03-troubleshooting.md b/articles/quickstart/backend/aspnet-core-webapi-v1_1/03-troubleshooting.md deleted file mode 100644 index 826c862e8e..0000000000 --- a/articles/quickstart/backend/aspnet-core-webapi-v1_1/03-troubleshooting.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -title: Troubleshooting -name: Shows how to troubleshoot the JWT middeware configuration -description: This document will help you troubleshoot your configuration if you get 401 (Unauthorized) response from your API. -budicon: 500 ---- - -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://rs256.test.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 options = new JwtBearerOptions -{ - Audience = "https://rs256.test.api", - Authority = "https://jerrie.auth0.com/" -}; -app.UseJwtBearerAuthentication(options); -``` - -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**. - -In this case the middleware needs to be configured as follows: - -```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); -``` - -## Using the log files to debug configuration issues - -The easiest way to debug potential configuration issuer is by inspecing the log files for your application. For more information please refer to the [Logging in ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging) document. - -For this document we will run the application from the command line, and inspect the console log output. - -### 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 do not, you will see the following warning: - -![Not specifying an Authorization Header](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png) - -The relevant warning message to look for is the following: - -```text -Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter' -``` - -To resolve this issue, ensure that your 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, but your middleware is configured for RS256 - or vice versa. - -In the following screenshot you can see that I still get the "Authorization failed..." warning message, but you will also notice that there is an informational message above that with more information: - -![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png) - -The relevant error message to look for is the following: - -```text -System.ArgumentException: IDX10634: Unable to create the SignatureProvider. - -SignatureAlgorithm: 'HS256', SecurityKey: 'Microsoft.IdentityModel.Tokens.RsaSecurityKey' is not supported. -``` - -So the error tells me that the JWT is signed using HS256, but this algorithm is not configured, because my middleware was configured to expect RS256 tokens. - -In the case where you configured you middleware for HS256, but you are sending an RS256 signed token the error message will be different: - -![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png) - -In this case the relevant error message to look for is the following: - -```text -Bearer was not authenticated. Failure message: IDX10501: Signature validation failed. Unable to match 'kid': 'NTF...' -``` - -To resolve this issue, be sure to that the signature algorithm with which the JWT was signed matches with 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/aspnet-core-webapi/troubleshoot-token-expired.png) - -The error message to look for is the following: - -```text -IDX10223: Lifetime validation failed. The token is expired -``` - -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/aspnet-core-webapi/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 middeware. For HS256 signed tokens, be sure to specify the correct value for the `ValidIssuer` property of the `TokenValidationParameters`. - -::: panel Using RS256 -For RS256 tokens the JWT middleware will download the OIDC discovery document from the `Authority` and configure the Issuer based on the `issuer` attribute specified in that document. You will therefore not get this error when using RS256 since because if your specified the wrong `Authority` then the signature validation would have failed first. -::: - -## 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/aspnet-core-webapi/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 middeware. Depending on how your JWT middleware was configured this means that you need to set the correct `Audience` property of the `JwtBearerOptions`, or the `ValidAudience` property of the `TokenValidationParameters`. diff --git a/articles/quickstart/backend/aspnet-core-webapi-v1_1/index.yml b/articles/quickstart/backend/aspnet-core-webapi-v1_1/index.yml deleted file mode 100644 index 4ccd87dfb9..0000000000 --- a/articles/quickstart/backend/aspnet-core-webapi-v1_1/index.yml +++ /dev/null @@ -1,19 +0,0 @@ -title: ASP.NET Core Web API v1.1 -alias: - - asp.net core webapi - - aspnet core webapi - - asp.net core webapi 1.1 -language: - - C# -framework: - - ASP.NET Core -thirdParty: false -image: /media/platforms/asp.png -tags: - - quickstart -snippets: - dependencies: server-apis/aspnet-core-webapi/dependencies -articles: - - 01-authorization - - 02-using - - 03-troubleshooting \ No newline at end of file diff --git a/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md b/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md index 08b17b552c..69a8279666 100644 --- a/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md +++ b/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md @@ -1,144 +1,91 @@ --- title: Authorization -name: Shows how to secure your API using the standard JWT middeware -description: Shows how to secure your API using the standard JWT middeware. +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/_package', { - org: 'auth0-samples', - branch: 'master', - repo: 'auth0-aspnetcore-webapi-samples', - path: 'Quickstart/01-Authorization', - requirements: [ - '.NET Core 2.0', - 'ASP.NET Core 2.0', - 'Visual Studio 2017 (Optional)', - 'Visual Studio Code (Optional)' - ] -}) %> + <%= include('../../../_includes/_api_auth_intro') %> -This tutorial shows you how to use Access Tokens from Auth0 to secure your ASP.NET Core Web API. - -## Before You Start +<%= include('../_includes/_api_create_new') %> -If you want to follow along with this tutorial, you can download the [seed project](https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/master/Quickstart/00-Starter-Seed). The seed project is a basic ASP.NET Web API with a simple controller and some NuGet packages. It also contains an `appSettings.json` file where you can configure the Auth0-related settings for your application. - -To see what the project looks like after each of the steps, check the [Quickstart folder of the Samples repository](https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/master/Quickstart). +<%= include('../_includes/_api_auth_preamble') %> -<%= include('../_includes/_api_create_new_2') %> +## Configure the Sample Project -Update the `appsettings.json` file in your project with the correct domain and API identifier for your API. See the example below: +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}", - "ApiIdentifier": "${apiIdentifier}" + "Audience": "${apiIdentifier}" } } ``` -<%= include('../_includes/_api_auth_preamble') %> - -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 with the standard ASP.NET Core JWT middleware +## Validate Access Tokens -## Install Dependencies +### Install dependencies -The seed project references the new ASP.NET Core metapackage (`Microsoft.AspNetCore.All`), which includes all the NuGet packages that are a part of the ASP.NET Core 2.0 framework. - -If you are not using the `Microsoft.AspNetCore.All` metapackage, add the `Microsoft.AspNetCore.Authentication.JwtBearer` package to your application. +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 - -<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/master/Samples/hs256' }) %> +### 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 the JWT Bearer tokens as the default authentication and challenge 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. +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 -// Startup.cs - -public void ConfigureServices(IServiceCollection services) +// Program.cs +var builder = WebApplication.CreateBuilder(args); +var domain = $"https://{builder.Configuration["Auth0:Domain"]}/"; +builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) +.AddJwtBearer(options => { - // Some code omitted for brevity... - - string domain = $"https://{Configuration["Auth0:Domain"]}/"; - services.AddAuthentication(options => - { - options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; - options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; - - }).AddJwtBearer(options => + options.Authority = domain; + options.Audience = builder.Configuration["Auth0:Audience"]; + options.TokenValidationParameters = new TokenValidationParameters { - options.Authority = domain; - options.Audience = Configuration["Auth0:ApiIdentifier"]; - }); -} + NameClaimType = ClaimTypes.NameIdentifier + }; +}); ``` -To add the authentication middleware to the middleware pipeline, add a call to the `UseAuthentication` method: +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 -// Startup.cs +// Program.cs +var app = builder.Build(); -public void Configure(IApplicationBuilder app, IHostingEnvironment env) +app.UseAuthentication(); +app.UseAuthorization(); +app.UseEndpoints(endpoints => { - // Some code omitted for brevity... - - app.UseAuthentication(); - - app.UseMvc(routes => - { - routes.MapRoute( - name: "default", - template: "{controller=Home}/{action=Index}/{id?}"); - }); -} + endpoints.MapControllers(); +}); ``` -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. +### Validate scopes -To secure an endpoint, you need to add the `[Authorize]` attribute to your controller action: - -```csharp -// Controllers/ApiController.cs - -[Route("api")] -public class ApiController : Controller -{ - [HttpGet] - [Route("private")] - [Authorize] - public IActionResult Private() - { - return Json(new - { - Message = "Hello from a private endpoint! You need to be authenticated to see this." - }); - } -} -``` - -## Configure the Scopes - -The JWT middleware shown above verifies if the user's Access Token included in the request is valid. The middleware doesn't check if the token has the sufficient scope to access the requested resources. - -<%= include('../_includes/_api_scopes_access_resources') %> - -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. +To make sure that an Access Token contains the correct scope, use the Policy-Based Authorization 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. @@ -181,39 +128,46 @@ public class HasScopeHandler : AuthorizationHandler } ``` -In your `ConfigureServices` method, 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: +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 -// Startup.cs +// Program.cs -public void ConfigureServices(IServiceCollection services) +builder.Services.AddAuthorization(options => { - // Add framework services. - services.AddMvc(); + options.AddPolicy("read:messages", policy => policy.Requirements.Add(new + HasScopeRequirement("read:messages", domain))); +}); - string domain = $"https://{Configuration["Auth0:Domain"]}/"; - services.AddAuthentication(options => - { - options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; - options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; +builder.Services.AddSingleton(); +``` - }).AddJwtBearer(options => - { - options.Authority = domain; - options.Audience = Configuration["Auth0:ApiIdentifier"]; - }); - - services.AddAuthorization(options => - { - options.AddPolicy("read:messages", policy => policy.Requirements.Add(new HasScopeRequirement("read:messages", domain))); - }); +## Protect API Endpoints + +The JWT middleware integrates with the standard ASP.NET Core Authentication and Authorization mechanisms. - // register the scope authorization handler - services.AddSingleton(); +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 the API endpoint, 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, passing `read:messages` as the `policy` parameter. +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 @@ -221,12 +175,11 @@ To secure the API endpoint, we need to make sure that the correct scope is prese [Route("api")] public class ApiController : Controller { - [HttpGet] - [Route("private-scoped")] + [HttpGet("private-scoped")] [Authorize("read:messages")] public IActionResult Scoped() { - return Json(new + 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/articles/quickstart/backend/aspnet-core-webapi/02-using.md b/articles/quickstart/backend/aspnet-core-webapi/02-using.md index ca1c2ad208..143001841d 100644 --- a/articles/quickstart/backend/aspnet-core-webapi/02-using.md +++ b/articles/quickstart/backend/aspnet-core-webapi/02-using.md @@ -1,7 +1,14 @@ --- title: Using your API -description: This tutorial will show you how to use 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/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md b/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md index a73a80e75e..003e467ef8 100644 --- a/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md +++ b/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md @@ -1,10 +1,18 @@ --- title: Troubleshooting -name: Shows how to troubleshoot the JWT middeware configuration 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. @@ -14,7 +22,7 @@ This document will help you troubleshoot your JWT middleware configuration. 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-). +Check if the structure of the token matches the structure of a JSON Web Token. Read more about 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. @@ -34,12 +42,12 @@ 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. +You can inspect a JWT with the 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 +* 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) @@ -58,12 +66,12 @@ 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 +* 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 alrgorithm, the middleware needs to be configured in the following way: +If your token is signed with the HS256 algorithm, the middleware needs to be configured in the following way: ```csharp var options = new JwtBearerOptions @@ -80,7 +88,7 @@ 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. +To debug potential configuration issues, inspect the log files for your application. For more information, refer to the Logging in ASP.NET Core document. In this example, we run the application from the command line and inspect the console log output. @@ -100,9 +108,9 @@ Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authori 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? +### 2. Did you configure the JWT middleware for the correct signing algorithm? -Make sure that the signing algorithm you used to sign your token matches the signing algorithm configured in your middleware. +Make sure that the signing algorithm 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..." @@ -132,7 +140,7 @@ Bearer was not authenticated. Failure message: IDX10501: Signature validation fa To resolve this issue, make sure that the algorithm for the JWT matches with the configuration of your middleware. -## 3. Has your token expired? +### 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: @@ -147,10 +155,10 @@ 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/). +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. ::: -## 4. Did you configure the correct Issuer? +### 4. Did you configure the correct issuer? The Issuer specified in your token must match exactly with your JWT middleware configuration. @@ -176,7 +184,7 @@ For RS256 tokens, the JWT middleware downloads the OIDC discovery document from 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? +### 5. Does the audience match your JWT middleware configuration? Check if the audience specified in your token matches your JWT middleware configuration. diff --git a/articles/quickstart/backend/aspnet-core-webapi/download.md b/articles/quickstart/backend/aspnet-core-webapi/download.md new file mode 100644 index 0000000000..57c9444623 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/download.md @@ -0,0 +1,15 @@ +To run the sample you need .NET Core installed, and run the following commands: + +```bash +dotnet restore +dotnet run +``` + +The sample includes a Docker 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/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.md b/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.md new file mode 100644 index 0000000000..9f8b83b336 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.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/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.md b/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.md new file mode 100644 index 0000000000..f67f1b2cd1 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.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/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.md b/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.md new file mode 100644 index 0000000000..fe73104225 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.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/articles/quickstart/backend/aspnet-core-webapi/files/Program.md b/articles/quickstart/backend/aspnet-core-webapi/files/Program.md new file mode 100644 index 0000000000..7b30acec02 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/files/Program.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/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md b/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md new file mode 100644 index 0000000000..2f9657aef0 --- /dev/null +++ b/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/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md b/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md new file mode 100644 index 0000000000..d9419a5dd9 --- /dev/null +++ b/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/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md b/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md new file mode 100644 index 0000000000..e2eea05829 --- /dev/null +++ b/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/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md b/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md new file mode 100644 index 0000000000..71b02ea80f --- /dev/null +++ b/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/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md b/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md new file mode 100644 index 0000000000..f3481fc996 --- /dev/null +++ b/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/articles/quickstart/backend/aspnet-core-webapi/index.yml b/articles/quickstart/backend/aspnet-core-webapi/index.yml index 2892ed17f9..47a5ed7ab9 100644 --- a/articles/quickstart/backend/aspnet-core-webapi/index.yml +++ b/articles/quickstart/backend/aspnet-core-webapi/index.yml @@ -1,19 +1,55 @@ -title: ASP.NET Core Web API v2.0 +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 2.0 + - 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 -image: /media/platforms/asp.png -tags: +topics: - quickstart +contentType: tutorial +useCase: quickstart snippets: dependencies: server-apis/aspnet-core-webapi/dependencies articles: - 01-authorization - 02-using - - 03-troubleshooting \ No newline at end of file + - 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/articles/quickstart/backend/aspnet-core-webapi/interactive.md b/articles/quickstart/backend/aspnet-core-webapi/interactive.md new file mode 100644 index 0000000000..8accefa5b5 --- /dev/null +++ b/articles/quickstart/backend/aspnet-core-webapi/interactive.md @@ -0,0 +1,613 @@ +--- +title: Add Authorization to Your 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. +interactive: true +files: + - files/appsettings + - files/Program + - files/HasScopeHandler + - files/HasScopeRequirement + - files/ApiController +github: + path: Quickstart/01-Authorization +locale: en-US +--- + +# 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, 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.

        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.

        + +## Define permissions + + +

        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 grant 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 section. The following example uses the read:messages scope.

        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab

        + +## Install dependencies + + +

        To allow your application to validate access tokens, add a reference to the Microsoft.AspNetCore.Authentication.JwtBearer NuGet package:

        Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
+
+
        + +

        + +## Configure the middleware {{{ data-action="code" data-code="Program.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. + +

          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 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 and 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:

        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 call your API from a Single-Page Application (SPA) or Native application, you will receive an access token after the authorization flow completes.

        If you call the API from a command-line tool or other service where a user entering credentials does not exist, use the OAuth Client Credentials Flow. To do so, register a Machine-to-Machine Application and pass the following values in your request:

        • Client ID as the client_id parameter.

        • Client Secret as the client_secret parameter.

        • API Identifier (the same value used to configure the middleware earlier in this quickstart) as the audience parameter.

        To learn more about getting the Client ID and Client Secret for your machine-to-machine application, read Application Settings.

        Example request

        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/token");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/token"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/token")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/token',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/token"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/token",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/token", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/token")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/token")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        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:
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http://localhost:3010/api/private \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN'
        var client = new RestClient("http://localhost:3010/api/private");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http://localhost:3010/api/private"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http://localhost:3010/api/private")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http://localhost:3010/api/private',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://localhost:3010/api/private"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_PORT => "3010",
+
+  CURLOPT_URL => "http://localhost:3010/api/private",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("localhost:3010")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN" }
+
+
+
+conn.request("get", "/api/private", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http://localhost:3010/api/private")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http://localhost:3010/api/private")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        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.
        ASP.NET API Quickstart - Step 6 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 to verify)
        Still having issues? To get more help, check out our documentation or visit our community page.
        
+
+  
        
diff --git a/articles/quickstart/backend/config.yml b/articles/quickstart/backend/config.yml
index 5fccfb523e..4f677dfe66 100644
--- a/articles/quickstart/backend/config.yml
+++ b/articles/quickstart/backend/config.yml
@@ -1,12 +1,2 @@
-next_steps:
-  - path: 01-authorization
-    list:
-    - text: Learn about custom APIs
-      icon: 345
-      href: "/api"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-    - text: Introduction to API Authorization
-      icon: 345
-      href: "/api-auth"
\ No newline at end of file
+sample_download_required_data:
+  - api
diff --git a/articles/quickstart/backend/django/01-authorization.md b/articles/quickstart/backend/django/01-authorization.md
index 7fd390cd9d..90fafab4a2 100644
--- a/articles/quickstart/backend/django/01-authorization.md
+++ b/articles/quickstart/backend/django/01-authorization.md
@@ -1,71 +1,94 @@
 ---
 title: Authorization
-description: This tutorial demonstrates how to use Auth0 to add authorization to your Django REST Framework API.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-django-api',
-  path: '01-Authorization',
-  requirements: [
-    'python 2.7, 3.3 and up',
-    'django 1.8 and up',
-    'djangorestframework 3.0 and up',
-    'djangorestframework-jwt 1.11.0',
-    'python-jose 1.3.2',
-    'cryptography 2.0.3'
-  ]
-}) %>
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
-This guide demonstrates how to add authorization to your Python API using [Django REST Framework](http://www.django-rest-framework.org/).
-
 <%= include('../_includes/_api_create_new') %>
 
 <%= include('../_includes/_api_auth_preamble') %>
 
-## Install the Dependencies
+## Setup the Django Application
+
+### Install dependencies
 
  Add the following dependencies to your `requirements.txt` and run `pip install -r requirements.txt`.
 
 ```python
-django
-djangorestframework
-djangorestframework-jwt
-cryptography
-pyjwt
-python-dotenv
+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
+### 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/1.11/intro/tutorial01/).
+This guide assumes you already have a Django application set up. If that is not the case, follow the steps in the Django Tutorial.
 
 The sample project was created with the following commands:
 
 ```bash
-$ django-admin startproject apiexample
-$ cd apiexample
-$ python manage.py startapp auth0authorization
+django-admin startproject apiexample
+cd apiexample
+python manage.py startapp auth0authorization
 ```
 
-## Django Settings
+### Add a Django remote user
 
-The `settings.py` file contains the configuration of the Django project.
+You need to define a way to map the username from the Access Token payload to the Django authentication system user.
 
-Add the following imports in `settings.py` file.
+Add `RemoteUserMiddleware` middleware component after `AuthenticationMiddleware` to middleware list.
 
 ```python
 # apiexample/settings.py
 
-import json
-from six.moves.urllib import request
+MIDDLEWARE = [
+    # ...
+    'django.contrib.auth.middleware.AuthenticationMiddleware',
+    'django.contrib.auth.middleware.RemoteUserMiddleware',
+]
+```
+
+Add `ModelBackend` and `RemoteUserBackend` to the Authentication Backends.
 
-from cryptography.x509 import load_pem_x509_certificate
-from cryptography.hazmat.backends import default_backend
+```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 method from 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
@@ -94,112 +117,61 @@ REST_FRAMEWORK = {
 }
 ```
 
-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).
-
-Obtain the public key from your [JWKS](/jwks). Then set the settings for [REST Framework JWK](http://getblimp.github.io/django-rest-framework-jwt/).
+Configure the Django REST Framework JWK 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.
+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
 
-jsonurl = request.urlopen("https://${account.namespace}/.well-known/jwks.json")
-jwks = json.loads(jsonurl.read())
-cert = '-----BEGIN CERTIFICATE-----\n' + jwks['keys'][0]['x5c'][0] + '\n-----END CERTIFICATE-----'
-
-certificate = load_pem_x509_certificate(str.encode(cert), default_backend())
-publickey = certificate.public_key()
-
 JWT_AUTH = {
     'JWT_PAYLOAD_GET_USERNAME_HANDLER':
-        'auth0authorization.user.jwt_get_username_from_payload_handler',
-    'JWT_PUBLIC_KEY': publickey,
+        'auth0authorization.utils.jwt_get_username_from_payload_handler',
+    'JWT_DECODE_HANDLER':
+        'auth0authorization.utils.jwt_decode_token',
     'JWT_ALGORITHM': 'RS256',
     'JWT_AUDIENCE': '${apiIdentifier}',
-    'JWT_ISSUER': '${account.namespace}',
+    'JWT_ISSUER': 'https://${account.namespace}/',
     'JWT_AUTH_HEADER_PREFIX': 'Bearer',
 }
 ```
 
-## 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/1.11/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) middleware component after `AuthenticationMiddleware` to middleware list.
+Create the function to fetch the JWKS from your Auth0 account to verify and decode the incoming Access Token.
 
 ```python
-# apiexample/settings.py
-
-MIDDLEWARE = [
-    # ...
-    'django.contrib.auth.middleware.AuthenticationMiddleware',
-    'django.contrib.auth.middleware.RemoteUserMiddleware',
-]
-```
-
-Add `ModelBackend` and `RemoteUserBackend` to the Authentication Backends.
+# auth0authorization/utils.py
 
-```python
-# apiexample/settings.py
-
-AUTHENTICATION_BACKENDS = [
-    'django.contrib.auth.backends.ModelBackend',
-    'django.contrib.auth.backends.RemoteUserBackend',
-]
-```
-
-Create `user.py` file in your application's folder and define a function that maps the `sub` field from the `access_token` to the username.
+import json
 
-```python
-# auth0authorization/user.py
+import jwt
+import requests
 
-from django.contrib.auth import authenticate
+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.')
 
-def jwt_get_username_from_payload_handler(payload):
-    username = payload.get('sub').replace('|', '.')
-    authenticate(remote_user=username)
-    return username
+    issuer = 'https://{}/'.format('${account.namespace}')
+    return jwt.decode(token, public_key, audience='${apiIdentifier}', issuer=issuer, algorithms=['RS256'])
 ```
 
-Then create a remote user in Django authentication system. Please check the [Django documentation](https://docs.djangoproject.com/en/2.0/howto/auth-remote-user/) for more information.
-
-## Protect Individual Endpoints
+### Validate scopes
 
-In the file `views.py` add `public` and `private` endpoints. Add the `@api_view` decorator to the `private` endpoint to indicate that the method requires authentication.
+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 rest_framework.decorators import api_view
 from django.http import JsonResponse
-from jose import jwt
-
-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.'})
-```
-
-## Configure the Scopes
-
-To configure scopes, click the Scopes section of the [Dashboard's APIs section](${manage_url}/#/apis) and configure the scopes you need.
-
-::: note
-This example uses the read:messages scopes.
-:::
-
-API endpoints can be configured to look for a particular `scope` in the `access_token`.
-
-Add the following methods to the `views.py` file to extract the granted scopes from the `access_token`.
-
-```python
-# auth0authorization/views.py
 
 def get_token_auth_header(request):
     """Obtains the Access Token from the Authorization Header
@@ -219,11 +191,12 @@ def requires_scope(required_scope):
         @wraps(f)
         def decorated(*args, **kwargs):
             token = get_token_auth_header(args[0])
-            unverified_claims = jwt.get_unverified_claims(token)
-            token_scopes = unverified_claims["scope"].split()
-            for token_scope in token_scopes:
-                if token_scope == required_scope:
-                    return f(*args, **kwargs)
+            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
@@ -231,7 +204,31 @@ def requires_scope(required_scope):
     return require_scope
 ```
 
-Use the decorator in the methods that require specific scopes granted. The method below requires the `read:messages` scope granted.
+## 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
@@ -239,28 +236,28 @@ Use the decorator in the methods that require specific scopes granted. The metho
 @api_view(['GET'])
 @requires_scope('read:messages')
 def private_scoped(request):
-    return JsonResponse("Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.")
+    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
+### Add URL mappings
 
-In previous steps we added methods to the `views.py` file. We need to map those methods to URLs.
+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/1.11/topics/http/urls/) that lets you map URL patterns to views.
+Django has a URL dispatcher 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.conf.urls import url
+from django.urls import path
 
 from . import views
 
 urlpatterns = [
-    url(r'^api/public$', views.public),
-    url(r'^api/private$', views.private),
-    url(r'^api/private-scoped$', views.private_scoped),
+    path('api/public', views.public),
+    path('api/private', views.private),
+    path('api/private-scoped', views.private_scoped),
 ]
 ```
 
@@ -269,11 +266,11 @@ The Django project also has a `urls.py` file. Add a reference to your applicatio
 ```python
 # apiexample/urls.py
 
-from django.conf.urls import url, include
 from django.contrib import admin
+from django.urls import include, path
 
 urlpatterns = [
-    url(r'^admin/', admin.site.urls),
-    url(r'^', include('auth0authorization.urls'))
+    path('admin/', admin.site.urls),
+    path('', include('auth0authorization.urls'))
 ]
 ```
diff --git a/articles/quickstart/backend/django/02-using.md b/articles/quickstart/backend/django/02-using.md
index 793ece84e6..00fd101849 100644
--- a/articles/quickstart/backend/django/02-using.md
+++ b/articles/quickstart/backend/django/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/django/03-troubleshooting.md b/articles/quickstart/backend/django/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/django/download.md b/articles/quickstart/backend/django/download.md
new file mode 100644
index 0000000000..0cc29df3bc
--- /dev/null
+++ b/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 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/articles/quickstart/backend/django/files/apiexample/urls.md b/articles/quickstart/backend/django/files/apiexample/urls.md
new file mode 100644
index 0000000000..dd7c571d81
--- /dev/null
+++ b/articles/quickstart/backend/django/files/apiexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/articles/quickstart/backend/django/files/apiexample/validator.md b/articles/quickstart/backend/django/files/apiexample/validator.md
new file mode 100644
index 0000000000..16b55b40c3
--- /dev/null
+++ b/articles/quickstart/backend/django/files/apiexample/validator.md
@@ -0,0 +1,28 @@
+---
+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/articles/quickstart/backend/django/files/apiexample/views.md b/articles/quickstart/backend/django/files/apiexample/views.md
new file mode 100644
index 0000000000..e9f3f9f404
--- /dev/null
+++ b/articles/quickstart/backend/django/files/apiexample/views.md
@@ -0,0 +1,37 @@
+---
+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/articles/quickstart/backend/django/files/urls.md b/articles/quickstart/backend/django/files/urls.md
new file mode 100644
index 0000000000..f5a6dc9e24
--- /dev/null
+++ b/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/articles/quickstart/backend/django/files/validator.md b/articles/quickstart/backend/django/files/validator.md
new file mode 100644
index 0000000000..839a4e5abf
--- /dev/null
+++ b/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/articles/quickstart/backend/django/files/views.md b/articles/quickstart/backend/django/files/views.md
new file mode 100644
index 0000000000..b44ec9baed
--- /dev/null
+++ b/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/articles/quickstart/backend/django/index.yml b/articles/quickstart/backend/django/index.yml
index ddd78f5857..67bb80cabe 100644
--- a/articles/quickstart/backend/django/index.yml
+++ b/articles/quickstart/backend/django/index.yml
@@ -1,12 +1,20 @@
 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
-image: /media/platforms/django.png
-tags:
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 snippets:
   dependencies: server-apis/django/dependencies
   setup: server-apis/django/setup
@@ -14,5 +22,32 @@ snippets:
 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/articles/quickstart/backend/django/interactive.md b/articles/quickstart/backend/django/interactive.md
new file mode 100644
index 0000000000..788a54162b
--- /dev/null
+++ b/articles/quickstart/backend/django/interactive.md
@@ -0,0 +1,316 @@
+---
+title: Add Authorization to Your Django API Application
+description: This tutorial demonstrates how to add authorization to a Python API built with Django.
+interactive:  true
+files:
+ - files/apiexample/validator
+ - files/apiexample/views
+ - files/apiexample/urls
+github:
+  path: 01-Authorization
+locale: en-US
+---
+
+# Add Authorization to Your Django API Application
+
+
+
        This guide demonstrates how to integrate Auth0 with any new or existing Python API built with Django.
        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, 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.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 grant 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 section. The following example uses the read:messages scope.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        
+
+## Configure Django to use Auth0
+
+
+
        Install dependencies
        1. Add the following dependencies to your requirements.txt:
+
+
        2. Run pip install -r requirements.txt
        Create a Django application
        
+
+## Create the JWT validator {{{ data-action="code" data-code="apiexample/validator.py" }}}
+
+
+
        You will use a library called Authlib to create a ResourceProtector, which is a type of Django view decorator 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 for validating Access Tokens.
        To create your Auth0JWTBearerTokenValidator, you need to pass it to 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 to 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. Next, map those methods to URLs using Django's URL dispatcher, which lets you map URL patterns to views. 
        Add the URL patterns to your apiexample/urls.py file. 
        Make a Call to Your API
        To make calls to your API, you will need an access token. You can retrieve an access token for testing purposes from the Test view in your API settings.
        Auth0 Dashboard> Applications > API > [Specific API] > Test tab
        Provide the access token as an Authorization header in your requests.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}.com/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}.com/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}.com/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}.com/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}.com/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}.com/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}.com/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}.com/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}.com/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}.com/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
diff --git a/articles/quickstart/backend/falcor/01-authentication.md b/articles/quickstart/backend/falcor/01-authentication.md
deleted file mode 100644
index d459da8452..0000000000
--- a/articles/quickstart/backend/falcor/01-authentication.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: Authentication
-description: This tutorial will show you how to use the Auth0 to add authentication to your Falcor API.
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-falcor-sample',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'Falcor 0.1.17',
-    'Express 4.15.2'
-  ]
-}) %>
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-## Add the Dependencies
-
-Add **express-jwt**, **express-jwt-authz**, **falcor-express**, **falcor-router**, and **falcor-http-datasource** to your project.
-
-${snippet(meta.snippets.dependencies)}
-
-## Configuration
-
-<%= include('../_includes/_api_jwks_description_no_link') %>
-
-Configure the **express-jwt** middleware to use the remote JWKS for your Auth0 account.
-
-${snippet(meta.snippets.setup)}
-
-## Configure the Scopes
-
-<%= include('../_includes/_api_scopes_access_resources') %>
-
-## Secure your API
-
-To protect an individual route that requires a valid JWT, configure the route with the `checkJwt` express-jwt middleware.
-
-```js
-// server.js
-
-// This endpoints doesn't need authentication
-app.use('/api/public/model.json', falcorExpress.dataSourceRoute(function(req, res) {
-  return new Router([
-    {
-      route: 'public.message',
-      get: function(pathSet) {
-        return { path:['public', 'message'], value: 'Hello from a public endpoint! You don\'t need to be authenticated to see this.' };
-      }
-    }
-  ]);
-}));
-
-app.use('/api/private/model.json', checkJwt, falcorExpress.dataSourceRoute(function(req, res) {
-  return new Router([
-    {
-      route: "private.message",
-      get: function(pathSet) {
-        return { path:['private', 'message'], value: 'Hello from a private endpoint! You need to be authenticated to see this.' };
-      }
-    }
-  ]);
-}));
-```
-
-```js
-// api.js
-
-// This endpoints doesn't need authentication
-app.get('/api/public', async function(req, res) {
-  const model = new falcor.Model(
-    {
-      source: new HttpDataSource('http://localhost:3000/api/public/model.json')
-    });
-
-  const message = await model.getValue(['public', 'message']);
-
-  res.json({ message: message });
-});
-
-app.get('/api/private', checkJwt, async function(req, res) {
-  const token = req.headers.authorization.split(" ")[1];
-  const model = new falcor.Model(
-    {
-      source: new HttpDataSource(
-        'http://localhost:3000/api/private/model.json',
-        {
-          headers: { 'Authorization': 'Bearer ' + token }
-        })
-    });
-
-  const message = await model.getValue(['private', 'message']);
-
-  res.json({ message: message });
-});
-```
-
-::: note
-If you are following along with the sample project you downloaded from the top of this page, base URL for Falcor's model should be set to http://localhost:3000.
-:::
-
-Individual routes can be configured to look for a particular `scope` by setting up another middleware with the **express-jwt-authz** package. To do so, provide an array of required scopes and apply the middleware to any routes you wish to add authorization to.
-
-${snippet(meta.snippets.use)}
-
-## Optional steps
-
-### Configuring CORS
-
-If you want to configure CORS, add this code to your Falcor app (assuming your Falcor app is hosted on `http://localhost:3010`):
-
-```js
-app.use(function(req, res, next) {
-  res.header("Access-Control-Allow-Origin", "http://localhost:3010");
-  res.header("Access-Control-Allow-Headers", "Authorization, Origin, X-Requested-With, Content-Type, Accept");
-  res.header("Access-Control-Allow-Credentials", "true");
-  next();
-});
-```
diff --git a/articles/quickstart/backend/falcor/02-using.md b/articles/quickstart/backend/falcor/02-using.md
deleted file mode 100644
index a39e59237b..0000000000
--- a/articles/quickstart/backend/falcor/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %>
diff --git a/articles/quickstart/backend/falcor/index.yml b/articles/quickstart/backend/falcor/index.yml
deleted file mode 100644
index cacffcdf35..0000000000
--- a/articles/quickstart/backend/falcor/index.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-title: Falcor API
-community: true
-thirdParty: false
-author:
-  community: true
-alias:
-  - falcor
-languages:
-  - Javascript
-image: /media/platforms/falcor.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/falcor/dependencies
-  setup: server-apis/falcor/setup
-  use: server-apis/falcor/use
-articles:
-  - 01-authentication
-  - 02-using
diff --git a/articles/quickstart/backend/golang/01-authorization.md b/articles/quickstart/backend/golang/01-authorization.md
index 799ccdea1b..8fa1a0a938 100644
--- a/articles/quickstart/backend/golang/01-authorization.md
+++ b/articles/quickstart/backend/golang/01-authorization.md
@@ -1,252 +1,257 @@
 ---
 title: Authorization
-description: This tutorial will show you how to use the Auth0 Go SDK to add authentication and authorization to your API.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-golang-api-samples',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'Go 1.8.2'
-  ]
-}) %>
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
 <%= include('../_includes/_api_create_new') %>
 
 <%= include('../_includes/_api_auth_preamble') %>
 
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid. The validity check is done in the `go-jwt-middleware` 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.
+## Validate Access Tokens
 
-## Install the Dependencies
+### Download dependencies
 
-The [**dgrijalva/jwt-go**](https://github.com/dgrijalva/jwt-go) package can be used to verify incoming JWTs. The [**auth0/go-jwt-middleware**](https://github.com/auth0/go-jwt-middleware) library can be used alongside it to fetch your Auth0 public key and complete the verification process. Finally, we'll use the [**gorilla/mux**](https://github.com/gorilla/mux) package to handle our routes and [**codegangsta/negroni**](https://github.com/urfave/negroni) for HTTP middleware.
+Add a `go.mod` file to list all the dependencies to be used.
 
-```bash
-go get "github.com/auth0/go-jwt-middleware"
-go get "github.com/dgrijalva/jwt-go"
-go get "github.com/codegangsta/negroni"
-go get "github.com/gorilla/mux"
-```
+```text
+// go.mod
 
-## Configuration
+module 01-Authorization-RS256
 
-Setup **go-jwt-middleware** middleware to verify `access_token` from incoming requests.
+go 1.21
 
-```go
-// main.go
-package main
+require (
+	github.com/auth0/go-jwt-middleware/v2 v2.2.0
+	github.com/joho/godotenv v1.5.1
+)
+```
 
-import (
-	"encoding/json"
-	"fmt"
-	"net/http"
-	"strings"
-	"errors"
-	"log"
-	"os"
+Download dependencies by running the following shell command:
 
-	"github.com/codegangsta/negroni"
-	"github.com/auth0/go-jwt-middleware"
-	"github.com/dgrijalva/jwt-go"
-	"github.com/gorilla/mux"
-	"github.com/joho/godotenv"
-)
+```shell
+go mod download
+```
 
-type Response struct {
-	Message string `json:"message"`
-}
+### Configure your application
 
-type Jwks struct {
-	Keys []JSONWebKeys `json:"keys"`
-}
+Create a `.env` file within the root of your project directory to store the app configuration, and fill in the
+environment variables:
 
-type JSONWebKeys struct {
-	Kty string `json:"kty"`
-	Kid string `json:"kid"`
-	Use string `json:"use"`
-	N string `json:"n"`
-	E string `json:"e"`
-	X5c []string `json:"x5c"`
-}
+```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}'
 
-func main() {
-	jwtMiddleware := jwtmiddleware.New(jwtmiddleware.Options {
-        ValidationKeyGetter: func(token *jwt.Token) (interface{}, error) {
-            // Verify 'aud' claim
-            aud := "${apiIdentifier}"
-            checkAud := token.Claims.(jwt.MapClaims).VerifyAudience(aud, false)
-            if !checkAud {
-                return token, errors.New("Invalid audience.")
-            }
-            // Verify 'iss' claim
-            iss := "https://${account.namespace}/"
-            checkIss := token.Claims.(jwt.MapClaims).VerifyIssuer(iss, false)
-            if !checkIss {
-                return token, errors.New("Invalid issuer.")
-            }
-
-            cert, err := getPemCert(token)
-            if err != nil {
-                panic(err.Error())
-            }
-
-            result, _ := jwt.ParseRSAPublicKeyFromPEM([]byte(cert))
-            return result, nil
-        },
-        SigningMethod: jwt.SigningMethodRS256,
-    })
-}
+# Our Auth0 API's Identifier.
+AUTH0_AUDIENCE='YOUR_API_IDENTIFIER'
 ```
 
-<%= include('../_includes/_api_jwks_description_no_link') %>
+### 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.
 
-Create the function to get the remote JWKS for your Auth0 account and return the certificate with the public key in PEM format.
+Setup **go-jwt-middleware** middleware to verify Access Tokens from incoming requests.
 
 ```go
-// main.go
+// middleware/jwt.go
 
-func getPemCert(token *jwt.Token) (string, error) {
-	cert := ""
-	resp, err := http.Get("https://${account.namespace}/.well-known/jwks.json")
+package middleware
 
-	if err != nil {
-		return cert, err
-	}
-	defer resp.Body.Close()
+import (
+	"context"
+	"log"
+	"net/http"
+	"net/url"
+	"os"
+	"time"
 
-	var jwks = Jwks{}
-	err = json.NewDecoder(resp.Body).Decode(&jwks)
+	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 {
-		return cert, err
+		log.Fatalf("Failed to parse the issuer url: %v", err)
 	}
 
-	for k, _ := range jwks.Keys {
-		if token.Header["kid"] == jwks.Keys[k].Kid {
-			cert = "-----BEGIN CERTIFICATE-----\n" + jwks.Keys[k].X5c[0] + "\n-----END CERTIFICATE-----"
-		}
+	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")
 	}
 
-	if cert == "" {
-		err := errors.New("Unable to find appropriate key.")
-		return cert, err
+	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."}`))
 	}
 
-	return cert, nil
+	middleware := jwtmiddleware.New(
+		jwtValidator.ValidateToken,
+		jwtmiddleware.WithErrorHandler(errorHandler),
+	)
+
+	return func(next http.Handler) http.Handler {
+		return middleware.CheckJWT(next)
+	}
 }
 ```
 
-## Protect Individual Endpoints
+<%= include('../_includes/_api_jwks_description') %>
+
+
+## Protect API Endpoints
 
-To protect individual routes pass the instance of `go-jwt-middleware` defined above to the `negroni` handler.
+To protect individual routes, pass `middleware` (defined above) to the http route.
 
 ```go
 // main.go
 
-func main() {
-    // ...
+package main
 
-    r := mux.NewRouter()
-
-    // This route is always accessible
-    r.Handle("/api/public", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-        message := "Hello from a public endpoint! You don't need to be authenticated to see this."
-        responseJSON(message, w, http.StatusOK)
-    }))
-
-    // This route is only accessible if the user has a valid access_token
-    // We are chaining the jwtmiddleware middleware into the negroni handler function which will check
-    // for a valid token.
-    r.Handle("/api/private", negroni.New(
-        negroni.HandlerFunc(jwtMiddleware.HandlerWithNext),
-        negroni.Wrap(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-            message := "Hello from a private endpoint! You need to be authenticated to see this."
-            responseJSON(message, w, http.StatusOK)
-    }))))
-}
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
 
-func responseJSON(message string, w http.ResponseWriter, statusCode int) {
-	response := Response{message}
+	"01-Authorization-RS256/middleware"
+)
 
-	jsonResponse, err := json.Marshal(response)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Error loading the .env file: %v", err)
 	}
 
-	w.Header().Set("Content-Type", "application/json")
-	w.WriteHeader(statusCode)
-	w.Write(jsonResponse)
+	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)
+	}
 }
 ```
 
-## Configuring Scopes
-
-The `go-jwt-middleware` 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.
-
-Scopes provide a way for you to define which resources should be accessible by the user holding a given `access_token`. For example, you might choose to permit `read` access to a `messages` resource if a user has a **manager** access level, or a `write` access to that resource if they are an **administrator**.
+### Validate scopes
 
-To configure scopes in your Auth0 dashboard, navigate to [your API](${manage_url}/#/apis) and choose the **Scopes** tab. In this area you can apply any scopes you wish, including one called `read:messages`, which will be used in this example.
+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.
 
-Let's create a function to check and ensure the `access_token` has the correct scope before returning a successful response.
+Create a function to check and ensure the Access Token has the correct scope before returning a successful response.
 
 ```go
-// main.go
-
-type CustomClaims struct {
-	Scope string `json:"scope"`
-	jwt.StandardClaims
-}
-
-func checkScope(scope string, tokenString string) bool {
-	token, _ := jwt.ParseWithClaims(tokenString, &CustomClaims{}, nil)
-
-	claims, _ := token.Claims.(*CustomClaims)
-
-	hasScope := false
-	result := strings.Split(claims.Scope, " ")
-	for i := range result {
-		if result[i] == scope {
-			hasScope = true
-		}
-	}
-
-	return hasScope
+// 👆 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
 }
 ```
 
-We will use this function in the endpoint that requires the scope `read:messages`.
+Use this function in the endpoint that requires the scope `read:messages`.
 
 ```go
-// main.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
-    // We are chaining the jwtmiddleware middleware into the negroni handler function which will check
-    // for a valid token and and scope.
-    r.Handle("/api/private-scoped", negroni.New(
-        negroni.HandlerFunc(jwtMiddleware.HandlerWithNext),
-        negroni.Wrap(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-            authHeaderParts := strings.Split(r.Header.Get("Authorization"), " ")
-            token := authHeaderParts[1]
-
-            hasScope := checkScope("read:messages", token)
-
-            if !hasScope {
-                message := "Insufficient scope."
-                responseJSON(message, w, http.StatusForbidden)
-                return
-            }
-            message := "Hello from a private endpoint! You need to be authenticated to see this."
-            responseJSON(message, w, http.StatusOK)
-    }))))
+    
+    // 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 our example we only checked for the `read:messages` scope. You may want to extend the `checkScope` function or make it a standalone middleware that accepts multiple roles to fit your use case.
+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/articles/quickstart/backend/golang/02-using.md b/articles/quickstart/backend/golang/02-using.md
index a39e59237b..bb649cc040 100644
--- a/articles/quickstart/backend/golang/02-using.md
+++ b/articles/quickstart/backend/golang/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/golang/03-troubleshooting.md b/articles/quickstart/backend/golang/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/golang/download.md b/articles/quickstart/backend/golang/download.md
new file mode 100644
index 0000000000..6ea2dbcd2e
--- /dev/null
+++ b/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 image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/backend/golang/files/jwt.md b/articles/quickstart/backend/golang/files/jwt.md
new file mode 100644
index 0000000000..d9aba4c4f1
--- /dev/null
+++ b/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/articles/quickstart/backend/golang/files/main.md b/articles/quickstart/backend/golang/files/main.md
new file mode 100644
index 0000000000..9e2ba946b6
--- /dev/null
+++ b/articles/quickstart/backend/golang/files/main.md
@@ -0,0 +1,67 @@
+---
+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/articles/quickstart/backend/golang/files/middleware/jwt.md b/articles/quickstart/backend/golang/files/middleware/jwt.md
new file mode 100644
index 0000000000..0149818d66
--- /dev/null
+++ b/articles/quickstart/backend/golang/files/middleware/jwt.md
@@ -0,0 +1,88 @@
+---
+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/articles/quickstart/backend/golang/index.yml b/articles/quickstart/backend/golang/index.yml
index e58ec06cbf..08e116eafa 100644
--- a/articles/quickstart/backend/golang/index.yml
+++ b/articles/quickstart/backend/golang/index.yml
@@ -1,13 +1,21 @@
-title: Go
+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
-image: /media/platforms/golang.png
-tags:
+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
@@ -15,3 +23,32 @@ snippets:
 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/articles/quickstart/backend/golang/interactive.md b/articles/quickstart/backend/golang/interactive.md
new file mode 100644
index 0000000000..35c858b565
--- /dev/null
+++ b/articles/quickstart/backend/golang/interactive.md
@@ -0,0 +1,359 @@
+---
+title: Add Authorization to Your Go Application
+description: This tutorial demonstrates how to add authorization to a Go API.
+interactive:  true
+files:
+ - files/middleware/jwt
+ - files/main
+github:
+  path: 01-Authorization-RS256
+locale: en-US
+---
+
+# 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 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.
        Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section. The following example uses the read:messages scope.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        
+
+## Install dependencies
+
+
+
        Add a go.mod file to list all the necessary dependencies.
        // 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:
        go mod download
+
+
        
+
+
        
+
+## Configure your application
+
+
+
        Create a .env file within the root of your project directory to store the app configuration. Then, fill in the environment variables:
        # 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.
        Set up the go-jwt-middleware middleware to verify access tokens from incoming requests.
        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.
        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.
        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.
        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.
        Auth0 Dashboard> Applications > API > [Specific API] > Test tab
        Provide the Access Token as an Authorization header in your requests.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Go API Quickstart - Step 5 Checkpoint 
        Now that you have configured your application, run your application and 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.
        
+
+  
        
+
+  
        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.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/backend/hapi/01-authorization.md b/articles/quickstart/backend/hapi/01-authorization.md
deleted file mode 100644
index bfe7d3ea1c..0000000000
--- a/articles/quickstart/backend/hapi/01-authorization.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization to a Hapi.js API
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-hapi-api-samples',
-  path: '01-Authenticate-RS256',
-  requirements: [
-    'Hapi.js 16.0.0',
-    'hapi-auth-jwt2 7.2.4'
-  ]
-}) %>
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid. The validity check is done using the **hapi-auth-jwt2** plugin and 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.
-
-## Install the Dependencies
-
-The **hapi-auth-jwt2** plugin can be used to verify incoming JWTs. The **jwks-rsa** library can be used alongside it to fetch your Auth0 public key and complete the verification process. Install these libraries with npm.
-
-```bash
-npm install --save hapi-auth-jwt2 jwks-rsa
-```
-
-## Configure hapi-auth-jwt2
-
-<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-hapi-api-samples/tree/master/02-Authenticate-HS256'}) %>
-
-Set up the **hapi-auth-jwt2** plugin to fetch this public key through the **jwks-rsa** library.
-
-```js
-// server.js
-
-const Hapi = require('hapi');
-const jwt = require('hapi-auth-jwt2');
-const jwksRsa = require('jwks-rsa');
-
-const server = new Hapi.Server();
-
-// ...
-
-server.register(jwt, err => {
-  if (err) throw err;
-  server.auth.strategy('jwt', 'jwt', 'required', {
-    complete: true,
-    // verify the Access Token against the
-    // remote Auth0 JWKS 
-    key: jwksRsa.hapiJwt2Key({
-      cache: true,
-      rateLimit: true,
-      jwksRequestsPerMinute: 5,
-      jwksUri: `https://${account.namespace}/.well-known/jwks.json`
-    }),
-    verifyOptions: {
-      audience: '${apiIdentifier}',
-      issuer: `https://${account.namespace}/`,
-      algorithms: ['RS256']
-    },
-    validateFunc: validateUser
-  });
-  registerRoutes();
-});
-```
-
-The **hapi-auth-jwt2** plugin does the work of actually verifying that the JWT is valid. However, the `validateFunc` key requires a function which is the final stop for accepting or rejecting authorization for a given request. This function must return a callback with either `true` or `false` to indicate the the request can proceed. The function can also operate on the decoded payload of the JWT and supply a modified `req.auth.credentials` object based on custom logic.
-
-When you request multiple `scope`s in an Auth0 authentication transaction, they come back as a space-delimited string in the `access_token` payload. However, the **hapi-auth-jwt2** plugin expects an array when multiple `scope`s are used. This conversion can be handled in the `validateFunc` function.
-
-Add a function called `validateUser` and modify the `req.auth.credentials` object such that the `scope` key is parsed into an array instead of a space-delimited string.
-
-```js
-// server.js
-
-const validateUser = (decoded, request, callback) => {
-  // This is a simple check that the `sub` claim
-  // exists in the Access Token. Modify it to suit
-  // the needs of your application
-  if (decoded && decoded.sub) {
-    if (decoded.scope)
-      return callback(null, true, {
-        scope: decoded.scope.split(' ')
-      });
-
-    return callback(null, true);
-  }
-
-  return callback(null, false);
-};
-```
-
-When a valid JWT Access Token is received at an endpoint, the `scope`s from the payload will be available as an array on `req.auth.credentials`.
-
-## Protect Individual Endpoints
-
-The configuration that is set up above for the **hapi-auth-jwt2** plugin specifies `required` as the third argument to the `strategy`. This means that all routes will require authentication by default. If you'd like to make a route public, you can simply pass `auth: false` to the route's `config`. To protect a route requiring a valid JWT you can pass `auth: 'jwt'`.
-
-```js
-// server.js
-
-// This route doesn't need authentication
-server.route({
-  method: 'GET',
-  path: '/api/public',
-  config: {
-    auth: false,
-    handler: (req, res) => {
-      res({
-        message: "Hello from a public endpoint! You don't need to be authenticated to see this."
-      });
-    }
-  }
-});
-
-// This route need authentication
-server.route({
-  method: 'GET',
-  path: '/api/private',
-  config: {
-    auth: 'jwt',
-    handler: (req, res) => {
-      res({
-        message: 'Hello from a private endpoint! You need to be authenticated to see this.'
-      });
-    }
-  }
-});
-```
-
-<%= include('../_includes/_api_scope_description') %>
-
-Individual routes can be configured to look for a particular `scope` in the `access_token` using `auth.scope`.
-
-```js
-// server.js
-
-// ...
-
-server.route({
-  method: 'GET',
-  path: '/api/private-scoped',
-  config: {
-    auth: {
-      scope: 'read:messages'
-    },
-    handler: (req, res) => {
-      res({
-        message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.'
-      });
-    }
-  }
-});
-```
-
-With this configuration in place, only valid `access_token`s which have a scope of `read:messages` will be allowed to access this endpoint.
diff --git a/articles/quickstart/backend/hapi/02-using.md b/articles/quickstart/backend/hapi/02-using.md
deleted file mode 100644
index 793ece84e6..0000000000
--- a/articles/quickstart/backend/hapi/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %> 
diff --git a/articles/quickstart/backend/hapi/index.yml b/articles/quickstart/backend/hapi/index.yml
deleted file mode 100644
index 76c0da660f..0000000000
--- a/articles/quickstart/backend/hapi/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Hapi API
-thirdParty: false
-author:
-  community: true
-alias:
-  - hapi
-  - hapijs
-  - hapi.js
-languages:
-  - Javascript
-image: /media/platforms/node.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/hapi/dependencies
-  setup: server-apis/hapi/setup
-  use: server-apis/hapi/use
-articles:
-  - 01-authorization
-  - 02-using
diff --git a/articles/quickstart/backend/java-spring-security/01-authorization.md b/articles/quickstart/backend/java-spring-security/01-authorization.md
deleted file mode 100644
index a348aaa71d..0000000000
--- a/articles/quickstart/backend/java-spring-security/01-authorization.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-title: Authorization
-name: How to secure your Spring Security API with Auth0
-description: This tutorial demonstrates how to add authorization to your Spring Security API using Auth0.
-budicon: 500
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-api-sample',
-  path: '01-Authorization',
-  requirements: [
-    'Java 8 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-This tutorial shows you how to protect your Spring Security API endpoints and limit access to resources in your API.
-
-## Create an API
-
-Create a new API in the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard.
-
-Enter a name and an identifier for the API. These values represent the `auth0.apiAudience` value in the configuration file.
-
-Select the signing algorithm. In the **Settings** tab,  you can change the token expiration time and allow to refresh a token for that API.
-In the **Scopes** tab, add scopes you will use later to limit access to resources in your API.
-
-<%= include('../_includes/_api_scopes_access_resources') %>
-
-## Install the Dependencies
-
-Add the `auth0-spring-security-api` dependency.
-
-If you are using Maven, add the dependency to your `pom.xml` file:
-
-${snippet(meta.snippets.dependencies)}
-
-If you are using Gradle, add the dependency to the dependencies block:
-
-${snippet(meta.snippets.dependenciesGradle)}
-
-## Configure Your Spring Security API
-
-Your Spring Security API needs some information to authenticate against your Auth0 account.
-
-The sample project you can download from the top of this page comes with a configuration file. You may need to update some of the entries with the values for your API. The filename is `/src/main/resources/auth0.properties` and it contains the following:
-
-${snippet(meta.snippets.setup)}
-
-| Attribute | Description|
-| --- | --- |
-| `auth0.issuer` | The issuer of the JWT Token. Typically, this is your Auth0 domain with a `https://` prefix and a `/` suffix. For example, if your Auth0 domain is `example.auth0.com`, the `auth0.issuer` must be set to `https://example.auth0.com/` (the trailing slash is important). |
-| `auth0.apiAudience` | The unique identifier for your API. You can find the correct value in the [APIs](${manage_url}/#/apis) section in your Auth0 dashboard. |
-
-::: note
-If you download the sample project, the `issuer` attribute is filled out for you. You must manually set the `apiAudience` attribute.
-:::
-
-## Configure JSON Web Token Signature Algorithm
-
-Configure your API to use the RS256 signing algorithm.
-
-::: note
-If you download the sample project, the signing algorithm is set to `RS256` by default.
-:::
-
-```java
-// src/main/java/com/auth0/example/AppConfig.java
-
-@EnableWebSecurity
-@Configuration
-public class SecurityConfig extends WebSecurityConfigurerAdapter {
-
-    @Value(value = "<%= "${auth0.apiAudience}" %>")
-    private String apiAudience;
-    @Value(value = "<%= "${auth0.issuer}" %>")
-    private String issuer;
-
-    @Override
-    protected void configure(HttpSecurity http) throws Exception {
-        JwtWebSecurityConfigurer
-                .forRS256(apiAudience, issuer)
-                .configure(http);
-    }
-}
-```
-
-## Configure the Protected Endpoints
-
-The example below shows how to implement secure API methods.
-
-In the `AppConfig` class, add route matchers to the snippet. The `hasAuthority()` method provides a way to specify the required scope for the resource.
-
-<%= include('../_includes/_api_endpoints') %>
-
-```java
-// src/main/java/com/auth0/example/AppConfig.java
-
-@EnableWebSecurity
-@Configuration
-public class SecurityConfig extends WebSecurityConfigurerAdapter {
-
-    @Value(value = "<%= "${auth0.apiAudience}" %>")
-    private String apiAudience;
-    @Value(value = "<%= "${auth0.issuer}" %>")
-    private String issuer;
-
-    @Override
-    protected void configure(HttpSecurity http) throws Exception {
-        JwtWebSecurityConfigurer
-                .forRS256(apiAudience, issuer)
-                .configure(http)
-                .authorizeRequests()
-                .antMatchers(HttpMethod.GET, "/api/public").permitAll()
-                .antMatchers(HttpMethod.GET, "/api/private").authenticated()
-                .antMatchers(HttpMethod.GET, "/api/private-scoped").hasAuthority("read:messages");
-    }
-}
-```
-
-## Create the API Controller
-
-Create a new class called `APIController` to handle each request to the endpoints.
-
-Next, in the `AppConfig.java` file, configure which endpoints are secure and which are not.
-
-```java
-// src/main/java/com/auth0/example/APIController.java
-
-import org.springframework.stereotype.Component;
-import org.springframework.stereotype.Controller;
-import org.springframework.web.bind.annotation.RequestMapping;
-import org.springframework.web.bind.annotation.RequestMethod;
-import org.springframework.web.bind.annotation.ResponseBody;
-import org.json.JSONObject;
-
-@Controller
-@Component
-public class APIController {
-
-    @RequestMapping(value = "/api/public", method = RequestMethod.GET, produces = "application/json")
-    @ResponseBody
-    public String publicEndpoint() {
-        return new JSONObject()
-                .put("message", "Hello from a public endpoint! You don\'t need to be authenticated to see this.")
-                .toString();
-    }
-
-    @RequestMapping(value = "/api/private", method = RequestMethod.GET, produces = "application/json")
-    @ResponseBody
-    public String privateEndpoint() {
-        return new JSONObject()
-                .put("message", "Hello from a private endpoint! You need to be authenticated to see this.")
-                .toString();
-    }
-
-    @RequestMapping(value = "/api/private-scoped", method = RequestMethod.GET, produces = "application/json")
-    @ResponseBody
-    public String privateScopedEndpoint() {
-        return new JSONObject()
-                .put("message", "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.")
-                .toString();
-    }
-
-}
-```
-
-To build and run the seed project, use the command: `mvn spring-boot:run`.
diff --git a/articles/quickstart/backend/java-spring-security/02-using.md b/articles/quickstart/backend/java-spring-security/02-using.md
deleted file mode 100644
index a39e59237b..0000000000
--- a/articles/quickstart/backend/java-spring-security/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %>
diff --git a/articles/quickstart/backend/java-spring-security/index.yml b/articles/quickstart/backend/java-spring-security/index.yml
deleted file mode 100644
index 530c2aa9f1..0000000000
--- a/articles/quickstart/backend/java-spring-security/index.yml
+++ /dev/null
@@ -1,29 +0,0 @@
-title: Spring Security Java API
-thirdParty: false
-alias:
-  - spring security
-  - spring
-author:
-  name: Luciano Balmaceda
-  email: luciano.balmaceda@auth0.com
-  community: false
-languages:
-  - Java
-framework:
-  - Spring
-image: /media/platforms/java.png
-tags:
-  - quickstart
-snippets:
-  configure: server-apis/java-spring-security/configure
-  dependencies: server-apis/java-spring-security/dependencies
-  dependenciesGradle: server-apis/java-spring-security/dependencies-gradle
-  setup: server-apis/java-spring-security/setup
-  use: server-apis/java-spring-security/use
-  newRule: server-apis/java-spring-security/newRule
-  AppConfig: server-apis/java-spring-security/AppConfig
-  PingController: server-apis/java-spring-security/PingController
-  SecurePingController: server-apis/java-spring-security/SecurePingController
-articles:
-  - 01-authorization
-  - 02-using
diff --git a/articles/quickstart/backend/java-spring-security5/01-authorization.md b/articles/quickstart/backend/java-spring-security5/01-authorization.md
new file mode 100644
index 0000000000..f0554aa049
--- /dev/null
+++ b/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 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 and the Dependency Management Plugin 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, 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, 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 article.
diff --git a/articles/quickstart/backend/java-spring-security5/02-using.md b/articles/quickstart/backend/java-spring-security5/02-using.md
new file mode 100644
index 0000000000..466de7dabc
--- /dev/null
+++ b/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/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md b/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/java-spring-security5/download.md b/articles/quickstart/backend/java-spring-security5/download.md
new file mode 100644
index 0000000000..94571c5ddb
--- /dev/null
+++ b/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 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/articles/quickstart/backend/java-spring-security5/files/APIController.md b/articles/quickstart/backend/java-spring-security5/files/APIController.md
new file mode 100644
index 0000000000..6f04ff5496
--- /dev/null
+++ b/articles/quickstart/backend/java-spring-security5/files/APIController.md
@@ -0,0 +1,35 @@
+---
+name: APIController.java
+language: powershell
+---
+    
+```powershell
+    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");
+}
+    }
+```
diff --git a/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md b/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
new file mode 100644
index 0000000000..5c6788d8a4
--- /dev/null
+++ b/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
@@ -0,0 +1,41 @@
+---
+name: SecurityConfig.java
+language: powershell
+---
+    
+```powershell
+    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();
+}
+    }
+```
diff --git a/articles/quickstart/backend/java-spring-security5/files/api-controller.md b/articles/quickstart/backend/java-spring-security5/files/api-controller.md
new file mode 100644
index 0000000000..ece3064bdf
--- /dev/null
+++ b/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/articles/quickstart/backend/java-spring-security5/files/application.md b/articles/quickstart/backend/java-spring-security5/files/application.md
new file mode 100644
index 0000000000..b94691c69a
--- /dev/null
+++ b/articles/quickstart/backend/java-spring-security5/files/application.md
@@ -0,0 +1,13 @@
+---
+name: application.yml
+language: 
+---
+    
+```
+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}
+```
diff --git a/articles/quickstart/backend/java-spring-security5/files/message.md b/articles/quickstart/backend/java-spring-security5/files/message.md
new file mode 100644
index 0000000000..fc1823b480
--- /dev/null
+++ b/articles/quickstart/backend/java-spring-security5/files/message.md
@@ -0,0 +1,11 @@
+---
+name: Message.java
+language: powershell
+---
+    
+```powershell
+    /**
+     * Simple domain object for our API to return a message.
+     */
+    public record Message(String message) {}
+```
diff --git a/articles/quickstart/backend/java-spring-security5/files/security-config.md b/articles/quickstart/backend/java-spring-security5/files/security-config.md
new file mode 100644
index 0000000000..257bdbaa32
--- /dev/null
+++ b/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/articles/quickstart/backend/java-spring-security5/index.yml b/articles/quickstart/backend/java-spring-security5/index.yml
new file mode 100644
index 0000000000..9baab5db4c
--- /dev/null
+++ b/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/articles/quickstart/backend/java-spring-security5/interactive.md b/articles/quickstart/backend/java-spring-security5/interactive.md
new file mode 100644
index 0000000000..eab5af715e
--- /dev/null
+++ b/articles/quickstart/backend/java-spring-security5/interactive.md
@@ -0,0 +1,145 @@
+---
+title: Add Authorization to Your Spring Boot Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Spring Boot application.
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/Message
+ - files/APIController
+github:
+  path: 01-Authorization-MVC
+locale: en-US
+---
+
+# 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 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.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        This example uses the read:messages scope.
        
+
+## Configure the sample project {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        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.
        
+
+## Install dependencies {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        If you are using Gradle, you can add the required dependencies using the Spring Boot Gradle Plugin and the Dependency Management Plugin to resolve dependency versions:
        // 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:
        // pom.xml
+
+
+
+<parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.5</version>
+
+ <relativePath/>
+
+</parent>
+
+<dependencies>
+
+ <dependency>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+ <groupId>com.okta.spring</groupId>
+
+ <artifactId>okta-spring-boot-starter</artifactId>
+
+ <version>3.0.5</version>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## 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
        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
        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.
        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:4" }}}
+
+
+
        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 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:
        ./gradlew bootRun
+
+
        
+
+
        Windows:
        gradlew.bat bootRun
+
+
        
+
+
        If you are configuring your own application using Maven and the Spring Boot Maven Plugin, you can execute the spring-boot:run goal.
        Linux or macOS:
        mvn spring-boot:run
+
+
        
+
+
        Windows:
        mvn.cmd spring-boot:run
+
+
        
+
+
        Spring Boot API Step 7 Checkpoint 
        The sample application will be available at http://localhost:3010/. Read about how to test and use your API in the Using Your API article.
        
+
+  
        
+
+  
        If your application did not launch successfully:
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/backend/laravel/01-authorization.md b/articles/quickstart/backend/laravel/01-authorization.md
index 77039acd11..b2b630db20 100644
--- a/articles/quickstart/backend/laravel/01-authorization.md
+++ b/articles/quickstart/backend/laravel/01-authorization.md
@@ -1,433 +1,245 @@
 ---
-title: Authorization
-description: This tutorial demonstrates how to add authorization to your Laravel API using Auth0
+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
 ---
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-laravel-api-samples',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'Composer 1.5',
-    'PHP 7.0',
-    'Laravel 5.5',
-    'laravel-auth0 5.0.2'
-  ]
-}) %>
+
 
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-## Install the Dependencies
-
-Protecting your Laravel API requires a middleware which will check for and verify an `access_token` in the `Authorization` header of an incoming HTTP request. You can use the middleware provided in the **[laravel-auth0](https://github.com/auth0/laravel-auth0)** package.
-
-Install `laravel-auth0` using **Composer**.
-
-::: note
-**[Composer](https://getcomposer.org/)** is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you. See Composer's [getting started](https://getcomposer.org/doc/00-intro.md) doc for information on how to use it.
-:::
+---
 
-${snippet(meta.snippets.dependencies)}
+**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 from `Authorization` headers in requests to control access to routes.**
 
-## Enable the Provider
+Separate front-end applications are usually built to interact with these types of backends. These can be anything from single-page applications or native or mobile apps (all of which Auth0 also provides SDKs for!)
 
-The `laravel-auth0` package comes with a provider called `LoginServiceProvider`. Add this to the list of application `providers`.
+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.
 
-${snippet(meta.snippets.setup)}
+As their name implies, 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, which we will demonstrate later.
 
-If you would like to use the `Auth0` [facade](http://laravel.com/docs/facades), add it to the list of `aliases`.
+## Laravel Installation
 
-```php
-// config/app.php
+**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:
 
- 'aliases' => [
-    // ...
-    'Auth0' => \Auth0\Login\Facade\Auth0::class,
-],
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0
 ```
 
-You will now be able to access user info with `Auth0::getUser()`.
-
-Finally, you need to bind a class that provides a user (your app model user) each time the user is logged in or an `access_token` is decoded. You can use the `Auth0UserRepository` provided by this package or you can build your own class.
-
-To use `Auth0UserRepository`, add the following lines to your `AppServiceProvider`:
-
-```php
-// app/Providers/AppServiceProvider.php
-
-public function register()
-{
-
-    $this->app->bind(
-        \Auth0\Login\Contract\Auth0UserRepository::class, 
-        \Auth0\Login\Repository\Auth0UserRepository::class
-    );
+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
 ```
 
-## Configure the Plugin
+## SDK Installation
 
-The **laravel-auth0** plugin comes with a configuration file that can be generated using `artisan`. Generate the file and complete the details found within.
+Run the following command within your project directory to install the Auth0 Laravel SDK:
 
-```bash
-php artisan vendor:publish
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
 ```
 
-After the file is generated, it will be located at `config/laravel-auth0.php`.
-
-## Configure Apache
+Then generate an SDK configuration file for your application:
 
-By default, Apache doesn't parse `Authorization` headers from incoming HTTP requests. To enable this, add a `mod_rewrite` to your `.htaccess` file.
-
-```bash
-RewriteCond %{HTTP:Authorization} ^(.*)
-RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
+```shell
+php artisan vendor:publish --tag auth0
 ```
 
-## Define a User and User Provider
+## SDK Configuration
 
-The [Laravel authentication system](https://laravel.com/docs/5.5/authentication) needs a **User Object** given by a **User Provider**. With these two abstractions, the user entity can have any structure you like and can be stored anywhere. You configure the **User Provider** indirectly by selecting a user provider in `app/config/auth.php`. The default provider is Eloquent, which persists the User model in a database using the ORM.
+Run the following command from your project directory to download the Auth0 CLI:
 
-The **laravel-auth0** plugin comes with an authentication driver called `auth0`. This driver defines a user structure that wraps the [normalized user profile](https://auth0.com/docs/user-profile/normalized) defined by Auth0. It doesn't actually persist the object but rather simply stores it in the session for future calls.
-
-This is adequate for basic testing or if you don't have a requirement to persist the user. At any point you can call `Auth::check()` to determine if there is a user logged in and `Auth::user()` to retrieve the wrapper with the user information.
-
-Configure the `driver` in `/config/auth.php` to use `auth0`.
-
-```php
-// app/config/auth.php
-
-// ...
-'providers' => [
-    'users' => [
-        'driver' => 'auth0'
-    ],
-],
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
 ```
 
-## Protect the API Routes
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
 
-Define a middleware to check and verify `access_token` in the `Authorization` header of an incoming HTTP request.
-
-To create a middleware use the `make:middleware` Artisan command.
-
-```bash
-php artisan make:middleware CheckJWT
+```shell
+./auth0 login
 ```
 
-Implement `handle` method to check for an `access_token`, and if it is valid log the user in Laravel authentication system.
+Next, create a new application with Auth0:
 
-```php
-// /app/Http/Middleware/CheckJWT.php
-
-userRepository = $userRepository;
-    }
-
-    /**
-     * Handle an incoming request.
-     *
-     * @param  \Illuminate\Http\Request  $request
-     * @param  \Closure  $next
-     * @return mixed
-     */
-    public function handle($request, Closure $next)
-    {
-        $auth0 = \App::make('auth0');
-
-        $accessToken = $request->bearerToken();
-        try {
-            $tokenInfo = $auth0->decodeJWT($accessToken);
-            $user = $this->userRepository->getUserByDecodedJWT($tokenInfo);
-            if (!$user) {
-                return response()->json(["message" => "Unauthorized user"], 401);
-            }
-
-            \Auth::login($user);
-
-        } catch (CoreException $e) {
-            return response()->json(["message" => $e->getMessage()], 401);
-        } catch (InvalidTokenException $e) {
-            return response()->json(["message" => $e->getMessage()], 401);
-        }
-
-        return $next($request);
-    }
-}
+```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
 ```
 
-To Assign the middleware to specific routes, append it to the list and assign a key in `$routeMiddleware` property.
+You should also create a new API:
 
-```php
-// /app/Http/Kernel.php
-
-protected $routeMiddleware = [
-    // ...
-    'jwt' => \App\Http\Middleware\CheckJWT::class,
-];
+```shell
+./auth0 apis create \
+  --name "My Laravel Backend API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
 ```
 
-Protecting individual API endpoints can be done by applying the `jwt` middleware to them.
+This produces two files in your project directory that configure the SDK.
 
-```php
-// routes/api.php
+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:
 
-// This endpoint doesn't need authentication
-Route::get('/public', function (Request $request) {
-    return response()->json(["message" => "Hello from a public endpoint! You don't need to be authenticated to see this."]);
-});
-
-Route::get('/private', function (Request $request) {
-    return response()->json(["message" => "Hello from a private endpoint! You need to have a valid access token to see this."]);
-})->middleware('jwt');
+```bash
+echo ".auth0.*.json" >> .gitignore
 ```
 
-This route is now only accessible if an `access_token` is included in the `Authorization` header of the incoming request.
-
-## Configure the Scopes
+## Access Control
 
-The middleware defined above that the `access_token` in the incoming HTTP request is valid, however it does not include a mechanism to check if the `access_token` has sufficient **scope** to access the requested resource.
+You can use the Auth0 SDK's authorization guard to restrict access to your application's routes.
 
-<%= include('../_includes/_api_scopes_access_resources') %>
+To reject requests that do not contain a valid access token in the `Authorization` header, you can use Laravel's `auth` middleware:
 
-Define a middleware to look for a particular **scope** claim in the `access_token`.
-
-To create a middleware use the `make:middleware` Artisan command.
-
-```bash
-php artisan make:middleware CheckScope
+```php
+Route::get('/private', function () {
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+  ]);
+})->middleware('auth');
 ```
 
-Implement `handle` method to check for an `access_token`, and if it is valid and have the appropriate scope log the user in Laravel authentication system.
+You can also require the provided token to have specific permissions by combining this with Laravel's `can` middleware:
 
 ```php
-// /app/Http/Middleware/CheckScope.php
-
-userRepository = $userRepository;
-    }
-
-    /**
-     * Handle an incoming request.
-     *
-     * @param  \Illuminate\Http\Request  $request
-     * @param  \Closure  $next
-     * @param  \string  $scope
-     * @return mixed
-     */
-    public function handle($request, Closure $next, $scope)
-    {
-        $auth0 = \App::make('auth0');
-
-        $accessToken = $request->bearerToken();
-        try {
-            $tokenInfo = $auth0->decodeJWT($accessToken);
-            $user = $this->userRepository->getUserByDecodedJWT($tokenInfo);
-            if (!$user) {
-                return response()->json(["message" => "Unauthorized user"], 401);
-            }
-
-            if($scope) {
-                $hasScope = false;
-                if(isset($tokenInfo->scope)) {
-                    $scopes = explode(" ", $tokenInfo->scope);
-                    foreach ($scopes as $s) {
-                        if ($s === $scope)
-                            $hasScope = true;
-                    }
-                }
-                if(!$hasScope)
-                    return response()->json(["message" => "Insufficient scope"], 403);
-
-                \Auth::login($user);
-            }
-        } catch (CoreException $e) {
-            return response()->json(["message" => $e->getMessage()], 401);
-        } catch (InvalidTokenException $e) {
-            return response()->json(["message" => $e->getMessage()], 401);
-        }
-
-        return $next($request);
-    }
-}
+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');
 ```
 
-Assign the middleware to specific routes like the previous one.
+## Token Information
 
-```php
-// /app/Http/Kernel.php
+Information about the provided access token is available through Laravel's `Auth` Facade, or the `auth()` helper function.
 
-protected $routeMiddleware = [
-    // ...
-    'check.scope' => \App\Http\Middleware\CheckScope::class,
-];
-```
-
-Apply the `check.scope` middleware to the route you want to protect.
+For example, to retrieve the user's identifier and email address:
 
 ```php
-// routes/api.php
-
-Route::get('/private-scoped', function (Request $request) {
+Route::get('/', function () {
+  if (! auth()->check()) {
     return response()->json([
-        "message" => "Hello from a private endpoint! You need to have a valid access token and a scope of read:messages to see this."
+      'message' => 'You did not provide a valid token.',
     ]);
-})->middleware('check.scope:read:messages');
+  }
+
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+    'id' => auth()->id(),
+    'token' => auth()?->user()?->getAttributes(),
+  ]);
+});
 ```
 
-This route is now only accessible if an `access_token` with a scope of `read:messages` is included in the `Authorization` header of the incoming request.
+## Retrieve User Information
 
-## Extend the `Auth0UserRepository` Class
+You can retrieve information about the user who created the access token from Auth0 using the Auth0 Management API. The SDK provides a convenient wrapper for this API, accessible through the SDK's `management()` method.
 
-There may be situations where you need to customize the `Auth0UserRepository` class. For example, you may want to use the default `User` model and store the user profile in your database. If you need a more advanced custom solution such as this, you can extend the `Auth0UserRepository` class with your own custom class.
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the Auth0 Dashboards API page, 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.
 
-::: note
-This is an example, the custom class in this scenario will not work unless a database setup has been configured.
-:::
+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.
 
 ```php
-// app/Repository/MyCustomUserRepository.php
+use Auth0\Laravel\Facade\Auth0;
 
-namespace App\Repository;
+Route::get('/me', function () {
+  $user = auth()->id();
+  $profile = cache()->get($user);
 
-use Auth0\Login\Contract\Auth0UserRepository;
+  if (null === $profile) {
+    $endpoint = Auth0::management()->users();
+    $profile = $endpoint->get($user);
+    $profile = Auth0::json($profile);
 
-class MyCustomUserRepository implements Auth0UserRepository {
+    cache()->put($user, $profile, 120);
+  }
 
-    /* This class is used on api authN to fetch the user based on the jwt.*/
-    public function getUserByDecodedJWT($jwt) {
-      /*
-       * The `sub` claim in the token represents the subject of the token
-       * and it is always the `user_id`
-       */
-      $jwt->user_id = $jwt->sub;
+  $name = $profile['name'] ?? 'Unknown';
+  $email = $profile['email'] ?? 'Unknown';
 
-      return $this->upsertUser($jwt);
-    }
+  return response()->json([
+    'name' => $name,
+    'email' => $email,
+  ]);
+})->middleware('auth');
+```
 
-    public function getUserByUserInfo($userInfo) {
-      return $this->upsertUser($userInfo['profile']);
-    }
+::: 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.
+:::
 
-    protected function upsertUser($profile) {
+## Run the Application
 
-      // Note: Requires configured database access
-      $user = User::where("auth0id", $profile->user_id)->first();
+You are now ready to start your Laravel application, so it can accept requests:
 
-      if ($user === null) {
-          // If not, create one
-          $user = new User();
-          $user->email = $profile->email; // you should ask for the email scope
-          $user->auth0id = $profile->user_id;
-          $user->name = $profile->name; // you should ask for the name scope
-          $user->save();
-      }
+```shell
+php artisan serve
+```
 
-      return $user;
-    }
+## Retrieve a Test Token
 
-    public function getUserByIdentifier($identifier) {
-        //Get the user info of the user logged in (probably in session)
-        $user = \App::make('auth0')->getUser();
+You can learn more about retrieving access tokens here. For this quickstart, however, you can simply use an access token from your API settings "test" view.
 
-        if ($user === null) return null;
+::: note
+The `/me` route we created above will not work with a test token as there is no actual user associated with it.
+:::
 
-        // build the user
-        $user = $this->getUserByUserInfo($user);
+## Checkpoint
 
-        // it is not the same user as logged in, it is not valid
-        if ($user && $user->auth0id == $identifier) {
-            return $user;
-        }
-    }
+Open a shell and try issuing requests to your application.
 
-}
-```
+Begin by requesting the public route:
 
-With your custom class in place, change the binding in the `AppServiceProvider`.
+```shell
+curl --request GET \
+  --url http://localhost:8000/api \
+  --header 'Accept: application/json'
+```
 
-```php
-// app/Providers/AppServiceProvider.php
+Next, use your access token in an `Authorization` header to request a protected route:
 
-// ...
-public function register()
-{
+```shell
+curl --request GET \
+  --url http://localhost:8000/api/private \
+  --header 'Accept: application/json' \
+  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
+```
 
-    $this->app->bind(
-        \Auth0\Login\Contract\Auth0UserRepository::class, 
-        \App\Repository\MyCustomUserRepository::class 
-    );
+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'
 ```
 
-## Optional Steps
+If you have any issues, here are a couple of things to try:
 
-### Configure CORS
+- 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.
 
-To configure CORS, you should add the `laravel-cors` dependency. You can [check it out here](https://github.com/barryvdh/laravel-cors).
+Encountering problems? Check the SDK's documentation or our documentation hub. You should also consider visiting the community where our team and other community members can help answer your questions.
 
-After installation, add the following to the configuration file for `CORS`:
+### Additional Reading
 
-```php
-'defaults' => array(
-    'supportsCredentials' => false,
-    'allowedOrigins' => array(),
-    'allowedHeaders' => array(),
-    'allowedMethods' => array(),
-    'exposedHeaders' => array(),
-    'maxAge' => 0,
-    'hosts' => array(),
-),
-
-'paths' => array(
-    '*' => array(
-        'allowedOrigins' => array('*'),
-        'allowedHeaders' => array('Content-Type', 'Authorization', 'Accept'),
-        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE')
-    ),
-),
-```
+- User Repositories and Models extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- Hooking Events covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- Management API support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/articles/quickstart/backend/laravel/02-using.md b/articles/quickstart/backend/laravel/02-using.md
deleted file mode 100644
index 793ece84e6..0000000000
--- a/articles/quickstart/backend/laravel/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %> 
diff --git a/articles/quickstart/backend/laravel/download.md b/articles/quickstart/backend/laravel/download.md
new file mode 100644
index 0000000000..e149badf02
--- /dev/null
+++ b/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/articles/quickstart/backend/laravel/files/api.md b/articles/quickstart/backend/laravel/files/api.md
new file mode 100644
index 0000000000..3fe3a4e6b3
--- /dev/null
+++ b/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/articles/quickstart/backend/laravel/files/routes/api.md b/articles/quickstart/backend/laravel/files/routes/api.md
new file mode 100644
index 0000000000..a966bef3c4
--- /dev/null
+++ b/articles/quickstart/backend/laravel/files/routes/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/articles/quickstart/backend/laravel/index.yml b/articles/quickstart/backend/laravel/index.yml
index 517f554c0f..34db441699 100644
--- a/articles/quickstart/backend/laravel/index.yml
+++ b/articles/quickstart/backend/laravel/index.yml
@@ -1,5 +1,7 @@
 title: Laravel API
-thirdParty: false
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: laravel
 alias:
   - laravel
 languages:
@@ -7,17 +9,28 @@ languages:
 framework:
   - Laravel
 author:
-  name: Josh Cunningham
-  email: josh.cunningham@auth0.com
+  name: Evan Sims
+  email: evan.sims@auth0.com
   community: false
-image: /media/platforms/php.png
-tags:
+topics:
   - quickstart
-snippets:
-  dependencies: server-apis/php-laravel/dependencies
-  setup: server-apis/php-laravel/setup
-  use: server-apis/php-laravel/use
-  request: server-apis/php-laravel/request
+contentType: tutorial
+useCase: quickstart
 articles:
   - 01-authorization
-  - 02-using
\ No newline at end of file
+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/articles/quickstart/backend/laravel/interactive.md b/articles/quickstart/backend/laravel/interactive.md
new file mode 100644
index 0000000000..b49f6875e9
--- /dev/null
+++ b/articles/quickstart/backend/laravel/interactive.md
@@ -0,0 +1,225 @@
+---
+title: Add Authorization to Your Laravel Application
+description: This guide demonstrates how to integrate Auth0 with a new (or existing) Laravel 9 or 10 application.
+interactive:  true
+files:
+ - files/routes/api
+github:
+  path: sample
+locale: en-US
+---
+
+# Add Authorization to Your Laravel Application
+
+
+
        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.
        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 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 or native or mobile apps (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 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, 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:
        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:
        cd auth0-laravel-api
+
+
        
+
+
        
+
+## SDK Installation
+
+
+
        Run the following command within your project directory to install the Auth0 Laravel SDK:
        composer require auth0/login:^7.8 --update-with-all-dependencies
+
+
        
+
+
        Then generate an SDK configuration file for your application:
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## SDK Configuration
+
+
+
        Run the following command from your project directory to download the Auth0 CLI:
        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:
        ./auth0 login
+
+
        
+
+
        Next, create a new application with Auth0:
        ./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:
        ./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:
        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.
        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:
        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 by combining this with Laravel's can middleware:
        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:
        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. 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, 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.
        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');
+
+
        
+
+
        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:
        php artisan serve
+
+
        
+
+
        
+
+## Retrieve a Test Token
+
+
+
        You can learn more about retrieving access tokens here. For this quickstart, however, you can simply use an access token from your API settings' "test" view.
        The /me route we created above will not work with a test token as there is no actual user associated with it.
        Laravel Quickstart Step 8 Checkpoint 
        Open a shell and try issuing requests to your application.
        Begin by requesting the public route:
        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:
        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:
        curl --request GET \ --url http://localhost:8000/api/scope \ --header 'Accept: application/json' \ --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
        
+
+  
        
+
+  
        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.
        Encountering problems? Check the SDK's documentation or our documentation hub. You should also consider visiting the community where our team and other community members can help answer your questions.
        
+
+  
        Additional Reading
        • User Repositories and Models extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
        • Hooking Events covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
        • Management API support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
        
diff --git a/articles/quickstart/backend/nginx/01-authorization.md b/articles/quickstart/backend/nginx/01-authorization.md
index 84bc320e7f..c58d60e8a6 100644
--- a/articles/quickstart/backend/nginx/01-authorization.md
+++ b/articles/quickstart/backend/nginx/01-authorization.md
@@ -1,6 +1,12 @@
 ---
 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
@@ -12,11 +18,11 @@ This tutorial and seed project have been tested with the following:
 
 ## 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.
+The `nginx-jwt` script is a Lua script that is designed to run on Nginx servers that have the HttpLuaModule installed. But ultimately its dependencies require components available in the OpenResty 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. Download the latest archive package from 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:
+1. Specify this directory's path using ngx_lua's lua_package_path directive:
 
 ```lua
 # nginx.conf:
@@ -40,7 +46,7 @@ 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):
+Now, secure one or more locations that point to your backing service endpoints by using the access_by_lua directive to call the `nginx-jwt` script's `auth()` function before executing any proxy_* directives:
 
 
 ```lua
@@ -58,12 +64,12 @@ server {
 }
 ```
 
-Click [here](https://github.com/auth0/nginx-jwt#usage) for more usage examples.
+Click here 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.
+You can now make requests against your secure API by providing the Authorization header in your requests with a valid JWT ID Token.
 
 ```har
 {
@@ -73,4 +79,4 @@ You can now make requests against your secure API by providing the Authorization
     { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
   ]
 }
-```
\ No newline at end of file
+```
diff --git a/articles/quickstart/backend/nodejs/01-authorization.md b/articles/quickstart/backend/nodejs/01-authorization.md
index 71bfbf783d..cb772ba3ea 100644
--- a/articles/quickstart/backend/nodejs/01-authorization.md
+++ b/articles/quickstart/backend/nodejs/01-authorization.md
@@ -1,86 +1,59 @@
 ---
 title: Authorization
-description: This tutorial demonstrates how to add authentication and authorization to an Express.js API
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-express-api-samples',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'express.js 4.4.0',
-    'express-jwt 5.1.0',
-    'express-jwt-authz 1.0.0'
-  ]
-}) %>
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
-<%= include('../_includes/_api_create_new') %>
+<%= 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') %>
 
-This guide shows you how to validate the token using the jwt-express middleware and how to check for appropriate scopes with the express-jwt-authz middleware. If the token is not valid or does not have the required scopes, the user gets a 401 Authorization error when they try to access the endpoints.
-
-## Install the Dependencies
+## Validate Access Tokens
 
-To verify incoming JWTs, you can use the [express-jwt](https://github.com/auth0/express-jwt) package.
+### Install dependencies
 
-To get your Auth0 public key and complete the verification process, you can use the [jwks-rsa](https://github.com/auth0/node-jwks-rsa) library with the package. 
+This guide shows you how to protect an Express API using the express-oauth2-jwt-bearer middleware. 
 
-To add the authorization middleware to your endpoints, you can use the [express-jwt-authz](https://github.com/auth0/express-jwt-authz) library.
-
-Install these libraries with npm.
+First install the SDK using npm.
 
 ```bash
-npm install --save express-jwt jwks-rsa express-jwt-authz
+npm install --save express-oauth2-jwt-bearer
 ```
+### Configure the middleware
 
-## Configure the Middleware
-
-<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-express-api-samples/tree/master/02-Authorization-HS256' }) %>
-
-Configure the express-jwt middleware so it uses the remote JWKS for your Auth0 account.
+Configure `express-oauth2-jwt-bearer` with your Domain and API Identifier.
 
 ```js
 // server.js
 
 const express = require('express');
 const app = express();
-const jwt = require('express-jwt');
-const jwtAuthz = require('express-jwt-authz');
-const jwksRsa = require('jwks-rsa');
-
-// Authentication middleware. When used, the
-// Access Token must exist and be verified against
-// the Auth0 JSON Web Key Set
-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.
+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}',
-  issuer: `https://${account.namespace}/`,
-  algorithms: ['RS256']
+  issuerBaseURL: `https://${account.namespace}/`,
 });
 ```
 
-## Configure the Scopes
-
-The `checkJwt` middleware shown above checks if the user's Access Token included in the request is valid. The middleware doesn't check if the token has the sufficient scope to access the requested resources.
+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.
 
-<%= include('../_includes/_api_scopes_access_resources') %>
+## Protect API Endpoints
 
-## Protect Individual Endpoints
+<%= include('../_includes/_api_endpoints') %>
 
-To protect an individual route that requires a valid JWT, configure the route with the `checkJwt` express-jwt middleware.
+To protect an individual route that requires a valid JWT, configure the route with the `checkJwt` `express-oauth2-jwt-bearer` middleware.
 
 ```js
 // server.js
@@ -92,7 +65,7 @@ app.get('/api/public', function(req, res) {
   });
 });
 
-// This route need authentication
+// 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.'
@@ -100,14 +73,15 @@ app.get('/api/private', checkJwt, function(req, res) {
 });
 ```
 
-You can configure individual routes to look for a particular scope. To achieve that, set up another middleware with the express-jwt-authz package. Provide an array of the required scopes and apply the middleware to any routes you want to add authorization to.
+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 `checkScopes` middlewares to the route you want to protect.
+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 = jwtAuthz([ 'read:messages' ]);
+const checkScopes = requiredScopes('read:messages');
 
 app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) {
   res.json({
@@ -116,4 +90,4 @@ app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) {
 });
 ```
 
-In this configuration, only the Access Tokens with the `read:messages` scope can access the endpoint.
+In this configuration, only Access Tokens with the `read:messages` scope can access the endpoint.
diff --git a/articles/quickstart/backend/nodejs/02-using.md b/articles/quickstart/backend/nodejs/02-using.md
index 793ece84e6..d7c9301b35 100644
--- a/articles/quickstart/backend/nodejs/02-using.md
+++ b/articles/quickstart/backend/nodejs/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/nodejs/03-troubleshooting.md b/articles/quickstart/backend/nodejs/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/nodejs/download.md b/articles/quickstart/backend/nodejs/download.md
new file mode 100644
index 0000000000..bbb58794cd
--- /dev/null
+++ b/articles/quickstart/backend/nodejs/download.md
@@ -0,0 +1,15 @@
+To run the example you need Node.JS LTS installed, and to run the following commands:
+
+```bash
+npm install
+npm start
+```
+
+The sample includes a Docker 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/articles/quickstart/backend/nodejs/files/server.md b/articles/quickstart/backend/nodejs/files/server.md
new file mode 100644
index 0000000000..4f8b8f5734
--- /dev/null
+++ b/articles/quickstart/backend/nodejs/files/server.md
@@ -0,0 +1,43 @@
+---
+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/articles/quickstart/backend/nodejs/index.yml b/articles/quickstart/backend/nodejs/index.yml
index c5c923e1ef..dd58dfd65c 100644
--- a/articles/quickstart/backend/nodejs/index.yml
+++ b/articles/quickstart/backend/nodejs/index.yml
@@ -1,4 +1,7 @@
 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
@@ -7,9 +10,14 @@ alias:
   - express
 languages:
   - Javascript
-image: /media/platforms/node.png
-tags:
+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
@@ -17,3 +25,32 @@ snippets:
 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/articles/quickstart/backend/nodejs/interactive.md b/articles/quickstart/backend/nodejs/interactive.md
new file mode 100644
index 0000000000..2ea62bdfea
--- /dev/null
+++ b/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,317 @@
+---
+title: Add Authorization to Your Express.js API Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Express.js API application using the express-oauth2-jwt-bearer package.
+interactive:  true
+files:
+ - files/server
+github:
+  path: 01-Authorization-RS256
+locale: en-US
+---
+
+# 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. Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section.
        This example uses the read:messages scope.
        
+
+## Install dependencies
+
+
+
        First, install the SDK with npm.
        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.
        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.
        Provide the Access Token as an Authorization header in your requests.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http:///%7ByourDomain%7D/api_path \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///%7ByourDomain%7D/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///%7ByourDomain%7D/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///%7ByourDomain%7D/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///%7ByourDomain%7D/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///%7ByourDomain%7D/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///%7ByourDomain%7D/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "%7ByourDomain%7D/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///%7ByourDomain%7D/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///%7ByourDomain%7D/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Node JS API Step 4 Checkpoint 
        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.
        
+
+  
        
+
+  
        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.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/backend/php/01-authentication.md b/articles/quickstart/backend/php/01-authentication.md
deleted file mode 100644
index 6aaccba5c9..0000000000
--- a/articles/quickstart/backend/php/01-authentication.md
+++ /dev/null
@@ -1,232 +0,0 @@
----
-title: Authentication
-description: This tutorial demonstrates how to add authentication and authorization to a PHP API
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-php-api-samples',
-  path: '01-Authenticate-RS256',
-  requirements: [
-    'PHP v5',
-    'Composer 1.0',
-  ]
-}) %>
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid. The validity check is done in the `JWTVerifier` class from the **auth0-PHP** library 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.
-
-## Install the Dependencies
-
-The **auth0-PHP** library and its `JWTVerifier` class can be used to verify incoming JWTs. The **router** library can be used to create simple routes. Install the libraries with **composer**.
-
-```bash
-composer require bramus/router:dev-master auth0/auth0-php:~5.0
-```
-
-## Configuration
-
-<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-php-api-samples/tree/master/02-Authenticate-HS256' }) %>
-
-Create an instance of `JWTVerifier` and pass your API identifier to `valid_audiences` and your Auth0 domain to `authorized_iss`. You can also create a function which will be called to return a message when a request is made to a protected endpoint.
-
-```php
-// src/Main.php
-
- ['RS256'],
-        'valid_audiences' => ['${apiIdentifier}'],
-        'authorized_iss' => ['https://${account.namespace}/']
-      ]);
-
-      $this->token = $token;
-      $this->tokenInfo = $verifier->verifyAndDecode($token);
-    }
-    catch(\Auth0\SDK\Exception\CoreException $e) {
-      throw $e;
-    }
-  }
-
-  // This endpoint doesn't need authentication
-  public function publicEndpoint() {
-    return array(
-      "status" => "ok",
-      "message" => "Hello from a public endpoint! You don't need to be authenticated to see this."
-    );
-  }
-
-  public function privateEndpoint() {
-    return array(
-      "status" => "ok",
-      "message" => "Hello from a private endpoint! You need to be authenticated to see this."
-    );
-  }
-}
-```
-
-## Configure Authenticated Routes
-
-The `before` hook from the **router** package can be used to configure which routes are to be protected. For example, you may wish to protect all routes under a URL of `/api/private`.
-
-```php
-// index.php
-
-// ...
-// Require composer autoloader
-require __DIR__ . '/vendor/autoload.php';
-
-// Read .env
-try {
-  $dotenv = new Dotenv\Dotenv(__DIR__);
-  $dotenv->load();
-} catch(InvalidArgumentException $ex) {
-  // Ignore if no dotenv
-}
-
-$app = new \App\Main();
-
-// Create Router instance
-$router = new \Bramus\Router\Router();
-
-// Activate CORS
-function sendCorsHeaders() {
-  header("Access-Control-Allow-Origin: *");
-  header("Access-Control-Allow-Headers: Authorization");
-  header("Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE");
-}
-
-$router->options('/.*', function() {
-    sendCorsHeaders();
-});
-
-sendCorsHeaders();
-
-// Check JWT on private routes
-$router->before('GET', '/api/private.*', function() use ($app) {
-
-  $requestHeaders = apache_request_headers();
-
-  if (!isset($requestHeaders['authorization']) && !isset($requestHeaders['Authorization'])) {
-    header('HTTP/1.0 401 Unauthorized');
-    header('Content-Type: application/json; charset=utf-8');
-    echo json_encode(array("message" => "No token provided."));
-    exit();
-  }
-
-  $authorizationHeader = isset($requestHeaders['authorization']) ? $requestHeaders['authorization'] : $requestHeaders['Authorization'];
-
-  if ($authorizationHeader == null) {
-    header('HTTP/1.0 401 Unauthorized');
-    header('Content-Type: application/json; charset=utf-8');
-    echo json_encode(array("message" => "No authorization header sent."));
-    exit();
-  }
-
-  $authorizationHeader = str_replace('bearer ', '', $authorizationHeader);
-  $token = str_replace('Bearer ', '', $authorizationHeader);
-
-  try {
-    $app->setCurrentToken($token);
-  }
-  catch(\Auth0\SDK\Exception\CoreException $e) {
-    header('HTTP/1.0 401 Unauthorized');
-    header('Content-Type: application/json; charset=utf-8');
-    echo json_encode(array("message" => $e->getMessage()));
-    exit();
-  }
-});
-```
-
-With this configuration, any time an endpoint which includes `/api/private` is reached, a valid JWT `access_token` will be required before the resource can be released. With this in place, private routes can be defined.
-
-```php
-// index.php
-
-// This route doesn't need authentication
-$router->get('/api/public', function() use ($app){
-  header('Content-Type: application/json; charset=utf-8');
-  echo json_encode($app->publicEndpoint());
-});
-
-$router->get('/api/private', function() use ($app){
-  header('Content-Type: application/json; charset=utf-8');
-  echo json_encode($app->privateEndpoint());
-});
-```
-
-## Configure the Scopes
-
-To add authorization you need to define the method `checkScope` to check for a particular scope in the `access_token`.
-
-```php
-// src/Main.php
-
-//..
-
-public function checkScope($scope){
-  if ($this->tokenInfo){
-    $scopes = explode(" ", $this->tokenInfo->scope);
-    foreach ($scopes as $s){
-      if ($s === $scope)
-        return true;
-    }
-  }
-
-  return false;
-}
-
-// ...
-
-public function privateScopedEndpoint() {
-  return array(
-    "status" => "ok",
-    "message" => "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
-  );
-}
-```
-
-The function `privateScopedEndpoint` will return the message when a request is made from a protected endpoint, and the `access_token` has a scope of `read:messages`.
-
-Add a `before` hook to the router to configure routes that require the scope of `read:messages`.
-
-```php
-// index.php
-
-// Check for read:messages scope
-$router->before('GET', '/api/private-scoped', function() use ($app) {
-  if (!$app->checkScope('read:messages')){
-    header('HTTP/1.0 403 forbidden');
-    header('Content-Type: application/json; charset=utf-8');
-    echo json_encode(array("message" => "Insufficient scope."));
-    exit();
-  }
-});
-
-// ...
-
-$router->get('/api/private-scoped', function() use ($app){
-  header('Content-Type: application/json; charset=utf-8');
-  echo json_encode($app->privateScopedEndpoint());
-});
-```
-
-The route `/api/private-scoped` will be accessible only if has a valid `access_token` with the scope `read:messages`.
diff --git a/articles/quickstart/backend/php/01-authorization.md b/articles/quickstart/backend/php/01-authorization.md
new file mode 100644
index 0000000000..f33c194a93
--- /dev/null
+++ b/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 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 and 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. There's numerous routes you could go for authenticating your users before they hit your backend API for authorization, such as using Auth0s SPA.js library. This approach is demonstrated in this Quickstart app accompanying Github project. 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, which you can plug any compatible caching library into for the SDK to fit in nicely with your architecture.
+
+For our sample, let's use the Symfony caching component 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/articles/quickstart/backend/php/02-using.md b/articles/quickstart/backend/php/02-using.md
index 793ece84e6..6697281ace 100644
--- a/articles/quickstart/backend/php/02-using.md
+++ b/articles/quickstart/backend/php/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/php/03-troubleshooting.md b/articles/quickstart/backend/php/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/php/download.md b/articles/quickstart/backend/php/download.md
new file mode 100644
index 0000000000..ab36580b17
--- /dev/null
+++ b/articles/quickstart/backend/php/download.md
@@ -0,0 +1,11 @@
+To run the sample, make sure PHP and Composer are installed and execute the following commands in the sample's directory:
+
+```bash
+composer run app
+```
+
+You can also run it from Docker with the following commands:
+
+```bash
+composer run docker
+```
diff --git a/articles/quickstart/backend/php/files/index.md b/articles/quickstart/backend/php/files/index.md
new file mode 100644
index 0000000000..5a0ab723f3
--- /dev/null
+++ b/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/articles/quickstart/backend/php/files/router.md b/articles/quickstart/backend/php/files/router.md
new file mode 100644
index 0000000000..73c5831f3c
--- /dev/null
+++ b/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/articles/quickstart/backend/php/index.yml b/articles/quickstart/backend/php/index.yml
index 8ab2c8b8bc..0bac6302ec 100644
--- a/articles/quickstart/backend/php/index.yml
+++ b/articles/quickstart/backend/php/index.yml
@@ -1,20 +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: Josh Cunningham
-  email: josh.cunningham@auth0.com
+  name: Evan Sims
+  email: evan.sims@auth0.com
   community: false
 thirdParty: false
-image: /media/platforms/php.png
-tags:
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 snippets:
-  dependencies: server-apis/php/dependencies
-  setup: server-apis/php/setup
-  use: server-apis/php/use
+  install: server-platforms/php/install
+default_article: 01-authorization
 articles:
-  - 01-authentication
-  - 02-using
+  - 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/articles/quickstart/backend/php/interactive.md b/articles/quickstart/backend/php/interactive.md
new file mode 100644
index 0000000000..be6785019d
--- /dev/null
+++ b/articles/quickstart/backend/php/interactive.md
@@ -0,0 +1,66 @@
+---
+title: Add Authorization to Your PHP Application
+description: This guide demonstrates how to integrate Auth0, add token-based authorization, and protect application routes using the Auth0 PHP SDK.
+interactive:  true
+files:
+ - files/index
+ - files/router
+github:
+  path: app
+locale: en-US
+---
+
+# 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
+
+
+
        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 (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps.
        The Auth0 PHP SDK requires PSR-17 and 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:
        cd <your-project-directory>
+
+    composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        Now, install the Auth0 PHP SDK by running the following command in your terminal:
        composer require auth0/auth0-php
+
+
        
+
+
        Configure the Auth0 SDK
        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, 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.
        PHP API Step 2 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Listen for the 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.
        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.
        
+
+## Configure 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/articles/quickstart/backend/python/01-authorization.md b/articles/quickstart/backend/python/01-authorization.md
index 36b9f68d7b..44b988113b 100644
--- a/articles/quickstart/backend/python/01-authorization.md
+++ b/articles/quickstart/backend/python/01-authorization.md
@@ -1,44 +1,41 @@
 ---
 title: Authorization
-description: This tutorial will show you how to use the Auth0 to add authorization to your Python API.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-python-api-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'python 2.7, 3.3 and up',
-    'flask 0.11.1',
-    'python-jose-cryptodome 1.3.2',
-    'flask-cors 3.0.2',
-    'six 1.10.0'
-  ]
-}) %>
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
 <%= include('../_includes/_api_create_new') %>
 
 <%= include('../_includes/_api_auth_preamble') %>
 
-## Install the Dependencies
+## Validate Access Tokens
+
+### Install dependencies
 
-This quickstart demonstrates how to add authorization to your Python API using [Flask](http://flask.pocoo.org/). Add the following dependencies to your `requirements.txt`:
+ Add the following dependencies to your `requirements.txt`:
 
 ```python
 # /requirements.txt
 
-flask
+flask==2.3.3
 python-dotenv
-python-jose-cryptodome
+pyjwt
 flask-cors
 six
 ```
 
-## Create the Flask APP
+### Create a Flask application
 
-Create a `server.py` file and initializate the Flask App. Set the domain, audience and the error handling.
+Create a `server.py` file and initialize the Flask application. Set the domain, audience and the error handling.
 
 ```python
 # /server.py
@@ -49,7 +46,7 @@ from functools import wraps
 
 from flask import Flask, request, jsonify, _request_ctx_stack
 from flask_cors import cross_origin
-from jose import jwt
+import jwt
 
 AUTH0_DOMAIN = '${account.namespace}'
 API_AUDIENCE = YOUR_API_AUDIENCE
@@ -62,7 +59,7 @@ 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)
@@ -70,11 +67,9 @@ def handle_auth_error(ex):
     return response
 ```
 
-## Create the JWT Validation Decorator
+### Create the JWT validation decorator
 
-<%= include('../_includes/_api_jwks_description_no_link') %>
-
-Add a decorator which verifies the `access_token` against your JWKS.
+Add a decorator which verifies the Access Token against your JWKS.
 
 ```python
 # /server.py
@@ -88,9 +83,9 @@ def get_token_auth_header():
         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":
@@ -117,21 +112,15 @@ def requires_auth(f):
         jsonurl = urlopen("https://"+AUTH0_DOMAIN+"/.well-known/jwks.json")
         jwks = json.loads(jsonurl.read())
         unverified_header = jwt.get_unverified_header(token)
-        rsa_key = {}
+        public_key = None
         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:
+                public_key = jwt.algorithms.RSAAlgorithm.from_jwk(json.dumps(jwk))
+        if public_key:
             try:
                 payload = jwt.decode(
                     token,
-                    rsa_key,
+                    public_key,
                     algorithms=ALGORITHMS,
                     audience=API_AUDIENCE,
                     issuer="https://"+AUTH0_DOMAIN+"/"
@@ -139,11 +128,16 @@ def requires_auth(f):
             except jwt.ExpiredSignatureError:
                 raise AuthError({"code": "token_expired",
                                 "description": "token is expired"}, 401)
-            except jwt.JWTClaimsError:
-                raise AuthError({"code": "invalid_claims",
+            except jwt.InvalidAudienceError:
+                raise AuthError({"code": "invalid_audience",
+                                "description":
+                                    "incorrect audience,"
+                                    " please check the audience"}, 401)
+            except jwt.InvalidIssuerError
+                raise AuthError({"code": "invalid_issuer",
                                 "description":
-                                    "incorrect claims,"
-                                    "please check the audience and issuer"}, 401)
+                                    "incorrect issuer,"
+                                    " please check the issuer"}, 401)
             except Exception:
                 raise AuthError({"code": "invalid_header",
                                 "description":
@@ -157,15 +151,9 @@ def requires_auth(f):
     return decorated
 ```
 
-## Use this Decorator in your Methods
+### Validate scopes
 
-You can now use the decorator in any routes that require authentication.
-
-${snippet(meta.snippets.use)}
-
-## Protect individual endpoints
-
-Individual routes can be configured to look for a particular `scope` in the `access_token` by using the following:
+Individual routes can be configured to look for a particular `scope` in the Access Token by using the following:
 
 ```python
 # /server.py
@@ -176,7 +164,7 @@ def requires_scope(required_scope):
         required_scope (str): The scope required to access the resource
     """
     token = get_token_auth_header()
-    unverified_claims = jwt.get_unverified_claims(token)
+    unverified_claims = jwt.decode(token, options={"verify_signature": False})
     if unverified_claims.get("scope"):
             token_scopes = unverified_claims["scope"].split()
             for token_scope in token_scopes:
@@ -185,23 +173,10 @@ def requires_scope(required_scope):
     return False
 ```
 
-Then, establish what scopes are needed in order to access the route. In this case `read:messages` is used:
+## Protect API Endpoints
 
-```python
-# /server.py
+<%= include('../_includes/_api_endpoints') %>
 
-@APP.route("/api/private-scoped")
-@cross_origin(headers=["Content-Type", "Authorization"])
-@cross_origin(headers=["Access-Control-Allow-Origin", "*"])
-@requires_auth
-def private_scoped():
-    """A valid Access Token and an appropriate scope are required to access this route
-    """
-    if requires_scope("read:messages"):
-        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)
-    raise AuthError({
-        "code": "Unauthorized",
-        "description": "You don't have access to this resource."
-    }, 403)
-```
+You can use the decorators and functions define above in the corresponding endpoints.
+
+${snippet(meta.snippets.use)}
diff --git a/articles/quickstart/backend/python/02-using.md b/articles/quickstart/backend/python/02-using.md
index a39e59237b..776d13c743 100644
--- a/articles/quickstart/backend/python/02-using.md
+++ b/articles/quickstart/backend/python/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/python/03-troubleshooting.md b/articles/quickstart/backend/python/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/python/download.md b/articles/quickstart/backend/python/download.md
new file mode 100644
index 0000000000..07303e40ac
--- /dev/null
+++ b/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 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/articles/quickstart/backend/python/files/server.md b/articles/quickstart/backend/python/files/server.md
new file mode 100644
index 0000000000..7d7c5c8bc9
--- /dev/null
+++ b/articles/quickstart/backend/python/files/server.md
@@ -0,0 +1,55 @@
+---
+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/articles/quickstart/backend/python/files/validator.md b/articles/quickstart/backend/python/files/validator.md
new file mode 100644
index 0000000000..bda3edb8ca
--- /dev/null
+++ b/articles/quickstart/backend/python/files/validator.md
@@ -0,0 +1,28 @@
+---
+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/articles/quickstart/backend/python/index.yml b/articles/quickstart/backend/python/index.yml
index c7fc616c0d..765d5a3e18 100644
--- a/articles/quickstart/backend/python/index.yml
+++ b/articles/quickstart/backend/python/index.yml
@@ -1,16 +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
-image: /media/platforms/python.png
-tags:
+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
\ No newline at end of file
+  - 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/articles/quickstart/backend/python/interactive.md b/articles/quickstart/backend/python/interactive.md
new file mode 100644
index 0000000000..d749585840
--- /dev/null
+++ b/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,318 @@
+---
+title: Add Authorization to Your Flask API Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Python API built with Flask.
+interactive:  true
+files:
+ - files/validator
+ - files/server
+github:
+  path: 00-Starter-Seed
+locale: en-US
+---
+
+# Add Authorization to Your Flask API Application
+
+
+
        This guide demonstrates how to integrate Auth0 with any new or existing Python API built with Flask.
        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 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.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        This example uses the read:messages scope.
        
+
+## Install dependencies
+
+
+
        Add the following dependencies to your requirements.txt:
        # /requirements.txt
+
+
+
+    flask
+
+    Authlib
+
+
        
+
+
        
+
+## Create the JWT validator {{{ data-action="code" data-code="validator.py" }}}
+
+
+
        We're going to use a library called Authlib to create a ResourceProtector, which is a type of Flask decorator 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.
        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.
        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.
        Auth0 Dashboard> Applications > API > [Specific API] > Test tab
        Provide the Access Token as an Authorization header in your requests.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
diff --git a/articles/quickstart/backend/rails/01-authorization.md b/articles/quickstart/backend/rails/01-authorization.md
index 3021f20360..4fe7330120 100644
--- a/articles/quickstart/backend/rails/01-authorization.md
+++ b/articles/quickstart/backend/rails/01-authorization.md
@@ -1,199 +1,285 @@
 ---
-title: Authentication
-description: This tutorial demonstrates how to add authentication to Ruby on Rails API
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-api-samples',
-  path: '01-Authentication-RS256',
-  requirements: [
-    'Ruby 2.1.8',
-    'Rails 4.2.5.1'
-  ]
-}) %>
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
-<%= include('../_includes/_api_create_new') %>
+<%= 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') %>
 
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid. The validity check is done using the **jwt** Gem within a custom `JsonWebToken` class. A Concern called `Secured` is used to mark endpoints which require authentication through an incoming `access_token`. If the token is valid, the resources which are served by the endpoint can be released, otherwise a `401 Authorization` error will be returned.
+## Validate Access Tokens
+
+### Install dependencies
 
-## Install the Dependencies
+This tutorial performs access token validation using the **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`
+gem 'jwt'
 bundle install
 ```
 
-## Create a JsonWebToken Class
-
-<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-rubyonrails-api-samples/tree/OIDC/02-Authentication-HS256' }) %>
+### Create an Auth0Client class
 
-Create a class called `JsonWebToken` 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.
+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
-# lib/json_web_token.rb
+# app/lib/auth0_client.rb
 
 # frozen_string_literal: true
+
+require 'jwt'
 require 'net/http'
-require 'uri'
-
-class JsonWebToken
-  def self.verify(token)
-    JWT.decode(token, nil,
-               true, # Verify the signature of this token
-               algorithm: 'RS256',
-               iss: 'https://${account.namespace}/',
-               verify_iss: true,
-               aud: Rails.application.secrets.auth0_api_audience,
-               verify_aud: true) do |header|
-      jwks_hash[header['kid']]
-    end
+
+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.jwks_hash
-    jwks_raw = Net::HTTP.get URI("https://${account.namespace}/.well-known/jwks.json")
-    jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
-    Hash[
-      jwks_keys
-      .map do |k|
-        [
-          k['kid'],
-          OpenSSL::X509::Certificate.new(
-            Base64.decode64(k['x5c'].first)
-          ).public_key
-        ]
-      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
+### 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 `JsonWebToken.verify`.
+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
 
-  included do
-    before_action :authenticate_request!
+  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 authenticate_request!
-    auth_token
-  rescue JWT::VerificationError, JWT::DecodeError
-    render json: { errors: ['Not Authenticated'] }, status: :unauthorized
-  end
+  def token_from_request
+    authorization_header_elements = request.headers['Authorization']&.split
+
+    render json: REQUIRES_AUTHENTICATION, status: :unauthorized and return unless authorization_header_elements
 
-  def http_token
-    if request.headers['Authorization'].present?
-      request.headers['Authorization'].split(' ').last
+    unless authorization_header_elements.length == 2
+      render json: MALFORMED_AUTHORIZATION_HEADER, status: :unauthorized and return
     end
-  end
 
-  def auth_token
-    JsonWebToken.verify(http_token)
+    scheme, token = authorization_header_elements
+
+    render json: BAD_CREDENTIALS, status: :unauthorized and return unless scheme.downcase == 'bearer'
+
+    token
   end
 end
 ```
 
-## Apply Authentication to Routes
+### Validate scopes
 
-With the `Secured` Concern in place, you can now apply it to whichever endpoints you wish to protect. Applying the Concern means that a valid `access_token` **must** be present in the request before the resource can be released.
+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.
 
-```rb
-# app/controllers/public_controller.rb
+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
-class PublicController < ActionController::API
-  # This route doesn't need authentication
-  def public
-    render json: { message: 'Hello from a public endpoint! You don't need to be authenticated to see this.' }
+
+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
-end
-```
 
-```rb
-# app/controllers/private_controller.rb
+  # ... 
 
-# frozen_string_literal: true
-class PrivateController < ActionController::API
-  include Secured
+  # Token Validation 
+  def self.validate_token(token)
+    jwks_response = get_jwks
 
-  def private
-    render json: 'Hello from a private endpoint! You need to be authenticated to see this.'
+    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
 ```
 
-## Configure Scopes
+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. 
 
-The `JsonWebToken.verify` 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.
+Apply these changes in your `Secured` concern by adding the following code: 
 
-Scopes provide a way for you to define which resources should be accessible by the user holding a given `access_token`. For example, you might choose to permit `read` access to a `messages` resource if a user has a **manager** access level, or a `write` access to that resource if they are an **administrator**.
+```rb
+# app/controllers/concerns/secured.rb
 
-To configure scopes in your Auth0 dashboard, navigate to [your API](${manage_url}/#/apis) and choose the **Scopes** tab. In this area you can apply any scopes you wish, including one called `read:messages`, which will be used in this example.
+# frozen_string_literal: true
 
-## Protect Individual Endpoints
+module Secured
+  extend ActiveSupport::Concern
 
-To look for a particular `scope` in an `access_token`, provide an array of required scopes and check if they are present in the payload of the token.
+  # ... 
 
-In this example the `SCOPES` array for the given key `/private-scoped` is intersected with the scopes coming in the payload, to determine if it contains one or more items from the other array.
+  INSUFFICIENT_PERMISSIONS = {
+    error: 'insufficient_permissions',
+    error_description: 'The access token does not contain the required permissions',
+    message: 'Permission denied'
+  }.freeze
 
-```rb
-# app/controllers/private_controller.rb
+  def authorize
+    token = token_from_request
 
-# frozen_string_literal: true
-class PrivateController < ActionController::API
-  include Secured
+    return if performed?
 
-  # ...
+    validation_response = Auth0Client.validate_token(token)
 
-  def private_scoped
-    render json: { message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' }
+    @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
 ```
 
-```rb
-# app/controllers/concerns/secured.rb
+## Protect API Endpoints
 
-  SCOPES = {
-    '/private' => nil,
-    '/private-scoped'    => ['read:messages']
-  }
+<%= include('../_includes/_api_endpoints') %>
 
-  private
+Add the `Secured` concern to the `ApplicationController`: 
+
+```ruby
+class ApplicationController < ActionController::API
+  include Secured
+end
+```
+
+You only ned to protect the `PrivateController` as follows:
 
-  def authenticate_request!
-    @auth_payload, @auth_header = auth_token
+```ruby
+class PrivateController < ApplicationController
+  before_action :authorize
 
-    render json: { errors: ['Insufficient scope'] }, status: :unauthorized unless scope_included
-  rescue JWT::VerificationError, JWT::DecodeError
-    render json: { errors: ['Not Authenticated'] }, status: :unauthorized
+  # ...
+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 scope_included
-    if SCOPES[request.env['PATH_INFO']] == nil
-      true
-    else
-      # The intersection of the scopes included in the given JWT and the ones in the SCOPES hash needed to access
-      # the PATH_INFO, should contain at least one element
-      (String(@auth_payload['scope']).split(' ') & (SCOPES[request.env['PATH_INFO']])).any?
+  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
-```
-
-With this configuration in place, only `access_token`s which have a scope of `read:messages` will be allowed to access this endpoint.
+end
+```
\ No newline at end of file
diff --git a/articles/quickstart/backend/rails/02-using.md b/articles/quickstart/backend/rails/02-using.md
index a39e59237b..ea41ac4cc4 100644
--- a/articles/quickstart/backend/rails/02-using.md
+++ b/articles/quickstart/backend/rails/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/rails/03-troubleshooting.md b/articles/quickstart/backend/rails/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/download.md b/articles/quickstart/backend/rails/download.md
new file mode 100644
index 0000000000..5ff8b4ddfb
--- /dev/null
+++ b/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 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/articles/quickstart/backend/rails/files/app/controllers/application_controller.md b/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
new file mode 100644
index 0000000000..75520386ba
--- /dev/null
+++ b/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
@@ -0,0 +1,12 @@
+---
+name: app/controllers/application_controller.rb
+language: powershell
+---
+    
+```powershell
+    # frozen_string_literal: true
+
+    class ApplicationController < ActionController::API
+      include Secured
+    end
+```
diff --git a/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md b/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
new file mode 100644
index 0000000000..c6529ef19b
--- /dev/null
+++ b/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
@@ -0,0 +1,67 @@
+---
+name: app/controllers/concerns/secured.rb
+language: powershell
+---
+    
+```powershell
+    # 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/articles/quickstart/backend/rails/files/app/controllers/private_controller.md b/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
new file mode 100644
index 0000000000..336740f6cd
--- /dev/null
+++ b/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/private_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/articles/quickstart/backend/rails/files/app/controllers/public_controller.md b/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
new file mode 100644
index 0000000000..f8a6db5aff
--- /dev/null
+++ b/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/public_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/articles/quickstart/backend/rails/files/app/lib/auth0_client.md b/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
new file mode 100644
index 0000000000..079089b4d9
--- /dev/null
+++ b/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
@@ -0,0 +1,66 @@
+---
+name: app/lib/auth0_client.rb
+language: powershell
+---
+    
+```powershell
+    # 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
+```
diff --git a/articles/quickstart/backend/rails/files/application_controller.md b/articles/quickstart/backend/rails/files/application_controller.md
new file mode 100644
index 0000000000..6b31483dfc
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/files/auth0_client.md b/articles/quickstart/backend/rails/files/auth0_client.md
new file mode 100644
index 0000000000..a57b2c9b36
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/files/private.md b/articles/quickstart/backend/rails/files/private.md
new file mode 100644
index 0000000000..65d1d14f24
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/files/public.md b/articles/quickstart/backend/rails/files/public.md
new file mode 100644
index 0000000000..841a3118a1
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/files/secured.md b/articles/quickstart/backend/rails/files/secured.md
new file mode 100644
index 0000000000..b89e6bc2a0
--- /dev/null
+++ b/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/articles/quickstart/backend/rails/index.yml b/articles/quickstart/backend/rails/index.yml
index 8fc0b8aff9..0c802dd929 100644
--- a/articles/quickstart/backend/rails/index.yml
+++ b/articles/quickstart/backend/rails/index.yml
@@ -1,4 +1,7 @@
 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
@@ -6,10 +9,15 @@ languages:
   - Ruby
 framework:
   - Ruby on Rails
+author:
+  name: Josh Cunningham
+  email: josh.cunningham@auth0.com
+  community: false
 thirdParty: false
-image: /media/platforms/rails.png
-tags:
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 snippets:
   dependencies: server-apis/rails/dependencies
   setup: server-apis/rails/setup
@@ -17,3 +25,33 @@ snippets:
 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/articles/quickstart/backend/rails/interactive.md b/articles/quickstart/backend/rails/interactive.md
new file mode 100644
index 0000000000..10f2d93d6d
--- /dev/null
+++ b/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,338 @@
+---
+title: Add Authorization to Your Ruby on Rails API
+description: This tutorial performs access token validation using the jwt Gem within a custom Auth0Client class.
+interactive:  true
+files:
+ - files/app/controllers/application_controller
+ - files/app/lib/auth0_client
+ - files/app/controllers/concerns/secured
+ - files/app/controllers/public_controller
+ - files/app/controllers/private_controller
+github:
+  path: 01-Authentication-RS256
+locale: en-US
+---
+
+# Add Authorization to Your Ruby on Rails API
+
+
+
        This tutorial performs access token validation using the 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.
        Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        This example uses the read:messages scope.
        
+
+## Install dependencies
+
+
+
        Install the jwt Gem.
        gem 'jwt'
+
+    bundle install
+
+
        
+
+ 
        
+
+## Create an Auth0Client class {{{ data-action="code" data-code="app/controllers/concerns/secured.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.
        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.
        Auth0 Dashboard> Applications > API > [Specific API] > Test tab
        Provide the Access Token as an Authorization header in your requests.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Ruby on rails Step 7 Checkpoint 
        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.
        
+
+  
        
+
+  
        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.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/backend/relay/01-authentication.md b/articles/quickstart/backend/relay/01-authentication.md
deleted file mode 100644
index 4ba21a571d..0000000000
--- a/articles/quickstart/backend/relay/01-authentication.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Authentication
-description: This tutorial will show you how to use Auth0 to add authentication to your Relay API.
----
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-## Add the Dependencies
-
-Add **express-jwt** and **express-graphql** as dependencies.
-
-${snippet(meta.snippets.dependencies)}
-
-## Configuration
-
-<%= include('../_includes/_api_jwks_description_no_link') %>
-
-Configure the **express-jwt** middleware to use the remote JWKS for your Auth0 account.
-
-${snippet(meta.snippets.setup)}
-
-## Secure your API
-
-In your Relay app, you serve a GraphQL object from a single endpoint, which is typically at `/graphql`. You can protect this endpoint globally with the `express-jwt` middleware.
-
-${snippet(meta.snippets.use)}
-
-## Send an Access Token from your Front End
-
-When you send a request to the GraphQL endpoint, you need to include the user's `access_token` as an `Authorization` header. This can be done by tapping into Relay's network layer and extending requests to include a header.
-
-${snippet(meta.snippets.frontend)}
diff --git a/articles/quickstart/backend/relay/index.yml b/articles/quickstart/backend/relay/index.yml
deleted file mode 100644
index bc03cd9e76..0000000000
--- a/articles/quickstart/backend/relay/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: Relay API
-thirdParty: false
-author:
-  community: true
-alias:
-  - relay
-languages:
-  - Javascript
-image: /media/platforms/relay.svg
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/relay/dependencies
-  setup: server-apis/relay/setup
-  use: server-apis/relay/use
-  frontend: server-apis/relay/frontend
-articles:
-  - 01-authentication
diff --git a/articles/quickstart/backend/ruby/01-authorization.md b/articles/quickstart/backend/ruby/01-authorization.md
deleted file mode 100644
index 182b9d6909..0000000000
--- a/articles/quickstart/backend/ruby/01-authorization.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authentication and authorization to Ruby API
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-ruby-api-samples',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'Ruby 2.3.0'
-  ]
-}) %>
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid. The validity check is done using the **jwt** Gem within a custom `JsonWebToken` class. An `authenticate!` method is used to mark endpoints which require authentication through an incoming `access_token`. If the token is valid, the resources which are served by the endpoint can be released, otherwise a `401 Authorization` error will be returned.
-
-## Install the Dependencies
-
-Install the **jwt** Gem.
-
-```bash
-gem `jwt`
-bundle install
-```
-
-## Create a `JsonWebToken` Class
-
-Create a class called `JsonWebToken` which decodes and verifies the incoming `access_token` token from the `Authorization` header of the request. The public key for your Auth0 tenant can be fetched to verify the token.
-
-```rb
-# lib/jwt/json_web_token.rb
-
-# frozen_string_literal: true
-require 'net/http'
-require 'uri'
-
-class JsonWebToken
-  def self.verify(token)
-    JWT.decode(token, nil,
-               true, # Verify the signature of this token
-               algorithm: 'RS256',
-               iss: 'https://${account.namespace}/',
-               verify_iss: true,
-               # auth0_api_audience is the identifier for the API set up in the Auth0 dashboard
-               aud: auth0_api_audience,
-               verify_aud: true) do |header|
-      jwks_hash[header['kid']]
-    end
-  end
-
-  def self.jwks_hash
-    jwks_raw = Net::HTTP.get URI("https://${account.namespace}/.well-known/jwks.json")
-    jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
-    Hash[
-      jwks_keys
-      .map do |k|
-        [
-          k['kid'],
-          OpenSSL::X509::Certificate.new(
-            Base64.decode64(k['x5c'].first)
-          ).public_key
-        ]
-      end
-    ]
-  end
-end
-```
-
-## Define an `authenticate!` method
-
-Create an `authenticate!` method to run before each endpoint which looks for the `access_token` in the `Authorization` header of an incoming request. If the token is present, it should be passed to `JsonWebToken.verify`.
-
-```rb
-# lib/server_rs256.rb
-
-def authenticate!
-  # Extract  from the 'Bearer ' value of the Authorization header
-  supplied_token = String(request.env['HTTP_AUTHORIZATION']).slice(7..-1)
-
-  @auth_payload, @auth_header = JsonWebToken.verify(supplied_token)
-
-rescue JWT::DecodeError => e
-  halt 401, json(error: e.class, message: e.message)
-end
-
-# This route doesn't need authentication
-get '/api/public' do
-  json( message: 'Hello from a public endpoint! You don't need to be authenticated to see this.' )
-end
-
-get '/api/private' do
-  authenticate!
-  json( message: 'Hello from a private endpoint! You need to be authenticated to see this.' )
-end
-```
-
-## Configure Scopes
-
-The `JsonWebToken.verify` 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.
-
-Scopes provide a way for you to define which resources should be accessible by the user holding a given `access_token`. For example, you might choose to permit `read` access to a `messages` resource if a user has a **manager** access level, or `write` access to that resource if they are an **administrator**.
-
-To configure scopes in your Auth0 dashboard, navigate to [your API](${manage_url}/#/apis) and choose the **Scopes** tab. In this area you can apply any scopes you wish, including one called `read:messages`, which will be used in this example.
-
-## Protect Individual Endpoints
-
-To look for a particular `scope` in an `access_token`, provide an array of required scopes and check if they are present in the payload of the token.
-
-In this example the `SCOPES` array for the given key `/api/private-scoped` is intersected with the `scopes` contained in the payload of the `access_token` to determine if it contains one or more items from the array.
-
-```rb
-# lib/server_rs256.rb
-
-SCOPES = {
-  '/api/private' => nil,
-  '/api/private-scoped' => ['read:messages']
-}
-
-def authenticate!
-  # Extract  from the 'Bearer ' value of the Authorization header
-  supplied_token = String(request.env['HTTP_AUTHORIZATION']).slice(7..-1)
-
-  @auth_payload, @auth_header = JsonWebToken.verify(supplied_token)
-
-  halt 403, json(error: 'Forbidden', message: 'Insufficient scope') unless scope_included
-
-rescue JWT::DecodeError => e
-  halt 401, json(error: e.class, message: e.message)
-end
-
-def scope_included
-  if SCOPES[request.env['PATH_INFO']] == nil
-    true
-  else
-    # The intersection of the scopes included in the given JWT and the ones in the SCOPES hash needed to access
-    # the PATH_INFO, should contain at least one element
-    (String(@auth_payload['scope']).split(' ') & (SCOPES[request.env['PATH_INFO']])).any?
-  end
-end
-
-# ...
-
-get '/api/private-scoped' do
-  authenticate!
-  json( message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' )
-end
-```
-
-With this configuration in place, only `access_token`s which have a scope of `read:messages` will be allowed to access this endpoint.
diff --git a/articles/quickstart/backend/ruby/02-using.md b/articles/quickstart/backend/ruby/02-using.md
deleted file mode 100644
index 793ece84e6..0000000000
--- a/articles/quickstart/backend/ruby/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %> 
diff --git a/articles/quickstart/backend/ruby/index.yml b/articles/quickstart/backend/ruby/index.yml
deleted file mode 100644
index 465a32e71f..0000000000
--- a/articles/quickstart/backend/ruby/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: Ruby API
-author:
-  community: true
-alias:
-  - ruby
-languages:
-  - Ruby
-thirdParty: false
-image: /media/platforms/rails.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/ruby/dependencies
-  setup: server-apis/ruby/setup
-  use: server-apis/ruby/use
-articles:
-  - 01-authorization
-  - 02-using
diff --git a/articles/quickstart/backend/symfony/01-authorization.md b/articles/quickstart/backend/symfony/01-authorization.md
deleted file mode 100644
index c9fd4000e3..0000000000
--- a/articles/quickstart/backend/symfony/01-authorization.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authentication and authorization to a Symfony API
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-symfony-api-samples',
-  path: '01-Authorization-RS256',
-  requirements: [
-    'PHP 5.5',
-    'Symfony 3.2'
-  ]
-}) %>
-
-<%= include('../../../_includes/_api_auth_intro') %>
-
-<%= include('../_includes/_api_create_new') %>
-
-<%= include('../_includes/_api_auth_preamble') %>
-
-## Install the Dependencies
-
-Protecting a Symfony API with Auth0 requires the **jwt-auth-bundle** package. Install it using **composer**.
-
-::: note
-**[Composer](https://getcomposer.org/)** is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you. See Composer's [getting started](https://getcomposer.org/doc/00-intro.md) doc for information on how to use it.
-:::
-
-${snippet(meta.snippets.dependencies)}
-
-::: note
-`v3.x.x` of the **jwt-auth-bundle** provides compatibility with Symfony 3. For Symfony 2.x support, use the v1 branch.
-:::
-
-## Add the Bundle to AppKernel.php
-
-```php
-// app/AppKernel.php
-
-class AppKernel extends Kernel
-{
-    public function registerBundles()
-    {
-        $bundles = array(
-
-            // ...
-            new \Auth0\JWTAuthBundle\JWTAuthBundle(),
-
-        );
-
-        // ...
-        return $bundles;
-    }
-```
-
-## Add Configuration Values
-
-Add your Auth0 domain and API audience to the `config.yml` file located in `app/config`.
-
-${snippet(meta.snippets.setup)}
-
-## Set Up the User and UserProvider
-
-Create your `User` and `UserProvider`.
-
-The `UserProvider` must implement the `JWTUserProviderInterface` (see `/source/AppBundle/Security/A0UserProvider`). This class should implement two methods:
-
-- `loadUserByJWT`: receives the decoded JWT `access_token` and returns a User.
-
-- `getAnonymousUser`: returns an anonymous user that represents an unauthenticated one (usually represented by the role `IS_AUTHENTICATED_ANONYMOUSLY`).
-
-::: note
-Both of the above methods can throw an `AuthenticationException`. If this exception is thrown by `loadUserByJWT`, the it will treat the user as being anonymous. If `getAnonymousUser` throw this exception, a `401 Unauthorized` will be returned.
-:::
-
-Provide configuration for the `UserProvider` in the `services.yml` file located in `app/config`.
-
-```yml
-services:
-    a0_user_provider:
-        class: AppBundle\Security\A0UserProvider
-        arguments: ["@jwt_auth.auth0_service"]
-```
-
-## Set Up the SecurityProvider
-
-Modify the `security.yml` file located in `app/config` such that it contains the following:
-
-- The `UserProvider`
-- The secured area that you want to authenticate using an `access_token`
-- The `access_control` section with the roles needed for each route
-
-${snippet(meta.snippets.use)}
-
-## Set Up a Protected Route
-
-```php
-// src/AppBundle/Controller/SecuredController.php
-
-// ...
-class SecuredController extends Controller
-{
-    /**
-     * @Route("/api/public", name="public")
-     */
-    // This route doesn't need authentication
-    public function publicAction()
-    {
-        return new JsonResponse(array(
-          'message' => "Hello from a public endpoint! You don't need to be authenticated to see this."
-        ));
-    }
-    /**
-     * @Route("/api/private", name="private")
-     */
-    public function privateAction()
-    {
-        return new JsonResponse(array(
-          'message' => "Hello from a private endpoint! You need to be authenticated to see this."
-        ));
-    }
-    /**
-     * @Route("/api/private-scoped", name="privatescoped")
-     */
-    public function privateScopedAction()
-    {
-        return new JsonResponse(array(
-          'message' => "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
-        ));
-    }
-}
-```
-
-## Configuring Scopes
-
-Scopes provide a way for you to define which resources should be accessible by the user holding a given `access_token`. For example, you might choose to permit `read` access to a `messages` resource if a user has a **manager** access level, or a `write` access to that resource if they are an **administrator**. The route defined above expects a scope of `read:messages` to be present in the payload of the `access_token`.
-
-To configure scopes in your Auth0 dashboard, navigate to [your API](${manage_url}/#/apis) and choose the **Scopes** tab. In this area you can apply any scopes you wish, including one called `read:messages`, which will be used in this example.
-
-With this configuration in place, only `access_token`s which have a scope of `read:messages` will be allowed to access this endpoint.
diff --git a/articles/quickstart/backend/symfony/02-using.md b/articles/quickstart/backend/symfony/02-using.md
deleted file mode 100644
index 793ece84e6..0000000000
--- a/articles/quickstart/backend/symfony/02-using.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Using your API
-description: This tutorial will show you how to use your API
-budicon: 500
----
-
-<%= include('../_includes/_api_using') %> 
diff --git a/articles/quickstart/backend/symfony/index.yml b/articles/quickstart/backend/symfony/index.yml
deleted file mode 100644
index b711b547f0..0000000000
--- a/articles/quickstart/backend/symfony/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Symfony API
-author:
-  community: true
-thirdParty: false
-alias:
-  - symfony
-languages:
-  - PHP
-framework:
-  - Symfony
-image: /media/platforms/php.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/php-symfony/dependencies
-  setup: server-apis/php-symfony/setup
-  use: server-apis/php-symfony/use
-articles:
-  - 01-authorization
-  - 02-using
diff --git a/articles/quickstart/backend/webapi-owin/01-authorization.md b/articles/quickstart/backend/webapi-owin/01-authorization.md
index 2f2c148a68..3fdc7972c1 100644
--- a/articles/quickstart/backend/webapi-owin/01-authorization.md
+++ b/articles/quickstart/backend/webapi-owin/01-authorization.md
@@ -1,39 +1,26 @@
 ---
 title: Authorization
-name: Shows how to secure your API using the standard OWIN JWT middeware
-description: This tutorial demonstrates how to add authorization to your ASP.NET OWIN API using Auth0.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-samples',
-  path: 'Quickstart/01-Authorization',
-  requirements: [
-    'Microsoft Visual Studio 2015 Update 3',
-    'Microsoft.Owin.Security.Jwt NuGet Package V3.0.1',
-    'System.IdentityModel.Tokens.Jwt NuGet Package v4.0.2',
-    'Auth0.OpenIdConnectSigningKeyResolver NuGet Package v1.0.0'
-  ]
-}) %>
-
-::: panel-warning OWIN 4 Incompatibility
-Please note that the **Auth0.OpenIdConnectSigningKeyResolver** NuGet package is only compatible with **System.IdentityModel.Tokens.Jwt 4.x** and the **OWIN 3.x** packages. Attempting to use **Auth0.OpenIdConnectSigningKeyResolver** with newer versions of those packages will result in compiler errors.
-:::
-
 <%= include('../../../_includes/_api_auth_intro') %>
 
-This Quickstart will guide you through the various tasks related to using Auth0-issued Access Tokens to secure your ASP.NET (OWIN) Web API.
-
-## Seed and Samples
+<%= include('../_includes/_api_create_new') %>
 
-If you would like to follow along with this Quickstart you can download the [seed project](https://github.com/auth0-samples/auth0-aspnet-owin-webapi-samples/tree/master/Quickstart/00-Starter-Seed). The seed project is just a basic ASP.NET Web API with a simple controller and some of the NuGet packages which will be needed included. It has also defined some of the required Auth0-related settings in the `appSettings` key of the `Web.config`.
-
-The final project after each of the steps is also available in the [Sample repository](https://github.com/auth0-samples/auth0-aspnet-owin-webapi-samples). You can find the final result for each step in the relevant folder inside the repository.
+<%= include('../_includes/_api_auth_preamble') %>
 
-<%= include('../_includes/_api_create_new_2') %>
+## Configure the Sample Project
 
-Also update the `web.config` file in your project with the correct **Domain** and **API Identifier** for your API, such as
+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
@@ -44,24 +31,44 @@ Also update the `web.config` file in your project with the correct **Domain** an
 
 ```
 
-<%= include('../_includes/_api_auth_preamble') %>
-
-This sample demonstrates how to check for a JWT in the `Authorization` header of an incoming HTTP request and verify that it is valid using the standard ASP.NET (OWIN) JWT middleware. 
+## Validate Access Tokens
 
-## Install Dependencies
+### Install dependencies
 
-To use Auth0 Access Tokens with ASP.NET Core you will use the OWIN JWT Middleware which is available in the `Microsoft.Owin.Security.Jwt` NuGet package. Also install the `Auth0.OpenIdConnectSigningKeyResolver` NuGet package which will assist you in verifying the token signature.
+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
-Install-Package Auth0.OpenIdConnectSigningKeyResolver
 ```
 
-## Configuration
+### 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, 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());
+    }
 
-<%= include('../_includes/_api_jwks_description', { sampleLink: 'https://github.com/auth0-samples/auth0-aspnet-owin-webapi-samples/tree/master/Samples/hs256' }) %>
+    public SecurityKey[] GetSigningKey(string kid)
+    {
+        return new[] { openIdConfig.JsonWebKeySet.GetSigningKeys().FirstOrDefault(t => t.KeyId == kid) };
+    }
+}
+```
 
-The `Auth0.OpenIdConnectSigningKeyResolver` package which you installed will automatically download the JSON Web Key Set which was used to sign the RS256 tokens by interrogating 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.
+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`.
 
@@ -74,8 +81,8 @@ 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
         {
@@ -84,7 +91,7 @@ public void Configuration(IAppBuilder app)
             {
                 ValidAudience = apiIdentifier,
                 ValidIssuer = domain,
-                IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => keyResolver.GetSigningKey(identifier)
+                IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid)
             }
         });
 
@@ -97,32 +104,9 @@ public void Configuration(IAppBuilder app)
 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.
 :::
 
-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:
+### Validate scopes
 
-```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."
-        });
-    }
-}
-```
-
-## Configuring 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.
-
-<%= include('../_includes/_api_scopes_access_resources') %>
+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.
 
@@ -137,7 +121,7 @@ public class ScopeAuthorizeAttribute : AuthorizeAttribute
     {
         this.scope = scope;
     }
-    
+
     public override void OnAuthorization(HttpActionContext actionContext)
     {
         base.OnAuthorization(actionContext);
@@ -147,8 +131,8 @@ public class ScopeAuthorizeAttribute : AuthorizeAttribute
 
         // 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
+
+        // 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)
         {
@@ -165,7 +149,32 @@ public class ScopeAuthorizeAttribute : AuthorizeAttribute
 }
 ```
 
-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:
+## 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
@@ -185,9 +194,3 @@ public class ApiController : ApiController
     }
 }
 ```
-
-## Further Reading
-
-* To learn how you can call your API from applications, please refer to the [Using your API section](/quickstart/backend/webapi-owin/02-using).
-
-* If your experience problems with your API, please refer to the [Troubleshooting section](/quickstart/backend/webapi-owin/03-troubleshooting).
diff --git a/articles/quickstart/backend/webapi-owin/02-using.md b/articles/quickstart/backend/webapi-owin/02-using.md
index ca1c2ad208..2c15aa3d87 100644
--- a/articles/quickstart/backend/webapi-owin/02-using.md
+++ b/articles/quickstart/backend/webapi-owin/02-using.md
@@ -1,7 +1,13 @@
 ---
 title: Using your API
-description: This tutorial will show you how to use 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/articles/quickstart/backend/webapi-owin/03-troubleshooting.md b/articles/quickstart/backend/webapi-owin/03-troubleshooting.md
index 4d459eb93f..6fcfdb792e 100644
--- a/articles/quickstart/backend/webapi-owin/03-troubleshooting.md
+++ b/articles/quickstart/backend/webapi-owin/03-troubleshooting.md
@@ -1,8 +1,14 @@
 ---
 title: Troubleshooting
-name: Shows how to troubleshoot the JWT middeware configuration
-description: This document will help you troubleshoot your configuration if you get 401 (Unauthorized) response from your API.
+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.
@@ -13,7 +19,7 @@ This document will help you troubleshoot your JWT middleware configuration.
 
 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-)
+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
 
 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.
 
@@ -29,11 +35,11 @@ In terms of validating a JWT, there are various things to consider:
 
 ## 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.
+A quick way to inspect a JWT is by using the 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**.
+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
 
@@ -45,9 +51,9 @@ app.UseJwtBearerAuthentication(
         AuthenticationMode = AuthenticationMode.Active,
         TokenValidationParameters = new TokenValidationParameters()
         {
-            ValidAudience = "https://rs256.test.api",
+            ValidAudience = "https://quickstarts/api",
             ValidIssuer = "https://jerrie.auth0.com/",
-            IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => keyResolver.GetSigningKey(identifier)
+            IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid)
         }
     });
 ```
@@ -56,21 +62,21 @@ 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**.
+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:
+In this case, the middleware needs to be configured as follows:
 
 ```csharp
 app.UseJwtBearerAuthentication(
     new JwtBearerAuthenticationOptions
     {
         AuthenticationMode = AuthenticationMode.Active,
-        AllowedAudiences = new[] { "https://hs256.test.api" },
-        IssuerSecurityTokenProviders = new IIssuerSecurityTokenProvider[]
+        AllowedAudiences = new[] { "https://quickstarts/api/hs256" },
+        IssuerSecurityKeyProviders = new IIssuerSecurityKeyProvider[]
         {
-            new SymmetricKeyIssuerSecurityTokenProvider("https://jerrie.auth0.com/",
+            new SymmetricKeyIssuerSecurityKeyProvider("https://jerrie.auth0.com/",
               Encoding.UTF8.GetBytes("your api secret"))
-        },
+        }
     });
 ```
 
@@ -92,13 +98,13 @@ This will log all OWIN log messages to the Output window in Visual Studio when r
 
 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 your send the JWT as a bearer token in the Authorization header.
+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, but your middleware is configured for RS256 - or vice versa.
+Another common mistake is that your tokens are signed using the HS256 signing algorithm, 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.
+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)
 
@@ -108,17 +114,17 @@ The relevant error message to look for is the following:
 IDX10503: Signature validation failed. Keys tried: 'null'.
 ```
 
-In the case where you configured you middleware for HS256, but you are sending an RS256 signed token the error message will be different:
+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:
+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 to that the signature algorithm with which the JWT was signed matches with how your middleware is configured.
+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?
 
@@ -150,7 +156,7 @@ The error message to look for is the following:
 IDX10205: Issuer validation failed.
 ```
 
-The resolve this issue, ensure that you specify the correct issuer for your JWT middeware. 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(...)`.
+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`.
 
@@ -166,6 +172,6 @@ The error message to look for is the following:
 IDX10214: Audience validation failed.
 ```
 
-The resolve this issue, ensure that you specify the correct audience for your JWT middeware.  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`
+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/articles/quickstart/backend/webapi-owin/download.md b/articles/quickstart/backend/webapi-owin/download.md
new file mode 100644
index 0000000000..2eac5c0083
--- /dev/null
+++ b/articles/quickstart/backend/webapi-owin/download.md
@@ -0,0 +1,3 @@
+To run the sample, open the solution in Visual Studio.
+
+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/articles/quickstart/backend/webapi-owin/files/ApiController.md b/articles/quickstart/backend/webapi-owin/files/ApiController.md
new file mode 100644
index 0000000000..f2c2cd153e
--- /dev/null
+++ b/articles/quickstart/backend/webapi-owin/files/ApiController.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."
+        });
+    }
+}
+```
diff --git a/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md b/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md
new file mode 100644
index 0000000000..f15111e01b
--- /dev/null
+++ b/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.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) };
+    }
+}
+```
diff --git a/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md b/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md
new file mode 100644
index 0000000000..6d78b4041a
--- /dev/null
+++ b/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.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);
+    }
+}
+```
diff --git a/articles/quickstart/backend/webapi-owin/files/api-controller.md b/articles/quickstart/backend/webapi-owin/files/api-controller.md
new file mode 100644
index 0000000000..9c04dd06e5
--- /dev/null
+++ b/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/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md b/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md
new file mode 100644
index 0000000000..a1aaee90b9
--- /dev/null
+++ b/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/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md b/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md
new file mode 100644
index 0000000000..ec5670f427
--- /dev/null
+++ b/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/articles/quickstart/backend/webapi-owin/files/startup.md b/articles/quickstart/backend/webapi-owin/files/startup.md
new file mode 100644
index 0000000000..015db9db1d
--- /dev/null
+++ b/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);
+}
+```
diff --git a/articles/quickstart/backend/webapi-owin/index.yml b/articles/quickstart/backend/webapi-owin/index.yml
index a4e267162a..9980953c84 100644
--- a/articles/quickstart/backend/webapi-owin/index.yml
+++ b/articles/quickstart/backend/webapi-owin/index.yml
@@ -1,4 +1,7 @@
 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:
@@ -6,10 +9,40 @@ languages:
 thirdParty: false
 framework:
   - OWIN
-image: /media/platforms/asp.png
-tags:
+author:
+  name: Damien Guard
+  email: damien.guard@auth0.com
+  community: false
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 articles:
   - 01-authorization
   - 02-using
-  - 03-troubleshooting
\ No newline at end of file
+  - 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/articles/quickstart/backend/webapi-owin/interactive.md b/articles/quickstart/backend/webapi-owin/interactive.md
new file mode 100644
index 0000000000..9126bdb1d8
--- /dev/null
+++ b/articles/quickstart/backend/webapi-owin/interactive.md
@@ -0,0 +1,58 @@
+---
+title: Add Authorization to Your 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.
+interactive:  true
+files:
+ - files/Startup
+ - files/OpenIdConnectSigningKeyResolver
+ - files/ScopeAuthorizeAttribute
+ - files/ApiController
+github:
+  path: Quickstart/Sample
+locale: en-US
+---
+
+# 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.
        Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
        New to Auth0? Learn how Auth0 works and read about implementing API authentication and authorization using the OAuth 2.0 framework.
        
+
+## Define permissions
+
+
+
        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 section. The following example uses the read:messages scope.
        Auth0 Dashboard> Applications > APIs > [Specific API] > Permissions tab
        
+
+## 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.
        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.
        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.
        
+
+## Verify 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.
        This custom resolver is deprecated and no longer available. You must provide this custom 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" }}}
+
+
+
        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.
        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 endpoint.
        ASP.NET API OWIN Quickstart - Step 6 Checkpoint 
        Now that you have configured your application, run your application and 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.
        
+
+  
        
+
+  
        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.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/config.yml b/articles/quickstart/config.yml
index 96c7ae5293..a99856f831 100644
--- a/articles/quickstart/config.yml
+++ b/articles/quickstart/config.yml
@@ -1,4 +1,4 @@
 author:
-  name: Andres Aguiar
-  email: andres.aguiar@auth0.com
+  name: Auth0
+  email: support@auth0.com
   community: false
diff --git a/articles/quickstart/native/_includes/_authorization-create-rule.md b/articles/quickstart/native/_includes/_authorization-create-rule.md
index ef210437db..f38269aab2 100644
--- a/articles/quickstart/native/_includes/_authorization-create-rule.md
+++ b/articles/quickstart/native/_includes/_authorization-create-rule.md
@@ -1,4 +1,4 @@
-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**.
+First, you will create a rule that assigns users to either an `admin` role, or a single `user` role. Go to the New Rule 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.
 
diff --git a/articles/quickstart/native/_includes/_authorization-introduction.md b/articles/quickstart/native/_includes/_authorization-introduction.md
index a96342dad8..3217218555 100644
--- a/articles/quickstart/native/_includes/_authorization-introduction.md
+++ b/articles/quickstart/native/_includes/_authorization-introduction.md
@@ -1,5 +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.
+This tutorial assumes that you have already completed the rules tutorial and that you know how to implement a basic rule in your app.
 :::
diff --git a/articles/quickstart/native/_includes/_callback-url-introduction.md b/articles/quickstart/native/_includes/_callback-url-introduction.md
index 377b599897..bf60aabc9c 100644
--- a/articles/quickstart/native/_includes/_callback-url-introduction.md
+++ b/articles/quickstart/native/_includes/_callback-url-introduction.md
@@ -1,7 +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). 
+Callback URLs can be manipulated by attackers. For security, add your application's URL to the **Allowed Callback URLs** field in your Application Settings. 
 
-If you do not whitelist your application's URL, your users will see a mismatch error when they try to log in.
+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/articles/quickstart/native/_includes/_calling_api_create_api.md b/articles/quickstart/native/_includes/_calling_api_create_api.md
index 755ffb537d..08a59ee1be 100644
--- a/articles/quickstart/native/_includes/_calling_api_create_api.md
+++ b/articles/quickstart/native/_includes/_calling_api_create_api.md
@@ -1,6 +1,6 @@
 ## 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.
+In the APIs section 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**.
 
diff --git a/articles/quickstart/native/_includes/_calling_api_create_scope.md b/articles/quickstart/native/_includes/_calling_api_create_scope.md
index 6ea9af9d0b..87f0601743 100644
--- a/articles/quickstart/native/_includes/_calling_api_create_scope.md
+++ b/articles/quickstart/native/_includes/_calling_api_create_scope.md
@@ -1,8 +1,8 @@
 ## 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).
+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.
 
-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.
+In the Auth0 dashboard, in the APIs section, 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.
diff --git a/articles/quickstart/native/_includes/_cordova_setup.md b/articles/quickstart/native/_includes/_cordova_setup.md
index 2c03b6254d..b201e26616 100644
--- a/articles/quickstart/native/_includes/_cordova_setup.md
+++ b/articles/quickstart/native/_includes/_cordova_setup.md
@@ -1,4 +1,4 @@
-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.
+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) 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.
diff --git a/articles/quickstart/native/_includes/_create_application.md b/articles/quickstart/native/_includes/_create_application.md
index a91678b6e6..d3ab5a20cf 100644
--- a/articles/quickstart/native/_includes/_create_application.md
+++ b/articles/quickstart/native/_includes/_create_application.md
@@ -1,3 +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
+Create a new application in your Auth0 dashboard. For **Type**, select **Native**.
\ No newline at end of file
diff --git a/articles/quickstart/native/_includes/_facebook_login_howto.md b/articles/quickstart/native/_includes/_facebook_login_howto.md
new file mode 100644
index 0000000000..f8e6312447
--- /dev/null
+++ b/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 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/articles/quickstart/native/_includes/_facebook_login_prerequisites.md b/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
new file mode 100644
index 0000000000..8fb2d56201
--- /dev/null
+++ b/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
@@ -0,0 +1,6 @@
+This tutorial describes how to implement login with the Facebook SDK.
+​
+## Before You Start
+​
+- Install and configure the Facebook Login SDK. You’ll also go through the process of creating a Facebook app in 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. **When you finish this step, your application will be able to implement Facebook Native Login.**
diff --git a/articles/quickstart/native/_includes/_getting_started.md b/articles/quickstart/native/_includes/_getting_started.md
new file mode 100644
index 0000000000..4d733e6f26
--- /dev/null
+++ b/articles/quickstart/native/_includes/_getting_started.md
@@ -0,0 +1,7 @@
+::: note
+**New to Auth?** Learn How Auth0 works, how it integrates with Native Applications and which protocol it uses.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+
diff --git a/articles/quickstart/native/_includes/_ionic_setup.md b/articles/quickstart/native/_includes/_ionic_setup.md
index 37ba70e5d8..2423463604 100644
--- a/articles/quickstart/native/_includes/_ionic_setup.md
+++ b/articles/quickstart/native/_includes/_ionic_setup.md
@@ -1,4 +1,4 @@
-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.
+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) 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.
@@ -39,7 +39,7 @@ 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.
+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
@@ -54,4 +54,4 @@ ionic cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME={Y
 
 ## Modify config.xml
 
-Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
\ No newline at end of file
+Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
diff --git a/articles/quickstart/native/_includes/_ios_config.md b/articles/quickstart/native/_includes/_ios_config.md
index 324434f73a..77794bc15d 100644
--- a/articles/quickstart/native/_includes/_ios_config.md
+++ b/articles/quickstart/native/_includes/_ios_config.md
@@ -1,16 +1,18 @@
+
+
 ## 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 will need some details about this application to communicate with Auth0. You can get these details from the Application 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. If you have more than one application in your account, the sample comes with the values for your **Default App**.
+If you download the sample from the top of this page, these details are filled out for you.
 :::
 
-Add your credentials in the `Auth0.plist` file. If the file does not exist in your project yet, create it:
+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):
 
 ```xml
 
@@ -53,7 +55,7 @@ In your application's `Info.plist` file, register your iOS Bundle identifier as
 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:
+Go to your Dashboard 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/articles/quickstart/native/_includes/_ios_dependency_centralized.md b/articles/quickstart/native/_includes/_ios_dependency_centralized.md
index fd396c89d3..8e86c3e3ff 100644
--- a/articles/quickstart/native/_includes/_ios_dependency_centralized.md
+++ b/articles/quickstart/native/_includes/_ios_dependency_centralized.md
@@ -1,30 +1,49 @@
+
+
 ## Install Dependencies
 
+### Cocoapods
+
+If you are using Cocoapods, 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.
+:::
+
 ### Carthage
 
-If you are using Carthage, add the following to your `Cartfile`:
+If you are using Carthage, add the following line to your `Cartfile`:
 
 ```ruby
 github "auth0/Auth0.swift" ~> 1.0
 ```
 
-Then, run `carthage bootstrap`.
+Then run `carthage bootstrap`.
 
 ::: note
-For more information on how to use Carthage, read [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+For more information about Carthage usage, check their official documentation.
 :::
 
-### Cocoapods
+### SPM
 
-If you are using [Cocoapods](https://cocoapods.org/), add the following to your `Podfile`:
+If you are using the Swift Package Manager, open the following menu item in Xcode:
 
-```ruby
-use_frameworks!
-pod 'Auth0', '~> 1.0'
+**File > Add Packages...**
+
+In the **Search or Enter Package URL** search box enter this url: 
+
+```text
+https://github.com/auth0/Auth0.swift.git
 ```
 
-Then, run `pod install`.
+Then select the dependency rule and press **Add Package**.
 
 ::: note
-For more information on how to use Cocoapods, read the [Cocoapods documentation](http://guides.cocoapods.org/using/getting-started.html).
-:::
\ No newline at end of file
+For further reference on SPM, check its official documentation.
+:::
diff --git a/articles/quickstart/native/_includes/_ios_link_accounts.md b/articles/quickstart/native/_includes/_ios_link_accounts.md
index 6910f25b64..956318d9bb 100644
--- a/articles/quickstart/native/_includes/_ios_link_accounts.md
+++ b/articles/quickstart/native/_includes/_ios_link_accounts.md
@@ -2,5 +2,5 @@
 
 Now, you can link the accounts. To do this, you need the following values: 
 - `id`: the logged-in user's ID (see `profile.sub`)
-- `idToken`: the ID Token for the saved account the user initially logged in to 
-- `otherUserToken`: the ID Token for the second account received in the last login response
\ No newline at end of file
+- `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/articles/quickstart/native/_includes/_mfa-enable.md b/articles/quickstart/native/_includes/_mfa-enable.md
deleted file mode 100644
index 88a3098cee..0000000000
--- a/articles/quickstart/native/_includes/_mfa-enable.md
+++ /dev/null
@@ -1,5 +0,0 @@
-To enable the Auth0 MFA feature, open the [Multifactor 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 Multifactor authentication in your application.
diff --git a/articles/quickstart/native/_includes/_mfa-introduction.md b/articles/quickstart/native/_includes/_mfa-introduction.md
deleted file mode 100644
index 5b6a2e680e..0000000000
--- a/articles/quickstart/native/_includes/_mfa-introduction.md
+++ /dev/null
@@ -1 +0,0 @@
-Multifactor 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 will be required. Currently, Auth0 supports [Auth0 Guardian](/multifactor-authentication/guardian), Google Authenticator and Duo. For more details, see: [Multifactor Authentication in Auth0](/multifactor-authentication).
diff --git a/articles/quickstart/native/_includes/_mfa-login.md b/articles/quickstart/native/_includes/_mfa-login.md
deleted file mode 100644
index ac9d206bca..0000000000
--- a/articles/quickstart/native/_includes/_mfa-login.md
+++ /dev/null
@@ -1,7 +0,0 @@
-There is no need to update the code you created in [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: [How to Use the Guardian App](/multifactor-authentication/guardian/user-guide).
-
-For advanced management of the multifactor authentication for your users, see [Step-up Authentication](/multifactor-authentication/developer/step-up-with-acr).
diff --git a/articles/quickstart/native/_includes/_profile-metadata-explanation.md b/articles/quickstart/native/_includes/_profile-metadata-explanation.md
index 0f6ac7889e..d1bd4b9fb4 100644
--- a/articles/quickstart/native/_includes/_profile-metadata-explanation.md
+++ b/articles/quickstart/native/_includes/_profile-metadata-explanation.md
@@ -1 +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: [User Metadata](/metadata).
\ No newline at end of file
+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.
\ No newline at end of file
diff --git a/articles/quickstart/native/_includes/_rules-create-section.md b/articles/quickstart/native/_includes/_rules-create-section.md
index 32426a0548..3fee4301ed 100644
--- a/articles/quickstart/native/_includes/_rules-create-section.md
+++ b/articles/quickstart/native/_includes/_rules-create-section.md
@@ -1,4 +1,4 @@
-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. 
+To create a rule, go to the New Rule 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.
 
diff --git a/articles/quickstart/native/_includes/_rules-introduction.md b/articles/quickstart/native/_includes/_rules-introduction.md
index ffd19a504a..1599ac7911 100644
--- a/articles/quickstart/native/_includes/_rules-introduction.md
+++ b/articles/quickstart/native/_includes/_rules-introduction.md
@@ -1 +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
+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.
\ No newline at end of file
diff --git a/articles/quickstart/native/_includes/_rules-test-result-intro.md b/articles/quickstart/native/_includes/_rules-test-result-intro.md
index af8850b325..1d5eb9010a 100644
--- a/articles/quickstart/native/_includes/_rules-test-result-intro.md
+++ b/articles/quickstart/native/_includes/_rules-test-result-intro.md
@@ -1,3 +1,3 @@
-To see the results of a created rule, login and fetch user profile information as explained in the [User Profile](${profilelink}) step.
+To see the results of a created rule, login and fetch user profile information as explained in the User Profile 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/articles/quickstart/native/_includes/ionic/_add_login_intro.md b/articles/quickstart/native/_includes/ionic/_add_login_intro.md
new file mode 100644
index 0000000000..a68040b2ad
--- /dev/null
+++ b/articles/quickstart/native/_includes/ionic/_add_login_intro.md
@@ -0,0 +1,7 @@
+
+
+In a Capacitor application, the Capacitors Browser plugin performs a redirect to the Auth0 Universal Login Page. 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 on iOS, and Chrome 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/articles/quickstart/native/_includes/ionic/_add_logout_intro.md b/articles/quickstart/native/_includes/ionic/_add_logout_intro.md
new file mode 100644
index 0000000000..4478a15ba5
--- /dev/null
+++ b/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. 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/articles/quickstart/native/_includes/ionic/_article_intro.md b/articles/quickstart/native/_includes/ionic/_article_intro.md
new file mode 100644
index 0000000000..b3d2d778ce
--- /dev/null
+++ b/articles/quickstart/native/_includes/ionic/_article_intro.md
@@ -0,0 +1,7 @@
+
+
+## Getting started
+
+This quickstart assumes you already have an Ionic application up and running with Capacitor. If not, check out the Using Capacitor with Ionic Framework guide to get started with a simple app, or clone our sample apps.
+
+You should also be familiar with the Capacitor development workflow.
diff --git a/articles/quickstart/native/_includes/ionic/_configure_urls.md b/articles/quickstart/native/_includes/ionic/_configure_urls.md
new file mode 100644
index 0000000000..327ed16b39
--- /dev/null
+++ b/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 Capacitors Config schema for more info.
+:::
+
+Go to the Application 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.
+
+```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.
\ No newline at end of file
diff --git a/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md b/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md
new file mode 100644
index 0000000000..a61c78f9b2
--- /dev/null
+++ b/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 Capacitors 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.
+
+::: 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.
diff --git a/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md b/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md
new file mode 100644
index 0000000000..eaa4e75188
--- /dev/null
+++ b/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/articles/quickstart/native/_includes/ionic/_install_plugins.md b/articles/quickstart/native/_includes/ionic/_install_plugins.md
new file mode 100644
index 0000000000..3b91206e64
--- /dev/null
+++ b/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` - allows you to interact with the device's system browser and is used to open the URL to Auth0's authorizaction endpoint
+- `@capacitor/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`, which on iOS 11+ does not share cookies with Safari on the device. This means that SSO will not work on those devices. If you need SSO, please instead use a compatible plugin that uses ASWebAuthenticationSession.
+:::
diff --git a/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md b/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md
new file mode 100644
index 0000000000..ddebb136b4
--- /dev/null
+++ b/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 for iOS, or Create Deep Links to App Content for Android.
+:::
diff --git a/articles/quickstart/native/_includes/ionic/_note_storage.md b/articles/quickstart/native/_includes/ionic/_note_storage.md
new file mode 100644
index 0000000000..8d3a958965
--- /dev/null
+++ b/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. 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.
+
+Additionally, the SDK has the ability to use a custom cache implementation to store tokens, if you have a requirement to use a more secure and persistent storage mechanism.
+
+**Note** that we recommend **against** using Capacitors Storage plugin to store tokens, as this is backed by UserDefaults and 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/articles/quickstart/native/android-facebook-login/00-login-facebook.md b/articles/quickstart/native/android-facebook-login/00-login-facebook.md
new file mode 100644
index 0000000000..d0fc42be23
--- /dev/null
+++ b/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/articles/quickstart/native/android-facebook-login/download.md b/articles/quickstart/native/android-facebook-login/download.md
new file mode 100644
index 0000000000..7105851e66
--- /dev/null
+++ b/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. 
+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/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md b/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
new file mode 100644
index 0000000000..c2593142a7
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
@@ -0,0 +1,26 @@
+---
+name: exchangeTokens
+language: kotlin
+---
+    
+```kotlin
+private fun exchangeTokens(
+        sessionToken: String,
+        userProfile: String,
+        callback: SimpleCallback
+    ) {
+        val params = mapOf("user_profile" to userProfile)
+        apiClient.loginWithNativeSocialToken(sessionToken, FACEBOOK_SUBJECT_TOKEN_TYPE)
+            .setScope(AUTH0_SCOPE)
+            .addParameters(params)
+            .start(object : Callback {
+                override fun onFailure(error: AuthenticationException) {
+                    callback.onError(error)
+                }
+
+                override fun onSuccess(result: Credentials) {
+                    callback.onResult(result)
+                }
+            })
+    }
+```
diff --git a/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md b/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
new file mode 100644
index 0000000000..24232d1f4c
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
@@ -0,0 +1,35 @@
+---
+name: fetchSessionToken
+language: kotlin
+---
+    
+```kotlin
+private fun fetchSessionToken(token: String, callback: SimpleCallback) {
+        val params = Bundle().apply {
+            putString("grant_type", "fb_attenuate_token")
+            putString("fb_exchange_token", token)
+            putString("client_id", getString(R.string.facebook_app_id))
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = "oauth/access_token"
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            if (response.error != null) {
+                callback.onError(response.error?.exception!!)
+                return@Callback
+            }
+
+            try {
+                val fbSessionToken = response.jsonObject!!.getString("access_token")
+                callback.onResult(fbSessionToken)
+            } catch (jsonException: JSONException) {
+                //Failed to parse session token
+                callback.onError(jsonException)
+            }
+        }
+        request.executeAsync()
+    }
+```
diff --git a/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md b/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
new file mode 100644
index 0000000000..d54981f1d4
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
@@ -0,0 +1,32 @@
+---
+name: fetchUserProfile
+language: kotlin
+---
+    
+```kotlin
+private fun fetchUserProfile(token: String, userId: String, callback: SimpleCallback) {
+
+        val params = Bundle().apply {
+            putString("access_token", token)
+            putString("fields", "first_name,last_name,email")
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = userId
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            val error = response.error
+            if (error != null) {
+                //Failed to fetch user profile
+                callback.onError(error.exception!!)
+                return@Callback
+            }
+            //Handle back the profile as received
+            callback.onResult(response.rawResponse!!)
+        }
+
+        request.executeAsync()
+    }
+```
diff --git a/articles/quickstart/native/android-facebook-login/files/onCreate.md b/articles/quickstart/native/android-facebook-login/files/onCreate.md
new file mode 100644
index 0000000000..1102e17fb5
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/onCreate.md
@@ -0,0 +1,41 @@
+---
+name: onCreate
+language: kotlin
+---
+    
+```kotlin
+override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+
+        FacebookSdk.setClientToken(getString(R.string.facebook_client_token))
+        FacebookSdk.sdkInitialize(this)
+
+        setContentView(R.layout.activity_login)
+
+        val auth0 =
+            Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain))
+        apiClient = AuthenticationAPIClient(auth0)
+
+        fbCallbackManager = CallbackManager.Factory.create()
+
+        val loginButton = findViewById(R.id.login_button).apply {
+            setPermissions(*FACEBOOK_PERMISSIONS)
+        }
+
+        loginButton.registerCallback(fbCallbackManager, object : FacebookCallback {
+            override fun onSuccess(result: LoginResult) {
+
+                val accessToken = result.accessToken
+                performLogin(accessToken)
+            }
+
+            override fun onCancel() {
+                Log.i(TAG, "Facebook sign-in cancelled")
+            }
+
+            override fun onError(error: FacebookException) {
+                Log.e(TAG, "Error {error.message}")
+            }
+        })
+    }
+```
diff --git a/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md b/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md
new file mode 100644
index 0000000000..6645fdf0d8
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md	
@@ -0,0 +1,12 @@
+---
+name: performLogin + SimpleCallback
+language: kotlin
+---
+    
+```kotlin
+private interface SimpleCallback {
+  fun onResult(result: T)
+
+  fun onError(cause: Throwable)
+}
+```
diff --git a/articles/quickstart/native/android-facebook-login/files/performLogin.md b/articles/quickstart/native/android-facebook-login/files/performLogin.md
new file mode 100644
index 0000000000..84a6251bd1
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/files/performLogin.md
@@ -0,0 +1,41 @@
+---
+name: performLogin
+language: kotlin
+---
+    
+```kotlin
+private fun performLogin(accessToken: AccessToken) {
+        val token = accessToken.token
+        fetchSessionToken(token, object : SimpleCallback {
+            override fun onResult(sessionToken: String) {
+                //2. Obtained the Facebook session token
+                fetchUserProfile(token, accessToken.userId, object : SimpleCallback {
+                    override fun onResult(userProfile: String) {
+                        //3. Obtained the user profile
+                        exchangeTokens(
+                            sessionToken,
+                            userProfile,
+                            object : SimpleCallback {
+                                override fun onResult(credentials: Credentials) {
+                                    //4. Exchanged the tokens
+                                    Log.i(TAG, "Logged in to Auth0")
+                                }
+
+                                override fun onError(cause: Throwable) {
+                                    Log.e(TAG, "Error exchanging tokens", cause)
+                                }
+                            })
+                    }
+
+                    override fun onError(cause: Throwable) {
+                        Log.e(TAG, "Error fetching the profile", cause)
+                    }
+                })
+            }
+
+            override fun onError(cause: Throwable) {
+                Log.e(TAG, "Error fetching the session token", cause)
+            }
+        })
+    }
+```
diff --git a/articles/quickstart/native/android-facebook-login/index.yml b/articles/quickstart/native/android-facebook-login/index.yml
new file mode 100644
index 0000000000..c4db748f26
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/index.yml
@@ -0,0 +1,55 @@
+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
+hidden_articles:
+  - interactive
+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/articles/quickstart/native/android-facebook-login/interactive.md b/articles/quickstart/native/android-facebook-login/interactive.md
new file mode 100644
index 0000000000..1ee182e8a8
--- /dev/null
+++ b/articles/quickstart/native/android-facebook-login/interactive.md
@@ -0,0 +1,129 @@
+---
+title: Android - Facebook Login
+description: This tutorial demonstrates how to add user login to an Android application using native Facebook Login.
+interactive:  true
+files:
+ - files/performLogin + SimpleCallback
+ - files/onCreate
+ - files/fetchSessionToken
+ - files/fetchUserProfile
+ - files/exchangeTokens
+ - files/performLogin
+github:
+  path: 00-login-facebook
+locale: en-US
+---
+
+# Android - Facebook Login
+
+
+
        This tutorial demonstrates how to add user login to an Android application using native Facebook Login. We recommend that you log in to follow this quickstart with examples configured for your account.
        System requirements 
        • Android Studio 3.6.1
        • Android SDK 25
        • Emulator - Nexus 5X - Android 6.0
        This tutorial describes how to implement login with the Facebook SDK.​
        Before You Start
        Configure your Auth0 application in the dashboard to use Facebook Native Sign In. See Add Facebook Login to Native Apps. When you finish this step, your application will be able to implement Facebook Native Login.
        
+
+## 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.
        Set the requested permissions to public_profile and email. This way, the user email will also be included as part of the response, provided the access request is accepted by the user.
        loginButton.setPermissions(Arrays.asList("public_profile", "email"));
        
+
+## Create performLogin method {{{ data-action="code" data-code="performLogin + SimpleCallback" }}}
+
+
+
        Now, to kick off the authentication process with Auth0, create a new method in which you will prepare the payload to be sent.
        You will make use of a small interface to handle our internal callbacks.
        In the sample, the method was named performLogin and the interface SimpleCallback. Go ahead and add both.
        
+
+## Call performLogin method {{{ data-action="code" data-code="onCreate" }}}
+
+
+
        Now, call the method from the Facebook login callback's onSuccess method.
        
+
+## 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 {{{ data-action="code" data-code="fetchSessionToken" }}}
+
+
+
        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.
        The sample uses the Facebook SDK's GraphRequest class to perform this request.
        
+
+## Fetch Facebook user profile {{{ data-action="code" data-code="fetchUserProfile" }}}
+
+
+
        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.
        
+
+## 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
        1. Go to the Applications section of the Auth0 Dashboard 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.
        2. Copy the Domain and Client ID values from the application settings page. These are required by the SDK.
        3. Create two new resources in your Android application's strings.xml file to store them. The name of the keys must match the ones used below:
+
+
          <resources>
+
+    <string name="com_auth0_domain">${account.namespace}</string>
+
+    <string name="com_auth0_client_id">${account.clientId}</string>
+
+</resources>
+
+
          
+
+
        Install the Auth0 SDK
        In your Android application, add this line to the app/build.gradle file:
        dependencies {
+
+    implementation 'com.auth0.android:auth0:1.+'
+
+}
+
+
        
+
+
        Now is time to run the Gradle Sync task to refresh the project and its dependencies.
        Update manifest for web authentication
        If your application does not plan to make use of the Web Authentication module provided by the SDK, you will need to remove the unused activity from the AndroidManifest.xml file to prevent Manifest Placeholder issues. This can be achieved by adding an activity declaration and annotating it with tools:node="remove".
        <application>
+
+  <!-- Add the activity declaration line below -->
+
+   <activity
+
+    android:name="com.auth0.android.provider.AuthenticationActivity"
+
+    tools:node="remove" />
+
+
+
+</application>
+
+
        
+
+
        However, if you do plan to support Web Authentication, head over here to learn how to declare the Manifest Placeholders.
        
+
+## Exchange the received data for Auth0 tokens {{{ data-action="code" data-code="exchangeTokens" }}}
+
+
+
        The SDK must be instantiated before use. Define a field at the class level and initialize it on the onCreate method. Note how the credentials defined in the step above are passed to the Auth0 constructor and then a new instance of the AuthenticationAPIClient is created with it.
        private AuthenticationAPIClient auth0Client;
+
+
+
+@Override
+
+public void onCreate(Bundle savedInstanceState) {
+
+    super.onCreate(savedInstanceState);
+
+
+
+    setContentView(R.layout.activity_login);
+
+
+
+    Auth0 account = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+
+    auth0Client = new AuthenticationAPIClient(account);
+
+
+
+    //...
+
+}
+
+
        
+
+
        Create the method that will hold the logic to exchange the two obtained artifacts for Auth0 user credentials. In the sample, this method is named exchangeTokens.
        The API client declares the method loginWithNativeSocialToken that receives a token and a subject type. The former corresponds to the session token, and the latter indicates what type of connection the backend will attempt to authenticate with.
        For native Facebook Login, you will use the following value: "http://auth0.com/oauth/token-type/facebook-info-session-access-token"
        Other values that need to be configured are the user profile (using the user_profile key) and the scope you request the Auth0 tokens contain.
        It's a good practice to keep all the values that you know won't change as constants at the top of the class. The sample makes use of constants for the subject token type, the Facebook permissions, and the Auth0 scopes. You can read more about Auth0 scopes in the dedicated article.
        
+
+## Update performLogin method {{{ data-action="code" data-code="performLogin" }}}
+
+
+
        Now that every step is defined in its own method, it's time to put everything together inside the performLogin method.
        If everything went well, you should now be able to authenticate natively with the Facebook Login SDK. This means that if the Facebook app is installed on the device, the authentication will be handled via the application and not a browser app.
        
diff --git a/articles/quickstart/native/android/00-login.md b/articles/quickstart/native/android/00-login.md
index 546a83dbec..ac2a1c37d9 100755
--- a/articles/quickstart/native/android/00-login.md
+++ b/articles/quickstart/native/android/00-login.md
@@ -1,23 +1,246 @@
 ---
 title: Login
-description: This tutorial will show you how to integrate the Auth0 Universal Login in your Android project in order to present the login box.
+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
 ---
 
-This tutorial shows you how to integrate Auth0 in your Android project and present the login box.
+
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '00-Login',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
+<%= include('../_includes/_getting_started', { library: 'Android' }) %>
 
-<%= include('_includes/_auth0') %>
+<%= include('../../../_includes/_callback_url') %>
 
-<%= include('_includes/_login') %>
\ No newline at end of file
+::: 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 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.
+:::
+
+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.  Whenever possible, Auth0 recommends using  Android App Links with  https  as a secure way to link directly to content within your app. Custom URL schemes can be subject to client impersonation attacks. You can read more about setting this value in the Auth0.Android SDK readme.
+:::
+
+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.
+:::
+
+## Add Login to your App
+
+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.
+
+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, 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. 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.
+
+
        
+  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 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 users profile from Auth0. 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/articles/quickstart/native/android/01-embedded-login.md b/articles/quickstart/native/android/01-embedded-login.md
deleted file mode 100755
index 1cb4e4aba4..0000000000
--- a/articles/quickstart/native/android/01-embedded-login.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Embedded Login
-description: This tutorial will show you how to integrate Lock v2 in your Android project in order to present an Embedded Login screen.
-seo_alias: android
-budicon: 448
----
-
-This tutorial will show you how to integrate Lock v2 in your Android project in order to present an Embedded Login screen.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  branch: 'embedded-login',
-  path: '01-Embedded-Login',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-::: warning
-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](/hosted-pages/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/application-grant-types) for more information.
-:::
-
-<%= include('_includes/_lock') %>
-
-<%= include('_includes/_lock_manifest') %>
-
-<%= include('_includes/_lock_login') %>
-
-### Optional: Log In with Social Connections
-
-To have a simple login mechanism through social connections, all you have to do is enable them in your account's [dashboard](${manage_url}/#/connections/social). Every social connection you switch on there, will appear in the login screen of your app.
diff --git a/articles/quickstart/native/android/01-user-metadata.md b/articles/quickstart/native/android/01-user-metadata.md
new file mode 100644
index 0000000000..50f6f12e95
--- /dev/null
+++ b/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
+:::
+
+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, you saw how to access basic user profile information 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, 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 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 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 and not part of the OIDC spec. You must call the Auth0 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 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 by inspecting the user and looking at the metadata collection in your web browser.
+:::
diff --git a/articles/quickstart/native/android/02-custom-login-form.md b/articles/quickstart/native/android/02-custom-login-form.md
deleted file mode 100755
index a6041f28ae..0000000000
--- a/articles/quickstart/native/android/02-custom-login-form.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Custom Login Form
-description: This tutorial will show you how to use the Auth0 authentication API in your Android project to create a custom login form.
-seo_alias: android
-budicon: 448
----
-
-This quickstart will show you how to add Auth0 login capabilities while using a customized login form.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  branch: 'embedded-login',
-  path: '02-Custom-Login-Form',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Before Starting
-
-You'll first need to whitelist the **Callback URL** in the "Allowed Callback URLs" section of the [Application settings](${manage_url}/#/applications) by adding the URL below. Remember to replace `YOUR_APP_PACKAGE_NAME` with your actual application's package name, available in the `app/build.gradle` file as the `applicationId` attribute:
-
-```text
-demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback
-```
-
-<%= include('_includes/_auth0') %>__
-
-### Configure Your Manifest File
-
-You need to add the INTERNET permission inside the `AndroidManifest.xml`:
-
-```xml
-
-```
-
-## Implement The Login
-
-At this point, you're all set to implement the login in any activity you want.
-
-### Using a Database connection
-
-First, you'll need to instantiate the Authentication API:
-
-```java
-Auth0 auth0 = new Auth0(this);
-auth0.setOIDCConformant(true);
-AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
-```
-
-Then, login using the username and password.
-
-```java
-private void login(String email, String password) {
-    //...
-    String connectionName = "Username-Password-Authentication";
-    client.login(email, password, connectionName)
-        .setAudience(String.format("https://%s/userinfo", getString(R.string.com_auth0_domain)))
-        .start(new BaseCallback() {
-            @Override
-            public void onSuccess(Credentials payload) {
-                // Store credentials
-                // Navigate to your main activity
-            }
-
-            @Override
-            public void onFailure(AuthenticationException error) {
-                // Show error to user
-            }
-        });
-}
-```
-
-This example uses an Auth0 Database Connection called "Username-Password-Authentication" for logging in. You can also [create your own](${manage_url}/#/connections/database/new) connection.
-
-::: note
-There are multiple ways of designing a customized login screen which are not covered in this tutorial. You can take the [Android Studio's login template](https://developer.android.com/studio/projects/templates.html) as an example.
-:::
-
-### Using a Social connection
-
-You'll use the `WebAuthProvider#init` method. If no connection name is given, the login page will be shown and the user may choose any of the connections enabled for your application. By calling `withConnection` you can force the user to use a specific connection. Let's do that for `Twitter`. Make sure to use a connection that is enabled in your application!
-
-```java
-private void login() {
-    Auth0 auth0 = new Auth0(this);
-    auth0.setOIDCConformant(true);
-    WebAuthProvider.init(auth0)
-        .withScheme("demo")
-        .withAudience(String.format("https://%s/userinfo", getString(R.string.com_auth0_domain)))
-        .withConnection("twitter")
-        .start(this, new AuthCallback() {
-            @Override
-            public void onFailure(@NonNull Dialog dialog) {
-                // Show error Dialog to user
-            }
-
-            @Override
-            public void onFailure(AuthenticationException exception) {
-                // Show error to user
-            }
-
-            @Override
-            public void onSuccess(@NonNull Credentials credentials) {
-                // Store credentials
-                // Navigate to your main activity
-            }
-    });
-}
-```
-
-There are many options to customize the authentication using `WebAuthProvider`. Make sure to check them [here](/libraries/auth0-android#implementing-web-based-auth).
diff --git a/articles/quickstart/native/android/03-session-handling.md b/articles/quickstart/native/android/03-session-handling.md
deleted file mode 100644
index 93150210a3..0000000000
--- a/articles/quickstart/native/android/03-session-handling.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-title: Session Handling
-description: This tutorial will show you how to login and maintain a session’s connectivity.
-seo_alias: android
-budicon: 280
----
-
-This tutorial shows you how to let users log in and maintain an active session with Auth0.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '03-Session-Handling',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-You need the `Credentials` class to handle users' credentials. The class is composed of these elements:
-
-* `accessToken`: Access Token used by the Auth0 API. To learn more, see the [Access Token documentation](/tokens/access-token).
-* `idToken`: Identity Token that proves the identity of the user. To learn more, see the [ID Token documentation](/tokens/id-token).
-* `refreshToken`: Refresh Token that can be used to request new tokens without signing in again. To learn more, see the [Refresh Token documentation](/tokens/refresh-token/current).
-* `tokenType`: The type of tokens issued by the server.
-* `expiresIn`: The number of seconds before the tokens expire.
-* `expiresAt`: The date when the tokens expire.
-* `scope`: The scope that was granted to a user. This information is shown only if the granted scope is different than the requested one.
-
-Tokens are objects used to prove your identity against the Auth0 APIs. Read more about them in the [tokens documentation](https://auth0.com/docs/tokens).
-
-## Before You Start
-
-::: note
-Before you continue with this tutorial, make sure that you have completed the [Login](/quickstart/native/android/00-login) tutorial.
-:::
-
-Before you launch the login process, make sure you get a valid Refresh Token in the response. To do that, ask for the `offline_access` scope. Find the snippet in which you are initializing the `WebAuthProvider` class. To that snippet, add the line `withScope("openid offline_access")`.
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-
-Auth0 auth0 = new Auth0(this);
-auth0.setOIDCConformant(true);
-WebAuthProvider.init(auth0)
-    .withScheme("demo")
-    .withAudience(String.format("https://%s/userinfo", getString(R.string.com_auth0_domain)))
-    .withScope("openid offline_access")
-    .start(LoginActivity.this, webCallback);
-```
-
-## Check for Tokens when the Application Starts
-
-::: panel Learn about Refresh Tokens
-Before you go further with this tutorial, read the [refresh token documentation](/refresh-token).
-It is important that you remember the following:
-* Refresh Tokens must be securely saved.
-* Even though Refresh Tokens cannot expire, they can be revoked.
-* New tokens will have the same scope as was originally requested during the first authentication.
-:::
-
-You can simplify the way you handle user sessions using a Credential Manager class, which knows how to securely store, retrieve and renew credentials obtained from Auth0. Two classes are provided in the SDK to help you achieve this. Further read on how they work and their implementation differences is available in the [Saving and Renewing Tokens](/libraries/auth0-android/save-and-refresh-tokens.md) article. For this series of tutorials we're going to use the `SecureCredentialsManager` class as it encrypts the credentials before storing them in a private SharedPreferences file.
-
-
-Create a new instance of the Credentials Manager. When you run the application, you should check if there are any previously stored credentials. You can use these credentials to bypass the login screen:
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-  Auth0 auth0 = new Auth0(this);
-  auth0.setOIDCConformant(true);
-  AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
-  SecureCredentialsManager credentialsManager = new SecureCredentialsManager(this, client, new SharedPreferencesStorage(this));
-
-  // Check if the activity was launched after a logout
-  if (getIntent().getBooleanExtra(KEY_CLEAR_CREDENTIALS, false)) {
-      credentialsManager.clearCredentials();
-  }
-
-  if (!credentialsManager.hasValidCredentials()) {
-    // Prompt Login screen.
-  } else {
-    // Obtain credentials and move to the next activity
-  }
-```
-
-::: note
-Ideally a single class should manage the handling of credentials. You can share this instance across activities or create a new one every time is required as long as the Storage strategy persists the data in the same location. Check the `LoginActivity` class to understand how to achieve this in a single class.
-:::
-
-
-## Save the User's Credentials
-
-After a successful login response, you can store the user's credentials using the `saveCredentials` method.
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-
-private final AuthCallback webCallback = new AuthCallback() {
-    @Override
-    public void onFailure(@NonNull final Dialog dialog) {
-        //show error dialog
-    }
-
-    @Override
-    public void onFailure(AuthenticationException exception) {
-        //show error message
-    }
-
-    @Override
-    public void onSuccess(@NonNull Credentials credentials) {
-        //user successfully authenticated
-        credentialsManager.saveCredentials(credentials);
-    }
-};
-```
-
-::: note
-A Storage defines how data is going to be persisted in the device. The Storage implementation given to the Credentials Manager in the seed project uses a SharedPreferences file to store the user credentials in [Private mode](https://developer.android.com/reference/android/content/Context.html#MODE_PRIVATE). You can modify this behavior by implementing a custom Storage. 
-:::
-
-## Recover the User's Credentials
-
-Retrieving the credentials from the Credentials Manager is an async process, as credentials may have expired and require to be refreshed. This renewing process is done automatically by the Credentials Manager as long as a valid Refresh Token is currently stored. A `CredentialsManagerException` exception will be raised if the credentials cannot be renewed.
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-
-credentialsManager.getCredentials(new BaseCallback() {
-    @Override
-    public void onSuccess(Credentials credentials) {
-        // Move to the next activity
-    }
-
-    @Override
-    public void onFailure(CredentialsManagerException error) {
-        // Credentials could not be refreshed.
-    }
-});
-```
-
-::: note
-The `SecureCredentialsManager` can prompt the user for local device authentication using the configured Lock Screen (PIN, Password, Pattern, Fingerprint) before giving them the stored credentials. This behavior can be enabled calling the `SecureCredentialsManager#requireAuthentication` method when setting up the Credentials Manager. The sample has this line commented for convenience, remove the comment to try it. 
-:::
-
-## Log the User Out
-
-To log the user out, you remove their credentials and navigate them to the login screen. When using a Credentials Manager you do that calling `clearCredentials`.
-
-In the sample, the LoginActivity checks that a boolean extra is present in the Intent at the Activity launch, so that if this flag is true the credentials are first removed from the Credentials Manager.
-
-```java
-// app/src/main/java/com/auth0/samples/MainActivity.java
-
-private void logout() {
-    Intent intent = new Intent(this, LoginActivity.class);
-    intent.putExtra(LoginActivity.KEY_CLEAR_CREDENTIALS, true);
-    startActivity(intent);
-    finish();
-}
-
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-@Override
-protected void onCreate(Bundle savedInstanceState) {
-    //...
-    if (getIntent().getBooleanExtra(KEY_CLEAR_CREDENTIALS, false)) {
-        credentialsManager.clearCredentials();
-    }
-}
-```
-
-::: note
-If you are not using our Credentials Manager classes, you are responsible for ensuring that the user's credentials have been removed.
-:::
\ No newline at end of file
diff --git a/articles/quickstart/native/android/04-user-profile.md b/articles/quickstart/native/android/04-user-profile.md
deleted file mode 100755
index 663fee9aa7..0000000000
--- a/articles/quickstart/native/android/04-user-profile.md
+++ /dev/null
@@ -1,188 +0,0 @@
----
-title: User Profile
-description: This tutorial will show you how to get and modify the user's profile data.
-seo_alias: android
-budicon: 292
----
-
-This tutorial shows you how to get and modify the user's profile data with Auth0 in your Android apps.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '04-User-Profile',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Before You Start
-
-::: note
-Before you continue with this tutorial, make sure that you have completed the [Login](/quickstart/native/android/00-login) and [Session Handling](/quickstart/native/android/03-session-handling) tutorials. To call the API applications, you need a valid Access Token and ID Token.
-:::
-
-Before launching the login process, you need to make sure the authorization server allows you to read and edit the current user profile. To do that, ask for the `openid profile email read:current_user update:current_user_metadata` scope and the Management API audience, which happens to include the User Info audience as well. Find the snippet in which you initialize the `WebAuthProvider` class. To that snippet, add the line `withScope("openid profile email read:current_user update:current_user_metadata")` and `withAudience(String.format("https://%s/api/v2/", getString(R.string.com_auth0_domain)))`.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/LoginActivity.java
-
-Auth0 auth0 = new Auth0(this);
-auth0.setOIDCConformant(true);
-WebAuthProvider.init(auth0)
-    .withScheme("demo")
-    .withAudience(String.format("https://%s/api/v2/", getString(R.string.com_auth0_domain)))
-    .withScope("openid profile email read:current_user update:current_user_metadata")
-    .start(this, callback);
-```
-
-::: note
-Note that the Management API audience value ends in `/` in constrast to the User Info audience. 
-:::
-
-## Request User Data
-
-
-To get the user's information:
-1. Use the user's access token to call the `userInfo` method in the `AuthenticationAPIClient` application instance.
-The profile obtained this way is OIDC-conformant. Depending on the [scopes](/scopes/current) you requested when logging in, the profile contains different information. The result will never contain fields outside the OIDC specification.
-2. Get the user's full profile using the [Management API](/api/management/v2#!/Users). Since fields such as [user_metadata](#additional-information) are not part of the OIDC specification you need to obtain the full profile to read them. This step is explained next:
-
-
-Create an instance of the Users API application using the Access Token that you saved in the log in step. This Access Token can be used to authorize requests since you've requested the Management API audience and the corresponding user entity scopes in the login step. In the snippet bellow we obtain the token from the extras that the LoginActivity class has passed when starting this activity. The API application is used to request the user's profile data.
-
-Create now an instance of the Authentication API application. This time is used to call the userinfo endpoint and retrieve the ID of the user to whom the token was issued.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-Auth0 auth0 = new Auth0(this);
-auth0.setOIDCConformant(true);
-
-String accessToken = getIntent().getStringExtra(LoginActivity.KEY_ACCESS_TOKEN);
-UsersAPIClient usersClient = new UsersAPIClient(auth0, accessToken);
-AuthenticationAPIClient authenticationAPIClient = new AuthenticationAPIClient(auth0);
-```
-
-::: note
-Do not hardcode the Auth0 `domain` and `clientId` values when creating the Auth0 instance. We recommend you add them to the `strings.xml` file.
-:::
-
-
-To get the user's profile:
-1. Use the user's Access Token to call the `userInfo` method in the `AuthenticationAPIClient` application instance.
-You get an instance of the `UserProfile` profile. The profile is OIDC-conformant. Depending on the on the [scopes](/scopes/current) you requested, the profile contains different information. 
-2. To get the user's full profile, use the [Management API](/api/management/v2#!/Users). Use the user ID obtained in previous step to call `getProfile` on the Users API application and obtain the full user profile. Use the received data to update the layout.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-authenticationAPIClient.userInfo(accessToken)
-    .start(new BaseCallback() {
-        @Override
-        public void onSuccess(UserProfile userinfo) {
-            usersClient.getProfile(userinfo.getId())
-                .start(new BaseCallback() {
-                    @Override
-                    public void onSuccess(UserProfile profile) {
-                      // Display the user profile        
-                    }
-
-                    @Override
-                    public void onFailure(ManagementException error) {
-                      // Show error                            
-                    }
-                });
-        }
-
-        @Override
-        public void onFailure(AuthenticationException error) {
-            // Show error
-        }
-    });
-```
-
-## Access the Data Inside the Received Profile
-
-### Default information
-
-At this point, you already have access to the full version of the `UserProfile` instance.
-You can use this data wherever you need it.
-
-Some examples are:
-
-```java
-profile.getName();
-profile.getEmail();
-profile.getPictureURL();
-```
-
-::: panel Modifying the UI
-You cannot modify the UI inside the callback methods as they run in a different thread. To solve this issue you can choose between three options:
-* Persist the data and then retrieve it
-* Create a task in the UI thread and run it. i.e. using the `Activity#runOnUiThread` method.
-* Create a `Handler` to post the information
-:::
-
-### Additional information
-
-You can handle additional information within any of the following maps:
-
-#### A. User metadata
-
-The `userMetadata` map contains user profile fields that can be added from the client-side (such as when a user edits their profile). You can access this information in the following way:
-
-```java
-String country = (String) profile.getUserMetadata().get("country");
-```
-
-::: note
-You can choose the key names and value types for subscripting the `user_metadata` map.
-:::
-
-#### B. App metadata
-
-The `appMetadata` map contains fields that are usually added with a [Rule](/rules) or a [Hook](/hooks). For native platforms, this information is read-only.
-
-::: note
-To learn more about metadata, see the [metadata documentation](/metadata).
-:::
-
-#### C. Extra information
-
-The `extraInfo` map contains additional values that are stored in Auth0 but not mapped to a `UserProfile` getter method. For native platforms, this information is read-only.
-
-## Update the User's Profile
-
-You can only update the user metadata. To do this, create a `Map` object and add the information you want to store.
-
-```java
-Map userMetadata = new HashMap<>();
-userMetadata.put("country", "USA");
-```
-
-Update the information with the Users API application created before:
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-usersClient.updateMetadata(userInfo.getId(), userMetadata).start(new BaseCallback() {
-  @Override
-  public void onSuccess(UserProfile profile) {
-    // As receive the updated profile here
-    // You can react to this, and show the information to the user.
-  }
-
-  @Override
-  public void onFailure(ManagementException error) {
-    //show error
-  }
-});
-```
-
-
-::: note
-A call to `updateMetadata` will replace any previous user metadata stored in Auth0. Remember to copy the old values that you wish to maintain. 
-::: 
diff --git a/articles/quickstart/native/android/05-linking-accounts.md b/articles/quickstart/native/android/05-linking-accounts.md
deleted file mode 100755
index 6ceece1c4d..0000000000
--- a/articles/quickstart/native/android/05-linking-accounts.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: Linking Accounts
-description: This tutorial will show you how to link two different accounts for the same user.
-seo_alias: android
-budicon: 345
----
-
-This tutorial shows you how to link two different accounts for the same user using Auth0.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '05-Linking-Accounts',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have integrated [Auth0](https://github.com/auth0/Auth0.Android) as a dependency in your project.
-* You are familiar with the `WebAuthProvider` class. To learn more, see the [Login](/quickstart/native/android/00-login) and the [Session Handling](/quickstart/native/android/03-session-handling) tutorials.
-* You are familiar with the concepts of `userId`, `accessToken` and `idToken`. You can find info about them in the [Session Handling](/quickstart/native/android/03-session-handling) and the [User Profile](/quickstart/native/android/04-user-profile) tutorials.
-
-We recommend that you read the [Linking Accounts](/link-accounts) documentation to understand the process of linking accounts.
-
-## API scopes on Authentication
-
-As seen previously in the [User Profile](/quickstart/native/android/04-user-profile) tutorial, you need to request the Management API audience and the corresponding scopes to be able to read the full user profile and edit their identities, since they are not part of the OIDC specification. Each identity in the user profile represents details from the authentication provider used to log in. e.g. the user's Facebook account details.
-
-Find the snippet in which you initialize the `WebAuthProvider` class. To that snippet, add the line `withScope("openid profile email read:current_user update:current_user_identities")` and `withAudience(String.format("https://%s/api/v2/", getString(R.string.com_auth0_domain)))`.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/LoginActivity.java
-
-Auth0 auth0 = new Auth0(this);
-auth0.setOIDCConformant(true);
-WebAuthProvider.init(auth0)
-    .withScheme("demo")
-    .withAudience(String.format("https://%s/api/v2/", getString(R.string.com_auth0_domain)))
-    .withScope("openid profile email read:current_user update:current_user_identities")
-    .start(this, callback);
-```
-
-::: note
-Note that the Management API audience value ends in `/` in constrast to the User Info audience. 
-:::
-
-
-## Enter Account Credentials
-
-Your users may want to link their other accounts to the account they are logged in to.
-
-To achieve this, you need to store the user ID for the logged user in the Intent, along with the ID Token and Access Token provided by the LoginActivity at launch, which are already available in the intent extras. 
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-Intent intent = new Intent(MainActivity.this, LoginActivity.class);        
-intent.putExtras(getIntent().getExtras());
-intent.putExtra(LoginActivity.KEY_LINK_ACCOUNTS, true);
-intent.putExtra(LoginActivity.KEY_PRIMARY_USER_ID, profile.getId());
-startActivity(intent);
-```
-
-Obtain the stored values in `LoginActivity`.
-
-First in `onCreate`, check if a new account linking was requested. Check as well if a previous `savedInstanceState` exists and contains the "logging in" state. This flag is set when the web authentication is launched and must be correctly handled to avoid state loss.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/LoginActivity.java
-
-private boolean linkSession;
-private boolean logginIn;
-
-@Override
-protected void onCreate(Bundle savedInstanceState) {
-  super.onCreate(savedInstanceState);
-
-  auth0 = new Auth0(this);
-  auth0.setOIDCConformant(true);
-  credentialsManager = new SecureCredentialsManager(this, new AuthenticationAPIClient(auth0), new SharedPreferencesStorage(this));
-
-  linkSessions = getIntent().getBooleanExtra(KEY_LINK_ACCOUNTS, false);
-  loggingIn = savedInstanceState != null && savedInstanceState.getBoolean(KEY_LOG_IN_IN_PROGRESS, false);
-
-  // Normal log in with existing credentials
-  if (!linkSessions && credentialsManager.hasValidCredentials()) {
-    // Obtain the existing credentials and move to the next activity
-    credentialsManager.getCredentials(new BaseCallback() {
-        @Override
-        public void onSuccess(Credentials credentials) {
-            showNextActivity(credentials);
-        }
-
-        @Override
-        public void onFailure(CredentialsManagerException error) {
-            //Authentication cancelled by the user. Exit the app
-            finish();
-        }
-    });
-    return;
-  }
-
-  // Show log in layout
-  setContentView(R.layout.activity_login);
-  final Button loginButton = (Button) findViewById(R.id.loginButton); 
-  loginButton.setOnClickListener(new View.OnClickListener() {
-        @Override
-        public void onClick(View v) {
-            doLogin();
-        }
-  });
-
-  // Account linking was requested
-  if (linkSessions && !loggingIn) {
-    loginButton.setText(R.string.link_account);
-    //Auto log in but allow to retry if authentication is cancelled
-    doLogin();
-  }
-}
-
-@Override
-protected void onSaveInstanceState(Bundle outState) {
-  outState.putBoolean(KEY_LOG_IN_IN_PROGRESS, loggingIn);
-  super.onSaveInstanceState(outState);
-}
-```
-
-In the login response, based on the boolean flag set in the first step, decide if you need to show the `MainActivity` screen, or continue to link the accounts.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/LoginActivity.java
-
-private final AuthCallback webCallback = new AuthCallback() {
-    @Override
-    public void onFailure(@NonNull final Dialog dialog) {
-        //show error message 
-        //If currently linking accounts, finish.
-    }
-
-    @Override
-    public void onFailure(AuthenticationException exception) {
-        //show error message 
-        //If currently linking accounts, finish.
-    }
-
-    @Override
-    public void onSuccess(@NonNull Credentials credentials) {
-        if (linkSessions) {
-            // Link the accounts
-            performLink(credentials.getIdToken());
-            return;
-        }
-
-        //Store the credentials and move to the next activity
-        credentialsManager.saveCredentials(credentials);
-        showNextActivity(credentials);
-    }
-};
-```
-
-::: note
-Make sure to handle the callback's failure calls as well
-:::
-
-
-## Link the Accounts
-
-Now, you can link the accounts. To do this, you need the logged-in user's ID and Access Token, and the ID Token for the secondary account received in the last login response.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/LoginActivity.java
-
-private void performLink(final String secondaryIdToken) {
-    UsersAPIClient client = new UsersAPIClient(auth0, getIntent().getExtras().getString(KEY_ACCESS_TOKEN));
-    String primaryUserId = getIntent().getExtras().getString(KEY_PRIMARY_USER_ID);
-    client.link(primaryUserId, secondaryIdToken)
-        .start(new BaseCallback, ManagementException>() {
-            @Override
-            public void onSuccess(List userIdentities) {
-                //Accounts linked
-            }
-
-            @Override
-            public void onFailure(ManagementException error) {
-                //Linking failed
-            }
-        });
-}
-```
-
-## Retrieve the Linked Accounts
-
-The updated list of identities is returned in the `link` method response. Alternatively, obtain the user's full profile, use the user's ID to call the `getProfile` method in the `UsersAPIClient` class. The profile includes the linked accounts as the `UserIdentities` array.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-usersClient.getProfile(userInfo.getId())
-    .start(new BaseCallback() {
-        @Override
-        public void onSuccess(UserProfile fullProfile) {
-            // Display the updated user profile
-        }
-
-        @Override
-        public void onFailure(ManagementException error) {
-            // Show error
-        }
-    });
-```
-
-::: note
-For more information, check the [UserIdentity.java class documentation](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/result/UserIdentity.java).
-:::
-
-## Unlink the Accounts
-
-To unlink the accounts, you need to specify the following:
-* user ID for the main account
-* user ID for the linked account
-* the provider name for the linked account
-
-To instantiate the `UsersAPIClient` client, use the Access Token for the main account like before.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-usersClient.unlink(userProfile.getId(), secondaryAccountIdentity.getId(), secondaryAccountIdentity.getProvider())
-    .start(new BaseCallback, ManagementException>() {
-        @Override
-        public void onSuccess(List userIdentities) {
-            //Accounts unlinked
-        }
-
-        @Override
-        public void onFailure(ManagementException error) {
-            //Accounts unlink failed
-        }
-    });
-```
diff --git a/articles/quickstart/native/android/06-calling-apis.md b/articles/quickstart/native/android/06-calling-apis.md
deleted file mode 100755
index acf393f6ad..0000000000
--- a/articles/quickstart/native/android/06-calling-apis.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: Calling APIs
-description: This tutorial will show you how to use the Auth0 tokens to make authenticated API calls.
-seo_alias: android
-budicon: 546
----
-
-You may want to restrict access to your API resources, so that only authenticated users with sufficient privileges can access them. Auth0 lets you manage access to these resources using [API Authorization](/api-auth).
-
-This tutorial shows you how to access protected resources in your API.
-
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '06-Calling-APIs',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have completed the [Session Handling](/quickstart/native/android/03-session-handling) tutorial and you know how to handle the `Credentials` object.
-* You have set up a backend application as API. To learn how to do it, follow one of the [backend tutorials](/quickstart/backend).
-
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>__
-
-
-## Get the User's Access Token
-
-To retrieve an Access Token that is authorized to access your API, you need to specify the API Identifier you created in the Auth0 dashboard before. At the top of the class add the constants for accessing the API: API_URL and API_IDENTIFIER
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-private static final String API_URL = "localhost:8080/secure";
-private static final String API_IDENTIFIER = "https://api.mysite.com";
-
-private void login() {
-    Auth0 auth0 = new Auth0(this);
-    auth0.setOIDCConformant(true);
-    WebAuthProvider.init(auth0)
-        .withScheme("demo")
-        .withAudience(API_IDENTIFIER)
-        .start(LoginActivity.this, new AuthCallback() {
-            @Override
-            public void onFailure(@NonNull Dialog dialog) {
-                // Show error Dialog to user
-            }
-
-            @Override
-            public void onFailure(AuthenticationException exception) {
-                // Show error to user
-            }
-
-            @Override
-            public void onSuccess(@NonNull Credentials credentials) {
-                // Verify tokens and Store credentials
-            }
-    });
-}
-```
-
-::: note
-For instructions on how to authenticate a user, see the [Login](/quickstart/native/android/00-login) tutorial.
-:::
-
-## Attach the Token
-
-To give the authenticated user access to secured resources in your API, include the user's Access Token in the requests you send to the API.
-
-::: note
-In this example, we use the [OkHttp](https://github.com/square/okhttp) library.
-:::
-
-Create an instance of the `OkHttpClient` client and a new `Request`. Use the provided builder to customize the Http method, the URL and the headers in the request. Set the **Authorization** header with the token type and the user's Access Token.
-
-::: note
-Depending on the standards in your API, you configure the authorization header differently. The code below is just an example.
-:::
-
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-
-OkHttpClient client = new OkHttpClient();
-Request request = new Request.Builder()
-    .get()
-    .url(API_URL)
-    .addHeader("Authorization", "Bearer " + accessToken);
-    .build();
-```
-
-## Send the Request
-
-Tell the client to create a new `Call` with the request you created. Call the `enqueue` function to execute the request asynchronously.
-
-```java
-// app/src/main/java/com/auth0/samples/LoginActivity.java
-
-client.newCall(request).enqueue(new Callback() {
-    @Override
-    public void onFailure(Request request, IOException e) {
-        //show error
-    }
-
-    @Override
-    public void onResponse(final Response response) throws IOException {
-        if (response.isSuccessful()) {
-            //API call success
-        } else {
-            //API call failed. Check http error code and message
-        }
-    }
-});
-```
-
-You need to configure your backend application to protect your API endpoints with the key for your Auth0 application, API identifier and API scopes. In this example, you can use the user's Access Token issued by Auth0 to call your own APIs.
diff --git a/articles/quickstart/native/android/07-authorization.md b/articles/quickstart/native/android/07-authorization.md
deleted file mode 100755
index 5a9d310c6c..0000000000
--- a/articles/quickstart/native/android/07-authorization.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Authorization
-description: This tutorial will show you how to use the Auth0 authentication API in your Android project to create a custom login screen.
-seo_alias: android
-budicon: 500
----
-
-This tutorial shows you how to use Auth0 to create access roles for your users. With access roles, you can authorize or deny access to your content to different users based on the level of access they have.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '07-Authorization',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Before You Start
-
-::: note
-Be sure that you have completed the [Login](/quickstart/native/android/00-login) quickstart.
-:::
-
-Create a rule that assigns the users either an `admin` role, or a simple `user` role. Go to the [new rule page](${manage_url}/#/rules/new) and select the "Set Roles To A User" template, under **Access Control**. Replace the default script contents with the following snippet:
-
-```js
-function (user, context, callback) {
-
-  //Define the name of the claim. Must look like a url:
-  //Have 'http' or 'https' scheme and a hostname other than
-  //'auth0.com', 'webtask.io' and 'webtask.run'.
-  var claimName = 'https://access.control/roles';
-
-  //Check if the email has the 'admin.com' domain and give the 'admin' role.
-  //Otherwise, keep a default 'user' role.
-  var roles = ['user'];
-  if (user.email && user.email.indexOf('@admin.com') > -1) {
-      roles.push('admin');
-  }
-  //Set the role claim in the id_token
-  context.idToken[claimName] = roles;
-
-  callback(null, user, context);
-}
-```
-
-The default rules for assigning access roles are:
-* If the user's email contains `@example.com`, the user gets the admin role.
-* If the email contains anything else, the user gets the regular user role.
-
-::: note
-The rule can be customized to grant the user different roles other than the ones explained here, depending on the conditions required in a project. There is a restriction on the name of the claims added to the ID Token which must be name-spaced (look like a URL). Read [this article](/rules/current#hello-world) for more context about Rules.
-:::
-
-
-## Test the Rule in Your Project
-
-Once the user credentials had been obtained (as explained in the [Login](/quickstart/native/android/00-login) tutorial), save them to access them at any time.
-
-The claims added to the ID Token via a Rule are included in the userinfo endpoint response. Use the Access Token to call this endpoint and obtain the user roles.
-
-```java
-// app/src/main/java/com/auth0/samples/activities/MainActivity.java
-
-authenticationClient.userInfo(accessToken)
-  .start(new BaseCallback() {
-      @Override
-      public void onSuccess(UserProfile userInfo) {
-        //Obtain the claim from the "extra info" of the user info
-        List roles = userInfo.getExtraInfo().containsKey("https://access.control/roles") ? (List) userInfo.getExtraInfo().get("https://access.control/roles") : Collections.emptyList();
-        
-        if (!roles.contains("admin")) {
-          // User is not authorized
-        } else {
-          // User is authorized  
-        }
-      }
-
-      @Override
-      public void onFailure(AuthenticationException error) {
-          // Show error
-      }
-  });
-```
-
-## Restrict Content Based On Access Level
-
-Roles can be used to distinguish user permissions within an app, authorizing or denying access to a certain feature. The sample project illustrates this by allowing users with the `admin` role to access the "Settings Activity".
diff --git a/articles/quickstart/native/android/_includes/_api_authz.md b/articles/quickstart/native/android/_includes/_api_authz.md
deleted file mode 100755
index ce5c91e660..0000000000
--- a/articles/quickstart/native/android/_includes/_api_authz.md
+++ /dev/null
@@ -1,125 +0,0 @@
-## Configuring Your Application
-
-## Dependencies
-
-This quickstart uses the Auth0.Android SDK to help you add authentication and API authorization to your Android app. To install it, simply add the following line to your module build.gradle file:
-
-```gradle
-dependencies {
-    compile "com.auth0.android:auth0:1.+"
-}
-```
-
-::: note
-You can check for the latest version on the repository [Readme](https://github.com/auth0/auth0.android#installation), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22auth0%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/auth0).
-:::
-
-Next, Syncronize bundle.gradle in Android Studio or run `./gradlew clean assembleDebug` from the command line.
-
-::: note
-For more information about Gradle usage, check [their official documentation](http://tools.android.com/tech-docs/new-build-system/user-guide).
-:::
-
-## Configuration
-
-First, you need to update `AndroidManifest.xml` with the following:
-
-```xml
-
-    
-        
-        
-        
-        
-    
-
-```
-
-Replace `YOUR_APP_PACKAGE_NAME` with your actual application's package name.
-
-
-Also include following permission:
-
-```xml
-
-```
-
-Finally, open the Dashboard and make sure the Allowed Callback URLs for your application contains a URL with the following format:
-
-`demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`
-
-Replace `YOUR_APP_PACKAGE_NAME` with your actual application's package name.
-
-
-## Initiate Authentication and Authorization
-
-First create an instance of Auth0 with your application information:
-
-```java
-Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
-account.setOIDCConformant(true);
-```
-
-Next, you need to use the `WebAuthProvider` to initiate the authentication and authorization. Note that we customize the scheme to `demo` as required by the Callback URL defined also in the intent-filter.
-
-```java
-public void startAuth() {
-    WebAuthProvider.init(account)
-        .withConnection("Username-Password-Authentication")
-        .withScope("openid profile {API_SCOPES}")
-        .withAudience("${apiIdentifier}")
-        .withScheme("demo")
-        .start(MainActivity.this, authCallback);
-}
-
-private AuthCallback authCallback = new AuthCallback() {
-    @Override
-    public void onSuccess(Credentials credentials) {
-        // here you have access to the tokens
-        // payload.getAccessToken()
-        // payload.getIdToken()
-        // payload.getRefreshToken()
-    }
-
-    @Override
-    public void onFailure(Dialog dialog) {
-        // Called when the failure reason is displayed in a android.app.Dialog
-    }
-
-    @Override
-    public void onFailure(AuthenticationException exception) {
-        //Called with an AuthenticationException that describes the error
-    }
-};
-```
-
-The `audience` parameter should contain your API identifier from the Dashboard. If you don't send this, the runtime will take it from the tenant settings (`tenant.default_audience` or you can set it in the Dashboard). The `scope` parameter should include one or more scopes you defined in the Dashboard for your API, in addition to any of the standard [OpenID scopes](https://auth0.com/docs/scopes).
-
-You also need to override the `onNewIntent` method in your Activity to resume the flow once the user has finished in the Browser:
-
-```java
-@Override
-protected void onNewIntent(Intent intent) {
-    if (WebAuthProvider.resume(intent)) {
-        return;
-    }
-    super.onNewIntent(intent);
-}
-```
-
-## Making an Authenticated API Call
-
-Use the `access_token` to invoke your Resource Server (API). In this example we are using the [Unirest library for Java](http://unirest.io/java.html):
-
-```java
-HttpResponse response = Unirest.get("https://someapi.com/api")
-    .header("content-type", "application/json")
-    .header("Authorization", "Bearer {ACCESS_TOKEN}")
-    .asString();
-```
-
-The Resource Server (API) should be configured to verify the JWT and any claims contained within it. Because the Resource Server is utilizing the RS256 signature method, tokens are signed using Auth0's private key for your account. Verification is done using the corresponding public key, which can be found at the following standard [JWKS (JSON Web Key set)](https://self-issued.info/docs/draft-ietf-jose-json-web-key.html) URL: [https://${account.namespace}/.well-known/jwks.json]. You can use any [recommended JWT library](https://jwt.io) to validate the standard claims returned in the token. These details are outside the scope of this quickstart tutorial. More information can be found [in our documentation](https://auth0.com/docs/api-auth/config/asking-for-access-tokens).
diff --git a/articles/quickstart/native/android/_includes/_auth0.md b/articles/quickstart/native/android/_includes/_auth0.md
deleted file mode 100755
index 79760dd630..0000000000
--- a/articles/quickstart/native/android/_includes/_auth0.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Add the Auth0 Android Dependency
-
-Add the [Auth0 Android](https://github.com/auth0/Auth0.Android) SDK into your project. The library makes requests to the Auth0's Authentication and Management APIs.
-
-### Add Auth0 to Gradle
-
-In your app's `build.gradle` dependencies section, add the following:
-
-```xml
-apply plugin: 'com.android.application'
-android {
-  //..
-}
-dependencies {
-  //---> Add the next line
-  compile 'com.auth0.android:auth0:1.+'
-  //<---
-}
-```
-
-::: note
-You can check for the latest version on the [repository Readme](https://github.com/auth0/auth0.android#installation), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22auth0%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/auth0).
-:::
-
-Add manifest placeholders required by the SDK. The placeholders are used internally to define an `intent-filter` that captures the authentication callback URL. 
-
-To add the manifest placeholders, add the next line:
-
-```xml
-apply plugin: 'com.android.application'
-android {
-    compileSdkVersion 25
-    buildToolsVersion "25.0.3"
-    defaultConfig {
-        applicationId "com.auth0.samples"
-        minSdkVersion 15
-        targetSdkVersion 25
-        //...
-
-        //---> Add the next line
-        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"]
-        //<---
-    }
-}
-```
-
-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/).
-:::
\ No newline at end of file
diff --git a/articles/quickstart/native/android/_includes/_callback_urls.md b/articles/quickstart/native/android/_includes/_callback_urls.md
deleted file mode 100755
index 8b641cd383..0000000000
--- a/articles/quickstart/native/android/_includes/_callback_urls.md
+++ /dev/null
@@ -1,9 +0,0 @@
-<%= include('../../../../_includes/_callback_url') %>
-
-This tutorial series uses a callback URL that looks like this:
-
-```js
-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.
diff --git a/articles/quickstart/native/android/_includes/_credentials.md b/articles/quickstart/native/android/_includes/_credentials.md
deleted file mode 100755
index 3c0778af33..0000000000
--- a/articles/quickstart/native/android/_includes/_credentials.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## Set 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) section in the Auth0 dashboard.
-
-You need the following information: 
-* **Client ID**
-* **Domain**
-
-We suggest you do not hardcode these values 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. 
-
-Edit your `res/values/strings.xml` file as follows:
-
-```xml
-
-    ${account.clientId}
-    ${account.namespace}
-
-```
-
-::: note
-If you download the sample from the top of this page, these details are filled out for you. If you have more than one application in your account, the sample comes with the values for your **Default App**.
-:::
diff --git a/articles/quickstart/native/android/_includes/_lock.md b/articles/quickstart/native/android/_includes/_lock.md
deleted file mode 100755
index 8242956de1..0000000000
--- a/articles/quickstart/native/android/_includes/_lock.md
+++ /dev/null
@@ -1,52 +0,0 @@
-## Add the Lock Dependency
-
-Your first step is to add [Lock](https://github.com/auth0/Lock.Android) into your project. Lock is a library for displaying a native UI in your app for logging in and signing up with different platforms via [Auth0](https://auth0.com/).
-
-### Add Lock with Gradle
-
-Inside the app's `build.gradle` dependencies section:
-
-```xml
-apply plugin: 'com.android.application'
-android {
-  //..
-}
-dependencies {
-  //---> Add the next line
-  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).
-:::
-
-
-Now add the _Manifest Placeholders_, required by the SDK to define internally an **intent-filter** to capture the authentication callback. You do that by adding the next line:
-
-```xml
-apply plugin: 'com.android.application'
-android {
-    compileSdkVersion 25
-    buildToolsVersion "25.0.3"
-    defaultConfig {
-        applicationId "com.auth0.samples"
-        minSdkVersion 15
-        targetSdkVersion 25
-        //...
-
-        //---> Add the next line
-        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"]
-        //<---
-    }
-}
-```
-
-<%= include('_credentials') %>
-
-Then, run **Sync Project with Gradle Files** inside Android Studio or `./gradlew clean assembleDebug` from the command line.
-
-::: note
-For more information about Gradle usage, check [their official documentation](https://gradle.org/getting-started-android-build/).
-:::
diff --git a/articles/quickstart/native/android/_includes/_lock_login.md b/articles/quickstart/native/android/_includes/_lock_login.md
deleted file mode 100755
index 094637a60e..0000000000
--- a/articles/quickstart/native/android/_includes/_lock_login.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## Implement the Login
-
-At this point, you're all set to implement the login in any activity you want. Inside the activity, override the `onCreate` and `onDestroy` methods to initialize and release **Lock**, and define an instance of `LockCallback` to handle the authentication result. The `Auth0` instance holds the client information such as Client ID and Domain. If you've added the `R.string.com_auth0_client_id` and `R.string.com_auth0_domain` String resources, you'll be able to use the constructor that receives an android Context. If you prefer to hardcode them, use the constructor that receives both strings.
-
-```java
-@Override
-protected void onCreate(Bundle savedInstanceState) {
-    Auth0 auth0 = new Auth0(this);
-    lock = Lock.newBuilder(auth0, callback)
-        .withScheme("demo")
-        .withAudience(String.format("https://%s/userinfo", getString(R.string.com_auth0_domain)))
-        // Add parameters to the Lock Builder
-        .build(this);
-}
-```
-
-```java
-@Override
-protected void onDestroy() {
-    super.onDestroy();
-    // Your own Activity code
-    lock.onDestroy(this);
-    lock = null;
-}
-```
-
-```java
-private LockCallback callback = new AuthenticationCallback() {
-    @Override
-    public void onAuthentication(Credentials credentials) {
-        // Login Success response
-    }
-
-    @Override
-    public void onCanceled() {
-        // Login Cancelled response
-    }
-
-    @Override
-    public void onError(LockException error){
-        // Login Error response
-    }
-};
-```
-
-Finally, whenever you want to start the login widget, call:
-
-```java
-startActivity(lock.newIntent(this));
-```
-
-
        Mobile example screenshot
        
-
-::: note
-If you require in-depth configuration, see [Lock Builder](/libraries/lock-android#lock-builder) for more information
-:::
-
-::: note
-There are multiple ways of implementing the login dialog. What you see above is the default widget; however, if you want, you can use [your own UI](/quickstart/native/android/02-custom-login).
-:::
diff --git a/articles/quickstart/native/android/_includes/_lock_manifest.md b/articles/quickstart/native/android/_includes/_lock_manifest.md
deleted file mode 100755
index 29ac5a2fcd..0000000000
--- a/articles/quickstart/native/android/_includes/_lock_manifest.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Configure the Manifest File
-
-Declare the `LockActivity` in your project's `AndroidManifest.xml`:
-
-```xml
-
-
-    
-
-    
-
-        
-          
-              
-              
-          
-        
-
-        
-
-    
-
-
-```
-
-It's very important to specify the `android:launchMode="singleTask"` in your activity to ensure the authentication state it's not lost along redirects and that the result arrives back in the same activity instance that first requested it.
-
-The next step is to whitelist the **Callback URL** of your app. Edit the "Allowed Callback URLs" section of the [Application Settings](${manage_url}/#/applications) and add a URL that looks like this:
-
-```text
-demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback
-```
-
-Replace `YOUR_APP_PACKAGE_NAME` with your actual application's package name, available in the app's `build.gradle` file as the `applicationId` attribute.
-
-
-::: note
-Do not add `` to the `LockActivity` as this will alter the correct functionality of **Lock**.
-:::
diff --git a/articles/quickstart/native/android/_includes/_login.md b/articles/quickstart/native/android/_includes/_login.md
deleted file mode 100755
index 7e13ab7545..0000000000
--- a/articles/quickstart/native/android/_includes/_login.md
+++ /dev/null
@@ -1,98 +0,0 @@
-## Start the Authentication
-
-[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.
-
-::: note
-You can also embed the login dialog directly in your application using the [Lock widget](/lock). If you use this method, some features, such as single sign-on, will not be accessible. 
-To learn how to embed the Lock widget in your application, follow the [Embedded Login sample](https://github.com/auth0-samples/auth0-android-sample/tree/embedded-login/01-Embedded-Login).
-:::
-
-::: note
-Read the [Browser-Based vs. Native Login Flows on Mobile Devices](/tutorials/browser-based-vs-native-experience-on-mobile) article to learn how to choose between the two types of login flows.
-:::
-
-In the `login` method, create a new instance of the `Auth0` class to hold user credentials. 
-
-You can use a constructor that receives an Android Context if you have added the following String resources: 
-* `R.string.com_auth0_client_id`
-* `R.string.com_auth0_domain`
-
-If you prefer to hardcode the resources, use the constructor that receives both strings. Then, use the `WebAuthProvider` class to authenticate with any connection you enabled on your application in the [Auth0 dashboard](${manage_url}/#/).
-
-After you call the `WebAuthProvider#start` function, the browser launches and shows the **Lock** widget. Once the user authenticates, the callback URL is called. The callback URL contains the final result of the authentication process.
-
-```java
-// app/src/main/java/com/auth0/samples/MainActivity.java
-
-private void login() {
-    WebAuthProvider.init(auth0)
-        .withScheme("demo")
-        .withAudience(String.format("https://%s/userinfo", getString(R.string.com_auth0_domain)))
-        .start(MainActivity.this, new AuthCallback() {
-            @Override
-            public void onFailure(@NonNull Dialog dialog) {
-               // Show error Dialog to user
-            }
-
-            @Override
-            public void onFailure(AuthenticationException exception) {
-               // Show error to user
-            }
-
-            @Override
-            public void onSuccess(@NonNull Credentials credentials) {
-               // Store credentials
-               // Navigate to your main activity
-            }
-    });
-}
-```
-
-## Capture the Result
-
-Whitelist the callback URL for your app in the **Allowed Callback URLs** section in [Application settings](${manage_url}/#/applications). In that section, enter the following URL: 
-
-```text
-demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback
-```
-
-::: note
-Replace `YOUR_APP_PACKAGE_NAME` with your application's package name, available in the `app/build.gradle` file as the `applicationId` attribute.
-:::
-
-After authentication, the browser redirects the user to your application with the authentication result. The SDK captures the result and parses it. 
-
-::: 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.
-:::
-
-The `AndroidManifest.xml` file should look like this:
-
-```xml
-
-
-    
-
-    
-
-        
-          
-              
-              
-          
-        
-
-    
-
-
-```
-
-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).
-
        
-  Mobile example screenshot
-
        
diff --git a/articles/quickstart/native/android/dashboard-default.md b/articles/quickstart/native/android/dashboard-default.md
deleted file mode 100755
index d8896201b3..0000000000
--- a/articles/quickstart/native/android/dashboard-default.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Getting started
-description: Short Introduction to the Auth0 Android Quickstarts.
-budicon: 715
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-android-sample',
-  path: '00-Login',
-  requirements: [
-    'Android Studio 2.3',
-    'Android SDK 25',
-    'Emulator - Nexus 5X - Android 6.0'
-  ]
-}) %>
-
-## Sample Projects
-
-Each tutorial in the series includes a link to its corresponding sample project. You can find all the samples [here](https://github.com/auth0-samples/auth0-android-sample).
-
-## Dependencies
-
-Each tutorial will require you to use the [Auth0.Android](https://github.com/auth0/Auth0.Android) library. This is a toolkit that lets you communicate with many of the basic [Auth0 API](https://auth0.com/docs/api) functions in a neat way.
-
-## Create an Application
-
-If you haven't already done so, create a new application in your [Auth0 dashboard](${manage_url}/#/applications/${account.clientId}/settings) and choose **Native** for the Type.
-
-![App Dashboard](/media/articles/angularjs/app_dashboard.png)
-
-<%= include('_includes/_callback_urls') %>
-
-<%= include('_includes/_credentials') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/native/android/download.md b/articles/quickstart/native/android/download.md
new file mode 100644
index 0000000000..51f51bd5bd
--- /dev/null
+++ b/articles/quickstart/native/android/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample first set the **Callback URL** in the Application Settings to
+
+```text
+demo://${account.namespace}/android/com.auth0.androidsample/callback
+```
+
+To run the sample first set the **Logout URL** in the Application 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. 
+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/articles/quickstart/native/android/files/MainActivity.md b/articles/quickstart/native/android/files/MainActivity.md
new file mode 100644
index 0000000000..2e476f1606
--- /dev/null
+++ b/articles/quickstart/native/android/files/MainActivity.md
@@ -0,0 +1,78 @@
+---
+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
+        }
+      })
+  }
+}
+```
diff --git a/articles/quickstart/native/android/files/build.md b/articles/quickstart/native/android/files/build.md
new file mode 100644
index 0000000000..949546a282
--- /dev/null
+++ b/articles/quickstart/native/android/files/build.md
@@ -0,0 +1,26 @@
+---
+name: build.gradle
+language: javascript
+---
+    
+```javascript
+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.+'
+}
+```
diff --git a/articles/quickstart/native/android/files/main.md b/articles/quickstart/native/android/files/main.md
new file mode 100644
index 0000000000..94497915cc
--- /dev/null
+++ b/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/articles/quickstart/native/android/files/strings.md b/articles/quickstart/native/android/files/strings.md
new file mode 100644
index 0000000000..b83b0540e1
--- /dev/null
+++ b/articles/quickstart/native/android/files/strings.md
@@ -0,0 +1,11 @@
+---
+name: strings.xml
+language: 
+---
+    
+```
+
+    "${account.namespace}"
+    "${account.clientId}"
+
+```
diff --git a/articles/quickstart/native/android/getting-started.md b/articles/quickstart/native/android/getting-started.md
deleted file mode 100755
index c54a38301d..0000000000
--- a/articles/quickstart/native/android/getting-started.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Getting started
-description: Short Introduction to the Auth0 Android Quickstarts.
-budicon: 715
----
-
-This quickstart guide walks you through managing authentication with Auth0 in your Android apps.
-
-## Sample Projects
-
-Each tutorial in the series includes a link to a sample project. You can find all the samples [here](https://github.com/auth0-samples/auth0-android-sample).
-
-## Dependencies
-
-Each tutorial uses the [Auth0.Android](https://github.com/auth0/Auth0.Android) library. It is a toolkit that lets you communicate with many of the basic [Auth0 API](https://auth0.com/docs/api) functions in a neat way.
-
-## Create an Application
-
-Create a new client application in your [Auth0 dashboard](${manage_url}/#/applications). For **Type**, select **Native**.
-
-![App Dashboard](/media/articles/angularjs/app_dashboard.png)
-
-<%= include('_includes/_callback_urls') %>
-
-<%= include('_includes/_credentials') %>
\ No newline at end of file
diff --git a/articles/quickstart/native/android/index.yml b/articles/quickstart/native/android/index.yml
index 97949c457e..0e64b75a56 100755
--- a/articles/quickstart/native/android/index.yml
+++ b/articles/quickstart/native/android/index.yml
@@ -1,31 +1,32 @@
 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:
-  - Java
-  - C
+  - Kotlin
 hybrid: false
 author:
   name: Luciano Balmaceda
   email: luciano.balmaceda@auth0.com
   community: false
-image: /media/platforms/android.png
-tags:
+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: dashboard-default
+default_article: 00-login
+hidden_articles:
+  - interactive
 articles:
-  - getting-started
   - 00-login
-  - 03-session-handling
-  - 04-user-profile
-  - 05-linking-accounts
-  - 06-calling-apis
-  - 07-authorization
+  - 01-user-metadata
 next_steps:
   - path: 00-login
     list:
@@ -35,35 +36,22 @@ next_steps:
     - text: Enable multifactor authentication
       icon: 345
       href: "/multifactor-authentication"
-    - text: Learn about anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-  - path: 03-session-handling
-    list:
-    - text: Learn about refresh tokens
-      icon: 345
-      href: "/tokens/refresh-tokens"
-  - path: 04-user-profile
-    list:
-    - text: Learn about the user profile structure
+    - text: Learn about attack protection
       icon: 345
-      href: "/user-profile/normalized/oidc"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-    - text: In-depth details about user profile
-      icon: 345
-      href: "/user-profile/user-profile-details"
-  - path: 06-calling-apis
-    list:
-    - text: Learn about custom APIs
-      icon: 345
-      href: "/api"
-    - text: Introduction to API authorization
-      icon: 345
-      href: "/api-auth"
-  - path: 07-authorization
-    list:
+      href: "/attack-protection"
     - text: Learn about rules
       icon: 345
-      href: "/rules"
\ No newline at end of file
+      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/articles/quickstart/native/android/interactive.md b/articles/quickstart/native/android/interactive.md
new file mode 100644
index 0000000000..c0bd077acb
--- /dev/null
+++ b/articles/quickstart/native/android/interactive.md
@@ -0,0 +1,78 @@
+---
+title: Add Login to Your Android Application
+description: This guide demonstrates how to integrate Auth0 with a Android application using the Auth0 Android SDK.
+interactive:  true
+files:
+ - files/build
+ - files/strings
+ - files/MainActivity
+github:
+  path: 00-Login-Kt
+locale: en-US
+---
+
+# Add Login to Your Android Application
+
+
+
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to demo://{yourDomain}/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.
        If you are following along with our sample project, set this to demo://{yourDomain}/android/YOUR_APP_PACKAGE_NAME/callback
        
+
+## Install the Auth0 Android SDK {{{ data-action="code" data-code="build.gradle#18:18" }}}
+
+
+
        Add the 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:
        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.
        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. You can read more about setting this value in the Auth0.Android SDK README.
        
+
+## 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, 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:
        <uses-permission android:name="android.permission.INTERNET" />
+
+
        
+
+
        Run Sync Project with Gradle Files inside Android Studio or execute ./gradlew clean assembleDebug from the command line.
        For more information about using Gradle, check the Gradle official documentation.
        
+
+## Add login to your application {{{ data-action="code" data-code="MainActivity.kt#6:38" }}}
+
+
+
        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.
        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. 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.
        Android Quickstart step 5 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 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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        Android Quickstart Step 6 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.
        
+
+  
        
+
+  
        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 or visit our community page 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. 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 retrieve the user's email address.
        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:
        Android Quickstart step 7 checkpoint 
        Call the showUserProfile function after login. Verify the onSuccess callback returns the user's profile information.
        
+
+  
        
+
+  
        If your application did not return user profile information:
        • Verify the accessToken is valid
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/native/chrome/01-login.md b/articles/quickstart/native/chrome/01-login.md
deleted file mode 100644
index 7351ea3018..0000000000
--- a/articles/quickstart/native/chrome/01-login.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0-Chrome SDK to add authentication and authorization to your Chrome extension
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-chrome-sample',
-  path: '00-Starter-Seed',
-  requirements: [
-    'auth0-chrome 0.1.2',
-    'jwt-decode 2.1.0'
-  ]
-}) %>
-
-This quickstart demonstrates how to add authentication to a Chrome extension with Auth0. The tutorial is based on a sample application which uses Auth0's hosted Lock widget and Chrome's `launchWebAuthFlow`.
-
-## Overview
-
-To integrate Auth0 in a Chrome extension, you can use the `auth0-chrome` package available on npm. This package provides a generic `PKCEClient.js` file which allows you to use the [Proof Key for Code Exchange](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native applications to mitigate the threat of authorization code interception.
-
-## Install the Dependencies
-
-Install `auth0-chrome` and `jwt-decode` with npm. The `jwt-decode` library is useful for decoding JSON Web Tokens and will be used to check the expiry time in this example.
-
-```bash
-npm install auth0-chrome jwt-decode --save
-```
-
-The `dist` folder of `Auth0Chrome` contains a webpack bundle for the package, including a minified version.
-
-Configure your `manifest.json` file to run the `auth0chrome` script, along with an `env.js` and `main.js` script for your project. The `default_popup` should be set to a file called `browser_action.html` which will be used to provide a view to the popup.
-
-```js
-{
-  ...
-  "browser_action": {
-    "default_title": "Auth0",
-    "default_popup": "src/browser_action/browser_action.html"
-  },
-  "background": {
-    "scripts": [
-      "./env.js",
-      "node_modules/auth0-chrome/dist/auth0chrome.min.js",
-      "src/main.js"
-    ],
-    "persistent": false
-  },
-  "permissions": [
-    "identity",
-    "notifications"
-  ]
-}
-```
-
-## Set Your Auth0 Credentials
-
-The **client ID** and **domain** for your application are used to connect to Auth0 and these will be required when instantiating `Auth0Chrome`. Create an `env.js` file and populate it with your application keys. Alternatively, you can pass these keys to the `Auth0Chrome` constructor directly.
-
-```js
-// env.js
-
-window.env = {
-  AUTH0_DOMAIN: '<%= account.namespace %>',
-  AUTH0_CLIENT_ID: '<%= account.clientId %>',
-};
-```
-
-::: note
-When downloading the sample project above, these values will come prepopulated for you.
-:::
-
-## Create the Main Popup
-
-Create a `browser_action.html` file in `src/browser_action` and provide a view for your extension's popup. In this example the view has controls for allowing the user to log in and log out, as well as an area for displaying the user's profile after authentication.
-
-```html
-
-...
-
-  
        
-    
-    
-    
        
-      
        
-        
        Chrome Demo
        
-        
-        
        Press the Log In button above to log in.
        
-      
        
-    
        
-  
        
-  
-  
-  
-
-```
-
-The `jwt-decode` library is included within a `script` tag, as is a `browser_action.js` file. It's the `browser_action.js` file that will be used to control the view.
-
-::: note
-For this example, `document.querySelector` and `document.querySelectorAll` are used as a minimal way to mimic jQuery. Keep in mind that the specific technologies used to power the Chrome extension are at your discretion.
-:::
-
-At a minimum, the Chrome extension needs to have views and logic to handle two cases: when the user is authenticated and when they are not. JWT authentication is stateless by nature, so the best indication we have that the user is authenicated is whether they have an unexpired token saved.
-
-When the user is authenticated, a profile area should be displayed. When they aren't authenticated (they don't have a JWT or it becomes expired), the "Log In" button should be shown.
-
-```js
-// src/browser_action/browser_action.js
-
-function isLoggedIn(token) {
-  // The user is logged in if their token isn't expired
-  return jwt_decode(token).exp > Date.now() / 1000;
-}
-
-function logout() {
-  // Remove the idToken from storage
-  localStorage.clear();
-  main();
-}
-
-// Minimal jQuery
-const $$ = document.querySelectorAll.bind(document);
-const $  = document.querySelector.bind(document);
-
-
-function renderProfileView(authResult) {
-  $('.default').classList.add('hidden');
-  $('.loading').classList.remove('hidden');
-  fetch(`https://<%= "${env.AUTH0_DOMAIN}" %>/userinfo`, {
-    headers: {
-      'Authorization': `Bearer <%= "${authResult.access_token}" %>`
-    }
-  }).then(resp => resp.json()).then((profile) => {
-    ['picture', 'name', 'nickname'].forEach((key) => {
-
-       const element = $('.' +  key);
-       if( element.nodeName === 'DIV' ) {
-         element.style.backgroundImage = 'url(' + profile[key] + ')';
-         return;
-       }
-
-       element.textContent = profile[key];
-    });
-    $('.loading').classList.add('hidden');
-    $('.profile').classList.remove('hidden');
-    $('.logout-button').addEventListener('click', logout);
-  }).catch(logout);
-}
-
-
-function renderDefaultView() {
-  $('.default').classList.remove('hidden');
-  $('.profile').classList.add('hidden');
-  $('.loading').classList.add('hidden');
-
-  $('.login-button').addEventListener('click', () => {
-    $('.default').classList.add('hidden');
-    $('.loading').classList.remove('hidden');
-    chrome.runtime.sendMessage({
-      type: "authenticate"
-    });
-  });
-}
-
-function main () {
-  const authResult = JSON.parse(localStorage.authResult || '{}');
-  const token = authResult.id_token;
-  if (token && isLoggedIn(token)) {
-    renderProfileView(authResult);
-  } else {
-    renderDefaultView();
-  }
-}
-
-document.addEventListener('DOMContentLoaded', main);
-```
-
-Two functions are provided to handle the scenarios described above. The `renderProfileView` function fetches the user's profile from Auth0's API at the `/userinfo` endpoint and shows the profile in the popup. The `renderDefaultView` function displays the Log In button and emits a message to trigger the authentication flow when clicked. Note that the user's `access_token` is attached as an `Authorization` header in the call to the `/userinfo` endpoint.
-
-The `main` function takes the `authResult` object saved in local storage and renders the profile view if the user's `id_token` is unexpired, or the default view if it is expired.
-
-![popup](/media/articles/native-platforms/chrome/01-popup.png)
-
-## Initiate the Authentication Flow
-
-The `browser_action.js` file controls the popup view and responds to button clicks, but the logic for the authentication flow still needs to be implemented.
-
-Create a `main.js` file in the `src` directory and set it up to listen for the `authenticate` message that is emitted when the Log In button is clicked.
-
-```js
-// src/main.js
-
-chrome.runtime.onMessage.addListener(function (event) {
-  if (event.type === 'authenticate') {
-
-    // scope
-    //  - openid if you want an id_token returned
-    //  - offline_access if you want a refresh_token returned
-    // device
-    //  - required if requesting the offline_access scope.
-    let options = {
-      scope: 'openid offline_access',
-      device: 'chrome-extension'
-    };
-
-    new Auth0Chrome(env.AUTH0_DOMAIN, env.AUTH0_CLIENT_ID)
-      .authenticate(options)
-      .then(function (authResult) {
-        localStorage.authResult = JSON.stringify(authResult);
-        chrome.notifications.create({
-          type: 'basic',
-          iconUrl: 'icons/icon128.png',
-          title: 'Login Successful',
-          message: 'You can use the app now'
-        });
-      }).catch(function (err) {
-        chrome.notifications.create({
-          type: 'basic',
-          title: 'Login Failed',
-          message: err.message,
-          iconUrl: 'icons/icon128.png'
-        });
-      });
-  }
-});
-```
-
-When the `authenticate` message is received, an `Auth0Chrome` instance is created and its `authenticate` method is called, which opens a new window showing Auth0's hosted Lock.
-
-The `Auth0Chrome` constructor takes the **domain** and **client ID** for your application, and the `authenticate` method takes an `options` object which allows you to customize the authentication flow. The `authenticate` method returns a promise and the result from the authentication process can be retrieved when it resolves. In this example, the result is saved in local storage immediately for future use and a Chrome notification is created to let the user know they have successfully logged in.
-
-![hosted-lock](/media/articles/native-platforms/chrome/02-hosted-lock.png)
-
-## Configure Your Auth0 Application
-
-Chrome extensions are packaged as `.crx` files for distribution but may be loaded "unpacked" for development. For more information on how to load an unpacked extension, see the [Chrome extension docs](https://developer.chrome.com/extensions/getstarted#unpacked).
-
-When loading your application as an unpacked extension, a unique ID will be generated for it. In your [application settings](${manage_url}/#/applications/${account.clientId}/settings), you must whitelist your callback URL (the URL that Auth0 will return to once authentication is complete) and the allowed origin URL.
-
-In the **Allowed Callback URLs** section, whitelist your callback URL.
-
-```bash
-https://.chromiumapp.org/auth0
-```
-
-In the **Allowed Origins** section, whitelist your chrome extension as an origin.
-
-```bash
-chrome-extension://
-```
-
-Once the extension is published in the Chrome Web Store the Callback URL and the CORS origins used for development must be changed.
-
-## Further Reading
-
-With authentication implemented in your Chrome extension, you'll likely want to make secure calls to a remote API. For more information on how to set up an API in your Auth0 dashboard and how to use Access Tokens to make requests for protected resources, see the [API authorization docs](https://auth0.com/docs/api-auth).
diff --git a/articles/quickstart/native/chrome/index.yml b/articles/quickstart/native/chrome/index.yml
deleted file mode 100644
index 957e0ab74f..0000000000
--- a/articles/quickstart/native/chrome/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Chrome Extension
-author:
-  community: true
-language:
-  - JavaScript
-framework:
-  - Chrome Extension
-tags:
-  - quickstart
-snippets:
-  dependencies: native-platforms/chrome-extension/dependencies
-  setup: native-platforms/chrome-extension/setup
-  use: native-platforms/chrome-extension/use
-alias:
-  - chrome
-  - chrome-extension
-seo_alias: chrome-extension
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/config.yml b/articles/quickstart/native/config.yml
index e7279838a2..51f64e8751 100644
--- a/articles/quickstart/native/config.yml
+++ b/articles/quickstart/native/config.yml
@@ -1,18 +1,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 anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-    - text: Learn about the user profile structure
-      icon: 345
-      href: "/user-profile/normalized/oidc"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
\ No newline at end of file
+sample_download_required_data:
+  - client
diff --git a/articles/quickstart/native/cordova/01-login.md b/articles/quickstart/native/cordova/01-login.md
deleted file mode 100644
index d866ab8e70..0000000000
--- a/articles/quickstart/native/cordova/01-login.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Cordova SDK to add authentication and authorization to your mobile app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-cordova-samples',
-  path: '01-Login',
-  requirements: [
-    'NodeJS 5',
-    'Cordova 5.4+'
-  ]
-}) %>
-
-<%= include('../_includes/_cordova_setup') %>
-
-## Set Up URL Redirects
-
-Use the `onRedirectUri` method from **auth0-cordova** when your app loads to properly handle redirects after authentication.
-
-```js
-var Auth0Cordova =  require('@auth0/cordova');
-var App = require('./App');
-
-function main() {
-  var app = new App();
-  function intentHandler(url) {
-    Auth0Cordova.onRedirectUri(url);
-  }
-  window.handleOpenURL = intentHandler;
-  app.run('#app');
-}
-
-document.addEventListener('deviceready', main);
-```
-
-::: note
-**Note:** The code samples shown in this tutorial assume that your app is using some kind of bundler like browserify or webpack to make npm modules available in a client application. The downloadable sample for this tutorial uses webpack but you are free to use whichever bundler you like.
-:::
-
-## Create a Main App File and Configure Auth0
-
-Create a main application file and initialize Auth0 in it. This file can also serve as the place where you change what is rendered in the app. This file needs methods for logging users in and out, as well as checking their authentication state. Be sure to replace `YOUR_PACKAGE_ID` with the identifier for your app in the configuration block.
-
-${snippet(meta.snippets.use)}
-
-## Add Login and Logout Controls
-
-Add controls to your app to allow users to log in and log out. The buttons should have classes which can be picked up with a `querySelector` and have event listeners attached to them as is demonstrated above.
-
-```html
-
-
-
-
-
-```
-
-After authentication, users will be redirected to your application where they will be taken to the `profile` route.
-
-### Troubleshooting
-
-#### Cannot read property 'isAvailable' of undefined
-
-This means that you're attempting to test this in a browser. At this time you'll need to run this either in an emulator or on a device.
-
-
diff --git a/articles/quickstart/native/cordova/index.yml b/articles/quickstart/native/cordova/index.yml
deleted file mode 100644
index 1f6e50bedd..0000000000
--- a/articles/quickstart/native/cordova/index.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-title: Cordova
-author:
-  community: true
-language:
-  - Javascript
-framework:
-  - Cordova
-hybrid: true
-image: /media/platforms/phonegap.png
-tags:
-  - quickstart
-snippets:
-  dependencies: native-platforms/cordova/dependencies
-  setup: native-platforms/cordova/setup
-  use: native-platforms/cordova/use
-alias:
-  - cordova
-  - apache-cordova
-seo_alias: cordova
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/device/01-login.md b/articles/quickstart/native/device/01-login.md
new file mode 100644
index 0000000000..5902c598bf
--- /dev/null
+++ b/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/articles/quickstart/native/device/index.yml b/articles/quickstart/native/device/index.yml
new file mode 100644
index 0000000000..f253fc43c5
--- /dev/null
+++ b/articles/quickstart/native/device/index.yml
@@ -0,0 +1,26 @@
+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
+hidden_articles:
+  - interactive
+show_steps: false
diff --git a/articles/quickstart/native/device/interactive.md b/articles/quickstart/native/device/interactive.md
new file mode 100644
index 0000000000..21129d0074
--- /dev/null
+++ b/articles/quickstart/native/device/interactive.md
@@ -0,0 +1,559 @@
+---
+title: Device Authorization Flow
+description: This tutorial demonstrates how to call your API from an input-constrained device using the Device Authorization Flow.
+interactive:  true
+
+locale: en-US
+---
+
+# Device Authorization Flow
+
+
+
        This tutorial demonstrates how to call your API from an input-constrained device using the Device Authorization Flow. We recommend that you log in to follow this quickstart with examples configured for your account.
        For an interactive experience, you can use the Device Flow Playground.
        Prerequisites
        
+
+## Request device code
+
+
+
        When the user starts the device application and wants to authorize it, your application must request a device code from the Auth0 Authentication API to associate with the user session.
        To get the device code, your application must call the Authentication API Device Authorization Flow Authorize endpoint:
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/device/code' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/device/code");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/device/code"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/device/code")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/device/code',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/device/code"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/device/code",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/device/code", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/device/code")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/device/code")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
+
+## Receive device code
+
+
+
        The device application should receive an HTTP 200 response and a payload similar to this:
        {
+
+  "device_code": "GmRh...k9eS",
+
+  "user_code": "WDJB-MJHT",
+
+  "verification_uri": "https://my-tenant.auth0.com/device",
+
+  "verification_uri_complete": "https://my-tenant.auth0.com/device?user_code=WDJB-MJHT",
+
+  "expires_in": 900,
+
+  "interval": 5
+
+}
+
+
        
+
+
        
+
+## Request device activation
+
+
+
        After your device application receives the device_code and the user_code, it should instruct the user to go to the verification_uri and enter the user_code.
        The device_code is not intended for the user directly and should not be displayed during the interaction to avoid confusing the user.
        When building a CLI, you could skip this step and immediately open the browser with verification_uri_complete.
        
+
+## Poll the token endpoint
+
+
+
        While your device application waits for the user to activate it, it should call the Authentication API POST /oauth/token endpoint intermittently and handle the response appropriately.
        Ensure your device application waits for the length of the interval (in seconds) or until it receives a successful response, whichever is longer, to avoid network latency issues.
        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:device_code \ 
+
+--data device_code=__AUTH0_SCOPES__ \ 
+
+--data 'client_id=${account.clientId}'
+
+
        
+
+
        
+
+## User authorization
+
+
+
        The user will either scan the QR code, or else will open the activation page and enter the user code:
        A confirmation page will be shown to have the user confirm that this is the right device:
        The user will complete the transaction by signing in. 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 SSO sessions
        • Obtaining user consent for the device, unless consent has been previously given
        Upon successful authentication and consent, the confirmation prompt will be shown:
        At this point, the user has authenticated and the device has been authorized.
        
+
+## Receive tokens
+
+
+
        After the user authorizes the device application, it receives an HTTP 200 response and the following payload:
        {
+
+  "access_token": "eyJz93a...k4laUWw",
+
+  "refresh_token": "GEbRxBN...edjnXbL",
+
+  "id_token": "eyJ0XAi...4faeEoQ",
+
+  "token_type": "Bearer",
+
+  "expires_in": 86400
+
+}
+
+
        
+
+
        You should validate your tokens before saving them. To learn how, read Validate Access Tokens and Validate ID Tokens.
        Access tokens are used to call the Authentication API Get User Info endpoint (if your device application requested the openid scope) or the API that was specified by the audience parameter. If you are calling your own API, your device application must verify the access token before using it.
        ID tokens contain user information that must be decoded and extracted. The Authentication API only returns an id_token if your device application requested the openid scope.
        Refresh tokens are used to obtain a new access token or ID token after the previous one has expired. The Authentication API only returns a refresh_token if the Allow Offline Access setting is enabled for the API specified by the audience parameter, and your device application requested the offline_access scope.
        
+
+## Call your API
+
+
+
        To call your API, your device application must pass the access token as a Bearer token in the Authorization header of your HTTP request.
        curl --request GET \
+
+  --url https://myapi.com/api \
+
+  --header 'authorization: Bearer __AUTH0_API_ACCESS_TOKEN__' \
+
+  --header 'content-type: application/json'
+
+
        
+
+
        
+
+## Refresh tokens
+
+
+
        To get a new access token for a user, your device application can call the Authentication API POST /oauth/token endpoint with the refresh_token parameter.
        curl --request POST \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded' \
+
+  --data grant_type=refresh_token \
+
+  --data 'client_id=${account.clientId}' \
+
+  --data 'client_secret=${account.clientSecret}' \
+
+  --data refresh_token=__AUTH0_REFRESH_TOKEN__
+
+
        
+
+
        If the request was successful, your device application receives an HTTP 200 response with the following payload:
        {
+
+  "access_token": "eyJ...MoQ",
+
+  "expires_in": 86400,
+
+  "scope": "openid offline_access",
+
+  "id_token": "eyJ...0NE",
+
+  "token_type": "Bearer"
+
+}
+
+
        
+
+
        To learn more about refresh tokens, read Refresh Tokens.
        
+
+## Troubleshooting
+
+
+
        Tenant logs are created for any interaction that takes place and can be used to troubleshoot issues.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **Code****Name****Description**
        fdeazFailed device authorization request
        fdeacFailed device activation
        fdeccUser canceled the device confirmation
        fedeFailed ExchangeDevice Code for Access Token
        sedeSuccess ExchangeDevice Code for Access Token
        Token responses
        While you wait for the user to authorize the device, you may receive a few different HTTP 4xx responses.
        Authorization pending
        You will see this error while waiting for the user to take action. Continue polling using the suggested interval retrieved in the previous step of this tutorial.
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "authorization_pending", 
+
+  "error_description": "..." 
+
+}
+
+
        
+
+
        Slow down
        You are polling too fast. Slow down and use the suggested interval retrieved in the previous step of this tutorial. To avoid receiving this error due to network latency, you should start counting each interval after receipt of the last polling request's response.
        `HTTP 429`
+
+
+
+{
+
+  "error": "slow_down",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        Expired token
        The user has not authorized the device quickly enough, so the device_code has expired. Your application should notify the user that the flow has expired and prompt them to reinitiate the flow.
        The expired_token error is returned exactly once. After that, the endpoint returns the invalid_grant error.
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "expired_token",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        Access Denied
        If access is denied, you receive:
        `HTTP 403`
+
+
+
+{
+
+  "error": "access_denied",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        This can occur for a variety of reasons, including:
        • The user refused to authorize the device.
        • The authorization server denied the transaction.
        • A configured Action denied access.
        
+
+## Sample implementations
+
+
+
        Refer to the samples below to learn how to implement this flow in real-world applications.
        • Device Authorization Playground
        • AppleTV (Swift): Simple application that shows how Auth0 can be used with the Device Authorization Flow from an AppleTV.
        • CLI (Node.js): Sample implementation of a CLI that uses the Device Authorization Flow instead of the Authorization Code Flow. The major difference is that your CLI does not need to host a webserver and listen on a port.
        
+
+## Limitations
+
+
+
        To use the Device Authorization Flow, a device application must:
        In addition, the Device Authorization Flow does not allow:
        
diff --git a/articles/quickstart/native/electron/01-login.md b/articles/quickstart/native/electron/01-login.md
deleted file mode 100644
index 6333938775..0000000000
--- a/articles/quickstart/native/electron/01-login.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Login
-description: This tutorial will show you how to use the Auth0 Electron SDK to add authentication and authorization to your app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-electron-samples',
-  path: '01-Login',
-  requirements: [
-    'NodeJS 5.0.0',
-    'Electron 1.4.3'
-  ]
-}) %>
-
-## Configure the Callback URL
-
-
        
-
        Go to the Application Settings section in your Auth0 dashboard and make sure that the Allowed Callback URLs field contains the following values:
        
-
-```text
-https://${account.namespace}/mobile, file:///
-```
-
-
        
-
-## Add the Lock Widget
-
-Add **Auth0Lock** to your `index.html` file and set the viewport.
-
-```html
-
-
-
-
-
-```
-
-::: note
-Some functionality provided by Lock is meant for regular web browsers. For best results, add `auth: { sso: false }` to your Lock configuration options.
-:::
-
-## Follow the frontend Quickstarts
-
-You can use any frontend technology you like in your Electron application. Follow the [quickstart](/quickstart/spa) guide specific to your use case.
-
-In the simple case of using [jQuery](/quickstart/spa/jquery), you can provide a control to render the Lock widget which will allow the user to log in.
-
-![Lock](/media/articles/electron/lock-open.png)
-
-If the user logs in with a social provider, they will be prompted for their credentials.
-
-![Lock Google](/media/articles/electron/lock-google-open.png)
diff --git a/articles/quickstart/native/electron/_index.yml b/articles/quickstart/native/electron/_index.yml
deleted file mode 100644
index c6cf7d5972..0000000000
--- a/articles/quickstart/native/electron/_index.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-title: Electron
-language:
-  - Javascript
-framework:
-  - Electron
-hybrid: false
-image:
-tags:
-  - quickstart
-  - electron
-  - atom
-snippets:
-  dependencies: native-platforms/electron/dependencies
-alias:
-  - electron
-seo_alias: electron
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/flutter/01-login.md b/articles/quickstart/native/flutter/01-login.md
new file mode 100644
index 0000000000..ab8b38946f
--- /dev/null
+++ b/articles/quickstart/native/flutter/01-login.md
@@ -0,0 +1,322 @@
+---
+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.
+
+:::note
+The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS.
+:::
+
+## Getting started
+
+This quickstart assumes you already have a Flutter app up and running. If not, check out the Flutter "getting started" guides to get started with a simple app.
+
+You should also be familiar with the Flutter command line tool.
+
+Finally, you will need a **Native** Auth0 application. If you don’t have a Native Auth0 application already, create one 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 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, 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. Whenever possible, Auth0 recommends using  Android App Links with `https` as a secure way to link directly to content within your app. Custom URL schemes can be subject to client impersonation attacks.
+
+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.
+
+Whenever possible, Auth0 recommends using Universal Links as a secure way to link directly to content within your iOS app. Custom URL schemes can be subject to [client impersonation attacks](https://datatracker.ietf.org/doc/html/rfc8252#section-8.6).
+
+**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. You can read more about setting this value in the Auth0.Android SDK README.
+
+:::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 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, 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 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 under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a custom domain, 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 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 or visit our community page 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.
+
+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 or visit our community page 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 or visit our community page to get more help.
+:::
+::::
diff --git a/articles/quickstart/native/flutter/_configure_urls_interactive.md b/articles/quickstart/native/flutter/_configure_urls_interactive.md
new file mode 100644
index 0000000000..cbdfaf2342
--- /dev/null
+++ b/articles/quickstart/native/flutter/_configure_urls_interactive.md
@@ -0,0 +1,54 @@
+## 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. Whenever possible, Auth0 recommends using  Android App Links with `https` as a secure way to link directly to content within your app. Custom URL schemes can be subject to client impersonation attacks.
+
+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.
+
+Whenever possible, Auth0 recommends using Universal Links as a secure way to link directly to content within your iOS app. Custom URL schemes can be subject to [client impersonation attacks](https://datatracker.ietf.org/doc/html/rfc8252#section-8.6).
+
+**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/articles/quickstart/native/flutter/download.md b/articles/quickstart/native/flutter/download.md
new file mode 100644
index 0000000000..7c90ca1bce
--- /dev/null
+++ b/articles/quickstart/native/flutter/download.md
@@ -0,0 +1,25 @@
+
+
+> On every step, if you have a custom domain, 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, and **App ID** to the app's bundle identifier.
+
+## 3. Run the app
+
+Use the Flutter CLI to run the app: `flutter run`.
diff --git a/articles/quickstart/native/flutter/files/app/build.md b/articles/quickstart/native/flutter/files/app/build.md
new file mode 100644
index 0000000000..c696fb8793
--- /dev/null
+++ b/articles/quickstart/native/flutter/files/app/build.md
@@ -0,0 +1,21 @@
+---
+name: app/build.gradle
+language: 
+---
+    
+```
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion flutter.targetSdkVersion
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders += [auth0Domain: "auth0-dsepaid.auth0.com", auth0Scheme: "https"]
+        // <---
+    }
+}
+```
diff --git a/articles/quickstart/native/flutter/files/build.md b/articles/quickstart/native/flutter/files/build.md
new file mode 100644
index 0000000000..39842f5c24
--- /dev/null
+++ b/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/articles/quickstart/native/flutter/files/main.md b/articles/quickstart/native/flutter/files/main.md
new file mode 100644
index 0000000000..b0f41fd59a
--- /dev/null
+++ b/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/articles/quickstart/native/flutter/files/main_view.md b/articles/quickstart/native/flutter/files/main_view.md
new file mode 100644
index 0000000000..7ad3aa9879
--- /dev/null
+++ b/articles/quickstart/native/flutter/files/main_view.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('auth0-dsepaid.auth0.com', 'OywWcFnHsbz50TfbRLWK0YTzrpxkwQL5');
+  }
+
+  @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/articles/quickstart/native/flutter/files/profile.md b/articles/quickstart/native/flutter/files/profile.md
new file mode 100644
index 0000000000..37883b3fa3
--- /dev/null
+++ b/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/articles/quickstart/native/flutter/files/profile_view.md b/articles/quickstart/native/flutter/files/profile_view.md
new file mode 100644
index 0000000000..3dedf5c4b3
--- /dev/null
+++ b/articles/quickstart/native/flutter/files/profile_view.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/articles/quickstart/native/flutter/index.yml b/articles/quickstart/native/flutter/index.yml
new file mode 100644
index 0000000000..23ca3922c3
--- /dev/null
+++ b/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: 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 Actions
+        icon: 345
+        href: '/customize/actions'
diff --git a/articles/quickstart/native/flutter/interactive.md b/articles/quickstart/native/flutter/interactive.md
new file mode 100644
index 0000000000..4324537d19
--- /dev/null
+++ b/articles/quickstart/native/flutter/interactive.md
@@ -0,0 +1,76 @@
+---
+title: Add Login to Your Flutter Application
+description: This guide demonstrates how to integrate Auth0 with a Flutter app using the Auth0 Flutter SDK.
+interactive:  true
+files:
+ - files/app/build
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: en-US
+---
+
+# 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.
        The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS.
        This quickstart assumes you already have a Flutter app up and running. If not, check out the Flutter "getting started" guides to get started with a simple app.
        You should also be familiar with the Flutter command line tool.
        New to Auth? Learn How Auth0 works, how it integrates with Single-Page Applications and which protocol it uses.
        
+
+## Configure Auth0
+
+
+
        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.
        On Android, the value of the SCHEME placeholder can be https or some other custom scheme. https schemes require enabling Android App Links.
        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. This feature requires Xcode 15.3+ and a paid Apple Developer account.
        Android
        SCHEME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback
        iOS
        https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
        macOS
        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:
        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:
        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.
        The sample 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. You can read more about setting this value in the Auth0.Android SDK README.
        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.
        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 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, and App ID to your app's bundle identifier.
        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 of the Runner target settings, and press the + Capability button. Then select Associated Domains.
        Next, add the following entry under Associated Domains:
        webcredentials:${account.namespace}
        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 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:
        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.
        Flutter - Step 5 - Add login to your application 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        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();
        Flutter - Step 6 - Add logout to your application 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        Flutter - Step 7 - Show user profile information 
        Log in and inspect the user property on the result. Verify the current user's profile information, such as email or name.
        
+
+  
        
+
+  
        If your app did not return user profile information:
        • Verify the access token is valid
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/native/ionic-angular/01-login.md b/articles/quickstart/native/ionic-angular/01-login.md
new file mode 100644
index 0000000000..b93e0379de
--- /dev/null
+++ b/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
+- `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 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 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 within a component correctly after you have logged in.
+:::
diff --git a/articles/quickstart/native/ionic-angular/download.md b/articles/quickstart/native/ionic-angular/download.md
new file mode 100644
index 0000000000..3d1147320c
--- /dev/null
+++ b/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
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the Application Settings
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)** in the Application Settings
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for Android and iOS are setup correctly. For iOS, CocoaPods must be installed.
+
+5) Make sure Node.JS LTS 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 on Capacitor's docs site.
diff --git a/articles/quickstart/native/ionic-angular/files/app-component.md b/articles/quickstart/native/ionic-angular/files/app-component.md
new file mode 100644
index 0000000000..7923e1cbd0
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-angular/files/app-module.md b/articles/quickstart/native/ionic-angular/files/app-module.md
new file mode 100644
index 0000000000..37b7db07fe
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-angular/files/app.component.md b/articles/quickstart/native/ionic-angular/files/app.component.md
new file mode 100644
index 0000000000..0b54654bab
--- /dev/null
+++ b/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();
+          }
+        }
+      });
+    });
+  }
+}
+```
diff --git a/articles/quickstart/native/ionic-angular/files/app.module.md b/articles/quickstart/native/ionic-angular/files/app.module.md
new file mode 100644
index 0000000000..987cc68c0d
--- /dev/null
+++ b/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],
+})
+```
diff --git a/articles/quickstart/native/ionic-angular/files/login-button.md b/articles/quickstart/native/ionic-angular/files/login-button.md
new file mode 100644
index 0000000000..7821093b94
--- /dev/null
+++ b/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();
+  }
+}
+```
diff --git a/articles/quickstart/native/ionic-angular/files/logout-button.md b/articles/quickstart/native/ionic-angular/files/logout-button.md
new file mode 100644
index 0000000000..32da066dac
--- /dev/null
+++ b/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();
+  }
+}
+```
diff --git a/articles/quickstart/native/ionic-angular/files/user-profile.md b/articles/quickstart/native/ionic-angular/files/user-profile.md
new file mode 100644
index 0000000000..01fea0f83d
--- /dev/null
+++ b/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) {}
+}
+```
diff --git a/articles/quickstart/native/ionic-angular/index.yml b/articles/quickstart/native/ionic-angular/index.yml
new file mode 100644
index 0000000000..8eac1d65b1
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-angular/interactive.md b/articles/quickstart/native/ionic-angular/interactive.md
new file mode 100644
index 0000000000..f2839fd570
--- /dev/null
+++ b/articles/quickstart/native/ionic-angular/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Add Login to Your Ionic Angular with Capacitor Application
+description: This guide demonstrates how to integrate Auth0 with an Ionic (Angular) & Capacitor application using the Auth0 Angular SDK.
+interactive:  true
+files:
+ - files/app.module
+ - files/app.component
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: angular
+locale: en-US
+---
+
+# 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.
        
+
+## Getting started
+
+
+
        This quickstart assumes you already have an Ionic application up and running with Capacitor. If not, check out the Using Capacitor with Ionic Framework guide to get started with a simple app, or clone our sample apps.
        You should also be familiar with the Capacitor development workflow.
        
+
+## Configure Auth0
+
+
+
        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.
        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 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.
        If you are following along with our sample project, set this to:
        YOUR_PACKAGE_ID://{yourDomain}/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.
        If you are following along with our sample project, set this to:
        YOUR_PACKAGE_ID://{yourDomain}/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.
        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.
        
+
+## Install the Auth0 Angular SDK
+
+
+
        Run the following command within your project directory to install the Auth0 Angular SDK:
        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.
        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:
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser: Allows you to interact with the device's system browser and is used to open the URL to Auth0's authorization endpoint.
        • @capacitor/app: Allows you to subscribe to high-level app events, useful for handling callbacks from Auth0.
        Capacitor's Browser plugin on iOS uses SFSafariViewController, which on iOS 11+ does not share cookies with Safari on the device. This means that SSO will not work on those devices. If you need SSO, please instead use a compatible plugin that uses ASWebAuthenticationSession.
        
+
+## 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.
        • 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.
        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. 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.
        Additionally, the SDK has the ability to use a custom cache implementation 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 to store tokens, as this is backed by UserDefaults and SharedPreferences on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud.
        Ionic & Capacitor (Angular) - Step 4 - Register and configure the authentication module 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application {{{ data-action="code" data-code="login-button.ts" }}}
+
+
+
        In a Capacitor application, the Capacitor's Browser plugin performs a redirect to the Auth0 Universal Login Page. 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 on iOS, and Chrome Custom Tabs on Android).
        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.
        Ionic & Capacitor (Angular) - Step 5 - Add login to your application 
        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.
        
+
+  
        
+
+  
        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" }}}
+
+
+
        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.
        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. Otherwise, the screen doesn't update to show the authenticated state after log in.
        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 for iOS, or Create Deep Links to App Content for Android.
        Ionic & Capacitor (Angular) - Step 6 - Handling the login callback 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## Add logout to your application {{{ data-action="code" data-code="logout-button.ts" }}}
+
+
+
        Now that users can log in, you need to configure a way to log out. 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.
        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.
        Ionic & Capacitor (Angular) - Step 7 - Add logout to your application 
        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.
        
+
+  
        
+
+  
        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 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.
        Ionic & Capacitor (Angular) - Step 8 - Show the user profile 
        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.
        
+
+  
        
+
+  
        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/articles/quickstart/native/ionic-react/01-login.md b/articles/quickstart/native/ionic-react/01-login.md
new file mode 100644
index 0000000000..1ec92b5d60
--- /dev/null
+++ b/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 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
+- `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 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 within a component correctly after you have logged in.
+:::
diff --git a/articles/quickstart/native/ionic-react/download.md b/articles/quickstart/native/ionic-react/download.md
new file mode 100644
index 0000000000..6dd3a8e492
--- /dev/null
+++ b/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
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the Application 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
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for Android and iOS are setup correctly. For iOS, CocoaPods must be installed.
+
+5) Make sure Node.JS LTS 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 on Capacitor's docs site.
diff --git a/articles/quickstart/native/ionic-react/files/app.md b/articles/quickstart/native/ionic-react/files/app.md
new file mode 100644
index 0000000000..f41566cdb1
--- /dev/null
+++ b/articles/quickstart/native/ionic-react/files/app.md
@@ -0,0 +1,58 @@
+---
+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]);
+
+  // ..
+};// 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]);
+
+  // ..
+};
+```
diff --git a/articles/quickstart/native/ionic-react/files/index.md b/articles/quickstart/native/ionic-react/files/index.md
new file mode 100644
index 0000000000..ab848413f9
--- /dev/null
+++ b/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(
+  
+    
+  
+);
+```
diff --git a/articles/quickstart/native/ionic-react/files/login-button.md b/articles/quickstart/native/ionic-react/files/login-button.md
new file mode 100644
index 0000000000..20dc0072e2
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/native/ionic-react/files/logout-button.md b/articles/quickstart/native/ionic-react/files/logout-button.md
new file mode 100644
index 0000000000..87d163ec18
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/native/ionic-react/files/user-profile.md b/articles/quickstart/native/ionic-react/files/user-profile.md
new file mode 100644
index 0000000000..8d811b0020
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/native/ionic-react/index.yml b/articles/quickstart/native/ionic-react/index.yml
new file mode 100644
index 0000000000..135bac3db8
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-react/interactive.md b/articles/quickstart/native/ionic-react/interactive.md
new file mode 100644
index 0000000000..bcbed1c505
--- /dev/null
+++ b/articles/quickstart/native/ionic-react/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Add login to your Ionic React with Capacitor app
+description: This guide demonstrates how to integrate Auth0 with an Ionic (React) & Capacitor application using the Auth0 React SDK.
+interactive:  true
+files:
+ - files/index
+ - files/login-button
+ - files/logout-button
+ - files/app
+ - files/user-profile
+github:
+  path: react
+locale: en-US
+---
+
+# 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.
        
+
+## Getting started
+
+
+
        This quickstart assumes you already have an Ionic application up and running with Capacitor. If not, check out the Using Capacitor with Ionic Framework guide to get started with a simple app, or clone our sample apps.
        You should also be familiar with the Capacitor development workflow.
        
+
+## Configure Auth0
+
+
+
        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.
        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 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.
        If you are following along with our sample project, set this to:
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/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.
        If you are following along with our sample project, set this to:
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/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.
        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.
        
+
+## Install the Auth0 React SDK
+
+
+
        Run the following command within your project directory to install the Auth0 React SDK:
        npm install @auth0/auth0-react
        The SDK exposes methods and variables that help you integrate Auth0 with your React application idiomatically using React Hooks or Higher-Order Components.
        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:
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser: Allows you to interact with the device's system browser and is used to open the URL to Auth0's authorization endpoint.
        • @capacitor/app: Allows you to subscribe to high-level app events, useful for handling callbacks from Auth0.
        Capacitor's Browser plugin on iOS uses SFSafariViewController, which on iOS 11+ does not share cookies with Safari on the device. This means that SSO will not work on those devices. If you need SSO, please instead use a compatible plugin that uses ASWebAuthenticationSession.
        
+
+## Configure the Auth0Provider component {{{ data-action="code" data-code="index.tsx" }}}
+
+
+
        Under the hood, the Auth0 React SDK uses React Context 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.
        • 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.
        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. 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.
        Additionally, the SDK has the ability to use a custom cache implementation 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 to store tokens, as this is backed by UserDefaults and SharedPreferences on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud.
        Ionic & Capacitor (React) - Step 4 - Configure the Auth0Provider component 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application {{{ data-action="code" data-code="login-button.tsx" }}}
+
+
+
        In a Capacitor application, the Capacitor's Browser plugin performs a redirect to the Auth0 Universal Login Page. 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 on iOS, and Chrome Custom Tabs on Android).
        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.
        Ionic & Capacitor (React) - Step 5- Add login to your application 
        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.
        
+
+  
        
+
+  
        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" }}}
+
+
+
        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.
        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 for iOS, or Create Deep Links to App Content for Android.
        Ionic & Capacitor (React) - Step 6 - Handle the login callback 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## Add logout to your application {{{ data-action="code" data-code="logout-button.tsx" }}}
+
+
+
        Now that users can log in, you need to configure a way to log out. 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.
        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.
        Ionic & Capacitor (React) - Step 7 - Add logout to your application 
        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.
        
+
+  
        
+
+  
        
+
+  
        
+
+## Show the user profile {{{ data-action="code" data-code="user-profile.tsx" }}}
+
+
+
        The Auth0 React SDK retrieves the user's 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.
        Ionic & Capacitor (React) - Step 8 - Show the user profile 
        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.
        
+
+  
        
+
+  
        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/articles/quickstart/native/ionic-vue/01-login.md b/articles/quickstart/native/ionic-vue/01-login.md
new file mode 100644
index 0000000000..0e31f36580
--- /dev/null
+++ b/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
+- `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 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 within a component correctly after you have logged in.
+:::
diff --git a/articles/quickstart/native/ionic-vue/download.md b/articles/quickstart/native/ionic-vue/download.md
new file mode 100644
index 0000000000..58a0397ae6
--- /dev/null
+++ b/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
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the Application 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
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for Android and iOS are setup correctly. For iOS, CocoaPods must be installed.
+
+5) Make sure Node.JS LTS 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 on Capacitor's docs site.
diff --git a/articles/quickstart/native/ionic-vue/files/LoginButton.md b/articles/quickstart/native/ionic-vue/files/LoginButton.md
new file mode 100644
index 0000000000..ceb58fc255
--- /dev/null
+++ b/articles/quickstart/native/ionic-vue/files/LoginButton.md
@@ -0,0 +1,41 @@
+---
+name: LoginButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+
+```
diff --git a/articles/quickstart/native/ionic-vue/files/LogoutButton.md b/articles/quickstart/native/ionic-vue/files/LogoutButton.md
new file mode 100644
index 0000000000..6ebfb8809e
--- /dev/null
+++ b/articles/quickstart/native/ionic-vue/files/LogoutButton.md
@@ -0,0 +1,44 @@
+---
+name: LogoutButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
diff --git a/articles/quickstart/native/ionic-vue/files/UserProfile.md b/articles/quickstart/native/ionic-vue/files/UserProfile.md
new file mode 100644
index 0000000000..0366a88cc4
--- /dev/null
+++ b/articles/quickstart/native/ionic-vue/files/UserProfile.md
@@ -0,0 +1,35 @@
+---
+name: UserProfile.vue
+language: 
+---
+    
+```
+
+
+
+```
diff --git a/articles/quickstart/native/ionic-vue/files/app.md b/articles/quickstart/native/ionic-vue/files/app.md
new file mode 100644
index 0000000000..1f9bee09d5
--- /dev/null
+++ b/articles/quickstart/native/ionic-vue/files/app.md
@@ -0,0 +1,45 @@
+---
+name: App.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
diff --git a/articles/quickstart/native/ionic-vue/files/login-button.md b/articles/quickstart/native/ionic-vue/files/login-button.md
new file mode 100644
index 0000000000..a18deea1df
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-vue/files/logout-button.md b/articles/quickstart/native/ionic-vue/files/logout-button.md
new file mode 100644
index 0000000000..43940c7d70
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-vue/files/main.md b/articles/quickstart/native/ionic-vue/files/main.md
new file mode 100644
index 0000000000..38d763e101
--- /dev/null
+++ b/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");
+});
+```
diff --git a/articles/quickstart/native/ionic-vue/files/user-profile.md b/articles/quickstart/native/ionic-vue/files/user-profile.md
new file mode 100644
index 0000000000..e0c6f390ea
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-vue/index.yml b/articles/quickstart/native/ionic-vue/index.yml
new file mode 100644
index 0000000000..52cbadde94
--- /dev/null
+++ b/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/articles/quickstart/native/ionic-vue/interactive.md b/articles/quickstart/native/ionic-vue/interactive.md
new file mode 100644
index 0000000000..89121aa1ff
--- /dev/null
+++ b/articles/quickstart/native/ionic-vue/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Add login to your Ionic Vue with Capacitor app
+description: This guide demonstrates how to integrate Auth0 with an Ionic (Vue) & Capacitor application using the Auth0 Vue SDK
+interactive:  true
+files:
+ - files/main
+ - files/LoginButton
+ - files/LogoutButton
+ - files/App
+ - files/UserProfile
+github:
+  path: vue
+locale: en-US
+---
+
+# 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. 
        
+
+## Getting started
+
+
+
        This quickstart assumes you already have an Ionic application up and running with Capacitor. If not, check out the Using Capacitor with Ionic Framework guide to get started with a simple app, or clone our sample apps.
        You should also be familiar with the Capacitor development workflow.
        
+
+## Configure Auth0
+
+
+
        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.
        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 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
        If you are following along with our sample project, set this to YOUR_PACKAGE_ID://{yourDomain}/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.
        If you are following along with our sample project, set this to YOUR_PACKAGE_ID://{yourDomain}/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.
        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.
        
+
+## Install the Auth0 Vue SDK
+
+
+
        Run the following command within your project directory to install the Auth0 Vue SDK:
        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.
        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:
        npm install @capacitor/browser @capacitor/app
        • @capacitor/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 - allows you to subscribe to high-level app events, useful for handling callbacks from Auth0
        Capacitor's Browser plugin on iOS uses SFSafariViewController, which on iOS 11+ does not share cookies with Safari on the device. This means that SSO will not work on those devices. If you need SSO, please instead use a compatible plugin that uses ASWebAuthenticationSession.
        
+
+## Configure the CreateAuht0 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.
        • 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.
        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. 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.
        Additionally, the SDK has the ability to use a custom cache implementation 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 to store tokens, as this is backed by UserDefaults and SharedPreferences on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud.
        ionic Quickstart - Step 4 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application {{{ data-action="code" data-code="LoginButton.vue" }}}
+
+
+
        In a Capacitor application, the Capacitor's Browser plugin performs a redirect to the Auth0 Universal Login Page. 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 on iOS, and Chrome Custom Tabs on Android).
        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.
        ionic step 5 checkpoint 
        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.
        
+
+  
        
+
+  
        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" }}}
+
+
+
        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.
        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 for iOS, or Create Deep Links to App Content for Android.
        ionic step 6 Checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## Add logout to your application {{{ data-action="code" data-code="LogoutButton.vue" }}}
+
+
+
        Now that users can log in, you need to configure a way to log out. 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.
        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.
        ionic step 7 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 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.
        ionic step 8 Checkpoint 
        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.
        
+
+  
        
+
+  
        
+
+  
        
diff --git a/articles/quickstart/native/ionic/01-login.md b/articles/quickstart/native/ionic/01-login.md
deleted file mode 100644
index 384f40f07f..0000000000
--- a/articles/quickstart/native/ionic/01-login.md
+++ /dev/null
@@ -1,240 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add authentication and authorization to an Ionic app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ionic-samples',
-  path: '01-Login',
-  requirements: [
-    'Ionic 1.x',
-    'AngularJS 1.5+'
-  ]
-}) %>
-
-<%= include('../_includes/_ionic_setup') %>
-
-## Set Up URL Redirects
-
-Use the `onRedirectUri` method from **auth0-cordova** when your app loads to properly handle redirects after authentication.
-
-```js
-// www/js/app.js
-
-var Auth0Cordova = require('@auth0/cordova');
-
-angular.module('yourApp', ['ionic'])
-
-.run(function($ionicPlatform) {
-  $ionicPlatform.ready(function() {
-    
-    // ...
-    function handleUrl(url) {
-      Auth0Cordova.onRedirectUri(url);
-    }
-
-    window.handleOpenURL = handleUrl;
-
-  });
-})
-
-// ...
-```
-
-::: note
-**Note:** The code samples shown in this tutorial assume that your app is using some kind of bundler like browserify or webpack to make npm modules available in a client application. The downloadable sample for this tutorial uses browserify to quickly bundle the JavaScript files for the app but you are free to use whichever bundler you like.
-:::
-
-## Create an Authentication Service and Configure Auth0
-
-To coordinate authentication tasks, it's best to set up an injectable service that can be reused across the application. This service needs methods for logging users in and out, as well as checking their authentication state. Be sure to replace `YOUR_PACKAGE_ID` with the identifier for your app in the configuration block.
-
-```js
-// www/js/services.js
-
-angular.module('starter.services', [])
-
-.factory('Auth', function($rootScope) {
-
-  var Auth0Cordova = require('@auth0/cordova');
-  var auth0 = require('auth0-js');
-  var userProfile = {};
-
-  var auth0Config = {
-    clientId: '${account.clientId}',
-    domain: '${account.namespace}',
-    callbackURL: location.href,
-    packageIdentifier: 'YOUR_PACKAGE_ID'
-  };
-
-  auth0Config.clientID = auth0Config.clientId;
-
-  var webAuth = new auth0.WebAuth(auth0Config);
-
-  function setSession(authResult) {
-    var expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    window.localStorage.setItem('access_token', authResult.accessToken);
-    window.localStorage.setItem('id_token', authResult.idToken);
-    window.localStorage.setItem('expires_at', expiresAt);
-  }
-
-  function isAuthenticated() {
-    var expiresAt = JSON.parse(window.localStorage.getItem('expires_at'));
-    return Date.now() < expiresAt;
-  }
-  
-  function getProfile(cb) {
-    var accessToken = localStorage.getItem('access_token');
-    if (!accessToken) {
-      throw new Error('Access token must exist to fetch profile');
-    }
-
-    webAuth.client.userInfo(accessToken, (err, profile) => {
-      if (profile) {
-        userProfile = profile;
-      }
-      cb(err, profile);
-    });
-  }
-
-  function login() {
-    var client = new Auth0Cordova(auth0Config);
-
-    var options = {
-      scope: 'openid profile offline_access'
-    };
-
-    client.authorize(options, function(err, authResult) {
-      if (err) {
-        throw new Error(err);
-      }
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        setSession(authResult);
-        $rootScope.$apply();
-      }
-    });
-  }
-
-  function logout() {
-    window.localStorage.removeItem('profile');
-    window.localStorage.removeItem('access_token');
-    window.localStorage.removeItem('id_token');
-    window.localStorage.removeItem('expires_at');
-  }
-
-  return {
-    login: login,
-    logout: logout,
-    getProfile: getProfile,
-    isAuthenticated: isAuthenticated
-  };
-});
-
-```
-
-## Add Login and Logout Controls
-
-Add controls to your app to allow users to log in and log out. The controls should call the `login` and `logout` methods from the `Auth` service. Start by injecting the `Auth` service in a controller.
-
-```js
-// www/js/controllers.js
-
-angular.module('starter.controllers', [])
-
-.controller('HomeCtrl', function($scope, Auth) {
-  $scope.auth = Auth;
-})
-```
-
-The `Auth` service is now accessible in the view and its `login` method can be called.
-
-```html
-
-
-
-
-
-```
-
-The **Log In** button is only displayed if the user has an unexpired `access_token` in local storage which is the indication that they are authenticated. The **Log Out** button is only displayed if the user isn't authenticated. 
-
-## Display Profile Data
-
-Your application will likely require some kind of profile area for users to see their information. Depending on your needs, this can also serve as the place for them to log out of the app.
-
-Create a controller for a **Profile** area and make use of the `Auth` service within it.
-
-```js
-// www/js/controllers.js
-
-angular.module('starter.controllers', [])
-
-// ...
-.controller('ProfileCtrl', function($scope, Auth) {
-  $scope.auth = Auth;
-
-  if (Auth.isAuthenticated()) {
-    if (Auth.userProfile) {
-      $scope.profile = Auth.userProfile;
-    } else {
-      
-      Auth.getProfile(function(err, profile) {
-        if (err) {
-          return alert(err);
-        }
-        $scope.$evalAsync(function() {
-          $scope.profile = profile;
-        });
-      });
-    }
-  }
-
-});
-```
-
-The `getProfile` method from the `Auth` service makes a call to Auth0 for the user's profile and saves the result in a `userProfile` object in the `Auth` service.
-
-The `ProfileCtrl` controller first checks whether the `userProfile` object is populated. If it is, that object is used to power the **Profile** view. If it isn't, a call to Auth0 is made for the profile.
-
-Create a view for the profile.
-
-```html
-
-
-
-  
-    
        
-      
        Please log in to view your profile.
        
-    
        
-    
        
-      
        
-        avatar
-        
        {{ profile.name }}
        
-        
        {{ profile.nickname  }}
        
-      
        
-      
        
-        
        {{ profile | json }}
        
-      
        
-    
        
-          
-        
-```
-
-### Troubleshooting
-
-#### Cannot read property 'isAvailable' of undefined
-
-This means that you're attempting to test this in a browser. At this time you'll need to run this either in an emulator or on a device.
diff --git a/articles/quickstart/native/ionic/_index.yml b/articles/quickstart/native/ionic/_index.yml
deleted file mode 100644
index da3c504339..0000000000
--- a/articles/quickstart/native/ionic/_index.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-# Remember to add snippets back to .md
-title: Ionic
-alias:
-  - ionic
-language:
-  - Javascript
-framework:
-  - AngularJS
-  - Cordova
-hybrid: true
-image: /media/platforms/ionic.jpeg
-tags:
-  - quickstart
-snippets:
-  use: native-platforms/ionic/use
-seo_alias: ionic
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/ionic2/01-login.md b/articles/quickstart/native/ionic2/01-login.md
deleted file mode 100644
index 51e5b68bc2..0000000000
--- a/articles/quickstart/native/ionic2/01-login.md
+++ /dev/null
@@ -1,236 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add authentication and authorization to an Ionic 2 app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ionic2-samples',
-  path: '01-Login',
-  requirements: [
-    'Ionic 2.x',
-    'Angular 4+'
-  ]
-}) %>
-
-<%= include('../_includes/_ionic_setup') %>
-
-## Set Up URL Redirects
-
-Use the `onRedirectUri` method from **auth0-cordova** when your app loads to properly handle redirects after authentication.
-
-```js
-// app.component.ts
-
-import { Component } from '@angular/core';
-import { Platform } from 'ionic-angular';
-import { StatusBar } from '@ionic-native/status-bar';
-import { SplashScreen } from '@ionic-native/splash-screen';
-
-import { HomePage } from '../pages/home/home';
-
-// Import Auth0Cordova
-import Auth0Cordova from '@auth0/cordova';
-
-@Component({
-  templateUrl: 'app.html'
-})
-export class MyApp {
-  rootPage:any = HomePage;
-
-  constructor(platform: Platform, statusBar: StatusBar, splashScreen: SplashScreen) {
-    platform.ready().then(() => {
-      statusBar.styleDefault();
-      splashScreen.hide();
-
-      // Add this function
-      (window).handleOpenURL = (url) => {
-        Auth0Cordova.onRedirectUri(url);
-      };
-
-    });
-  }
-}
-```
-
-## Create an Authentication Service and Configure Auth0
-
-To coordinate authentication tasks, it's best to set up an injectable service that can be reused across the application. This service needs methods for logging users in and out, as well as checking their authentication state. Be sure to replace `YOUR_PACKAGE_ID` with the identifier for your app in the configuration block.
-
-```js
-// src/services/auth.service.ts
-
-import { Injectable, NgZone } from '@angular/core';
-import { Observable, Subscription } from 'rxjs';
-
-import Auth0Cordova from '@auth0/cordova';
-import Auth0 from 'auth0-js';
-
-const auth0Config = {
-  // needed for auth0
-  clientID: '${account.clientId}',
-
-  // needed for auth0cordova
-  clientId: '${account.clientId}',
-  domain: '${account.namespace}',
-  callbackURL: location.href,
-  packageIdentifier: 'YOUR_PACKAGE_ID'
-};
-
-@Injectable()
-export class AuthService {
-  auth0 = new Auth0.WebAuth(auth0Config);
-  accessToken: string;
-  idToken: string;
-  user: any;
-
-  constructor(public zone: NgZone) {
-    this.user = this.getStorageVariable('profile');
-    this.idToken = this.getStorageVariable('id_token');
-  }
-
-  private getStorageVariable(name) {
-    return JSON.parse(window.localStorage.getItem(name));
-  }
-
-  private setStorageVariable(name, data) {
-    window.localStorage.setItem(name, JSON.stringify(data));
-  }
-
-  private setIdToken(token) {
-    this.idToken = token;
-    this.setStorageVariable('id_token', token);
-  }
-
-  private setAccessToken(token) {
-    this.accessToken = token;
-    this.setStorageVariable('access_token', token);
-  }
-
-  public isAuthenticated() {
-    const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return Date.now() < expiresAt;
-  }
-
-  public login() {
-    const client = new Auth0Cordova(auth0Config);
-
-    const options = {
-      scope: 'openid profile offline_access'
-    };
-
-    client.authorize(options, (err, authResult) => {
-      if(err) {
-        throw err;
-      }
-
-      this.setIdToken(authResult.idToken);
-      this.setAccessToken(authResult.accessToken);
-
-      const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-      this.setStorageVariable('expires_at', expiresAt);
-
-      this.auth0.client.userInfo(this.accessToken, (err, profile) => {
-        if(err) {
-          throw err;
-        }
-
-        profile.user_metadata = profile.user_metadata || {};
-        this.setStorageVariable('profile', profile);
-        this.zone.run(() => {
-          this.user = profile;
-        });
-      });
-    });
-  }
-
-  public logout() {
-    window.localStorage.removeItem('profile');
-    window.localStorage.removeItem('access_token');
-    window.localStorage.removeItem('id_token');
-    window.localStorage.removeItem('expires_at');
-
-    this.idToken = null;
-    this.accessToken = null;
-    this.user = null;
-  }
-
-}
-```
-
-## Add a Login Control
-
-Add a control to your app to allow users to log in. The control should call the `login` method from the `AuthService`. Start by injecting the `AuthService` in a component.
-
-```js
-// src/pages/home/home.ts
-
-import { Component } from '@angular/core';
-
-import { AuthService } from '../../services/auth.service';
-
-@Component({
-  selector: 'page-home',
-  templateUrl: 'home.html'
-})
-export class HomePage {
-
-  constructor(public auth: AuthService) {}
-
-}
-```
-
-The `AuthService` is now accessible in the view and its `login` method can be called.
-
-```html
-
-
-
        
-  
-
        
-```
-
-## Display Profile Data
-
-Your application will likely require some kind of profile area for users to see their information. Depending on your needs, this can also serve as the place for them to log out of the app.
-
-The `login` method in the `AuthService` includes a call to Auth0 for the authenticated user's profile. This profile information can now be used in a template.
-
-```html
-
-
-
-  
-    
-      Home Page
-    
-  
-
-
-
-
-  
-  
        
-    
-      
-      
-        {{ auth.user.name }}
-      
-    
-    
-  
        
-
-        
-```
-
-### Troubleshooting
-
-#### Cannot read property 'isAvailable' of undefined
-
-This means that you're attempting to test this in a browser. At this time you'll need to run this either in an emulator or on a device.
-
-#### Completely blank page when launching the app
-
-This could either mean that you've built the seed project using Ionic 1, or that the device where you are testing it isn't entirely supported by Ionic 2 yet. Be sure to check the console for errors.
diff --git a/articles/quickstart/native/ionic2/_index.yml b/articles/quickstart/native/ionic2/_index.yml
deleted file mode 100644
index 958aacb098..0000000000
--- a/articles/quickstart/native/ionic2/_index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Ionic 2
-logo_name: ionic
-alias:
-  - ionic2
-language:
-  - Typescript
-framework:
-  - Ionic2
-  - Angular4
-  - Cordova
-hybrid: true
-image: /media/platforms/ionic.jpeg
-tags:
-  - quickstart
-snippets:
-  use: native-platforms/ionic2/use
-seo_alias: ionic2
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/ionic3/01-login.md b/articles/quickstart/native/ionic3/01-login.md
deleted file mode 100644
index 2079b0e1b5..0000000000
--- a/articles/quickstart/native/ionic3/01-login.md
+++ /dev/null
@@ -1,263 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add authentication and authorization to an Ionic 3 app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ionic3-samples',
-  path: '01-Login',
-  requirements: [
-    'Ionic 3.x',
-    'Angular 5+'
-  ]
-}) %>
-
-<%= include('../_includes/_ionic_setup') %>
-
-## Set Up URL Redirects
-
-Use the `onRedirectUri` method from **auth0-cordova** when your app loads to properly handle redirects after authentication.
-
-```js
-// src/app/app.component.ts
-
-import { Component } from '@angular/core';
-import { Platform } from 'ionic-angular';
-import { StatusBar } from '@ionic-native/status-bar';
-import { SplashScreen } from '@ionic-native/splash-screen';
-
-import { TabsPage } from '../pages/tabs/tabs';
-
-// Import Auth0Cordova
-import Auth0Cordova from '@auth0/cordova';
-
-@Component({
-  templateUrl: 'app.html'
-})
-export class MyApp {
-  rootPage:any = TabsPage;
-
-  constructor(
-    platform: Platform,
-    statusBar: StatusBar,
-    splashScreen: SplashScreen
-  ) {
-    platform.ready().then(() => {
-      // Okay, so the platform is ready and our plugins are available.
-      // Here you can do any higher level native things you might need.
-      statusBar.styleDefault();
-      splashScreen.hide();
-
-      // Redirect back to app after authenticating
-      (window as any).handleOpenURL = (url: string) => {
-        Auth0Cordova.onRedirectUri(url);
-      }
-    });
-  }
-}
-```
-
-## Configure Auth0
-
-Create a new file called `auth.config.ts` in your `src/services` folder to provide the necessary Auth0 configuration for your Ionic app:
-
-```js
-// src/services/auth.config.ts
-
-export const AUTH_CONFIG = {
-  // Needed for Auth0 (capitalization: ID):
-  clientID: '${account.clientId}',
-  // Needed for Auth0Cordova (capitalization: Id):
-  clientId: '${account.clientId}',
-  domain: '${account.namespace}',
-  packageIdentifier: 'YOUR_PACKAGE_ID' // config.xml widget ID, e.g., com.auth0.ionic
-};
-```
-
-Be sure to replace `YOUR_PACKAGE_ID` with the identifier for your app.
-
-## Create an Authentication Service
-
-To coordinate authentication tasks, it's best to set up an injectable service that can be reused across the application. This service needs methods for logging users in and out, as well as checking their authentication state.
-
-```js
-// src/services/auth.service.ts
-import { Injectable, NgZone } from '@angular/core';
-import { Storage } from '@ionic/storage';
-
-// Import AUTH_CONFIG, Auth0Cordova, and auth0.js
-import { AUTH_CONFIG } from './auth.config';
-import Auth0Cordova from '@auth0/cordova';
-import * as auth0 from 'auth0-js';
-
-@Injectable()
-export class AuthService {
-  Auth0 = new auth0.WebAuth(AUTH_CONFIG);
-  Client = new Auth0Cordova(AUTH_CONFIG);
-  accessToken: string;
-  user: any;
-  loggedIn: boolean;
-  loading = true;
-
-  constructor(
-    public zone: NgZone,
-    private storage: Storage
-  ) {
-    this.storage.get('profile').then(user => this.user = user);
-    this.storage.get('access_token').then(token => this.accessToken = token);
-    this.storage.get('expires_at').then(exp => {
-      this.loggedIn = Date.now() < JSON.parse(exp);
-      this.loading = false;
-    });
-  }
-
-  login() {
-    this.loading = true;
-    const options = {
-      scope: 'openid profile offline_access'
-    };
-    // Authorize login request with Auth0: open login page and get auth results
-    this.Client.authorize(options, (err, authResult) => {
-      if (err) {
-        throw err;
-      }
-      // Set access token
-      this.storage.set('access_token', authResult.accessToken);
-      this.accessToken = authResult.accessToken;
-      // Set access token expiration
-      const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-      this.storage.set('expires_at', expiresAt);
-      // Set logged in
-      this.loading = false;
-      this.loggedIn = true;
-      // Fetch user's profile info
-      this.Auth0.client.userInfo(this.accessToken, (err, profile) => {
-        if (err) {
-          throw err;
-        }
-        this.storage.set('profile', profile).then(val =>
-          this.zone.run(() => this.user = profile)
-        );
-      });
-    });
-  }
-
-  logout() {
-    this.storage.remove('profile');
-    this.storage.remove('access_token');
-    this.storage.remove('expires_at');
-    this.accessToken = null;
-    this.user = null;
-    this.loggedIn = false;
-  }
-}
-```
-
-## Show Authentication State and Profile Data
-
-Add a control to your app to allow users to log in. The control should call the `login` method from the `AuthService`. Start by injecting the `AuthService` in a component.
-
-```js
-// src/pages/home/home.ts
-import { Component } from '@angular/core';
-import { NavController } from 'ionic-angular';
-import { AuthService } from './../../services/auth.service';
-
-@Component({
-  selector: 'page-home',
-  templateUrl: 'home.html'
-})
-export class HomePage {
-  
-  constructor(
-    public navCtrl: NavController,
-    public auth: AuthService
-  ) {}
-
-}
-```
-
-The `AuthService` is now accessible in the view and its `login` method can be called.
-
-```html
-
-
-
-  
-    Home
-  
-
-
-
-  
        Loading...
        
-  
-    
-    
-    
-    
-      
-        
-        
-          {{ auth.user.name }}
-          
        {{ auth.user | json }}
        
-                
-              
-      
-            
-          
-        
-```
-
-## Add Platform and Run the App
-
-You will now need to allow Ionic / Cordova to install the necessary plugins and update your `config.xml` appropriately for the platform you wish to run on.
-
-Use the following commands to add your desired platform(s) (e.g., `ios` or `android`) and run the app:
-
-```bash
-# Add platform (e.g., ios or android)
-$ ionic cordova platform add {platform}
-# Run on desired platform (e.g., ios or android)
-$ ionic cordova run {platform} --livereload
-```
-
-This will then launch your app in the local emulation environment for the platform you chose (Xcode Simulator for iOS or the Android emulator of your choice).
-
-Don't be alarmed if you _cannot authenticate_ successfully yet at this stage! There was some configuration generated by running the app that you still need to add to your Auth0 settings.
-
-## Update Auth0 Dashboard Configuration
-
-1. After executing the `run` command, your `config.xml` file should contain `` tag(s).
-2. Make note of IP address URLs from any `` tags.
-3. In your [Auth0 Dashboard](https://manage.auth0.com), go to your Ionic app's **Settings**.
-4. Add the full allowed navigation addresses (including `http://` and ports) to the **Allowed Origins (CORS)** settings for your Auth0 application and click the **Save Changes** button.
-
-You should now be able to log into your app!
-
-## Troubleshooting
-
-### Cannot read property 'isAvailable' of undefined
-
-This means that you're attempting to test this in a browser. This library was designed to be run on a device and expects a Cordova environment with the `SafariViewController` plugin available.
-
-### Completely blank page when launching the app
-
-This could either mean that you've built the seed project using a different version of Ionic, or that the device where you are testing it isn't entirely supported by Ionic 3 yet.
-
-This could also occur on iOS if you are running the app in a simulator and something else is listening on port `8080` on the same machine. A good way to check for this is to run the application from XCode instead and check the logs.
-
-### Profile doesn't show after successful login
-
-This is not actually an issue with your code, but is an Ionic quirk when running in an emulator (generally iOS). You can use a real device, or generally fix this by turning on live reload when you run your app in the emulator, and adding an alert in your `auth.service.ts` that simply creates a notification with the JSON stringified contents of the `authResult` in the `Client.authorize()` callback. This will generally fix the issue, and then you can remove the alert and everything should work normally.
diff --git a/articles/quickstart/native/ionic3/index.yml b/articles/quickstart/native/ionic3/index.yml
deleted file mode 100644
index 6c7858543a..0000000000
--- a/articles/quickstart/native/ionic3/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Ionic 3
-logo_name: ionic
-alias:
-  - ionic3
-language:
-  - Typescript
-framework:
-  - Ionic3
-  - Angular5
-  - Cordova
-hybrid: true
-image: /media/platforms/ionic.jpeg
-tags:
-  - quickstart
-snippets:
-  use: native-platforms/ionic3/use
-seo_alias: ionic3
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/ios-objc/00-login.md b/articles/quickstart/native/ios-objc/00-login.md
deleted file mode 100644
index 0026653976..0000000000
--- a/articles/quickstart/native/ios-objc/00-login.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Login
-description: This tutorial will show you how to integrate the Auth0 Login in your iOS ObjectiveC project in order to present a login screen.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '01-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-<%= include('_includes/_login_centralized') %>
diff --git a/articles/quickstart/native/ios-objc/01-embedded-login.md b/articles/quickstart/native/ios-objc/01-embedded-login.md
deleted file mode 100644
index bbb69598f6..0000000000
--- a/articles/quickstart/native/ios-objc/01-embedded-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Embedded Login
-description: This tutorial demonstrates how to integrate Embedded Login in your iOS Objective-C project in order to present a login widget.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  branch: 'embedded-login',
-  path: '01-Embedded-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-<%= include('_includes/_login_embedded') %>
diff --git a/articles/quickstart/native/ios-objc/02-custom-login-form.md b/articles/quickstart/native/ios-objc/02-custom-login-form.md
deleted file mode 100644
index 81e31dfd33..0000000000
--- a/articles/quickstart/native/ios-objc/02-custom-login-form.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Custom Login Form
-description: This tutorial demonstrates how to perform Login and Sign Up by creating your own Login form.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  branch: 'embedded-login',
-  path: '02-Custom-Login-Form',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-<%= include('_includes/_hybrid_setup') %>
-
-## Implement Database Login
-
-${snippet(meta.snippets.setup)}
-
-Then, add the following code to perform a login:
-
-```objc
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth loginWithUsernameOrEmail:@"email@foo.com"
-                      password:@"123456"
-                         realm:@"Username-Password-Authentication"
-                      audience:nil
-                         scope:@"openid profile"
-                      callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-                              if(error) {
-                                  // You've got an error
-                              } else {
-                                  // Logged in successfully
-                                  // You've got a Credentials instance, which you'll use, for example, to retrieve the User Profile
-                              }
-                      }];
-```
-
-That's it! You'll get either a `credentials` object or an `error` case after performing a login.
-
-Basically, `credentials` contains token-related information; you will normally store this object for later use. On the other hand, `error` is an enum containing possible authentication error cases that you might want to keep track of.
-
-::: note
-For further reference on the `Credentials` object, see [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift)
-:::
-
-## Retrieve the User Profile
-
-Once you've obtained a `Credentials` object, retrieving a user profile is quite simple. All you have to do is:
-
-```objc
-[auth userInfoWithAccessToken:[credentials accessToken]
-      callback:^(NSError * _Nullable error, UserInfo * _Nullable profile) {
-               dispatch_async(dispatch_get_main_queue(), ^{
-                   [self.spinner stopAnimating];
-                   if(error) {
-                       // You've got an error
-                   } else {
-                       // You've got a Profile object
-                   }
-               });
-           }];
-```
-
-::: note
-For further reference on the `userInfo` object, see [UserInfo](https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift) documentation.
-:::
-
-## Implement a Sign Up
-
-${snippet(meta.snippets.setup)}
-
-Next add the following:
-
-```objc
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth signUpWithEmail:@"foo@email.com",
-             username:nil
-             password:@"123456"
-           connection:@"Username-Password-Authentication"
-         userMetadata:@{@"first_name": @"Foo",
-                        @"last_name": @"Bar"}
-                scope:@"openid profile"
-           parameters:@{}
-             callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-                 dispatch_async(dispatch_get_main_queue(), ^{
-                     [self.spinner stopAnimating];
-                     if(error) {
-                         // You've got an error
-                     } else {
-                        // Registered successfully
-                        // You've got a Credentials object
-                     }
-                 });
-             }];
-```
-
-Notice that any extra information that you need to add to the user's profile, other than the `email` and `password`, goes within the `userMetadata` dictionary, which is passed as a parameter to this function.
-
-## Perform Social Authentication
-
-::: note
-Please ensure you have configured your callback URL as show in [Configure Callback](/quickstart/native/ios-objc/getting-started#configure-callback-urls).
-:::
-
-Add the following function in your application's `AppDelegate`:
-
-${snippet(meta.snippets.setup)}
-
-```objc
-- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options{
-    return [HybridAuth resume:url options:options];
-}
-```
-
-### Web Authentication
-
-Finally, you can now perform webAuth authentication by specifying the social connection name, for example with Facebook.
-
-```objc
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth showLoginWithScope:@"openid profile" connection:@"facebook" callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-        if (error) {
-            // Handle the error
-        } else {
-            // You've got your credentials
-        }
-    }];
-```
-
-Once you obtain the `credentials` object upon a successful authentication, you can deal with them as usual.
diff --git a/articles/quickstart/native/ios-objc/03-user-sessions.md b/articles/quickstart/native/ios-objc/03-user-sessions.md
deleted file mode 100644
index c368a28078..0000000000
--- a/articles/quickstart/native/ios-objc/03-user-sessions.md
+++ /dev/null
@@ -1,303 +0,0 @@
----
-title: User Sessions
-description: This tutorial will show you how to handle user sessions and retrieve the user's profile.
-budicon: 280
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '03-User-Sessions',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you are using the Swift wrapper and the Auth0 library to handle login. For more information, read the [Login](/quickstart/native/ios-objc/00-login) guide.
-
-## Add the SimpleKeychain Dependency
-
-Integrate the [SimpleKeychain](https://github.com/auth0/SimpleKeychain) library for managing user credentials.
-
-### Carthage
-
-If you are using Carthage, add the following to your `Cartfile`:
-
-```ruby
-github "auth0/SimpleKeychain"
-```
-
-Then, run `carthage bootstrap`.
-
-::: note
-For more information on how to use Carthage, read [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
-:::
-
-### Cocoapods
-
-If you are using [Cocoapods](https://cocoapods.org/), add the following to your `Podfile`:
-
-```ruby
-pod 'SimpleKeychain', '~> 0.7'
-```
-
-Then, run `pod install`.
-
-::: note
-For more information on how to use Cocoapods, read the [Cocoapods documentation](http://guides.cocoapods.org/using/getting-started.html).
-:::
-
-## Save User Credentials When They Log in
-
-When your users log in successfully, save their credentials. You can then log them in automatically when they open your application again.
-
-${snippet(meta.snippets.setup)}
-
-Then, present the hosted login screen:
-
-```objc
-// HomeViewController.m
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth showLoginWithScope:@"openid profile" connection:nil callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-    dispatch_async(dispatch_get_main_queue(), ^{
-        if (error) {
-            NSLog(@"Error: %@", error);
-        } else if (credentials) {
-          // Do something with credentials such as save them.
-          // Auth0 will dismiss itself automatically by default.
-        }
-    });
-}];
-```
-
-You need a valid Access Token. You can find the token in the `credentials` object. To save the Access Token, use an `A0SimpleKeychain` instance. `SimpleKeychain` can be a key-value storage.
-
-```objc
-// HomeViewController.m
-
-A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-[keychain setString:accessToken forKey:@"access_token"];
-```
-
-## Check for an Access Token When the User Opens Your Application
-
-When the user opens your application, check for an Access Token. If it exists, you can log the user in automatically and redirect them to the app's main flow without any additional login steps.
-
-First, retrieve the Access Token value from the `accessToken` key in the keychain:
-
-```objc
-// HomeViewController.m
-
-A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-NSString* accessToken = [keychain stringForKey:@"access_token"];
-if (accessToken) {
-    // accessToken exists
-    // You still need to validate it!
-}
-```
-
-## Validate the Access Token
-
-Check if the user's Access Token is still valid. Use `Auth0` to fetch the user's profile:
-
-```objc
-// HomeViewController.m
-
-[auth userInfoWithAccessToken:accessToken callback:^(NSError * _Nullable error, UserInfo * _Nullable profile) {
-        if (error) {
-            // accessToken has expired or no longer valid
-        } else {
-            // The accessToken is still valid and you have the user's profile
-            // This would be a good time to store the profile
-        }
-}];
-```
-
-## Deal with a Non-Valid Access Token
-
-Decide how to deal with a non-valid Access Token. You can choose between two options:
-* Ask users to re-enter their credentials.
-* Use `.renew(withRefreshToken: refreshToken)` with a [refresh_token](/refresh-token) to obtain a new valid Access Token.
-
-If you want to ask your users to re-enter their credentials, clear all the values stored in the keychain:
-
-```objc
-// HomeViewController.m
-A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-[keychain clearAll];
-```
-
-The rest of this tutorial shows you how to use a Refresh Token to obtain a new Access Token. 
-
-The Refresh Token is a token string stored in the `Credentials` object after a successful login. The Refresh Token doesn't expire. 
-
-::: note
-Even though the Refresh Token cannot expire, it can be revoked. For more information, read the [Refresh Token documentation](/refresh-token) before you proceed with this tutorial.
-:::
-
-### Store the Refresh Token
-
-::: note 
-If you do not send `offline_access` as a scope during authentication, the Refresh Token will be `nil`.
-:::
-
-To get a new Access Token, you need to first save the Refresh Token after the user logs in. Go to the section where you're saving the Access Token and update it as follows: 
-
-```objc
-// HomeViewController.m
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth showLoginWithScope:@"openid profile offline_access" connection:nil callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-       if (error) {
-           // Handle the error
-       } else {
-           [auth userInfoWithAccessToken:accessToken callback:^(NSError * _Nullable error, UserInfo * _Nullable profile) {
-               if (error) {
-                     NSLog(@"Error: %@", error.localizedDescription);
-               } else {
-                     A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-                     [keychain setString:[credentials accessToken] forKey:@"access_token"];
-                     [keychain setString:[credentials refreshToken] forKey:@"refresh_token"];
-               }
-           }];
-       }
-   }];
-```
-
-### Use the Refresh Token to obtain a new Access Token
-
-Now, you can use the saved Refresh Token to obtain a new Access Token:
-
-```objc
-// HomeViewController.m
-
-A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-NSString* refreshToken = [keychain stringForKey:@"refresh_token"];
-if (!refreshToken) {
-    [keychain clearAll];
-}
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth renewWithRefreshToken:[keychain stringForKey:@"refresh_token"] scope:nil callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-              if (error) {
-                  // refreshToken is no longer valid (for example, it has been revoked)
-                  // Cleaning stored values since they are no longer valid
-                  [keychain clearAll];
-                  // At this point, you should ask the user to enter their credentials again!
-              } else {
-                  // Just got a new accessToken!
-                  // Don't forget to store it...
-                  [keychain setString:[credentials accessToken] forKey:@"access_token"];
-                  // At this point, you can log the user into your app, for example, by navigating to the corresponding screen
-              }
-      }];
-```
-
-## Clear the Keychain When the User Logs Out
-
-When you need to log the user out, remove their credentials from the keychain:
-
-```objc
-// HomeViewController.m
-
-A0SimpleKeychain *keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"];
-[keychain clearAll];
-```
-
-## Optional: Encapsulate Session Handling
-
-Handling user sessions is not a straightforward task. You can simplify it by storing token-related information and processes in a class. The class separates the logic for handling user sessions from the View Controller layer. 
-
-We recommend that you download the sample project from this tutorial and look at its implementation. Focus on the `SessionManager` class, which manages the session handling processes.
-
-## Get the User Profile
-
-To get the user profile, you need a valid Access Token. 
-
-From the `Auth0` module, call the `userInfo` method that allows you to get the user profile:
-
-```objc
-// HomeViewController.m
-
-// Retrieve profile
-[auth userInfoWithAccessToken:accessToken callback:^(NSError * _Nullable error, UserInfo * _Nullable profile) {
-        if (error) {
-            // Handle the error
-        } else {
-            // You have the user's profile
-        }
-}];
-```
-
-## Show the User Profile Information
-
-### Default information
-
-To show the information contained in the user profile, access its properties, for example:
-
-```objc
-// ProfileViewController.m
-NSURL *pictureURL = self.userProfile.picture;
-NSString *name = self.userProfile.name;
-```
-
-::: note
-Read the [UserInfo](https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift) class documentation to learn more about its properties.
-:::
-
-### Additional information
-
-You can request more information than returned in the basic profile. To do this, add `userMetadata` to the profile.
-
-## Update the User Profile
-
-You store additional user information in the user metadata. Perform a `patch`:
-
-```objc
-// ProfileViewController.m
-NSString *idToken = ... // You will need the idToken from your credentials instance 'credentials.idToken'
-UserInfo *profile = ... // the Profile instance you obtained before
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth patchProfileWithIdToken:idToken userId:profile.sub metaData:@{@"first_name": @"John", @"last_name": @"Doe", @"country": @"USA"} callback:^(NSError * _Nullable error, NSDictionary * _Nullable user) {
-    if (error) {
-        // Handle the error
-    } else {
-        // Success
-    }
-}];
-```
-
-## Retrieve User Metadata
-
-The `user_metadata` dictionary contains fields related to the user profile. These fields can be added from client-side (for example, when the user edits their profile). 
-
-You can specify the fields you want to retrieve, or use an empty array `[]` to pull back the complete user profile. 
-
-Retrieve the `user_metadata` dictionary:
-
-```objc
-// HomeViewController.m
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth userProfileWithIdToken:idToken userId:profile.sub callback:^(NSError * _Nullable error, NSDictionary * _Nullable user) {
-    if (error) {
-        // Deal with error
-    } else {
-        NSDictionary *metaData = [user objectForKey:@"user_metadata"];
-        // Access userMetadata
-    }
-}];
-```
-
-Access the user's metadata. You can choose the key names and types for the `user_metadata` dictionary.
-
-```objc
-// ProfileViewController.m
-NSString* firstName = [metaData objectForKey:@"first_name"];
-NSString* lastName = [metaData objectForKey:@"last_name"];
-NSString* country = [metaData objectForKey:@"country"];
-```
diff --git a/articles/quickstart/native/ios-objc/04-calling-apis.md b/articles/quickstart/native/ios-objc/04-calling-apis.md
deleted file mode 100644
index fe9d832a46..0000000000
--- a/articles/quickstart/native/ios-objc/04-calling-apis.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Calling APIs
-description: This tutorial will show you how to manage tokens to make authenticated API calls, using NSURLSession.
-budicon: 546
----
-
-You may want to restrict access to your API resources, so that only authenticated users with sufficient privileges can access them. Auth0 lets you manage access to these resources using [API Authorization](/api-auth).
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '04-Calling-APIs',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-Auth0 provides a set of tools for protecting your resources with end-to-end authentication in your application. 
-
-This tutorial shows you how to get an Access Token, attach it to a request with an authorization header and call an API. We recommend you use this method for the best security and compliance with RFC standards. 
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have completed the [Session Handling](/quickstart/native/ios-objc/03-user-sessions) tutorial and you know how to handle the `Credentials` object.
-* You have set up a backend application as API. To learn how to do it, follow one of the [backend tutorials](/quickstart/backend).
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Get the User's Access Token
-
-To retrieve an access token that is authorized to access your API, you need to specify the **API Identifier** value you created in the [Auth0 APIs Dashboard](https://manage.auth0.com/#/apis).
-
-Present the Hosted Login Page:
-
-```objc
-// HomeViewController.m
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth showLoginWithScope:@"openid profile" connection:nil audience:"API_IDENTIFIER" callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-    dispatch_async(dispatch_get_main_queue(), ^{
-        if (error) {
-            NSLog(@"Error: %@", error);
-        } else if (credentials) {
-          // Do something with credentials such as save them.
-          // Auth0 will dismiss itself automatically by default.
-        }
-    });
-}];
-```
-
-## Attach the Access Token
-
-To give the authenticated user access to secured resources in your API, include the user's access token in the requests you send to the API.
-
-::: note
-Depending on the standards in your API, you configure the authorization header differently. The code below is just an example.
-:::
-
-To attach an Access Token to a request: 
-
-```objc
-// ProfileViewController.m
-
-NSString* token = ... // The accessToken you stored after authentication
-NSString *url = @"https://localhost/api"; // Set to your Protected API URL
-NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:[NSURL URLWithString:url]];
-// Configure your request here (method, body, and so on)
-
-[request addValue:[NSString stringWithFormat:@"Bearer %@", token] forHTTPHeaderField:@"Authorization"];
-[[[NSURLSession sharedSession] dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
-    // Parse the response
-}] resume];
-```
-
-### Sample project configuration
-
-When you are testing the sample project, configure your URL request in the `ProfileViewController.swift` file:
-
-```objc
-// ProfileViewController.m
-
-NSString *url = @"https://localhost/api"; // Change to your API
-NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:[NSURL URLWithString:url]];
-// Configure your request here (method, body, and so on)
-```
-
-After you send a request and receive a response from your API, you can check the request status code in an alert view. 
-
-::: note
-Read more about authentication API on the server-side in [the API documentation](/api/authentication).
-:::
diff --git a/articles/quickstart/native/ios-objc/05-authorization.md b/articles/quickstart/native/ios-objc/05-authorization.md
deleted file mode 100644
index 2b52b2101c..0000000000
--- a/articles/quickstart/native/ios-objc/05-authorization.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Authorization
-description: This tutorial will show you how assign roles to your users, and use those claims to authorize or deny a user to perform certain actions in the app.
-budicon: 500
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '05-Authorization',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-Many identity providers supply access claims which contain, for example, user roles or groups. You can request the access claims in your token with `scope: openid roles` or `scope: openid groups`.
-
-If an identity provider does not supply this information, you can create a rule for assigning roles to users. 
-
-## Create a Rule to Assign Roles
-
-Create a rule that assigns the following access roles to your user: 
-* An admin role
-* A regular user role
-
-To assign roles, go to the [New rule](${manage_url}/#/rules/new) page. In the **Access Control** section, select the **Set roles to a user** template. 
-
-Edit the following line from the default script to match the conditions that fit your needs:
-
-```
-if (user.email.indexOf('@example.com') > -1)
-```
-
-The rule is checked every time a user attempts to authenticate. 
-
-* If the user has a valid email and the domain is `@example.com`, the user gets the admin role.
-* If the email contains anything else, the user gets the regular user role.
- 
-::: note
-Depending on your needs, you can define roles other than admin and user. Read about the names you give your claims in the [Rules documentation](/rules#hello-world).
-:::
-
-## Test the Rule in Your Project
-
-${snippet(meta.snippets.setup)}
-
-```objc
-// ProfileViewController.m
-
-NSString *userId = ... // the id of the user, available in profile.sub
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth userProfileWithIdToken:idToken userId:userId callback:^(NSError * _Nullable error, NSDictionary * _Nullable user) {
-  if (error) {
-    // Handle error
-  } else {
-     NSDictionary *metaData = [user objectForKey:@"app_metadata"];
-     NSArray *roles = [metaData objectForKey:@"roles"];
-     if (![roles containsObject:@"admin"]) {
-        // Not an admin user, access denied.
-     } else {
-        // Admin user, grant access
-        [self performSegueWithIdentifier:@"AdminSegue" sender:nil];
-     }
-   }
-}];
-```
-
-## Restrict Content Based on Access Level
-
-Now you can recognize the users with different roles in your app. You can use this information to give and restrict access to selected features in your app to users with different roles.
-
-In the sample project, the user with the admin role can access the admin panel.
\ No newline at end of file
diff --git a/articles/quickstart/native/ios-objc/07-linking-accounts.md b/articles/quickstart/native/ios-objc/07-linking-accounts.md
deleted file mode 100644
index b8914e9ffe..0000000000
--- a/articles/quickstart/native/ios-objc/07-linking-accounts.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Linking Accounts
-description: This tutorial will show you how to link multiple accounts within the same user.
-budicon: 345
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '07-Linking-Accounts',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have integrated [Auth0.swift](https://github.com/auth0/Auth0.swift/) as a dependency in your project. 
-* You are familiar with presenting the login screen. To learn more, see the [Login](/quickstart/native/ios-objc/00-login) and the [User Sessions](/quickstart/native/ios-objc/03-user-sessions) tutorials.
-
-We recommend that you read the [Linking Accounts](/link-accounts) documentation to understand the process of linking accounts.
-
-## Enter Account Credentials
-
-Your users may want to link their other accounts to the account they are logged in to. 
-
-To achieve this, present an additional login dialog where your users can enter the credentials for any additional account. You can present this dialog as described in the [Login](/quickstart/native/ios-objc/00-login#implement-the-login) tutorial.
-
-After the user authenticates, save the `idToken` value for the secondary account.
-
-<%= include('../_includes/_ios_link_accounts') %>
-
-${snippet(meta.snippets.setup)}
-
-To link accounts:
-
-```objc
-// ProfileViewController.m
-
-NSString *id = ... // the id of the user, available in profile.sub
-NSString *idToken = ... // the user's idToken
-NSString *otherUserToken = ... // the idToken from the account you want to link the user with
-[auth linkUserAccountWithIdToken:idToken userId:id otherAccountToken:otherUserToken
-      callback:^(NSError * _Nullable error, NSArray *> * _Nullable payload) {
-          if (error) {
-              // Handler Error
-          } else {
-              // Success account was linked
-          }
-}];
-```
-
-## Retrieve the Linked Accounts
-
-Once you have the `id` value from the `profile.sub`, you can retrieve user identities. Call the management API:
-
-```objc
-// HomeViewController.m
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth userProfileWithIdToken:idToken userId:id callback:^(NSError * _Nullable error, NSDictionary * _Nullable user) {
-    if (error) {
-        // Handle error
-    } else {
-        NSArray *identities = [[NSArray alloc] init];
-        for (NSDictionary *identity in [user objectForKey:@"identities"]) {
-           identities = [identities arrayByAddingObject:[[A0Identity alloc] initWithJson:identity]];
-        }
-    }
-}];
-```
-
-::: note
-A linked account is handled as an `Identity` instance. Read more about this object in the [Identity class documentation](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Identity.swift).
-:::
-
-<%= include('../_includes/_ios_unlink_accounts') %>
-
-Unlink the accounts:
-
-```objc
-// ProfileViewController.m
-NSString *id = ... // the id of the user, available in profile.sub
-NSString *idToken = ... // the user idToken
-A0Identity *identity = ... // the identity (account) you want to unlink from the user
-[auth unlinkUserAccountWithIdToken:idToken userId:id identity:identity callback:^(NSError * _Nullable error, NSArray *> * _Nullable payload) {
-    if (error) {
-        // Handle Error
-    } else {
-        // Success, account unlinked.
-    }
-}];
-```
diff --git a/articles/quickstart/native/ios-objc/_includes/_config.md b/articles/quickstart/native/ios-objc/_includes/_config.md
deleted file mode 100644
index cddcc8468a..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_config.md
+++ /dev/null
@@ -1,54 +0,0 @@
-## Adding Auth0 Credentials
-
-The dependencies listed above require your client credentials in order for them to work. If you downloaded any sample project from here, these credentials are automatically set. Either way, you have to make sure they are there otherwise your app might crash.
-
-Add your credentials in `Auth0.plist`. You have to create that file if it doesn't already exist in your project:
-
-```xml
-
-
-
-
-
-
-  ClientId
-  ${account.clientId}
-  Domain
-  ${account.namespace}
-
-
-```
-
-## Configure Callback URLs
-
-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 a token. Since callback URLs can be manipulated, you will need to add your application's URL to your client's **Allowed Callback URLs** for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful.
-
-In your application's `Info.plist` file, register your iOS Bundle Identifer as a custom scheme:
-
-```xml
-
-
-CFBundleURLTypes
-
-    
-        CFBundleTypeRole
-        None
-        CFBundleURLName
-        auth0
-        CFBundleURLSchemes
-        
-            $(PRODUCT_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**.
-:::
-
-Finally, go to your [Client's Dashboard](${manage_url}/#/applications/${account.clientId}/settings) and make sure that "Allowed Callback URLs" contains the following:
-
-```text
-{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback
-```
diff --git a/articles/quickstart/native/ios-objc/_includes/_dependency_embedded.md b/articles/quickstart/native/ios-objc/_includes/_dependency_embedded.md
deleted file mode 100644
index d4e1eb5057..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_dependency_embedded.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Install
-
-### Carthage
-
-If you are using Carthage, add the following lines to your `Cartfile`:
-
-```ruby
-github "auth0/Lock.swift" ~> 2.0
-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).
-:::
-
-### Cocoapods
-
-If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`:
-
-```ruby
-use_frameworks!
-pod 'Lock', '~> 2.0'
-pod 'Auth0', '~> 1.0'
-```
-
-Then, run `pod install`.
-
-::: note
-For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html).
-:::
diff --git a/articles/quickstart/native/ios-objc/_includes/_hybrid_setup.md b/articles/quickstart/native/ios-objc/_includes/_hybrid_setup.md
deleted file mode 100644
index 1390f54511..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_hybrid_setup.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## Set Up the Objective-C & Swift Hybrid
-
-### Configure project settings
-
-1. Download the [HybridAuth.swift](https://github.com/auth0-samples/auth0-ios-objc-sample/blob/master/07-Linking-Accounts/Auth0Sample/HybridAuth.swift) file and add it to your project. The following message appears: "Would you like to configure an Objective-C bridging header?". Click **Yes**.
-3. Click on your Xcode Project file.
-4. Click on **Build Settings**.
-5. Search for **Defines Module**.
-6. Change the value to **Yes**.
-7. Search for **Product Module Name**.
-8. Make a note of the name. This tutorial uses the name `Auth0Sample`.
-
-### Import
-
-To import the Swift code and Auth0 library, add the following headers:
-
-```objc
-#import "Auth0Sample-Swift.h"
-@import Auth0;
-```
diff --git a/articles/quickstart/native/ios-objc/_includes/_hybrid_setup_lock.md b/articles/quickstart/native/ios-objc/_includes/_hybrid_setup_lock.md
deleted file mode 100644
index 1d0b84a035..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_hybrid_setup_lock.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## Set up the Objective-C & Swift Hybrid
-
-### Configure project settings
-
-1. Download the [HybridLock.swift](https://github.com/auth0-samples/auth0-ios-objc-sample/blob/embedded-login/01-Embedded-Login/Auth0Sample/HybridLock.swift) file and add it to your project.
-2. The following message will appear: "Would You like to configure an Objective-C bridging Header". Click **Yes**
-3. Click on your Xcode Project file.
-4. Click **Build Settings**.
-5. Search for **Defines Module**.
-6. Change the value to **Yes**.
-7. Search fir **Product Module Name**.
-8. Make a note of the name,. This tutorial uses the name `Auth0Sample`.
-
-### Import
-
-To import the Swift code and Auth0 library, add the following headers:
-
-```objc
-#import "Auth0Sample-Swift.h"
-@import Auth0;
-```
diff --git a/articles/quickstart/native/ios-objc/_includes/_login_centralized.md b/articles/quickstart/native/ios-objc/_includes/_login_centralized.md
deleted file mode 100644
index a9fb95991c..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_login_centralized.md
+++ /dev/null
@@ -1,64 +0,0 @@
-[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.
-
-::: note
-You can also embed the login dialog directly in your application using the [Lock widget](/lock). If you use this method, some features, such as single sign-on, will not be accessible. 
-To learn how to embed the Lock widget in your application, follow the [Embedded Login sample](https://github.com/auth0-samples/auth0-ios-objc-sample/tree/embedded-login/01-Embedded-Login).
-:::
-
-
        universal login
        
-
-::: note
-Read the [Browser-Based vs. Native Login Flows on Mobile Devices](/tutorials/browser-based-vs-native-experience-on-mobile) article to learn how to choose between the two types of login flows.
-:::
-
-<%= include('../../_includes/_ios_dependency_centralized') %>
-
-<%= include('_hybrid_setup') %>
-
-# Add the Callback
-
-For Auth0 to handle the authentication callback, update your `AppDelegate` file. 
-
-${snippet(meta.snippets.setup)}
-
-Then, add the following `UIApplicationDelegate` method:
-
-```swift
-// AppDelegate.m
-
-- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
-    return [HybridAuth resume:url options:options];
-}
-```
-
-::: note
-To configure callback, you must configure your callback URL first. Read about the Callback URL in the [Configure Callback](/quickstart/native/ios-objc/getting-started#configure-callback-urls) step.
-:::
-
-## Implement Login
-
-${snippet(meta.snippets.setup)}
-
-Then, present the hosted login screen:
-
-```objc
-// HomeViewController.m
-
-HybridAuth *auth = [[HybridAuth alloc] init];
-[auth showLoginWithScope:@"openid" connection:nil callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-    dispatch_async(dispatch_get_main_queue(), ^{
-        if (error) {
-            NSLog(@"Error: %@", error);
-        } else if (credentials) {
-          // Do something with credentials, such as save them.
-          // Auth0 will dismiss itself automatically by default.
-        }
-    });
-}];
-```
-
-After the user authenticates, their information is returned in a `credentials` object.
-
-::: note
-To learn more about the `credentials` object, read the [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) article.
-:::
diff --git a/articles/quickstart/native/ios-objc/_includes/_login_embedded.md b/articles/quickstart/native/ios-objc/_includes/_login_embedded.md
deleted file mode 100644
index 95fb8c45bc..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_login_embedded.md
+++ /dev/null
@@ -1,61 +0,0 @@
-<%= include('_dependency_embedded') %>
-
-<%= include('_hybrid_setup_lock') %>
-
-Auth0 will need to handle the callback of this authentication, add the following to your `AppDelegate`:
-
-First, import the Swift wrapper:
-
-```objc
-#import "Auth0Sample-Swift.h"
-```
-
-Then, add the following `UIApplicationDelegate` method:
-
-```swift
-- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
-    return [HybridLock resumeAuth:url options:options];
-}
-```
-
-::: note
-Please ensure you have configured your callback URL as demonstrated in [Configure Callback](/quickstart/native/ios-objc/00-getting-started#configure-callback-urls).
-:::
-
-## Implement the Login
-
-Import the Swift wrapper and Auth0 library:
-
-```objc
-#import "Auth0Sample-Swift.h"
-@import Auth0;
-```
-
-Then, configure and present the embedded login widget:
-
-```swift
-HybridLock *lock = [[HybridLock alloc] init];
-[lock showLockFrom:self callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) {
-    if (error) {
-        NSLog(@"Error: %@", error);
-    } else if (credentials) {
-        // Do something with credentials, such as save them.
-        // Auth0 will dismiss itself automatically by default.
-    }
-}];
-```
-
-
        Lock UI
        
-
-As you can see, upon successful authentication, the `onAuth` callback will yield the user's `credentials`.
-
-::: note
-For further reference on the `credentials` object, please see
-[Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) documentation. We will cover the storage of the user's credentials in a later chapter.  By default Lock will not store this for you.
-:::
-
-This sets you up for handling Database connections.
-
-### Log In with Enterprise & Social Connections
-
-In order to use browser based Auth mechanism through social and enterprise connections, all you have to do is enable them in your account's [connections dashboard](${manage_url}/#/connections/social). Every connection you switch on there, will appear in the Login screen of your app.
diff --git a/articles/quickstart/native/ios-objc/_includes/_prerequisite.md b/articles/quickstart/native/ios-objc/_includes/_prerequisite.md
deleted file mode 100644
index f77661ec7f..0000000000
--- a/articles/quickstart/native/ios-objc/_includes/_prerequisite.md
+++ /dev/null
@@ -1,7 +0,0 @@
-::: panel System Requirements
-These tutorials and seed projects have been tested with the following:
-
-* CocoaPods 1.2.1
-* Version 8.3.2 (8E2002)
-* iPhone 7 - iOS 10.3 (14E269)
-:::
diff --git a/articles/quickstart/native/ios-objc/dashboard-default.md b/articles/quickstart/native/ios-objc/dashboard-default.md
deleted file mode 100644
index da59267e60..0000000000
--- a/articles/quickstart/native/ios-objc/dashboard-default.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Getting Started
-description: Short Introduction to the Auth0 iOS Objective-C Quickstarts.
-budicon: 715
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-objc-sample',
-  path: '01-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-::: note
-It is recommend in order to make the most of all the features in the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit to start with the [iOS Swift QuickStart](/quickstart/native/ios-swift)
-:::
-
-This multistep quickstart guide will walk you through managing authentication in your iOS Objective-C apps with Auth0.
-
-## About the Sample Applications
-
-Each step within this quickstart guide (starting with **Login**) contains a downloadable sample which demonstrates the topic being covered. Within each of these samples, you will find an appropriate application to demonstrate the features discussed in the chapter.
-
-## Auth0 Dependencies
-
-Each tutorial will require you to use the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit.
-
-A brief description:
-
-- [**Auth0.swift**](https://github.com/auth0/Auth0.swift) is a toolkit that lets you communicate efficiently with many the [Auth0 API](/api/info) functions and enables you to integrate the Login.
-
-## Create an Application
-
-If you haven't already done so, create a new application in your [Auth0 dashboard](${manage_url}/#/applications/${account.clientId}/settings) and choose **Native**.
-
-![App Dashboard](/media/articles/angularjs/app_dashboard.png)
-
-<%= include('_includes/_config') %>
-
-<%= include('_includes/_login_centralized') %>
diff --git a/articles/quickstart/native/ios-objc/getting-started.md b/articles/quickstart/native/ios-objc/getting-started.md
deleted file mode 100644
index 25fdd7782a..0000000000
--- a/articles/quickstart/native/ios-objc/getting-started.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Getting Started
-description: Initial steps to integrate Auth0 in an iOS Objective-C application.
-budicon: 448
----
-
-This quickstart guide walks you through managing authentication with Auth0 in your iOS Objective-C apps.
-
-::: note
-To make the most of all the features in the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit, read the [iOS Swift Quickstart](/quickstart/native/ios-swift) first. 
-:::
-
-# Sample Projects
-
-Each tutorial in this guide includes a link to a sample project showing the features described in the article. You can find all the samples in the [iOS Objective-C samples folder](https://github.com/auth0-samples/auth0-ios-objc-sample). 
-
-All sample projects use a hybrid project, combining Objective-C and Swift. For more information, read the [Mix and Match](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html) guide from Apple. 
-
-## Dependencies
-
-Each tutorial uses the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit. It is a toolkit that lets you efficiently communicate with many of the basic [Auth0 API](/api/info) functions.
-
-<%= include('../_includes/_create_application') %>
-
-<%= include('../_includes/_ios_config') %>
diff --git a/articles/quickstart/native/ios-objc/index.yml b/articles/quickstart/native/ios-objc/index.yml
deleted file mode 100644
index 4a7e9636cd..0000000000
--- a/articles/quickstart/native/ios-objc/index.yml
+++ /dev/null
@@ -1,65 +0,0 @@
-title: iOS Objective-C
-language:
-  - Objective-C
-image: /media/platforms/ios.png
-author:
-  name: Martin Walsh
-  email: martin.walsh@auth0.com
-  community: false
-tags:
-  - quickstart
-alias:
-  - ios
-  - objective-c
-  - iphone
-  - ipad
-seo_alias: ios-objc
-snippets:
-  setup: native-platforms/ios-objc/setup_wrapper
-default_article: dashboard-default
-articles:
-  - getting-started
-  - 00-login
-  - 03-user-sessions
-  - 04-calling-apis
-  - 05-authorization
-  - 07-linking-accounts
-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 anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-  - path: 03-user-sessions
-    list:
-    - text: Learn about refresh tokens
-      icon: 345
-      href: "/tokens/refresh-tokens"
-    - text: Learn about the user profile structure
-      icon: 345
-      href: "/user-profile/normalized/oidc"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-    - text: In-depth details about user profile
-      icon: 345
-      href: "/user-profile/user-profile-details"
-  - path: 04-calling-apis
-    list:
-    - text: Learn about custom APIs
-      icon: 345
-      href: "/api"
-    - text: Introduction to API authorization
-      icon: 345
-      href: "/api-auth"
-  - path: 05-authorization
-    list:
-    - text: Learn about rules
-      icon: 345
-      href: "/rules"
\ No newline at end of file
diff --git a/articles/quickstart/native/ios-swift/00-login.md b/articles/quickstart/native/ios-swift/00-login.md
deleted file mode 100644
index 5acf0af4cc..0000000000
--- a/articles/quickstart/native/ios-swift/00-login.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to integrate the Auth0 Login in your iOS Swift project to present a hosted Lock page.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '00-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-<%= include('_includes/_login_centralized') %>
\ No newline at end of file
diff --git a/articles/quickstart/native/ios-swift/01-embedded-login.md b/articles/quickstart/native/ios-swift/01-embedded-login.md
deleted file mode 100644
index d8d0a3b1ff..0000000000
--- a/articles/quickstart/native/ios-swift/01-embedded-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Embedded Login
-description: This tutorial demonstrates how to integrate Embedded Login in your iOS Swift project in order to present a login widget.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  branch: 'embedded-login',
-  path: '01-Embedded-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-<%= include('_includes/_login_embedded') %>
diff --git a/articles/quickstart/native/ios-swift/01-login.md b/articles/quickstart/native/ios-swift/01-login.md
new file mode 100755
index 0000000000..ac03db32a7
--- /dev/null
+++ b/articles/quickstart/native/ios-swift/01-login.md
@@ -0,0 +1,269 @@
+---
+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 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.
+
+Whenever possible, Auth0 recommends using Universal Links as a secure way to link directly to content within your app. Custom URL schemes can be subject to [client impersonation attacks](https://datatracker.ietf.org/doc/html/rfc8252#section-8.6).
+
+**This feature requires Xcode 15.3+ and a paid Apple Developer account**.
+:::
+
+Go to the settings page 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, 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, 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 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 under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a custom domain, 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 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.
+:::
+
+### 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.
+:::
+
+### 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.
+:::
+
+## 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 of your Auth0 application. If you are using a custom domain, 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 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 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 to learn more.
+:::
+
+
        Screenshot of the Universal Login page
        
+
+::: panel Checkpoint
+Verify that pressing the **Login** button shows an alert box 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. 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. 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 for decoding JWTs 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 to learn more.
+:::
+
+::: panel Checkpoint
+Verify that you can access the `email`, `picture`, or any other claim 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
+- API documentation
+- FAQ
diff --git a/articles/quickstart/native/ios-swift/02-custom-login-form.md b/articles/quickstart/native/ios-swift/02-custom-login-form.md
deleted file mode 100644
index 3e3f9a6942..0000000000
--- a/articles/quickstart/native/ios-swift/02-custom-login-form.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: Custom Login Form
-description: This tutorial demonstrates how to perform Login and Sign Up by creating your own Login form.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  branch: 'embedded-login',
-  path: '02-Custom-Login-Form',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-## Implement the Login
-
-First, import the `Auth0` module in the file where you want to present the login dialog:
-
-```swift
-import Auth0
-```
-
-Then, add the following code to perform a login:
-
-```swift
-Auth0
-    .authentication()
-    .login(
-        usernameOrEmail: "email@foo.com",
-        password: "123456",
-        realm: "Username-Password-Authentication",
-        scope: "openid profile"
-    )
-    .start { result in
-        switch result {
-        case .success(let credentials):
-            // Logged in successfully
-            // You've got a Credentials instance, which you'll use, for example, to retrieve the User Profile
-        case .failure(let error):
-            // You've got an error
-        }
-    }
-```
-
-That's it! You'll get either a `credentials` object or an `error` case after performing a login.
-
-Basically, `credentials` contains token-related information; you will normally store this object for later use. On the other hand, `error` is an enum containing possible authentication error cases that you might want to keep track of.
-
-::: note
-For further reference on the `Credentials` object, see [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) documentation.
-:::
-
-## Retrieve the User Profile
-
-Once you've obtained a `Credentials` object, retrieving a user profile is quite simple. All you have to do is:
-
-```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
-        }
-}
-```
-
-::: note
-For further reference on the `profile` object, see [Profile](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Profile.swift) documentation.
-:::
-
-## Implement a Sign Up
-
-First, import the `Auth0` module in the file where you want to present the Sign Up dialog:
-
-```swift
-import Auth0
-```
-
-Next add the following:
-
-```swift
-Auth0
-    .authentication()
-    .signUp(
-        email: "foo@email.com",
-        password: "123456",
-        connection: "Username-Password-Authentication",
-        userMetadata: ["first_name": "Foo", "last_name": "Bar"] // or any extra user data you need
-    )
-    .start { result in
-        switch result {
-        case .success(let credentials):
-            // Registered successfully
-            // You've got a Credentials object
-        case .failure(let error):
-            // You've got an error
-        }
-    }
-}
-```
-
-Notice that any extra information that you need to add to the user's profile, other than the `email` and `password`, goes within the `userMetadata` dictionary, which is passed as a parameter to this function.
-
-## Perform Social Authentication
-
-First, go to your [Application Dashboard](${manage_url}/#/applications/${account.clientId}/settings/${account.clientId}/settings) and make sure that *Allowed Callback URLs* contains the following:
-
-```shell
-{YOUR_APP_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{YOUR_APP_BUNDLE_IDENTIFIER}/callback
-```
-
-In your application's `Info.plist` file, register your iOS Bundle Identifier as a custom scheme. To do so, open the `Info.plist` as source code, and add this chunk of code under the main `` entry:
-
-```xml
-CFBundleURLTypes
-
-    
-        CFBundleTypeRole
-        None
-        CFBundleURLName
-        auth0
-        CFBundleURLSchemes
-        
-            {YOUR_APP_BUNDLE_IDENTIFIER}
-        
-    
-
-```
-
-Remember to replace all the `{YOUR_APP_BUNDLE_IDENTIFIER}` appearances with your actual app's bundle identifier, which you can get from your project settings.
-
-::: note
-The **Auth0.swift** toolkit will only handle URLs with your Auth0 domain as host, for instance: `com.auth0.MyApp://samples.auth0.com/ios/com.auth0.MyApp/callback`
-:::
-
-Then, add the following function in your application's `AppDelegate`:
-
-```swift
-import Auth0
-```
-
-```swift
-func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
-    return Auth0.resumeAuth(url, options: options)
-}
-```
-
-### Web Authentication
-
-Finally, you can now perform webAuth authentication by specifying the social connection name, for example with Facebook.
-
-```swift
-Auth0
-    .webAuth()
-    .audience("https://${account.namespace}/userinfo")
-    .scope("openid profile")
-    .connection("facebook")
-    .start { result in
-        switch result {
-        case .success(let credentials):
-            // You've got your credentials
-        case .failure(let error):
-            // Handle the error
-        }
-    }
-```
-
-Once you obtain the `credentials` object upon a successful authentication, you can deal with them as usual.
-
-#### Connection Scopes
-
-If you need additional provider permissions these can be specified using the `connectionScope` method and providing
-a comma separated list of provider permissions.
-
-```swift
-Auth0
-    .webAuth()
-    .audience("https://${account.namespace}/userinfo")
-    .connection("facebook")
-    .connectionScope("public_profile,email,user_friends,user_birthday")
-    .scope("openid profile")
-    .start { result in
-        switch result {
-        case .success(let credentials):
-            // You've got your credentials
-        case .failure(let error):
-            // Handle the error
-        }
-    }
-```
diff --git a/articles/quickstart/native/ios-swift/03-user-sessions.md b/articles/quickstart/native/ios-swift/03-user-sessions.md
deleted file mode 100644
index a4095e5c1a..0000000000
--- a/articles/quickstart/native/ios-swift/03-user-sessions.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-title: User Sessions
-description: This tutorial will show you how to handle user sessions and retrieve the user's profile.
-budicon: 280
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '03-User-Sessions',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have integrated the Auth0 library into your project. If you have not, follow the [Login](/quickstart/native/ios-swift/00-login) tutorial.
-
-## Credentials Manager
-
-This guide shows you how to use the credentials manager to store and Refresh Tokens. 
-
-[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. 
-
-::: note
-You can also use `SimpleKeychain` directly, without the added benefits and convenience of the credentials manager. To learn more, read about [Saving and Refreshing Tokens](/libraries/auth0-swift/save-and-refresh-jwt-tokens#simplekeychain). 
-:::
-
-## Save the User's Credentials When They Log in
-
-When your users log in successfully, save their credentials. You can then log them in automatically when they open your application again.
-
-To get a [Refresh Token](/refresh-token) during authentication, use the `offline_access` scope. You can use the Refresh Token to request a new Access Token when the previous one expires. 
-
-First, import the `Auth0` module to the file that will present the login page:
-
-${snippet(meta.snippets.setup)}
-
-Next, present the login page:
-
-```swift
-// HomeViewController.swift
-Credentials manager
-// Create an instance of the credentials manager for storing credentials
-let credentialsManager = CredentialsManager(authentication: Auth0.authentication())
-
-Auth0
-    .webAuth()
-    .scope("openid profile offline_access")
-    .audience("https://${account.namespace}/userinfo")
-    .start {
-        switch $0 {
-        case .failure(let error):
-            // Handle the error
-            print("Error: \(error)")
-        case .success(let credentials):
-            // Auth0 will automatically dismiss the login page
-            // Store the credentials
-            credentialsManager.store(credentials: credentials)
-        }
-}
-```
-
-## Check for Credentials When the User Opens Your Application
-
-When the user opens your application, check for valid credentials. If they exist, you can log the user in automatically and redirect them to the app's main flow without any additional login steps.
-
-::: note
-We recommend that you download the sample project from this tutorial and take a look at its implementation. Focus on the `CredentialsManager` class, which manages session handling, obtains user credentials and saves them.
-:::
-
-First, you check if the credentials manager has valid credentials:
-
-```swift
-// SessionManager.swift
-
-guard credentialsManager.hasValid() else {
-    // No valid credentials exist, present the login page
-}
-```
-
-Next, retrieve the credentials:
-
-```swift
-// SessionManager.swift
-
-credentialsManager.credentials { error, credentials in
-    guard error == nil, let credentials = credentials else {
-        // Handle error
-        print("Error: \(error)")
-    }
-    // You now have a valid credentials object, you might want to store this locally for easy access.
-    // You will use this later to retrieve the user's profile
-} 
-```
-
-If the credentials have expired, the credentials manager will automatically renew them for you with the Refresh Token.
-
-## Clear the Keychain When the User Logs Out
-
-When you need to log the user out, remove their credentials from the keychain:
-
-```swift
-// SessionManager.swift
-
-credentialsManager.clear()
-```
-
-## Get the User Profile
-
-To get the user's profile, you need a valid Access Token. You can find the token in the `credentials` object returned by the credentials manager.
-
-```swift
-// SessionManager.swift
-
-// credentials = A returned credentials object from the credentials manager in the previous step.
-
-guard let accessToken = credentials?.accessToken
-    else { // Handle Error }
-Auth0
-    .authentication()
-    .userInfo(withAccessToken: accessToken)
-    .start { result in
-        switch(result) {
-        case .success(let profile):
-            // You've got the user's profile, good time to store it locally.
-            // e.g. self.profile = profile
-        case .failure(let error):
-            // Handle the error
-            print("Error: \(error)")
-        }
-    }
-```
-
-## Show the User Profile Information
-
-### Default information
-
-To show the information contained in the user profile, access its properties, for example:
-
-```swift
-// ProfileViewController.swift
-
-if let name = profile.name, let pictureURL = profile.picture {
-  // Show Information
-}
-```
-
-::: note
-Read the [UserInfo](https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift) class documentation to learn more about its properties.
-:::
-
-### Additional information
-
-You can request more information than returned in the basic profile. To do this, add `userMetadata` to the profile.
-
-## Update the User Profile
-
-You store additional user information in the user metadata. Perform a `patch`:
-
-```swift
-let idToken = ... // You will need the idToken from your credentials instance 'credentials.idToken'
-let profile = ... // the Profile instance you obtained before
-Auth0
-    .users(token: idToken)
-    .patch(profile.sub, userMetadata: ["first_name": "John", "last_name": "Appleseed", "country": "Canada"]
-    .start { result in
-        switch result {
-          case .success(let ManagementObject):
-              // deal with success
-          case .failure(let error):
-              // deal with failure
-        }
-}
-```
-
-## Retrieve User Metadata
-
-The `user_metadata` dictionary contains fields related to the user profile. These fields can be added from client-side (for example, when the user edits their profile). 
-
-You can specify the fields you want to retrieve, or use an empty array `[]` to pull back the complete user profile. 
-
-Retrieve the `user_metadata` dictionary:
-
-```swift
-Auth0
-    .users(token: idToken)
-    .get(profile.sub, fields: ["user_metadata"], include: true)
-    .start { result in
-        switch result {
-        case .success(let user):
-            guard let userMetadata = user["user_metadata"] as? [String: Any] else { return }
-            // Access userMetadata
-        case .failure(let error):
-            // Deal with failure
-        }
-}
-```
-
-Access the user's metadata. You can choose the key names and types for the `user_metadata` dictionary.
-
-```swift
-let firstName = userMetadata["first_name"] as? String
-let lastName = userMetadata["last_name"] as? String
-let country = userMetadata["country"] as? String
-let isActive = userMetadata["active"] as? Bool
-```
diff --git a/articles/quickstart/native/ios-swift/04-calling-apis.md b/articles/quickstart/native/ios-swift/04-calling-apis.md
deleted file mode 100644
index a234edac40..0000000000
--- a/articles/quickstart/native/ios-swift/04-calling-apis.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Calling APIs
-description: This tutorial will show you how to use the Auth0 tokens to make authenticated API calls.
-budicon: 546
----
-
-You may want to restrict access to your API resources, so that only authenticated users with sufficient privileges can access them. Auth0 lets you manage access to these resources using [API Authorization](/api-auth).
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '04-Calling-APIs',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-Auth0 provides a set of tools for protecting your resources with end-to-end authentication in your application. 
-
-In this tutorial, you'll learn how to get a token, attach it to a request (using the authorization header), and call any API you need to authenticate with. 
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have completed the [Session Handling](/quickstart/native/ios-swift/03-user-sessions) tutorial and you know how to handle the `Credentials` object.
-* You have set up a backend application as API. To learn how to do it, follow one of the [backend tutorials](/quickstart/backend).
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Get the User's Access Token
-
-To retrieve an access token that is authorized to access your API, you need to specify the **API Identifier** value you created in the [Auth0 APIs Dashboard](https://manage.auth0.com/#/apis).
-
-Present the Hosted Login Page:
-
-::: note
-Depending on the standards in your API, you configure the authorization header differently. The code below is just an example.
-:::
-
-```swift
-// HomeViewController.swift
-let APIIdentifier = "API_IDENTIFIER" // Replace with the API Identifier value you created
-
-Auth0
-    .webAuth()
-    .scope("openid profile")
-    .audience(APIIdentifier)
-    .start {
-        switch $0 {
-        case .failure(let error):
-            // Handle the error
-            print("Error: \(error)")
-        case .success(let credentials):
-            // Do something with credentials e.g.: save them.
-            // Auth0 will automatically dismiss the hosted login page
-            print("Credentials: \(credentials)")
-        }
-}
-```
-
-## Attach the Access Token
-
-To give the authenticated user access to secured resources in your API, include the user's access token in the requests you send to the API.
-
-```swift
-// ProfileViewController.swift
-
-let token  = ... // The accessToken you stored after authentication
-let url = URL(string: "your api url")! // Set to your Protected API URL
-var request = URLRequest(url: url)
-
-request.addValue("Bearer \(token)", forHTTPHeaderField: "Authorization")
-let task = URLSession.shared.dataTask(with: request) { data, response, error in
-    // Parse the response
-}
-```
-
-## Send the Request
-
-Send the request you created:
-
-```swift
-// ProfileViewController.swift
-
-task.resume()
-```
\ No newline at end of file
diff --git a/articles/quickstart/native/ios-swift/05-authorization.md b/articles/quickstart/native/ios-swift/05-authorization.md
deleted file mode 100644
index 864db143aa..0000000000
--- a/articles/quickstart/native/ios-swift/05-authorization.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Authorization
-description: This tutorial will show you how assign roles to your users, and use those claims to authorize or deny a user to perform certain actions in the app.
-budicon: 500
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '05-Authorization',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-Many identity providers supply access claims which contain, for example, user roles or groups. You can request the access claims in your token with `scope: openid roles` or `scope: openid groups`.
-
-If an identity provider does not supply this information, you can create a rule for assigning roles to users. 
-
-## Create a Rule to Assign Roles
-
-Create a rule that assigns the following access roles to your user: 
-* An admin role
-* A regular user role
-
-To assign roles, go to the [New rule](${manage_url}/#/rules/new) page. In the **Access Control** section, select the **Set roles to a user** template. 
-
-Edit the following line from the default script to match the conditions that fit your needs:
-
-```js
-function (user, context, callback) {
-
-  //Define the name of the claim. Must look like a url:
-  //Have 'http' or 'https' scheme and a hostname other than
-  //'auth0.com', 'webtask.io' and 'webtask.run'.
-  var claimName = 'https://access.control/roles';
-
-  //Check if the email has the 'admin.com' domain and give the 'admin' role.
-  //Otherwise, keep a default 'user' role.
-  var roles = ['user'];
-  if (user.email && user.email.indexOf('@admin.com') > -1) {
-      roles.push('admin');
-  }
-  //Set the role claim in the id_token
-  context.idToken[claimName] = roles;
-
-  callback(null, user, context);
-}
-```
-
-The rule is checked every time a user attempts to authenticate. 
-
-* If the user has a valid email and the domain is `admin.com`, the user gets the admin and user roles.
-* If the email contains anything else, the user gets the regular user role.
-
-The claim is saved in the ID Token under the name `https://access.control/roles`. 
-
-::: note
-Depending on your needs, you can define roles other than admin and user. Read about the names you give your claims in the [Rules documentation](/rules#hello-world).
-:::
-
-## Test the Rule in Your Project
-
-The claim with the roles you set is stored in the user's ID Token. It is a [JSON Web Token (JWT)](/jwt) that holds claims. You can use a JWT decoding library to obtain the roles and perform access control. You can use the [JWTDecode](https://github.com/auth0/JWTDecode.swift) library. 
-
-```swift
-import JWTDecode
-```
-
-```swift
-guard
-    let idToken = self.keychain.string(forKey: "id_token"),
-    let jwt = try? decode(jwt: idToken),
-    let roles = jwt.claim(name: "https://access.control/roles").array
-    else { // Couldn't retrieve claim }
-
-if roles.contains("admin") {
-    // Access Granted
-    // Present Admin Screen
-} else {
-    // Access Denied
-    // Show warning
-}
-```
-
-## Restrict Content Based on Access Level
-
-Now you can recognize the users with different roles in your app. You can use this information to give and restrict access to selected features in your app to users with different roles.
-
-In the sample project, the user with the admin role can access the admin panel. 
\ No newline at end of file
diff --git a/articles/quickstart/native/ios-swift/07-linking-accounts.md b/articles/quickstart/native/ios-swift/07-linking-accounts.md
deleted file mode 100644
index 49c7296c01..0000000000
--- a/articles/quickstart/native/ios-swift/07-linking-accounts.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-title: Linking Accounts
-description: This tutorial will show you how to link multiple accounts within the same user.
-budicon: 345
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '07-Linking-Accounts',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have integrated [Auth0.swift](https://github.com/auth0/Auth0.swift/) as a dependency in your project. 
-* You are familiar with presenting the login screen. To learn more, see the [Login](/quickstart/native/ios-swift/00-login) and the [User Sessions](/quickstart/native/ios-swift/03-user-sessions) tutorials.
-
-We recommend that you read the [Linking Accounts](/link-accounts) documentation to understand the process of linking accounts.
-
-## Enter Account Credentials
-
-Your users may want to link their other accounts to the account they are logged in to. 
-
-To achieve this, present an additional login dialog where your users can enter the credentials for any additional account. You can present this dialog in the way described in the [Login](/quickstart/native/ios-swift/00-login#enter-account-credentials) tutorial.
-
-After the user authenticates, save the `idToken` value for the secondary account.
-
-<%= include('../_includes/_ios_link_accounts') %>
-
-```swift
-import Auth0
-```
-
-```swift
-// UserIdentitiesViewController.swift
-
-Auth0
-    .users(token: idToken)
-    .link(id, withOtherUserToken: otherUserToken)
-    .start { result in
-        switch result {
-        case .success:
-            // The account was linked
-        case .failure(let error):
-            // Handler Error
-        }
-    }
-```
-
-## Retrieve the Linked Accounts
-
-Once you have the `sub` value from the profile, you can retrieve user identities. Call the management API:
-
-```swift
-// SessionManager.swift
-
-Auth0
-    .users(token: idToken)
-    .get(profile.sub, fields: ["identities"], include: true)
-    .start { result in
-        switch result {
-        case .success(let user):
-            let identityValues = user["identities"] as? [[String: Any]] ?? []
-            let identities = identityValues.flatMap { Identity(json: $0) }
-        case .failure(let error):
-            // Handle error
-        }
-  }
-```
-
-::: note
-A linked account is handled as an `Identity` instance. Read more about this object in the [Identity class documentation](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Identity.swift).
-:::
-
-<%= include('../_includes/_ios_unlink_accounts') %>
-
-Unlink the accounts:
-
-```swift
-// UserIdentitiesViewController.swift
-
-let id = ... // the user id. (See profile.sub)
-let idToken = ... // the user idToken
-let identity: Identity = ... // the identity (account) you want to unlink from the user
-Auth0
-    .users(token: idToken)
-    .unlink(identityId: identity.identifier, provider: identity.provider, fromUserId: id)
-    .start { result in
-            switch result {
-            case .success:
-                // Unlinked account!
-            case .failure(let error):
-                // Deal with error
-            }
-     }
-```
diff --git a/articles/quickstart/native/ios-swift/08-touch-id-authentication.md b/articles/quickstart/native/ios-swift/08-touch-id-authentication.md
deleted file mode 100644
index 20796ab0c5..0000000000
--- a/articles/quickstart/native/ios-swift/08-touch-id-authentication.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Touch ID Authentication
-description: This tutorial will show you how to utilise Touch ID and the Credentials Manager
-budicon: 345
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '08-Credentials-TouchID',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)',
-    'Touch ID Enrolled Device'
-  ]
-}) %>
-
-## Before You Start
-
-Before you continue with this tutorial, make sure that you have completed the previous tutorials. This tutorial assumes that:
-* You have integrated [Auth0.swift](https://github.com/auth0/Auth0.swift/) as a dependency in your project. 
-* You are familiar with presenting the login screen. To learn more, see the [Login](/quickstart/native/ios-swift/00-login) tutorial.
-* You know how to renew a user's credentials with a Refresh Token. To learn more, see the [User Sessions](/quickstart/native/ios-swift/03-user-sessions) tutorial.
-
-## Apply Touch ID Authentication
-
-This tutorial shows you how to renew the user's credentials without presenting the user with the login page. Additionally, the guide shows you how to use Touch ID to validate the renewal. 
-
-This tutorial covers how to use 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 Touch ID.
-
-Import the `Auth0` module:
-
-${snippet(meta.snippets.setup)}
-
-## Add the Credentials Manager
-
-Add a property to your class for the credentials manager:
-
-```swift
-let credentialsManager: CredentialsManager!
-```
-
-Next, initialize the credentials manager in the appropriate `init` method of your class:
-
-```swift
-self.credentialsManager = CredentialsManager(authentication: Auth0.authentication())
-```
-
-## Add Login
-
-Present the login page. Add the `offline_access` scope to receive a `refreshToken`.
-
-::: note
-Read more about presenting the login page in the [User Sessions](/quickstart/native/ios-swift/03-user-sessions) tutorial.
-:::
-
-```swift
-// HomeViewController.swift
-
-Auth0
-    .webAuth()
-    .scope("openid profile offline_access")
-    .audience("https://${account.namespace}/userinfo")
-    .start {
-        switch $0 {
-        case .failure(let error):
-            // Handle the error
-            print("Error: \(error)")
-        case .success(let credentials):
-            // Store credentials securely with the Credentials Manager
-            self.credentialsManager.store(credentials: credentials)
-        }
-}
-```
-
-When the user logs in, the credentials object is encrypted and stored securely in the keychain.
-
-## Renew the User's Credentials
-
-To automatically renew the user's credentials, use the [credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/CredentialsManager.swift#L98) method in the credentials manager. 
-
-The credentials manager retrieves stored credentials from the keychain and checks if the Access Token is still valid:
-* If the current credentials are still valid, the credentials manager returns them
-* If the Access Token has expired, the credentials manager renews them using the Refresh Token and returns them
-
-Add the following:
-
-```swift
-self.credentialsManager.credentials { error, credentials in
-    guard error == nil, let credentials = credentials else {
-        // Handle Error
-        // Route user back to Login Screen
-    }
-    // There is no need to store the credentials as you did in Login. The Credentials Manager will do this for you internally
-    // Continue routing the user as authentication was a success
-}
-```
-
-## Enable Touch ID
-
-After the line that initialized the credentials manager, add a line that enables Touch ID:
-
-```swift
-self.credentialsManager.enableTouchAuth(withTitle: "Touch to Authenticate")
-```
-
-Next time you call the `credentials` method, the user will be prompted for their Touch ID with a "Touch to Authenticate" message.
-
-## Improve the User Experience
-
-If the user has logged out and you have cleared the credentials from the credentials manager, for example, with the following: 
-
-```swift
-self.credentialsManager.clear()
-```
-
-The user is still prompted for their touch ID. This returns an error in the `credentials` closure because there are no credentials to renew from.
-
-The credentials manager has a `hasValid()` method that lets you know if there are valid credentials that can be returned directly or renewed and returned.
-
-You can add this check before you call the `credentials` method:
-
-```swift
-guard self.credentialsManager.hasValid() else {
-    // Route to Login
-}
-```
diff --git a/articles/quickstart/native/ios-swift/_includes/_config.md b/articles/quickstart/native/ios-swift/_includes/_config.md
deleted file mode 100644
index cddcc8468a..0000000000
--- a/articles/quickstart/native/ios-swift/_includes/_config.md
+++ /dev/null
@@ -1,54 +0,0 @@
-## Adding Auth0 Credentials
-
-The dependencies listed above require your client credentials in order for them to work. If you downloaded any sample project from here, these credentials are automatically set. Either way, you have to make sure they are there otherwise your app might crash.
-
-Add your credentials in `Auth0.plist`. You have to create that file if it doesn't already exist in your project:
-
-```xml
-
-
-
-
-
-
-  ClientId
-  ${account.clientId}
-  Domain
-  ${account.namespace}
-
-
-```
-
-## Configure Callback URLs
-
-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 a token. Since callback URLs can be manipulated, you will need to add your application's URL to your client's **Allowed Callback URLs** for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful.
-
-In your application's `Info.plist` file, register your iOS Bundle Identifer as a custom scheme:
-
-```xml
-
-
-CFBundleURLTypes
-
-    
-        CFBundleTypeRole
-        None
-        CFBundleURLName
-        auth0
-        CFBundleURLSchemes
-        
-            $(PRODUCT_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**.
-:::
-
-Finally, go to your [Client's Dashboard](${manage_url}/#/applications/${account.clientId}/settings) and make sure that "Allowed Callback URLs" contains the following:
-
-```text
-{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback
-```
diff --git a/articles/quickstart/native/ios-swift/_includes/_dependency_embedded.md b/articles/quickstart/native/ios-swift/_includes/_dependency_embedded.md
deleted file mode 100644
index d4e1eb5057..0000000000
--- a/articles/quickstart/native/ios-swift/_includes/_dependency_embedded.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Install
-
-### Carthage
-
-If you are using Carthage, add the following lines to your `Cartfile`:
-
-```ruby
-github "auth0/Lock.swift" ~> 2.0
-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).
-:::
-
-### Cocoapods
-
-If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`:
-
-```ruby
-use_frameworks!
-pod 'Lock', '~> 2.0'
-pod 'Auth0', '~> 1.0'
-```
-
-Then, run `pod install`.
-
-::: note
-For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html).
-:::
diff --git a/articles/quickstart/native/ios-swift/_includes/_login_centralized.md b/articles/quickstart/native/ios-swift/_includes/_login_centralized.md
deleted file mode 100644
index 7d55c5f125..0000000000
--- a/articles/quickstart/native/ios-swift/_includes/_login_centralized.md
+++ /dev/null
@@ -1,54 +0,0 @@
-[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.
-
-::: note
-You can also embed the login dialog directly in your application using the [Lock widget](/lock). If you use this method, some features, such as single sign-on, will not be accessible. 
-To learn how to embed the Lock widget in your application, follow the [Embedded Login sample](https://github.com/auth0-samples/auth0-ios-swift-sample/tree/embedded-login/01-Embedded-Login).
-:::
-
-
        login page
        
-
-::: note
-Read the [Browser-Based vs. Native Login Flows on Mobile Devices](/tutorials/browser-based-vs-native-experience-on-mobile) article to learn how to choose between the two types of login flows.
-:::
-
-<%= include('../../_includes/_ios_dependency_centralized') %>
-
-## Add the Callback
-
-For Auth0 to handle the authentication callback, update your `AppDelegate` file. 
-
-First, import the `Auth0` module:
-
-${snippet(meta.snippets.setup)}
-
-Then, add the following `UIApplicationDelegate` method:
-
-```swift
-// AppDelegate.swift
-
-func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any]) -> Bool {
-    return Auth0.resumeAuth(url, options: options)
-}
-```
-
-::: note
-To configure callback, you must configure your callback URL first. Read about the Callback URL in the [Configure Callback](/quickstart/native/ios-swift/getting-started#configure-callback-urls) step.
-:::
-
-## Implement Login
-
-First, import the `Auth0` module in the file where you want to present the login page:
-
-${snippet(meta.snippets.setup)}
-
-Then, present the login screen:
-
-${snippet(meta.snippets.use)}
-
-This adds the `profile` scope to enable [retrieving the User Profile](/quickstart/native/ios-swift/03-user-sessions#fetch-the-user-profile).
-
-After the user authenticates, their information is returned in a `credentials` object.
-
-::: note
-To learn more about the `credentials` object, read the [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) article.
-:::
diff --git a/articles/quickstart/native/ios-swift/_includes/_login_embedded.md b/articles/quickstart/native/ios-swift/_includes/_login_embedded.md
deleted file mode 100644
index 2144fdd748..0000000000
--- a/articles/quickstart/native/ios-swift/_includes/_login_embedded.md
+++ /dev/null
@@ -1,65 +0,0 @@
-<%= include('_dependency_embedded') %>
-
-## Implement the Login
-
-First, import the `Lock` module in the file where you want to present the login dialog:
-
-```swift
-import Lock
-```
-
-Then, configure and present the embedded login widget:
-
-```swift
-Lock
-    .classic()
-    .withOptions {
-        $0.oidcConformant = true
-        $0.scope = "openid profile"
-    }
-    .onAuth { credentials in
-        // Do something with credentials, such as save them.
-        // Lock will not save these objects for you.
-        // Lock will dismiss itself automatically by default.
-    }
-    .present(from: self)
-```
-
-::: note
-The snippet enables `oidcConformant`, 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. For more information, please see our [Introduction to OIDC Conformant Authentication](/api-auth/intro) and the [OIDC adoption guide](/api-auth/tutorials/adoption).
-:::
-
-
        Lock UI
        
-
-As you can see, upon successful authentication, the `onAuth` callback will yield the user's `credentials`.
-
-::: note
-For further reference on the `credentials` object, please see
-[Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) documentation. We will cover the storage of the user's credentials in a later chapter.  By default Lock will not store this for you.
-:::
-
-This sets you up for handling Database connections.
-
-### Log In with Enterprise & Social Connections
-
-In order to use browser based Auth mechanism through social and enterprise connections, all you have to do is enable them in your account's [connections dashboard](${manage_url}/#/connections/social). Every connection you switch on there, will appear in the Login screen of your app.
-
-Lock will need to handle the callback of this authentication, Lock can take responsibility for this by adding the following to your `AppDelegate`:
-
-First, import the `Lock` module:
-
-```swift
-import Lock
-```
-
-Then, add the following `UIApplicationDelegate` method:
-
-```swift
-func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any]) -> Bool {
-  return Lock.resumeAuth(url, options: options)
-}
-```
-
-::: note
-Please ensure you have configured your callback URL as demonstrated in [Configure Callback](/quickstart/native/ios-swift/00-getting-started#configure-callback-urls).
-:::
diff --git a/articles/quickstart/native/ios-swift/_includes/_prerequisite.md b/articles/quickstart/native/ios-swift/_includes/_prerequisite.md
deleted file mode 100644
index f77661ec7f..0000000000
--- a/articles/quickstart/native/ios-swift/_includes/_prerequisite.md
+++ /dev/null
@@ -1,7 +0,0 @@
-::: panel System Requirements
-These tutorials and seed projects have been tested with the following:
-
-* CocoaPods 1.2.1
-* Version 8.3.2 (8E2002)
-* iPhone 7 - iOS 10.3 (14E269)
-:::
diff --git a/articles/quickstart/native/ios-swift/dashboard-default.md b/articles/quickstart/native/ios-swift/dashboard-default.md
deleted file mode 100644
index 25a10eb8d5..0000000000
--- a/articles/quickstart/native/ios-swift/dashboard-default.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Getting Started
-description: Short Introduction to the Auth0 iOS Swift Quickstarts.
-budicon: 715
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ios-swift-sample',
-  path: '00-Login',
-  requirements: [
-    'CocoaPods 1.2.1',
-    'Version 8.3.2 (8E2002)',
-    'iPhone 7 - iOS 10.3 (14E269)'
-  ]
-}) %>
-
-This multistep quickstart guide will walk you through managing authentication in your iOS Swift apps with Auth0.
-
-## About the Sample Applications
-
-Each step within this quickstart guide (starting with **Login**) contains a downloadable sample which demonstrates the topic being covered. Within each of these samples, you will find an appropriate application to demonstrate the features discussed in the chapter.
-
-## Auth0 Dependencies
-
-Each tutorial will require you to use either the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit, the [Lock](https://github.com/auth0/Lock.swift) widget or both.
-
-A brief description:
-
-- [**Auth0.swift**](https://github.com/auth0/Auth0.swift) is a toolkit that lets you communicate efficiently with many the [Auth0 API](/api/info) functions and enables you to integrate the Login.
-
-- [**Lock.swift**](https://github.com/auth0/Lock.swift) is a native widget that is easy to embed in your app. It contains default templates (that can be customized) for login with email/password, signup, social providers integration, and password recovery.
-
-## Create an Application
-
-If you haven't already done so, create a new application in your [Auth0 dashboard](${manage_url}/#/applications/${account.clientId}/settings) and choose **Native**.
-
-![App Dashboard](/media/articles/angularjs/app_dashboard.png)
-
-<%= include('_includes/_config') %>
-
-<%= include('_includes/_login_centralized') %>
diff --git a/articles/quickstart/native/ios-swift/download.md b/articles/quickstart/native/ios-swift/download.md
new file mode 100644
index 0000000000..32124138f3
--- /dev/null
+++ b/articles/quickstart/native/ios-swift/download.md
@@ -0,0 +1,20 @@
+
+
+> On every step, if you have a custom domain, 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, 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/articles/quickstart/native/ios-swift/files/Auth0.md b/articles/quickstart/native/ios-swift/files/Auth0.md
new file mode 100644
index 0000000000..06a0a42d16
--- /dev/null
+++ b/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/articles/quickstart/native/ios-swift/files/MainView.md b/articles/quickstart/native/ios-swift/files/MainView.md
new file mode 100644
index 0000000000..c7dd749fe5
--- /dev/null
+++ b/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/articles/quickstart/native/ios-swift/files/ProfileView.md b/articles/quickstart/native/ios-swift/files/ProfileView.md
new file mode 100644
index 0000000000..cd896b9fe0
--- /dev/null
+++ b/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/articles/quickstart/native/ios-swift/files/User.md b/articles/quickstart/native/ios-swift/files/User.md
new file mode 100644
index 0000000000..ac70c8d6b6
--- /dev/null
+++ b/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/articles/quickstart/native/ios-swift/getting-started.md b/articles/quickstart/native/ios-swift/getting-started.md
deleted file mode 100644
index ee0a566c65..0000000000
--- a/articles/quickstart/native/ios-swift/getting-started.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Getting Started
-description: Initial steps to integrate Auth0 in an iOS Swift application.
-budicon: 448
----
-
-This quickstart guide walks you through managing authentication with Auth0 in your iOS Swift apps.
-
-## Sample Projects
-
-Each tutorial in this guide includes a link to a sample project showing the features described in the article. You can find all the samples in the [iOS Swift samples folder](https://github.com/auth0-samples/auth0-ios-swift-sample).
-
-## Dependencies
-
-Each tutorial uses the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit. It is a toolkit that lets you efficiently communicate with many of the basic [Auth0 API](/api/info) functions.
-
-<%= include('../_includes/_create_application') %>
-
-<%= include('../_includes/_ios_config') %>
diff --git a/articles/quickstart/native/ios-swift/index.yml b/articles/quickstart/native/ios-swift/index.yml
old mode 100644
new mode 100755
index 389b806cce..db922d99d6
--- a/articles/quickstart/native/ios-swift/index.yml
+++ b/articles/quickstart/native/ios-swift/index.yml
@@ -1,67 +1,38 @@
-title: iOS Swift
+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
-framework:
-  - Swift
+hybrid: false
 author:
-  name: Martin Walsh
-  email: martin.walsh@auth0.com
+  name: Rita Zerrizuela
+  email: rita.zerrizuela@auth0.com
   community: false
-image: /media/platforms/ios.png
-tags:
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 seo_alias: swift
-snippets:
-  setup: native-platforms/ios-swift/setup
-  use: native-platforms/ios-swift/use
-default_article: dashboard-default
+show_releases: true
+show_steps: true
+requirements:
+  - iOS 13+ or macOS 11+
+  - Xcode 14.x
+default_article: 01-login
 articles:
-  - getting-started
-  - 00-login
-  - 03-user-sessions
-  - 04-calling-apis
-  - 05-authorization
-  - 07-linking-accounts
-  - 08-touch-id-authentication
-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 anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-  - path: 03-user-sessions
-    list:
-    - text: Learn about refresh tokens
-      icon: 345
-      href: "/tokens/refresh-tokens"
-    - text: Learn about the user profile structure
-      icon: 345
-      href: "/user-profile/normalized/oidc"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-    - text: In-depth details about user profile
-      icon: 345
-      href: "/user-profile/user-profile-details"
-  - path: 04-calling-apis
-    list:
-    - text: Learn about custom APIs
-      icon: 345
-      href: "/api"
-    - text: Introduction to API authorization
-      icon: 345
-      href: "/api-auth"
-  - path: 05-authorization
-    list:
-    - text: Learn about rules
-      icon: 345
-      href: "/rules"
\ No newline at end of file
+  - 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/articles/quickstart/native/ios-swift/interactive.md b/articles/quickstart/native/ios-swift/interactive.md
new file mode 100644
index 0000000000..c455ebbbaa
--- /dev/null
+++ b/articles/quickstart/native/ios-swift/interactive.md
@@ -0,0 +1,106 @@
+---
+title: Add Login to Your iOS or macOS Application
+description: This guide demonstrates how to integrate Auth0 with any iOS / macOS app using the Auth0.swift SDK.
+interactive:  true
+files:
+ - files/Auth0
+ - files/MainView
+ - files/ProfileView
+ - files/User
+github:
+  path: Sample-01
+locale: en-US
+---
+
+# 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 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
+
+
+
        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.
        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, use this instead of your Auth0 tenant’s domain.
        iOS
        https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+
+
        
+
+
        macOS
        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:
        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
        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 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 and App ID to your app's bundle identifier.
        Auth0 Dashboard> Applications > Applications > [Native App] > Settings tab > Advanced Settings > Device Settings tab
        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 of your app's target settings, and press the + Capability button. Then select Associated Domains.
        Xcode> Signing and Capabilities tab > Add New > Associated Domains
        Next, add the following entry under Associated Domains:
        webcredentials:labs-fundtraining.us.auth0.com
+
+
        
+
+
        If you have a custom domain, use this instead of your Auth0 tenant’s domain.
        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:
        https://github.com/auth0/Auth0.swift
+
+
        
+
+
        Then, select the dependency rule and press Add Package.
        For further reference on SPM, check its official documentation.
        Using Cocoapods
        Add the following line to your Podfile:
        pod 'Auth0', '~> 2.0'
+
+
        
+
+
        Then, run pod install. 
        For further reference on Cocoapods, check their official documentation.
        Using Carthage
        Add the following line to your Cartfile:
        github "auth0/Auth0.swift" ~> 2.0
+
+
        
+
+
        Then, run carthage bootstrap --use-xcframeworks.
        For further reference on Carthage, check their official documentation.
        
+
+## 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 of your Auth0 application.
        • domain: The domain of your Auth0 tenant. If you have a custom domain, 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.
        You can also configure the SDK programmatically. Check the README to learn more.
        iOS Swift Quickstart - Step 3 Checkpoint 
        You configured the Auth0.swift SDK. Run your app to verify that it is not producing any errors related to the SDK.
        
+
+  
        
+
+  
        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 or visit our community page 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 page in the action of your Login button.
        You can use async/await or Combine instead of the callback-based API. Check the README to learn more.
        An example Universal Login screen for an iOS app
        iOS Swift Quickstart - Step 4 Checkpoint 
        Press the Login button and verify that:
        • An alert box 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. 
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add logout to your application {{{ data-action="code" data-code="MainView.swift#34:45" }}}
+
+
+
        Now that you can log in to your app, you need a way to log out. In the action of your Logout button, call the clearSession() method to clear the Universal Login session cookie.
        iOS Swift Quickstart - Step 5 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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. 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 for decoding JWTs 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.
        You can retrieve the latest user information with the userInfo(withAccessToken:) method. Check the EXAMPLES to learn more.
        iOS Swift Quickstart - Step 6 Checkpoint 
        Verify that you can access the email, picture, or any other claim after you have logged in.
        
+
+  
        
+
+  
        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 or visit our community forums to get more help.
        
+
+  
        
diff --git a/articles/quickstart/native/maui/01-login.md b/articles/quickstart/native/maui/01-login.md
new file mode 100755
index 0000000000..32108b32c7
--- /dev/null
+++ b/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 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 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/articles/quickstart/native/maui/download.md b/articles/quickstart/native/maui/download.md
new file mode 100644
index 0000000000..96bd62f994
--- /dev/null
+++ b/articles/quickstart/native/maui/download.md
@@ -0,0 +1,22 @@
+To run the sample first set the **Allowed Callback URLs** in the Application Settings:
+
+  ```text
+myapp://callback
+  ```
+
+Set the **Allowed Logout URLs** in the Application Settings:
+
+  ```text
+myapp://callback
+  ```
+
+Then, to run it **on Windows**:
+
+1) Open the Auth0MauiApp.sln in Visual Studio 2022.
+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.
+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/articles/quickstart/native/maui/files/MainPage.xaml.md b/articles/quickstart/native/maui/files/MainPage.xaml.md
new file mode 100644
index 0000000000..010c5970f8
--- /dev/null
+++ b/articles/quickstart/native/maui/files/MainPage.xaml.md
@@ -0,0 +1,73 @@
+---
+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 = "";
+    }
+}
+```
diff --git a/articles/quickstart/native/maui/files/main-page.md b/articles/quickstart/native/maui/files/main-page.md
new file mode 100644
index 0000000000..6bb02cb95e
--- /dev/null
+++ b/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/articles/quickstart/native/maui/index.yml b/articles/quickstart/native/maui/index.yml
new file mode 100755
index 0000000000..f0dc62f629
--- /dev/null
+++ b/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/articles/quickstart/native/maui/interactive.md b/articles/quickstart/native/maui/interactive.md
new file mode 100644
index 0000000000..2cd149cf4d
--- /dev/null
+++ b/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,158 @@
+---
+title: Add Login to Your MAUI Application
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET MAUI application.
+interactive:  true
+files:
+ - files/MainPage.xaml
+github:
+  path: Sample
+locale: en-US
+---
+
+# 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.
        The MAUI SDK supports Android, iOS, macOS, and Windows. Continue reading for platform-specific configuration.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to myapp://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.
        If you are following along with our sample project, set this to myapp://callback.
        
+
+## Install the Auth0 SDK
+
+
+
        Auth0 provides a 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).
        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:
        [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).
        <Applications>
+
+ <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="$targetentrypoint$">
+
+ <Extensions>
+
+ <uap:Extension Category="windows.protocol">
+
+ <uap:Protocol Name="myapp"/>
+
+ </uap:Extension>
+
+ </Extensions>
+
+ </Application>
+
+</Applications>
+
+
        
+
+
        • Call Activator.Default.CheckRedirectionActivation() in the Windows-specific App.xaml.cs file.
        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.
        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.
        MAUI Quickstart - Step 4 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application {{{ data-action="code" data-code="MainPage.xaml.cs#25: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.
        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().
        MAUI Quickstart - Step 5 Checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's something to double-check:
        • you called LoginAsync as expected
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
+
+## Add logout to your application {{{ data-action="code" data-code="MainPage.xaml.cs#32: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.
        await client.LogoutAsync();
+
+
        
+
+
        MAUI Quickstart - Step 6 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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 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/articles/quickstart/native/net-android-ios/01-login.md b/articles/quickstart/native/net-android-ios/01-login.md
new file mode 100755
index 0000000000..c404a03cbf
--- /dev/null
+++ b/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.
+
+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 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/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md b/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md
new file mode 100644
index 0000000000..755e7c5a89
--- /dev/null
+++ b/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.
diff --git a/articles/quickstart/native/net-android-ios/download.md b/articles/quickstart/native/net-android-ios/download.md
new file mode 100644
index 0000000000..4aea81c06c
--- /dev/null
+++ b/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 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 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.
+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.
+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/articles/quickstart/native/net-android-ios/files/AppDelegate.md b/articles/quickstart/native/net-android-ios/files/AppDelegate.md
new file mode 100644
index 0000000000..0efcf0d8ce
--- /dev/null
+++ b/articles/quickstart/native/net-android-ios/files/AppDelegate.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;
+    }
+}
+```
diff --git a/articles/quickstart/native/net-android-ios/files/MainActivity.md b/articles/quickstart/native/net-android-ios/files/MainActivity.md
new file mode 100644
index 0000000000..dcf30e59af
--- /dev/null
+++ b/articles/quickstart/native/net-android-ios/files/MainActivity.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 = "${account.namespace}",
+    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();
+    }
+}
+```
diff --git a/articles/quickstart/native/net-android-ios/files/MyViewController.md b/articles/quickstart/native/net-android-ios/files/MyViewController.md
new file mode 100644
index 0000000000..99821cc2bd
--- /dev/null
+++ b/articles/quickstart/native/net-android-ios/files/MyViewController.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();
+    }
+}
+```
diff --git a/articles/quickstart/native/net-android-ios/files/app-delegate.md b/articles/quickstart/native/net-android-ios/files/app-delegate.md
new file mode 100644
index 0000000000..4968ce3e1e
--- /dev/null
+++ b/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/articles/quickstart/native/net-android-ios/files/main-activity.md b/articles/quickstart/native/net-android-ios/files/main-activity.md
new file mode 100644
index 0000000000..513b7067ee
--- /dev/null
+++ b/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/articles/quickstart/native/net-android-ios/files/my-view-controller.md b/articles/quickstart/native/net-android-ios/files/my-view-controller.md
new file mode 100644
index 0000000000..e67f6d00fc
--- /dev/null
+++ b/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/articles/quickstart/native/net-android-ios/index.yml b/articles/quickstart/native/net-android-ios/index.yml
new file mode 100755
index 0000000000..7c97755a57
--- /dev/null
+++ b/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/articles/quickstart/native/net-android-ios/interactive.md b/articles/quickstart/native/net-android-ios/interactive.md
new file mode 100644
index 0000000000..723d6a2e52
--- /dev/null
+++ b/articles/quickstart/native/net-android-ios/interactive.md
@@ -0,0 +1,165 @@
+---
+title: Add Login to Your .NET Android and iOS Application
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET Android or iOS application.
+interactive:  true
+files:
+ - files/MainActivity
+ - files/AppDelegate
+ - files/MyViewController
+github:
+  path: Quickstart/01-Login
+locale: en-US
+---
+
+# 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 and iOS.
        This quickstart focuses 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 the 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.
        
+
+## Configure Auth0
+
+
+
        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.
        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://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS: YOUR_BUNDLE_ID://{yourDomain}/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.
        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://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS: YOUR_BUNDLE_ID://{yourDomain}/ios/YOUR_BUNDLE_ID/callback
        Lastly, be sure that the Application Type for your application is set to Native in the Application Settings.
        
+
+## Install the Auth0 SDK
+
+
+
        Auth0 provides an Android and 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).
        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.
        using Auth0.OidcClient;
+
+
+
+var client = new Auth0Client(new Auth0ClientOptions {
+
+  Domain = "${account.namespace}",
+
+  ClientId = "${account.clientId}"
+
+}, this);
+
+
        
+
+
        By default, the SDK will leverage Chrome Custom Tabs for Android and ASWebAuthenticationSession for iOS.
        .NET Android/iOS Quickstart - Step 3 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Configure Android {{{ data-action="code" data-code="MainActivity.cs#2:9" }}}
+
+
+
        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 lowercase. 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.
        protected override void OnNewIntent(Intent intent)
+
+    {
+
+        base.OnNewIntent(intent);
+
+        ActivityMediator.Instance.Send(intent.DataString);
+
+    }
+
+
        
+
+
        
+
+## 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:
        1. Open your application's Info.plist file in Visual Studio, 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:
        <key>CFBundleURLTypes</key>
+
+<array>
+
+ <dict>
+
+ <key>CFBundleTypeRole</key>
+
+ <string>None</string>
+
+ <key>CFBundleURLName</key>
+
+ <string>Auth0</string>
+
+ <key>CFBundleURLSchemes</key>
+
+ <array>
+
+ <string>YOUR_BUNDLE_IDENTIFIER</string>
+
+ </array>
+
+ </dict>
+
+</array>
+
+
        
+
+
        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.
        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().
        .NET Android/iOS Quickstart - Step 6 Checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's something to double-check:
        • you called LoginAsync as expected
        Still having issues? Check out our documentation or visit our community page 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.
        await client.LogoutAsync();
+
+
        
+
+
        .NET Android/iOS Quickstart - Step 7 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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 associated with authenticated users. For example, you may want 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.
        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/articles/quickstart/native/phonegap/01-login.md b/articles/quickstart/native/phonegap/01-login.md
deleted file mode 100644
index ed76fd925b..0000000000
--- a/articles/quickstart/native/phonegap/01-login.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial will show you how to use the Auth0 Phonegap SDK to add authentication and authorization to your mobile app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-cordova-samples',
-  path: '01-Login',
-  requirements: [
-    'NodeJS 4.3',
-    'Phonegap 5.5'
-  ]
-}) %>
-
-### 1. Setting up the callback URL in Auth0
-
-
        
-
        Go to the Application Settings section in the Auth0 dashboard and make sure that Allowed Callback URLs contains the following value:
        
-
-
        https://${account.namespace}/mobile
        
-
-
        Also, if you are testing your application locally, make sure to add your local URL as an Allowed Callback URL and the following as an Allowed Origin (CORS):
        
-
-
        file://\*
        
-
-
        
-
-### 2. Add `InAppBrowser` plugin
-
-You must install the `InAppBrowser` plugin to be able to show the Login popup. For that, just run the following command:
-
-::: note
-If you're using __Phonegap Build__ service, you need to add the plugin using the `` tag between the `` tags inside your __config.xml__ file. Please check [this phonegap guide for more information](http://docs.build.phonegap.com/en_US/configuring_plugins.md.html#importing-config).
-:::
-
-### 3. Follow the guide specific to the frontend technology you're using
-
-Now, you can just follow the tutorial for the frontend technology that you're using. We currently support applications using [jQuery](/application-platforms/jquery), [AngularJS](/application-platforms/angularjs) and [Vanilla JS](/application-platforms/vanillajs).
-
-::: note
-Phonegap doesn't support getting dependencies from a CDN, so you're going to have to download the JS and CSS dependencies locally and then point to the downloaded files.
-:::
-
-::: note
-You must use `popup` mode when configuring an application with Phonegap (all available guides currently do that by default).
-:::
-
-### 4. Sit back and relax
-
-Now it's time to sit back, relax and open a beer. You've implemented Login and Signup with Auth0 and Phonegap.
-
-### Troubleshooting
-
-#### Command failed with exit code 65 when running Phonegap build
-
-This means that the `InAppBrowser` plugin wasn't installed successfully. Try any of the followings to fix this.
-
-* Reinstall the `InAppBrowser` plugin
-
-```bash
-phonegap plugin remove cordova-plugin-inappbrowser
-phonegap plugin add cordova-plugin-inappbrowser
-```
-* Remove the platform and re-add it
-
-iOS:
-
-```bash
-phonegap platform remove ios
-phonegap platform add ios
-```
-Android:
-
-```bash
-phonegap platform remove android
-phonegap platform add android
-```
-
-* Copy the contents from the plugin to the platform plugins
-
-iOS:
-
-```bash
-cp plugins/cordova-plugin-inappbrowser/src/ios/* platforms/ios/[yourAppName]/Plugins/cordova-plugin-inappbrowser/
-```
-Android:
-```bash
-cp plugins/cordova-plugin-inappbrowser/src/android/* platforms/android/[yourAppName]/Plugins/cordova-plugin-inappbrowser/
-```
-#### Get a blank page with an `OK` after signin
-
-This could mean that the `InAppBrowser` plugin wasn't installed successfully.
-
-#### Get error `We could not reach the server. Please try again`
-
-This means you need to install `cordova-plugin-whitelist` by running following command:
-
-```bash
-ionic plugin add cordova-plugin-whitelist
-```
-
-After that, configure your `config.xml` by adding or overriding following instructions:
-
-```
-
-
-```
diff --git a/articles/quickstart/native/phonegap/_index.yml b/articles/quickstart/native/phonegap/_index.yml
deleted file mode 100644
index 74a24ef570..0000000000
--- a/articles/quickstart/native/phonegap/_index.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-title: Phonegap
-author:
-  community: true
-alias:
-  - phonegap
-language:
-  - Javascript
-framework:
-  - Phonegap
-hybrid: true
-image: /media/platforms/phonegap.png
-tags:
-  - quickstart
-snippets:
-  dependencies: native-platforms/phonegap/dependencies
-  setup: native-platforms/jquery/setup
-  use: native-platforms/jquery/use
-seo_alias: phonegap
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/native/react-native-expo/00-login.md b/articles/quickstart/native/react-native-expo/00-login.md
new file mode 100644
index 0000000000..88024c27ac
--- /dev/null
+++ b/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
+
+::: 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 for additional details on Expo.
+:::
+
+### Yarn
+
+```bash
+yarn add react-native-auth0
+```
+
+::: note
+For further reference on yarn, check their official documentation.
+:::
+
+### 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.
+
+
        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 to achieve this.
+
+Add the `react-native-auth0` plugin to the Expo config 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 and iOS bundle identifier 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 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, 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 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. You can create a logout button using the `logout()` method from the `AuthService` service. Executing `logout()` redirects your users to your Auth0 logout endpoint (`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 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 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 within a component correctly after you have logged in.
+:::
\ No newline at end of file
diff --git a/articles/quickstart/spa/angular/02-calling-an-api.md b/articles/quickstart/spa/angular/02-calling-an-api.md
new file mode 100644
index 0000000000..b86c4a898c
--- /dev/null
+++ b/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 section of the Angular Authentication By Example 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, 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, 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 with Auth0.
+:::
+
+Please refer to the docs 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 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 to learn how to integrate Auth0 with your backend platform.
diff --git a/articles/quickstart/spa/angular/download.md b/articles/quickstart/spa/angular/download.md
new file mode 100644
index 0000000000..a74d04f1ae
--- /dev/null
+++ b/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 to
+```text
+http://localhost:4200
+```
+2) Set **Allowed Web Origins** in the Application Settings to
+```text
+http://localhost:4200
+```
+3) Set **Allowed Logout URLs** in the Application Settings to
+```text
+http://localhost:4200
+```
+4) Make sure Node.JS LTS 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 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/articles/quickstart/spa/angular/files/index.md b/articles/quickstart/spa/angular/files/index.md
new file mode 100644
index 0000000000..da47c6b504
--- /dev/null
+++ b/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/articles/quickstart/spa/angular/files/login-button.md b/articles/quickstart/spa/angular/files/login-button.md
new file mode 100644
index 0000000000..e23ae11430
--- /dev/null
+++ b/articles/quickstart/spa/angular/files/login-button.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();
+  }
+}
+```
diff --git a/articles/quickstart/spa/angular/files/login.md b/articles/quickstart/spa/angular/files/login.md
new file mode 100644
index 0000000000..d5c245b6dc
--- /dev/null
+++ b/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/articles/quickstart/spa/angular/files/logout-button.md b/articles/quickstart/spa/angular/files/logout-button.md
new file mode 100644
index 0000000000..15c515882b
--- /dev/null
+++ b/articles/quickstart/spa/angular/files/logout-button.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 
+      }
+    });
+  }
+}
+```
diff --git a/articles/quickstart/spa/angular/files/logout.md b/articles/quickstart/spa/angular/files/logout.md
new file mode 100644
index 0000000000..126448a5e0
--- /dev/null
+++ b/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/articles/quickstart/spa/angular/files/main.md b/articles/quickstart/spa/angular/files/main.md
new file mode 100644
index 0000000000..75912e62eb
--- /dev/null
+++ b/articles/quickstart/spa/angular/files/main.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
+      }
+    }),
+  ]
+});
+```
diff --git a/articles/quickstart/spa/angular/files/profile.md b/articles/quickstart/spa/angular/files/profile.md
new file mode 100644
index 0000000000..562ec1280b
--- /dev/null
+++ b/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/articles/quickstart/spa/angular/files/user-profile.md b/articles/quickstart/spa/angular/files/user-profile.md
new file mode 100644
index 0000000000..711e1577df
--- /dev/null
+++ b/articles/quickstart/spa/angular/files/user-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) {}
+}
+```
diff --git a/articles/quickstart/spa/angular/index.yml b/articles/quickstart/spa/angular/index.yml
new file mode 100644
index 0000000000..69ed119319
--- /dev/null
+++ b/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/articles/quickstart/spa/angular/interactive.md b/articles/quickstart/spa/angular/interactive.md
new file mode 100644
index 0000000000..28dc113aa6
--- /dev/null
+++ b/articles/quickstart/spa/angular/interactive.md
@@ -0,0 +1,70 @@
+---
+title: Add Login to Your Angular Application
+description: This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Angular application using the Auth0 Angular SDK.
+interactive:  true
+files:
+ - files/main
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: Sample-01
+locale: en-US
+---
+
+# Add Login to Your Angular Application
+
+
+
        Visit the Angular Authentication By Example 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.
        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.
        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.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:4200.
        
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:4200.
        
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:4200.
        
+
+## Install the Auth0 Angular SDK
+
+
+
        Auth0 provides an Angular SDK 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:
        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.
        If you are using a custom domain with Auth0, the value of the domain property is the value of your custom domain instead of the value reflected in the "Settings" tab.
        
+
+## 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.
        Angular Step 4 Checkpoint 
        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 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.
        
+
+  
        
+
+  
        Sorry about that. Here are a few things to double check:
        • make sure you configured the correct authorizationParams.redirect_uri
        • make sure you added theLoginButtonComponent button to the module's declarations
        Still having issues? To get more help, check out our documentation or visit our community page.
        
+
+  
        
+
+## 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. 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, 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.
        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.
        Angular Step 5 checkpoint 
        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.
        
+
+  
        
+
+  
        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 for further errors
        Still having issues? To get more help, check out our documentation or visit our community page.
        
+
+  
        
+
+## 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 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.
        Angular Step 6 Checkpoint 
        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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
diff --git a/articles/quickstart/spa/angular2/01-login.md b/articles/quickstart/spa/angular2/01-login.md
deleted file mode 100644
index 473b4804c9..0000000000
--- a/articles/quickstart/spa/angular2/01-login.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '01-Login',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Angular 2+', callback: 'http://localhost:3000/callback' }) %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/angular2/02-user-profile.md b/articles/quickstart/spa/angular2/02-user-profile.md
deleted file mode 100644
index e8088ba6a5..0000000000
--- a/articles/quickstart/spa/angular2/02-user-profile.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch a user's information from Auth0
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '02-User-Profile',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_user_profile_preamble') %>
-
-## Request the Profile Scope
-
-To retrieve user information, request a scope of `openid profile` in the instance of the `auth0.WebAuth` object. 
-
-```ts
-// src/app/auth/auth.service.ts
-
-auth0 = new auth0.WebAuth({
-  // ...
-  scope: 'openid profile'
-});
-``` 
-
-## Make a Call for the User's Information
-
-<%= include('../_includes/_user_profile_auth0js_method') %>
-
-Add a method that calls the `client.userInfo` method to the `AuthService` service.
-
-```ts
-// src/app/auth/auth.service.ts
-
-// ...
-userProfile: any;
-
-//...
-public getProfile(cb): void {
-  const accessToken = localStorage.getItem('access_token');
-  if (!accessToken) {
-    throw new Error('Access Token must exist to fetch profile');
-  }
-
-  const self = this;
-  this.auth0.client.userInfo(accessToken, (err, profile) => {
-    if (profile) {
-      self.userProfile = profile;
-    }
-    cb(err, profile);
-  });
-}
-```
-
-<%= include('../_includes/_user_profile_in_memory') %>
-
-## Add a Profile Component
-
-Some applications have a dedicated profile section for displaying user information. The example below shows how to set it up. 
-
-Create a new component called `ProfileComponent`.
-
-```ts
-// src/app/profile/profile.component.ts
-
-import { Component, OnInit } from '@angular/core';
-import { AuthService } from './../auth/auth.service';
-
-@Component({
-  selector: 'app-profile',
-  templateUrl: './profile.component.html',
-  styleUrls: ['./profile.component.css']
-})
-export class ProfileComponent implements OnInit {
-
-  profile: any;
-
-  constructor(public auth: AuthService) { }
-
-  ngOnInit() {
-    if (this.auth.userProfile) {
-      this.profile = this.auth.userProfile;
-    } else {
-      this.auth.getProfile((err, profile) => {
-        this.profile = profile;
-      });
-    }
-  }
-
-}
-```
-
-The component injects the `AuthService` service. Then, it checks the service for a populated `userProfile` object. If it doesn't find the object, the component makes a call to `getProfile` to get the user's information.
-
-The user's information can be displayed in a template.
-
-```html
-
-
-
        
-  
        
-    
        Profile
        
-  
        
-  
        
-    avatar
-    
        
-      
-      
        {{ profile?.nickname }}
        
-    
        
-    
        {{ profile | json }}
        
-  
        
-
        
-```
-
-<%= include('../_includes/_user_profile_additional_info') %>
diff --git a/articles/quickstart/spa/angular2/03-calling-an-api.md b/articles/quickstart/spa/angular2/03-calling-an-api.md
deleted file mode 100644
index 5a72a14a20..0000000000
--- a/articles/quickstart/spa/angular2/03-calling-an-api.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: Calling an API
-description: This tutorial demonstrates how to make API calls for protected resources on your server
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '03-Calling-an-API',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_calling_api_preamble') %>
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Set the Audience and Scope in `auth0.WebAuth`
-
-In your `auth0.WebAuth` instance, enter your API identifier as the value for `audience`.
-Add your scopes to the `scope` key.
-
-```ts
-// src/app/auth/auth.service.ts
-
-auth0 = new auth0.WebAuth({
-  // ...
-  audience: '${apiIdentifier}',
-  scope: 'openid profile read:messages'
-});
-```
-
-<%= include('../_includes/_calling_api_use_rules') %>
-
-## Add `HttpClientModule`
-
-<%= include('../_includes/_calling_api_access_token') %>
-
-You can use the Angular HttpClientModule to attach JSON Web Tokens to requests you make with Angular's `HttpClient` class.
-
-Import the `HttpClientModule` in your AppModule:
-
-```ts
-// src/app/app.module.ts
-...
-import { HttpClientModule } from '@angular/common/http';
-
-@NgModule({
-  declarations: [...],
-  imports: [
-    ...,
-    HttpClientModule
-  ],
-  providers: [...],
-  bootstrap: [...]
-})
-```
-
-## Make Authenticated Calls with `HttpHeaders`
-
-You can now use `HttpClient` and `HttpHeaders` to make secure calls to your API from anywhere in the application.
-
-If you have an API that sends messages from the protected `/private` endpoint, you can create an API call. Set the `headers` option to a new instance of `HttpHeaders()` to attach an `Authorization` header with a value of `Bearer` and the Access token stored in local storage.
-
-```ts
-// src/app/ping/ping.component.ts
-
-import { HttpClient, HttpHeaders } from '@angular/common/http';
-import { map } from 'rxjs/operators';
-
-interface IApiResponse {
-  message: string;
-}
-
-// ...
-export class PingComponent {
-
-  API_URL: string = 'http:///api';
-  message: string;
-
-  constructor(public http: HttpClient) {}
-
-  public securedPing(): void {
-    this.message = '';
-    this.http
-      .get(`<%= "${this.API_URL}" %>/private`, {
-        headers: new HttpHeaders().set('Authorization', `Bearer <%= "${localStorage.getItem('access_token')}" %>`)
-      })
-      .subscribe(
-        data => this.message = data.message,
-        error => this.message = error
-      );
-  }
-
-  public securedScopedPing(): void {
-    this.message = '';
-    this.http
-      .get(`<%= "${this.API_URL}" %>/private-scoped`, {
-        headers: new HttpHeaders().set('Authorization', `Bearer <%= "${localStorage.getItem('access_token')}" %>`)
-    })
-      .subscribe(
-        data => this.message = data.message,
-        error => this.message = error
-      );
-    }
-}
-```
-
-::: note
-Alternatively, as of version 4.3 of Angular, you could use [HTTP interceptors](https://angular.io/api/common/http/HttpInterceptor) to attach the token to all outgoing HTTP requests.
-:::
-
-<%= include('../_includes/_calling_api_protect_resources') %>
diff --git a/articles/quickstart/spa/angular2/04-authorization.md b/articles/quickstart/spa/angular2/04-authorization.md
deleted file mode 100644
index b9352dedf6..0000000000
--- a/articles/quickstart/spa/angular2/04-authorization.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization and access control to your application
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '04-Authorization',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_authz_preamble') %>
-
-<%= include('../_includes/_authz_determining_scopes') %>
-
-## Handle Scopes in the `AuthService` Service
-
-Add a local member to your `AuthService` service and intialize it with all the scopes you want to request when users log in. Use this member when initializing your instance of the `auth0.WebAuth` object.
-
-```ts
-// src/app/auth/auth.service.ts
-
-requestedScopes: string = 'openid profile read:messages write:messages';
-
-auth0 = new auth0.WebAuth({
-  // ...
-  scope: this.requestedScopes
-});
-``` 
-
-<%= include('../_includes/_authz_set_session') %>
-
-```ts
-// src/app/auth/auth.service.ts
-
-private setSession(authResult): void {
-
-  const scopes = authResult.scope || this.requestedScopes || '';
-
-  // ...
-  localStorage.setItem('scopes', JSON.stringify(scopes));
-}
-```
-
-<%= include('../_includes/_authz_user_has_scopes') %>
-
-```ts
-// src/app/auth/auth.service.ts
-
-public userHasScopes(scopes: Array): boolean {
-  const grantedScopes = JSON.parse(localStorage.getItem('scopes')).split(' ');
-  return scopes.every(scope => grantedScopes.includes(scope));
-}
-```
-
-## Conditionally Display UI Elements
-
-You can use the `userHasScopes` method with the `isAuthenticated` method to show and hide certain UI elements.
-
-```html
-
-
-
-```
-
-## Protect Client-Side Routes
-
-You may want to give access to some routes in your application only to authenticated users. You can check if the user is authenticated with the `canActivate` hook.
-
-Create a new service called `AuthGuardService`.
-
-```ts
-// src/app/auth/auth-guard.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router, CanActivate } from '@angular/router';
-import { AuthService } from './auth.service';
-
-@Injectable()
-export class AuthGuardService implements CanActivate {
-
-  constructor(public auth: AuthService, public router: Router) {}
-
-  canActivate(): boolean {
-    if (!this.auth.isAuthenticated()) {
-      this.router.navigate(['']);
-      return false;
-    }
-    return true;
-  }
-
-}
-```
-
-In your route configuration, apply the `AuthGuardService` service to the `canActivate` hook for any routes you want to protect.
-
-```ts
-// src/app/app.routes.ts
-
-import { AuthGuardService as AuthGuard } from './auth/auth-guard.service';
-
-export const ROUTES: Routes = [
-  // ...
-  { path: 'profile', component: ProfileComponent, canActivate: [AuthGuard] },
-  { path: 'ping', component: PingComponent, canActivate: [AuthGuard] },
-];
-```
-
-The guard implements the `CanActivate` interface which requires the `canActivate` method in the service. This method returns `true` if the user is authenticated and `false` if they are not. It also navigates the user to the home route if they are not authenticated.
-
-### Limit Route Access Based on Scopes
-
-To prevent access to client-side routes based on a scope, create a service called `ScopeGuard`. This service uses Angular's   `ActivatedRouteSnapshot` to check for a set of `expectedScopes` passed in the `data` key of the route configuration.
-
-If the user does not have the `write:messages` scope, they are redirected to the main route.
-
-```ts
-// src/app/auth/scope-guard.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router, CanActivate, ActivatedRouteSnapshot } from '@angular/router';
-import { AuthService } from './auth.service';
-
-@Injectable()
-export class ScopeGuardService implements CanActivate {
-
-  constructor(public auth: AuthService, public router: Router) {}
-
-  canActivate(route: ActivatedRouteSnapshot): boolean {
-
-    const scopes = (route.data as any).expectedScopes;
-
-    if (!this.auth.isAuthenticated() || !this.auth.userHasScopes(scopes)) {
-      this.router.navigate(['']);
-      return false;
-    }
-    return true;
-  }
-
-}
-```
-
-```ts
-// src/app/app.routes.ts
-
-import { ScopeGuardService as ScopeGuard } from './auth/scope-guard.service';
-
-export const ROUTES: Routes = [
-  // ...
-  { path: 'admin', component: AdminComponent, canActivate: [ScopeGuard], data: { expectedScopes: ['write:messages']} },
-];
-```
-
-<%= include('../_includes/_authz_conditionally_assign_scopes') %>
-
-<%= include('../_includes/_authz_client_routes_disclaimer') %>
diff --git a/articles/quickstart/spa/angular2/05-token-renewal.md b/articles/quickstart/spa/angular2/05-token-renewal.md
deleted file mode 100644
index de13b37f33..0000000000
--- a/articles/quickstart/spa/angular2/05-token-renewal.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Token Renewal
-description: This tutorial demonstrates how to add automatic Access Token renewal to an application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '05-Token-Renewal',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_token_renewal_preamble') %>
-
-## Add Token Renewal
-
-To the `AuthService` service, add a method which calls the `checkSession` method from auth0.js. If the renewal is successful, use the existing `setSession` method to set the new tokens in local storage.
-
-```typescript
-// src/app/auth/auth.service.ts
-
-public renewToken() {
-  this.auth0.checkSession({}, (err, result) => {
-    if (err) {
-      console.log(err);
-    } else {
-      this.setSession(result);
-    }
-  });
-}
-```
-
-Add a method called `scheduleRenewal` to set up the time when authentication is silently renewed. 
-
-Define the `refreshSubscription` class property, which will hold a reference to the subscription that refreshes your token.
-
-```ts
-// src/app/auth/auth.service.ts
-export class AuthService {
-
-  // ..
-  // define the refreshSubscription property
-  refreshSubscription: any;
-
-  // ...
-  public scheduleRenewal() {
-    if (!this.isAuthenticated()) { return; }
-    this.unscheduleRenewal();
-
-    const expiresAt = JSON.parse(window.localStorage.getItem('expires_at'));
-
-    const expiresIn$ = Observable.of(expiresAt).pipe(
-      mergeMap(
-        expiresAt => {
-          const now = Date.now();
-          // Use timer to track delay until expiration
-          // to run the refresh at the proper time
-          return Observable.timer(Math.max(1, expiresAt - now));
-        }
-      )
-    );
-
-    // Once the delay time from above is
-    // reached, get a new JWT and schedule
-    // additional refreshes
-    this.refreshSub = expiresIn$.subscribe(
-      () => {
-        this.renewToken();
-        this.scheduleRenewal();
-      }
-    );
-  }
-
-  public unscheduleRenewal() {
-    if (this.refreshSub) {
-      this.refreshSub.unsubscribe();
-    }
-  }
-}
-```
-
-This lets you schedule token renewal any time. For example, you can schedule a renewal after the user logs in and then again, if the page is refreshed. 
-
-In the `setSession` method, add the function right after setting the `access_token` and `id_token` into local storage.
-
-```ts
-// src/app/auth/auth.service.ts
-
-private setSession(authResult): void {
-  // Set the time that the Access Token will expire at
-  const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + Date.now());
-
-  localStorage.setItem('access_token', authResult.accessToken);
-  localStorage.setItem('id_token', authResult.idToken);
-  localStorage.setItem('expires_at', expiresAt);
-
-  this.scheduleRenewal();
-}
-```
-
-Add a call to the `scheduleRenewal` method in the root app component to schedule a renewal when the page is refreshed.
-
-```ts
-// src/app/app.component.ts
-
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthentication();
-    auth.scheduleRenewal();
-  }
-
-}
-```
-
-Since client-side sessions should not be renewed after the user logs out, call the `unscheduleRenewal` method in the `logout` method to cancel the renewal.
-
-```ts
-// src/app/auth/auth.service.ts
-
-public logout(): void {
-  // Remove tokens and expiry time from localStorage
-  localStorage.removeItem('access_token');
-  localStorage.removeItem('id_token');
-  localStorage.removeItem('expires_at');
-  this.unscheduleRenewal();
-  // Go back to the home route
-  this.router.navigate(['/']);
-}
-```
-
-<%= include('../_includes/_token_renewal_troubleshooting') %>
-
diff --git a/articles/quickstart/spa/angular2/_includes/_centralized_login.md b/articles/quickstart/spa/angular2/_includes/_centralized_login.md
deleted file mode 100644
index 9b300dd54f..0000000000
--- a/articles/quickstart/spa/angular2/_includes/_centralized_login.md
+++ /dev/null
@@ -1,208 +0,0 @@
-<%= include('../../_includes/_login_preamble', { library: 'Angular 2+', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-angular-samples/tree/embedded-login/01-Embedded-Login'}) %>
-
-## Create an Authentication Service
-
-Create a service to manage and coordinate user authentication. You can give the service any name. In the examples below, the service is `AuthService` and the filename is `auth.service.ts`.
-
-In the service add an instance of the `auth0.WebAuth` object. When creating that instance, you can specify the following:
-<%= include('../../_includes/_auth_service_configure_client_details') %>
-
-::: note
-In this tutorial, the route is `/callback`, which is implemented in the [Add a Callback Component](#add-a-callback-component) step. 
-:::
-
-Add a `login` method that calls the `authorize` method from auth0.js.
-
-```ts
-// src/app/auth/auth.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router } from '@angular/router';
-import { filter } from 'rxjs/operators';
-import * as auth0 from 'auth0-js';
-
-@Injectable()
-export class AuthService {
-
-  auth0 = new auth0.WebAuth({
-    clientID: '${account.clientId}',
-    domain: '${account.namespace}',
-    responseType: 'token id_token',
-    audience: 'https://${account.namespace}/userinfo',
-    redirectUri: 'http://localhost:3000/callback',
-    scope: 'openid'
-  });
-
-  constructor(public router: Router) {}
-
-  public login(): void {
-    this.auth0.authorize();
-  }
-
-}
-```
-
-::: note
- **Checkpoint:** Try to call the `login` method from somewhere in your application to see the login page. For example, you can trigger the method from a button click or a lifecycle event.
- :::
- 
- ![hosted login](/media/articles/web/hosted-login.png)
- 
-### Finish the Service
-
-Add more methods to the `AuthService` service to handle authentication in the app.
-
-The example below shows the following methods:
-* `handleAuthentication`: looks for the result of authentication in the URL hash. Then, the result is processed with the `parseHash` method from auth0.js.
-* `setSession`: stores the user's Access Token, ID Token, and the Access Token's expiry time in browser storage.
-* `logout`: removes the user's tokens and expiry time from browser storage.
-* `isAuthenticated`: checks whether the expiry time for the user's Access Token has passed.
-
-```ts
-// src/app/auth/auth.service.ts
-
-// ...
-@Injectable()
-export class AuthService {
-
-  // ...
-  public handleAuthentication(): void {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        this.setSession(authResult);
-        this.router.navigate(['/home']);
-      } else if (err) {
-        this.router.navigate(['/home']);
-        console.log(err);
-      }
-    });
-  }
-
-  private setSession(authResult): void {
-    // Set the time that the Access Token will expire at
-    const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  public logout(): void {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // Go back to the home route
-    this.router.navigate(['/']);
-  }
-
-  public isAuthenticated(): boolean {
-    // Check whether the current time is past the
-    // Access Token's expiry time
-    const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-
-}
-```
-
-## Provide a Login Control
-
-Provide a template with controls for the user to log in and out.
-
-```html
-
-
-
-
-
        
-  
-
        
-```
-
-::: note
-This example uses Bootstrap styles. You can use any style library, or not use one at all.
-:::
-
-Depending on whether the user is authenticated or not, they see the **Log In** or **Log Out** button. The `click` events on the buttons make calls to the `AuthService` service to let the user log in or out. When the user clicks **Log In**, they are redirected to the login page. 
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Add a Callback Component
-
-When you use universal login, your users are taken away from your application. After they authenticate, they are automatically returned to your application and a client-side session is set for them. 
-
-::: note
-This example assumes you are using the default Angular path-based routing. If you are using hash-based routing with `{ useHash: true }`, you will not be able to specify a dedicated callback route. The URL hash will be used to hold the user's authentication information.
-:::
-
-<%= include('../../_includes/_callback_component') %>
-
-Create a component named `CallbackComponent` and add a loading indicator.
-
-::: note
-To display a loading indicator, you need a loading spinner or another indicator in the `assets` directory. See the downloadable sample for demonstration. 
-:::
-
-```html
-
-
-
        
-  loading
-
        
-```
-
-After authentication, your users are taken to the `/callback` route. They see the loading indicator while the application sets up a client-side session for them. After the session is set up, the users are redirected to the `/home` route.
-
-## Process the Authentication Result
-
-When a user authenticates at the login page, they are redirected to your application. Their URL contains a hash fragment with their authentication information. The `handleAuthentication` method in the `AuthService` service processes the hash. 
-
-Call the `handleAuthentication` method in your app's root component. The method processess the authentication hash while your app loads. 
-
-```ts
-// src/app/app.component.ts
-
-import { Component } from '@angular/core';
-import { AuthService } from './auth/auth.service';
-
-@Component({
-  selector: 'app-root',
-  templateUrl: './app.component.html',
-  styleUrls: ['./app.component.css']
-})
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthentication();
-  }
-
-}
-```
diff --git a/articles/quickstart/spa/angular2/custom-login-form.md b/articles/quickstart/spa/angular2/custom-login-form.md
deleted file mode 100644
index 0ec968bd87..0000000000
--- a/articles/quickstart/spa/angular2/custom-login-form.md
+++ /dev/null
@@ -1,215 +0,0 @@
----
-title: Custom Login Form
-description: This tutorial demonstrates how to add a custom login form to an Angular 2+ application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '02-Custom-Login-Form',
-  branch: 'embedded-login',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../_includes/_custom_login_preamble') %>
-
-<%= include('../_includes/_install_auth0js') %>
-
-## Create a Login Component
-
-Create a component to house the login form that should be used for your custom UI. In this example, the logic for all authentication transactions will be handled from the `AuthService`, which means the `LoginComponent` class only needs to inject that service.
-
-```js
-// src/app/login/login.component.ts
-
-import { Component } from '@angular/core';
-import { AuthService } from './../auth/auth.service';
-
-@Component({
-  selector: 'app-login',
-  templateUrl: './login.component.html',
-  styleUrls: ['./login.component.css']
-})
-export class LoginComponent {
-
-  constructor(public auth: AuthService) { }
-
-}
-```
-
-## Implement the Login Screen
-
-Create a template with a `form` which allows users to pass in their email and password. This example will not make full use of Angular's form features, but rather will simply use template variables on the username and password inputs. The values from those inputs will be passed into the methods called on the Log In and Sign Up button's `click` events. You may also supply a button to trigger social authentication.
-
-```html
-
-
-
        
-  
        
-    
-    
-  
        
-  
        
-    
-    
-  
        
-  
-  
-  
-
        
-```
-
-## Create an Authentication Service
-
-All authentication transactions should be handled from an injectable service. The service requires methods named `login`, `signup`, and `loginWithGoogle` which all make calls to the appropriate auth0.js methods to handle those actions. These methods are called from the `login` template above.
-
-The auth0.js methods for making authentication requests come from the `WebAuth` object. Create an instance of `auth0.WebAuth` and provide the domain, client ID, and callback URL for your application. A `responseType` of `token id_token` should also be specified.
-
-The `login` and `signup` methods should take the username and password input supplied by the user and pass it to the appropriate auth0.js methods. In the case of `login`, these values are passed to the `client.login` method. Since `client.login` is an XHR-based transaction, the authentication result is handled in a callback and the `setSession` method is called to set the user's `access_token`, `id_token`, and `access_token` expiry time in local storage if the transaction is successful.
-
-The `signup` method is a redirect-based flow and the authentication result is handled by the `handleAuthentication` method. This method looks for an `access_token` and `id_token` in the URL hash when the user is redirected back to the application. If the tokens are found, they are saved into local storage and the user is redirected to the home route.
-
-```js
-// src/app/auth/auth.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router } from '@angular/router';
-
-// Avoid name not found warnings
-declare var auth0: any;
-
-@Injectable()
-export class AuthService {
-
-  // Configure Auth0
-  auth0 = new auth0.WebAuth({
-    domain: ${account.namespace},
-    clientID: ${account.clientId},
-    redirectUri: 'http://localhost:4200/callback',
-    audience: `https://${account.namespace}/userinfo`,
-    responseType: 'token id_token'
-  });
-
-  constructor(private router: Router) { }
-
-  public login(username: string, password: string): void {
-    this.auth0.client.login({
-      realm: 'Username-Password-Authentication',
-      username,
-      password
-    }, (err, authResult) => {
-      if (err) {
-        alert(`Error: <%= "${err.description}" %>`);
-        return;
-      }
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-      }
-      this.router.navigate(['/home']);
-    });
-  }
-
-  public signup(email, password): void {
-    this.auth0.redirect.signupAndLogin({
-      connection: 'Username-Password-Authentication',
-      email,
-      password,
-    }, function (err) {
-      if (err) {
-        alert(`Error: <%= "${err.description}" %>`);
-      }
-    });
-  }
-
-  public loginWithGoogle(): void {
-    this.auth0.authorize({
-      connection: 'google-oauth2',
-    });
-  }
-
-  public handleAuthentication(): void {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        this.setSession(authResult);
-        this.router.navigate(['/home']);
-      } else if (err) {
-        this.router.navigate(['/home']);
-        alert(`Error: <%= "${err.error}" %>`); 
-      }
-    });
-  }
-
-  private setSession(authResult): void {
-    // Set the time that the Access Token will expire at
-    let expiresAt = JSON.stringify(
-      (authResult.expiresIn * 1000) + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  public logout(): void {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // Go back to the home route
-    this.router.navigate(['/home']);
-  }
-
-  public isAuthenticated(): boolean {
-    // Check whether the current time is past the 
-    // Access Token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-
-}
-```
-
-The service has several other utility methods that are necessary to complete authentication transactions.
-
-<%= include('../_includes/_custom_login_method_description') %>
-
-The `handleAuthentication` method needs to be called in the application's root component.
-
-```js
-// src/app/app.component.ts
-
-// ...
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthentication();
-  }
-
-}
-```
\ No newline at end of file
diff --git a/articles/quickstart/spa/angular2/dashboard-default.md b/articles/quickstart/spa/angular2/dashboard-default.md
deleted file mode 100644
index 4b40aa2039..0000000000
--- a/articles/quickstart/spa/angular2/dashboard-default.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add user login to your application with Auth0
----
-
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '01-Login',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000/callback
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
-
-
diff --git a/articles/quickstart/spa/angular2/embedded-login.md b/articles/quickstart/spa/angular2/embedded-login.md
deleted file mode 100644
index bc51838e8b..0000000000
--- a/articles/quickstart/spa/angular2/embedded-login.md
+++ /dev/null
@@ -1,251 +0,0 @@
----
-title: Embedded Login
-description: This tutorial demonstrates how to add user login to an Angular 2+ application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angular-samples',
-  path: '01-Embedded-Login',
-  branch: 'embedded-login',
-  requirements: [
-    'Angular 2+'
-  ]
-}) %>
-
-As an alternative to Auth0's universal login page, the Lock widget can be embedded directly in your application.
-
-<%= include('../_includes/_install_lock') %>
-
-The Lock widget can also be retrieved from Auth0's CDN.
-
-```html
-
-```
-
-## Create an Authentication Service
-
-The best way to manage and coordinate the tasks necessary for user authentication is to create a reusable service. With the service in place, you'll be able to call its methods throughout your application. The name for it is at your discretion, but in these examples it will be called `AuthService` and the filename will be `auth.service.ts`. An instance of the `Auth0Lock` can be created in the service.
-
-```ts
-// src/app/auth/auth.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router, NavigationStart } from '@angular/router';
-import { filter } from 'rxjs/operators';
-import Auth0Lock from 'auth0-lock';
-
-@Injectable()
-export class AuthService {
-
-  lock = new Auth0Lock(${account.clientId}, ${account.namespace}, {
-    autoclose: true,
-    auth: {
-      redirectUrl: 'http://localhost:3000/callback',
-      responseType: 'token id_token',
-      audience: `https://${account.namespace}/userinfo`,
-      params: {
-        scope: 'openid'
-      }
-    }
-  });
-
-  constructor(public router: Router) {}
-
-  public login(): void {
-    this.lock.show();
-  }
-
-  // Call this method in app.component
-  // if using path-based routing
-  public handleAuthentication(): void {
-    this.lock.on('authenticated', (authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-        this.router.navigate(['/']);
-      }
-    });
-    this.lock.on('authorization_error', (err) => {
-      this.router.navigate(['/']);
-      console.log(err);
-    });
-  }
-
-  private setSession(authResult): void {
-    // Set the time that the Access Token will expire at
-    const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  public logout(): void {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // Go back to the home route
-    this.router.navigate(['/']);
-  }
-
-  public isAuthenticated(): boolean {
-    // Check whether the current time is past the
-    // Access Token's expiry time
-    const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-
-}
-```
-
-<%= include('../_includes/_auth_service_methods') %>
-
-<%= include('../_includes/_auth_service_method_description_lock') %>
-
-## Provide a Login Control
-
-Provide a template with controls for the user to log in and log out.
-
-```html
-
-
-
-
-
        
-  
-
        
-```
-
-::: note
-This example uses Bootstrap styles, but that's unimportant. Use whichever style library you like, or don't use one at all.
-:::
-
-The `click` events on the **Log In** and **Log Out** buttons make the appropriate calls to the `AuthService` to allow the user to log in and log out. Notice that these buttons are conditionally hidden and shown depending on whether or not the user is currently authenticated.
-
-When the **Log In** button is clicked, the Lock widget will be shown.
-
-![embedded login](/media/articles/web/embedded-login.png)
-
-## Process the Authentication Result
-
-When users authenticate with the Lock widget, they are redirected back to your application with authentication information in the URL where it can be picked up and processed by Lock. The `handleAuthentication` method in the `AuthService` listens for the appropriate Lock events and sets the user's client-side session or logs an error to the console.
-
-Call `handleAuthentication` in your app's root component so that Lock's events can be listened for.
-
-```js
-// src/app/app.component.ts
-
-import { Component } from '@angular/core';
-import { AuthService } from './auth/auth.service';
-
-@Component({
-  selector: 'app-root',
-  templateUrl: './app.component.html',
-  styleUrls: ['./app.component.css']
-})
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthentication();
-  }
-
-}
-```
-
-## Add a Callback Component
-
-When users log in with the Lock widget, they will be redirected back to your application where Lock will process the result.
-
-<%= include('../_includes/_callback_component') %>
-
-Create a component named `CallbackComponent` and populate it with a loading indicator.
-
-```html
-
-
-
        
-  loading
-
        
-```
-
-:;: note
-This example assumes some kind of loading spinner is available in an `assets` directory. See the downloadable sample for a demonstration.
-:::
-
-The options that were passed to the `Auth0Lock` instance above include a `redirectUrl` set to the `/callback` route. This means that the user will be redirected to this newly created route after they authenticate with a redirect-based flow.
-
-## Using HashLocationStrategy
-
-Single page applications generally provide two ways to accomplish routing: with hashes or without hashes. The benefit to not uses hashes is that the URLs produced for the routes are cleaner, but this also requires some configuration on the server to make it work properly.
-
-Angular 2+ uses `PathLocationStrategy` by default, meaning that there will be no hash fragment in the URL when routes are produced. You can elect to use `HashLocationStrategy` if you like, but doing so will require a different way to handle the `authenticated` event fired by the Lock widget.
-
-If you are using `HashLocationStrategy`, use the following method to respond to authentication transactions instead of the `handleAuthentication` method defined above.
-
-```js
-// src/app/auth/auth.service.ts
-
-// Call this method in app.component
-// if using hash-based routing
-public handleAuthenticationWithHash(): void {
-  this
-    .router
-    .events
-    .pipe(
-      filter(event => event.constructor.name === 'NavigationStart'),
-      filter(event => (/access_token|id_token|error/).test(event.url))
-    )
-    .subscribe(() => {
-      this.lock.resumeAuth(window.location.hash, (error, authResult) => {
-        if (error) return console.log(error);
-        this.setSession(authResult);
-        this.router.navigate(['/']);
-      });
-  });
-}
-```
-
-This method uses the `resumeAuth` function from Lock to properly handle the hash fragment that is included with authentication results.
-
-Call the `handleAuthenticationWithHash` method in your `AppComponent`.
-
-```js
-// src/app/auth/auth.service.ts
-
-// ...
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthenticationWithHash();
-  }
-
-}
-```
diff --git a/articles/quickstart/spa/angular2/index.yml b/articles/quickstart/spa/angular2/index.yml
deleted file mode 100644
index ea6c7ce44f..0000000000
--- a/articles/quickstart/spa/angular2/index.yml
+++ /dev/null
@@ -1,23 +0,0 @@
-title: Angular 2+
-image: /media/platforms/angular.png
-alias:
-  - angular2
-  - angularjs
-language:
-  - Javascript
-framework:
-  - Angular 2
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/angular2/dependencies
-  setup: application-platforms/angular2/setup
-  use: application-platforms/angular2/use
-seo_alias: angular2
-default_article: dashboard-default
-articles:
-  - 01-login
-  - 02-user-profile
-  - 03-calling-an-api
-  - 04-authorization
-  - 05-token-renewal
diff --git a/articles/quickstart/spa/angularjs/01-login.md b/articles/quickstart/spa/angularjs/01-login.md
deleted file mode 100644
index e3973115cb..0000000000
--- a/articles/quickstart/spa/angularjs/01-login.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '01-Login',
-  requirements: [
-    'AngularJS 1.6'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'AngularJS', callback: 'http://localhost:3000/callback' }) %>
-
-<%= include('_includes/_install_angular_auth0') %>
-
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/angularjs/02-user-profile.md b/articles/quickstart/spa/angularjs/02-user-profile.md
deleted file mode 100644
index 7460e66874..0000000000
--- a/articles/quickstart/spa/angularjs/02-user-profile.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch a user's information from Auth0
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '02-User-Profile',
-  requirements: [
-    'AngularJS 1.6'
-  ]
-}) %>
-
-<%= include('../_includes/_user_profile_preamble') %>
-
-## Request the Profile Scope
-
-To retrieve user information, request a scope of `openid profile` in the `angularAuth0Provider` options. 
-
-```js
-// app/app.js
-
-angularAuth0Provider.init({
-  // ...
-  scope: 'openid profile'
-});
-``` 
-
-## Make a Call for the User's Information
-
-<%= include('../_includes/_user_profile_auth0js_method') %>
-
-Add a method that calls the `client.userInfo` method to the `authService` service.
-
-```js
-// app/auth/auth.service.js
-
-var userProfile;
-
-function getProfile(cb) {
-  var accessToken = localStorage.getItem('access_token');
-  if (!accessToken) {
-    throw new Error('Access Token must exist to fetch profile');
-  }
-  angularAuth0.client.userInfo(accessToken, function(err, profile) {
-    if (profile) {
-      setUserProfile(profile);
-    }
-    cb(err, profile);
-  });
-}
-
-function setUserProfile(profile) {
-  userProfile = profile;
-}
-
-function getCachedProfile() {
-  return userProfile;
-}
-```
-
-<%= include('../_includes/_user_profile_in_memory') %>
-
-## Add a Profile Component
-
-You can adjust how you show profile information to your users. Some applications have a dedicated profile section for displaying user information. The example below shows how to set it up. 
-
-Create a new controller and view to display the profile.
-
-```js
-// app/profile/profile.controller.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .controller('ProfileController', profileController);
-
-  profileController.$inject = ['authService'];
-
-  function profileController(authService) {
-
-    var vm = this;
-    vm.auth = authService;
-    vm.profile;
-
-    if (authService.getCachedProfile()) {
-      vm.profile = authService.getCachedProfile();
-    } else {
-      authService.getProfile(function(err, profile) {
-        vm.profile = profile;
-      });
-    }
-
-  }
-
-})();
-```
-
-```html
-
-
-
        
-  
        Profile
        
-  
        
-    avatar
-    
        
-      
-      
        {{ vm.profile.nickname }}
        
-    
        
-    
        {{ vm.profile | json }}
        
-  
        
-
        
-```
-
-The component first looks for a profile cached on the service. If it doesn't find the profile, the component calls the `getProfile` function to get the user's profile from Auth0.
-
-<%= include('../_includes/_user_profile_additional_info') %>
diff --git a/articles/quickstart/spa/angularjs/03-calling-an-api.md b/articles/quickstart/spa/angularjs/03-calling-an-api.md
deleted file mode 100644
index f1885e3cf5..0000000000
--- a/articles/quickstart/spa/angularjs/03-calling-an-api.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-title: Calling an API
-description: This tutorial demonstrates how to make API calls for protected resources on your server
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '03-Calling-an-API',
-  requirements: [
-    'AngularJS 1.6'
-  ]
-}) %>
-
-<%= include('../_includes/_calling_api_preamble') %>
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Set the Audience and Scope
-
-In the `angularAuth0Provider.init` call, enter your API identifier as the value for `audience`. Set the scopes in the `scope` parameter.
-
-```js
-// app/app.js
-
-angularAuth0Provider.init({
-  audience: '${apiIdentifier}',
-  scope: 'openid profile read:messages'
-});
-```
-
-<%= include('../_includes/_calling_api_use_rules') %>
-
-## Configure angular-jwt
-
-<%= include('../_includes/_calling_api_access_token') %>
-
-You can use the [angular-jwt](https://github.com/auth0/angular-jwt) module to automatically attach JSON Web Tokens to requests you make with Angular's `$http` service. 
-
-Install angular-jwt using npm or yarn.
-
-```bash
-# installation with npm
-npm install --save angular-jwt
-
-# installation with yarn
-yarn add angular-jwt
-```
-
-Reference the `angular-jwt` module from your application's main module. Inject `jwtOptionsProvider` and `$httpProvider`. In the provider, specify a `tokenGetter` function which retrieves the user's Access Token from local storage. The token can then be attached as an `Authorization` header. 
-
-Whitelist any domains you want to enable authenticated `$http` calls for. 
-Push `jwtInterceptor` into the `$httpProvider.interceptors` array.
-
-```js
-// app/app.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app', ['auth0.auth0', 'angular-jwt', 'ui.router'])
-    .config(config);
-
-  config.$inject = [
-    // ...
-    '$httpProvider',
-    'jwtOptionsProvider'
-  ];
-
-  function config(
-    // ...
-    $httpProvider,
-    jwtOptionsProvider
-  ) {
-
-    jwtOptionsProvider.config({
-      tokenGetter: function() {
-        return localStorage.getItem('access_token');
-      },
-      whiteListedDomains: ['localhost']
-    });
-
-    $httpProvider.interceptors.push('jwtInterceptor');
-  }
-
-})();
-```
-
-## Make Authenticated Calls with `$http`
-
-With `jwtInterceptor` in place, the user's Access Token is automatically attached to `$http` calls. 
-When you make `$http` calls, your protected API resources become accessible to the user. 
-
-```js
-// app/ping/ping.controller.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .controller('PingController', pingController);
-
-  pingController.$inject = ['$http', 'authService'];
-
-  function pingController($http, authService) {
-
-    var API_URL = 'http://localhost:3001/api';
-    var vm = this;
-    vm.auth = authService;
-    vm.message = '';
-
-    vm.securedPing = function() {
-      vm.message = '';
-      $http.get(API_URL + '/private').then(function(result) {
-        vm.message = result.data.message;
-      }, function(error) {
-        vm.message = error.data.message || error.data;
-      });
-    }
-
-  vm.securedScopedPing = function() {
-      vm.message = '';
-      $http.get(API_URL + '/private-scoped').then(function(result) {
-        vm.message = result.data.message;
-      }, function(error) {
-        vm.message = error.data.message || error.data;
-      });
-    }
-  }
-
-})();
-```
-
-::: note
-To learn more about configuration options for angular-jwt, see the [main project repo](https://github.com/auth0/angular-jwt).
-:::
-
-<%= include('../_includes/_calling_api_protect_resources') %>
diff --git a/articles/quickstart/spa/angularjs/04-authorization.md b/articles/quickstart/spa/angularjs/04-authorization.md
deleted file mode 100644
index c2c13f29ff..0000000000
--- a/articles/quickstart/spa/angularjs/04-authorization.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization and access control to your application
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '04-Authorization',
-  requirements: [
-    'AngularJS 1.6'
-  ]
-}) %>
-
-<%= include('../_includes/_authz_preamble') %>
-
-<%= include('../_includes/_authz_determining_scopes') %>
-
-## Handle Scopes in the `angularAuth0` Configuration
-
-Add a local variable to `app/app.js` and initialize it with all the scopes you want to request when users log in.
-
-Use that variable to set the scopes in the `angularAuth0Provider` initialization.
-
-```js
-// app/app.js
-
-var REQUESTED_SCOPES = 'openid profile read:messages write:messages';
-
-angularAuth0Provider.init({
-  // ...
-  scope: REQUESTED_SCOPES
-});
-``` 
-
-<%= include('../_includes/_authz_set_session') %>
-
-```js
-// app/auth/auth.service.js
-
-function setSession(authResult) {
-  // ...
-  var scopes = authResult.scope || REQUESTED_SCOPES || '';
-
-  localStorage.setItem('scopes', JSON.stringify(scopes));
-}
-```
-
-<%= include('../_includes/_authz_user_has_scopes') %>
-
-```js
-// app/auth/auth.service.js
-
-// ...
-function userHasScopes(scopes) {
-  var grantedScopes = JSON.parse(localStorage.getItem('scopes')).split(' ');
-  for (var i = 0; i < scopes.length; i++) {
-    if (grantedScopes.indexOf(scopes[i]) < 0) {
-      return false;
-    }
-  }
-  return true;
-}
-
-return {
-  // ...
-  userHasScopes: userHasScopes
-}
-```
-
-## Conditionally Display UI Elements
-
-You can use the `userHasScopes` method with the `isAuthenticated` method to show and hide certain UI elements.
-
-```html
-
-
-
-```
-
-## Protect Client-Side Routes
-
-You may want to give access to some routes in your application only to authenticated users. If you are using UI Router v1, you can check if the user is authenticated with the `onEnter` hook for a specific state.
-
-Define a function that uses the `authService` service to check if the user is authenticated. If the user is not authenticated, they are redirected to the home route. Use this function in the `onEnter` hook for any states you want to protect.
-
-```js
-// app/app.js
-
-$stateProvider
-  // ...
-  .state('ping', {
-    url: '/ping',
-    controller: 'PingController',
-    templateUrl: 'app/ping/ping.html',
-    controllerAs: 'vm',
-    onEnter: checkAuthentication
-  })
-
-// ...
-
-function checkAuthentication($transition$) {
-  var $state = $transition$.router.stateService;
-  var auth = $transition$.injector().get('authService');
-  if (!auth.isAuthenticated()) {
-    return $state.target('home');
-  }
-}
-```
-
-::: note
-In this example, when an unauthenticated user tries to access the `/ping` route, they are redirected to the `/home` route.
-:::
-
-### Limit Route Access Based on Scopes
-
-You can use the `onEnter` hook to prevent access to client-side routes based on scopes. Call a `checkForScopes` function that passes the scope you choose to the `userHasScopes` function from the `authService` service.
-
-If the user does not have the `write:messages` scope, they are redirected to the main route.
-
-```js
-// app/app.js
-
-$stateProvider
-  // ...
-  .state('admin', {
-    url: '/admin',
-    controller: 'AdminController',
-    templateUrl: 'app/admin/admin.html',
-    controllerAs: 'vm',
-    onEnter: checkForScopes(['write:messages'])
-  })
-
-function checkForScopes(scopes) {
-  return function checkAuthentication($transition$) {
-    var $state = $transition$.router.stateService;
-    var auth = $transition$.injector().get('authService');
-    if (!auth.isAuthenticated() || !auth.userHasScopes(scopes)) {
-      return $state.target('home');
-    }
-  }
-}
-```
-
-<%= include('../_includes/_authz_conditionally_assign_scopes') %>
-
-<%= include('../_includes/_authz_client_routes_disclaimer') %>
diff --git a/articles/quickstart/spa/angularjs/05-token-renewal.md b/articles/quickstart/spa/angularjs/05-token-renewal.md
deleted file mode 100644
index 77fcdb4334..0000000000
--- a/articles/quickstart/spa/angularjs/05-token-renewal.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Token Renewal
-description: This tutorial demonstrates how to add automatic Access Token renewal to an application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '05-Token-Renewal',
-  requirements: [
-    'Angular 1.6'
-  ]
-}) %>
-
-<%= include('../_includes/_token_renewal_preamble') %>
-
-## Add Token Renewal
-
-To the `authService` service, add a method  to call the `checkSession` method from auth0.js. If the renewal is successful, use the existing `setSession` method to set new tokens in local storage.
-
-```js
-// app/auth/auth.service.js
-
-function renewToken() {
-  angularAuth0.checkSession({},
-    function(err, result) {
-      if (err) {
-        console.log(err);
-      } else {
-        setSession(result);
-      }
-    }
-  );
-}
-```
-
-The Access Token should be renewed when it expires. In this tutorial, the expiry time of the token is stored in local storage as `expires_at`.
-
-Define a timing mechanism for renewing the Access Token. 
-
-::: note
-You can define any timing mechanism you want. You can choose any library that handles timers. This example shows how to use a `setTimeout` call. 
-:::
-
-In the `authService` service, add a property called `tokenRenewalTimeout`. The property refers to the `setTimeout` call used to schedule the renewal.
-
-Add a method called `scheduleRenewal` to set up the time when authentication is silently renewed.
-The method subtracts the current time from the Access Token's expiry time and calculates delay. 
-The `setTimeout` call uses the calculated delay and makes a call to `renewToken`.
-
-The `setTimeout` call is assigned to the `tokenRenewalTimeout` property. When the user logs out, the timeout is cleared. 
-
-```js
-// app/auth/auth.service.js
-
-var tokenRenewalTimeout
-// ...
-function scheduleRenewal() {
-  var expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-  var delay = expiresAt - Date.now();
-  if (delay > 0) {
-    tokenRenewalTimeout = setTimeout(function() {
-      renewToken();
-    }, delay);
-  }
-}
-```
-
-You can now include a call to the `scheduleRenewal` method in the `setSession` method.
-
-```js
-// app/auth/auth.service.js
-
-// ...
-function setSession(authResult) {
-  // Set the time that the Access Token will expire at
-  let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-  localStorage.setItem('access_token', authResult.accessToken);
-  localStorage.setItem('id_token', authResult.idToken);
-  localStorage.setItem('expires_at', expiresAt);
-
-  // schedule a token renewal
-  scheduleRenewal();
-}
-```
-
-To schedule renewing the tokens when the page is refreshed, in the application's `run` block, add a call to the `scheduleRenewal` method.
-
-```js
-// app/app.run.js
-
-angular
-  .module('app')
-  .run(run);
-  
-function run(authService) {
-  // ...
-
-  // Schedule the token to be renewed
-  authService.scheduleRenewal();
-}
-```
-
-Since client-side sessions should not be renewed after the user logs out, call `unscheduleRenewal` in the `logout` method to cancel the renewal.
-
-```js
-// app/auth/auth.service.js
-
-function logout() {
-  // Remove tokens and expiry time from localStorage
-  localStorage.removeItem('access_token');
-  localStorage.removeItem('id_token');
-  localStorage.removeItem('expires_at');
-  clearTimeout(tokenRenewalTimeout);
-  $state.go('home');
-}
-```
-
-<%= include('../_includes/_token_renewal_troubleshooting') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/angularjs/_includes/_centralized_login.md b/articles/quickstart/spa/angularjs/_includes/_centralized_login.md
deleted file mode 100644
index 2738cfa640..0000000000
--- a/articles/quickstart/spa/angularjs/_includes/_centralized_login.md
+++ /dev/null
@@ -1,274 +0,0 @@
-
-<%= include('../../_includes/_login_preamble', { library: 'AngularJS', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-angularjs-samples/tree/embedded-login/01-Embedded-Login' }) %>
-
-## Configure angular-auth0
-
-The angular-auth0 wrapper comes with a provider called `angularAuth0Provider`. The provider has an `init` method which takes a configuration object used to create an instance of the `WebAuth` object from auth0.js. 
-
-Inject the `angularAuth0Provider` provider. 
-In the options object you pass to `angularAuth0Provider.init`, include the following information:
-<%= include('../../_includes/_auth_service_configure_client_details') %>
-
-::: note
-In this tutorial, the route is `/callback`, which is implemented in the [Add a Callback Component](#add-a-callback-component) step. 
-:::
-
-```js
-// app/app.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app', ['auth0.auth0', 'ui.router'])
-    .config(config);
-
-  config.$inject = [
-    '$stateProvider',
-    '$locationProvider',
-    '$urlRouterProvider',
-    'angularAuth0Provider'
-  ];
-
-  function config(
-    $stateProvider,
-    $locationProvider,
-    $urlRouterProvider,
-    angularAuth0Provider
-  ) {
-
-    $stateProvider
-      .state('home', {
-        url: '/',
-        controller: 'HomeController',
-        templateUrl: 'app/home/home.html',
-        controllerAs: 'vm'
-      })
-      .state('callback', {
-        url: '/callback',
-        controller: 'CallbackController',
-        templateUrl: 'app/callback/callback.html',
-        controllerAs: 'vm'
-      });
-
-    // Initialization for the angular-auth0 library
-    angularAuth0Provider.init({
-      clientID: '${account.clientId}',
-      domain: '${account.namespace}',
-      responseType: 'token id_token',
-      audience: 'https://${account.namespace}/userinfo',
-      redirectUri: 'http://localhost:3000/callback',
-      scope: 'openid'
-    });
-
-    $urlRouterProvider.otherwise('/');
-
-    $locationProvider.hashPrefix('');
-
-    /// Comment out the line below to run the app
-    // without HTML5 mode (will use hashes in routes)
-    $locationProvider.html5Mode(true);
-  }
-
-})();
-```
-
-## Create an Authentication Service
-
-Create a reusable service to manage and coordinate user authentication. You can call the service's methods from your application. 
-
-::: note
-You can give the service any name. In the examples below, the service is `authService` and the filename is `auth.service.js`.
-:::
-
-Create a service and provide a `login` method that calls the `authorize` method from angular-auth0.
-
-```js
-// app/auth/auth.service.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .service('authService', authService);
-
-  authService.$inject = ['$state', 'angularAuth0', '$timeout'];
-
-  function authService($state, angularAuth0, $timeout) {
-
-    function login() {
-      angularAuth0.authorize();
-    }
-
-    return {
-      login: login
-    }
-  }
-})();
-```
-
-::: note
-**Checkpoint:** Try to call the `login` method from somewhere in your application to see the login page.
-:::
-
-
-![hosted login](/media/articles/web/hosted-login.png)
-
-### Finish the Service
-
-Add more methods to the `authService` service to handle authentication in the app.
-
-The example below shows the following methods:
-* `handleAuthentication`: looks for the result of authentication in the URL hash. Then, the result is processed with the `parseHash` method from auth0.js
-* `setSession`: sets the user's Access Token and ID Token, and the Access Token's expiry time 
-* `logout`: removes the user's tokens and expiry time from browser storage
-* `isAuthenticated`: checks whether the expiry time for the user's Access Token has passed
-
-```js
-// app/auth/auth.service.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .service('authService', authService);
-
-  authService.$inject = ['$state', 'angularAuth0', '$timeout'];
-
-  function authService($state, angularAuth0, $timeout) {
-
-    // ...    
-    function handleAuthentication() {
-      angularAuth0.parseHash(function(err, authResult) {
-        if (authResult && authResult.accessToken && authResult.idToken) {
-          setSession(authResult);
-          $state.go('home');
-        } else if (err) {
-          $timeout(function() {
-            $state.go('home');
-          });
-          console.log(err);
-        }
-      });
-    }
-
-    function setSession(authResult) {
-      // Set the time that the Access Token will expire at
-      let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-      localStorage.setItem('access_token', authResult.accessToken);
-      localStorage.setItem('id_token', authResult.idToken);
-      localStorage.setItem('expires_at', expiresAt);
-    }
-    
-    function logout() {
-      // Remove tokens and expiry time from localStorage
-      localStorage.removeItem('access_token');
-      localStorage.removeItem('id_token');
-      localStorage.removeItem('expires_at');
-    }
-    
-    function isAuthenticated() {
-      // Check whether the current time is past the 
-      // Access Token's expiry time
-      let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-      return new Date().getTime() < expiresAt;
-    }
-
-    return {
-      // ...
-      handleAuthentication: handleAuthentication,
-      logout: logout,
-      isAuthenticated: isAuthenticated
-    }
-  }
-})();
-```
-
-## Provide a Login Control
-
-Provide a component with controls for the user to log in and log out.
-
-${snippet(meta.snippets.use)}
-
-::: note
-This example uses Bootstrap styles. You can use any style library, or not use one at all.
-:::
-
-Depending on whether the user is authenticated or not, they see the **Log Out** or **Log In** button. The `ng-click` events on the buttons make calls to the `authService` service to let the user log in or out. When the user clicks **Log In**, they are redirected to the login page. 
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Add a Callback Component
-
-When you use the login page, your users are taken away from your application. After they authenticate, they are automatically returned to your application and a client-side session is set for them. 
-
-::: note
-This example assumes you are using path-based routing by setting `$locationProvider.html5Mode(true)`. If you are using hash-based routing, you will not be able to specify a dedicated callback route. The URL hash will be used to hold the user's authentication information.
-:::
-
-<%= include('../../_includes/_callback_component') %>
-
-Create a controller and a template to use for a callback route. Add a loading indicator.
-
-::: note
-To display a loading indicator, you need a loading spinner or another indicator in the `assests` directory. See the downloadable sample for demonstration. 
-:::
-
-```js
-// app/callback/callback.controller.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .controller('CallbackController', callbackController);
-
-  function callbackController() {}
-
-})();
-```
-
-```html
-
-
-
        
-  loading
-
        
-```
-
-After authentication, your users are taken to the `/callback` route. They see the loading indicator while the application sets up a client-side session for them. After the session is set up, the users are redirected to the `/home` route.
-
-## Process the Authentication Result
-
-When a user authenticates at the login page, they are redirected to your application. Their URL contains a hash fragment with their authentication information. The `handleAuthentication` method in the `authService` service processes the hash. 
-
-Call the `handleAuthentication` method in your app's run block. The method processess the authentication hash while your app loads. 
-
-```js
-// app/app.run.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .run(run);
-
-  run.$inject = ['authService'];
-    
-  function run(authService) {
-    // Handle the authentication
-    // result in the hash
-    authService.handleAuthentication();
-  }
-
-})();
-```
diff --git a/articles/quickstart/spa/angularjs/_includes/_install_angular_auth0.md b/articles/quickstart/spa/angularjs/_includes/_install_angular_auth0.md
deleted file mode 100644
index 21ed9547e8..0000000000
--- a/articles/quickstart/spa/angularjs/_includes/_install_angular_auth0.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## Install angular-auth0
-
-To use auth0.js in your AngularJS application, you need a thin wrapper called angular-auth0.
-
-Install angular-auth0 using npm or yarn.
-
-```bash
-# installation with npm
-npm install --save angular-auth0
-
-# installation with yarn
-yarn add angular-auth0
-```
-
-Once you install angular-auth0, add it to your build system or bring it in to your project as a script tag.
-
-```html
-
-```
diff --git a/articles/quickstart/spa/angularjs/dashboard-default.md b/articles/quickstart/spa/angularjs/dashboard-default.md
deleted file mode 100644
index 9f85702f12..0000000000
--- a/articles/quickstart/spa/angularjs/dashboard-default.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Auth0 AngularJS Tutorial
-default: true
-description: This tutorial demonstrates how to use the Auth0 with AngularJS applications
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-angularjs-samples',
-  path: '01-Login',
-  requirements: [
-    'Angular 1.6'
-  ]
-}) %>
-
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000/callback
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_install_angular_auth0') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/angularjs/index.yml b/articles/quickstart/spa/angularjs/index.yml
deleted file mode 100644
index 61738dbf45..0000000000
--- a/articles/quickstart/spa/angularjs/index.yml
+++ /dev/null
@@ -1,24 +0,0 @@
-title: AngularJS
-alias:
-  - angular
-  - angularjs
-  - angular-1
-language:
-  - Javascript
-framework:
-  - AngularJS
-image: /media/platforms/angular.png
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/angularjs/dependencies
-  setup: application-platforms/angularjs/setup
-  use: application-platforms/angularjs/use
-seo_alias: angularjs
-default_article: dashboard-default
-articles:
-  - 01-login
-  - 02-user-profile
-  - 03-calling-an-api
-  - 04-authorization
-  - 05-token-renewal
diff --git a/articles/quickstart/spa/aurelia/01-login.md b/articles/quickstart/spa/aurelia/01-login.md
deleted file mode 100644
index d5cc385c02..0000000000
--- a/articles/quickstart/spa/aurelia/01-login.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-aurelia-samples',
-  path: '01-Login',
-  requirements: [
-    'Aurelia 1.1'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Aurelia', callback: 'http://localhost:3000/callback' }) %>
-
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/aurelia/_includes/_centralized_login.md b/articles/quickstart/spa/aurelia/_includes/_centralized_login.md
deleted file mode 100644
index 90be16f14b..0000000000
--- a/articles/quickstart/spa/aurelia/_includes/_centralized_login.md
+++ /dev/null
@@ -1,202 +0,0 @@
-<%= include('../../_includes/_login_preamble', { library: 'Aurelia' }) %>
-
-## Create an Authentication Service
-
-The best way to manage and coordinate the tasks necessary for user authentication is to create a reusable service. With the service in place, you'll be able to call its methods throughout your application. The name for it is at your discretion, but in these examples it will be called `AuthService` and the filename will be `auth-service.js`. An instance of the `WebAuth` object from **auth0.js** can be created in the service.
-
-Create a service and instantiate `auth0.WebAuth`. Provide a method called `login` which calls the `authorize` method from auth0.js.
-
-```js
-// src/auth-service.js
-
-import auth0 from 'auth0-js';
-
-export class AuthService {
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:3000/callback',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  login() {
-    this.auth0.authorize();
-  }
-```
-
-::: note
-**Checkpoint:** Try calling the `login` method from somewhere in your application. This could be from a button click or in some lifecycle event, just something that will trigger the method so you can see the login page.
-:::
-
-![hosted login](/media/articles/web/hosted-login.png)
-
-### Finish Out the Service
-
-Add some additional methods to the `Auth` service to fully handle authentication in the app. Use the `inject` decorator to inject `Router`.
-
-```js
-// src/auth-service.js
-
-import { inject } from 'aurelia-framework';
-import { Router } from 'aurelia-router';
-import EventEmitter from 'EventEmitter';
-
-@inject(Router)
-export class AuthService {
-  // ...
-  authNotifier = new EventEmitter();
-
-  constructor(Router) {
-    this.router = Router;
-  }
-
-  handleAuthentication() {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-        this.router.navigate('home');
-        this.authNotifier.emit('authChange', { authenticated: true });
-      } else if (err) {
-        console.log(err);
-      }
-    });
-  }
-
-  setSession(authResult) {
-    // Set the time that the Access Token will expire at
-    let expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  logout() {
-    // Clear Access Token and ID Token from local storage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    this.router.navigate('home');
-    this.authNotifier.emit('authChange', false);
-  }
-
-  isAuthenticated() {
-    // Check whether the current time is past the
-    // Access Token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-}
-```
-
-The service now includes several other methods for handling authentication.
-
-* `handleAuthentication` - looks for an authentication result in the URL hash and processes it with the `parseHash` method from auth0.js
-* `setSession` - sets the user's `access_token`, `id_token`, and a time at which the `access_token` will expire
-* `logout` - removes the user's tokens from browser storage
-* `isAuthenticated` - checks whether the expiry time for the `access_token` has passed
-
-### About the Authentication Service
-
-<%= include('../../_includes/_auth_service_method_description_auth0js') %>
-
-## Provide a Login Control
-
-Provide a component with controls for the user to log in and log out.
-
-${snippet(meta.snippets.use)}
-
-::: note
-This example uses Bootstrap styles, but that's unimportant. Use whichever style library you like, or don't use one at all.
-:::
-
-The `click.delegate` events on the **Log In** and **Log Out** buttons make the appropriate calls to the `AuthService` to allow the user to log in and log out. Notice that these buttons are conditionally hidden and shown depending on whether or not the user is currently authenticated.
-
-When the **Log In** button is clicked, the user will be redirected to the login page.
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Add a Callback Component
-
-Using universal login means that users are taken away from your application to a login page hosted by Auth0. After they successfully authenticate, they are returned to your application where a client-side session is set for them.
-
-<%= include('../../_includes/_callback_component') %>
-
-When a user authenticates at the login page and is then redirected back to your application, their authentication information will be contained in a URL hash fragment. The `handleAuthentication` method in the `AuthService` is responsbile for processing the hash.
-
-Create a component named `CallbackComponent` and populate it with a loading indicator. The component should also call `handleAuthentication` from the `AuthService`.
-
-```html
-
-
-
-```
-
-```js
-// src/callback.js
-
-import { inject } from 'aurelia-framework';
-import { AuthService } from './auth-service';
-
-@inject(AuthService)
-export class Callback {
-  constructor(AuthService) {
-    this.auth = AuthService;
-    this.auth.handleAuthentication();
-  }
-}
-```
-
-::: note
-This example assumes some kind of loading spinner is available in the `assets` directory. See the downloadable sample for a demonstration.
-:::
-
-### Configure Routing
-
-Add routing configuration using `configureRouter` to the application's main module.
-
-```js
-// src/app.js
-
-export class App {
-  // ...
-  configureRouter(config, router) {
-    config.options.pushState = true;
-    config.map([
-      {
-        route: ['', 'home'],
-        name: 'home',
-        moduleId: PLATFORM.moduleName('./home'),
-        nav: true,
-        title: 'Home'
-      },
-      {
-        route: 'callback',
-        name: 'callback',
-        moduleId: PLATFORM.moduleName('./callback'),
-        nav: false,
-        title: 'Callback'
-      }
-    ]);
-
-    this.router = router;
-  }
-}
-```
-
-After authentication, users will be taken to the `/callback` route for a brief time where they will be shown a loading indicator. During this time, their client-side session will be set, after which they will be redirected to the `/home` route.
-
-::: note
-This example assumes you are using path-based routing with `config.options.pushState = true`. If you are using hash-based routing, you won't be able to specify a dedicated callback route because the URL hash will be used to hold the user's authentication information.
-:::
-
-## Embedded Login
-
-Auth0's universal login provides the fastest, most secure, and most feature-rich way to implement authentication in your app. If required, the Lock widget can also be embedded directly into your application, but certain features such as single sign-on won't be accessible. It is highly recommended that you use the login page (as covered in this tutorial), but if you wish to embed the Lock widget directly in your application, follow the [Embedded Login sample](https://github.com/auth0-community/auth0-aurelia-samples/tree/embedded-login/01-Embedded-Login).
diff --git a/articles/quickstart/spa/aurelia/dashboard-default.md b/articles/quickstart/spa/aurelia/dashboard-default.md
deleted file mode 100644
index 64c4405dc0..0000000000
--- a/articles/quickstart/spa/aurelia/dashboard-default.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add user login to your application with Auth0
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-aurelia-samples',
-  path: '01-Login',
-  requirements: [
-    'Aurelia 1.1'
-  ]
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000/callback
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/aurelia/index.yml b/articles/quickstart/spa/aurelia/index.yml
deleted file mode 100644
index 408347ec47..0000000000
--- a/articles/quickstart/spa/aurelia/index.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-title: Aurelia
-author:
-  community: true
-alias:
-  - aurelia
-  - aureliajs
-language:
-  - Javascript
-framework:
-  - Aurelia
-image:
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/aurelia/dependencies
-  setup: application-platforms/aurelia/setup
-  use: application-platforms/aurelia/use
-seo_alias: aurelia
-default_article: dashboard-default
-articles:
-  - 01-login
diff --git a/articles/quickstart/spa/config.yml b/articles/quickstart/spa/config.yml
index eb392cb9c6..51f64e8751 100644
--- a/articles/quickstart/spa/config.yml
+++ b/articles/quickstart/spa/config.yml
@@ -1,44 +1,2 @@
-next_steps:
-  - path: 01-login
-    list:
-    - text: Configure other identity providers
-      icon: 350
-      href: "/identityproviders"
-    - text: Enable multifactor authentication
-      icon: 345
-      href: "/multifactor-authentication"
-    - text: Learn about anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-    - text: Learn about options for storing tokens
-      icon: 345
-      href: "/security/store-tokens"
-  - path: 02-user-profile
-    list:
-    - text: Learn about the user profile structure
-      icon: 350
-      href: "/user-profile/normalized/oidc"
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-    - text: In-depth details about user profile
-      icon: 345
-      href: "/user-profile/user-profile-details"
-  - path: 03-calling-an-api
-    list:
-    - text: Learn about custom APIs
-      icon: 350
-      href: "/api"
-    - text: Introduction to API authorization
-      icon: 345
-      href: "/api-auth"
-  - path: 04-authorization
-    list:
-    - text: Learn about scopes
-      icon: 345
-      href: "/scopes"
-  - path: 05-token-renewal
-    list:
-    - text: Learn about token renewal
-      icon: 345
-      href: "/api-auth/tutorials/silent-authentication"
\ No newline at end of file
+sample_download_required_data:
+  - client
diff --git a/articles/quickstart/spa/cyclejs/01-login.md b/articles/quickstart/spa/cyclejs/01-login.md
deleted file mode 100644
index 87ad8631d0..0000000000
--- a/articles/quickstart/spa/cyclejs/01-login.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial will show you how to use the Auth0 Cycle.js driver to add authentication and authorization to your web app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-cycle-samples',
-  path: '04-User-Profile',
-  requirements: [
-    'NodeJS 6.3',
-    'npm 3.10.3',
-    '@cycle/xstream-run 3.0.3',
-    'cyclejs-auth0 3.0.0'
-  ]
-}) %>
-
-<%= include('../_callback') %>
-
-## 1. Install the `cyclejs-auth0` Package
-
-To install `cyclejs-auth0` from the command line, run:
-
-${snippet(meta.snippets.dependencies)}
-
-## 2. Instantiate the Driver and Configure Auth0Lock
-
-In your main application file, you can now setup the `auth0Driver` and feed it your `clientID` and `domain`:
-
-${snippet(meta.snippets.setup)}
-
-## 3. Implement the Login
-
-Now that everything is set, you can activate authentication on some of your components. Activating authentication on a component is as simple as calling the `protect` function on that component.
-Let's assume you have a `Todos` component and you want to ensure the user is logged in to see it.
-
-${snippet(meta.snippets.use)}
-
-Now if the user is not logged in when the component is instantiated, the Auth0 form will show up.
-
-## 4. Configuring the Login Form
-
-You may want to configure the behavior of the Auth0 login form. To achieve that, you can use the `auth0ShowParams` options on the `protect` function:
-
-${snippet(meta.snippets.configure)}
-
-It defaults to:
-
-```js
-{
-    authParams: { scope: "openid" },
-    responseType: "token"
-}
-```
-
-All the available configurable parameters are supported, see [User configurable options](/libraries/lock/v10/customization).
-
-After authentication, the `protect` function will handle the token parsing and store it to `localStorage`.
-
-## 4. Retrieve and display the User's Information
-
-Once a component is protected, it is given a `props` object that contains a `tokens$` stream that can be used to either:
-- be decoded to get some basic information about your user (sub, nickname ... depending on your `authParams.scope` setting);
-- send a `getUserInfo` request to the Auth0 lock to retrieve a full profile.
-
-${snippet(meta.snippets.query)}
-
-```html
-
        Welcome 
        
-```
-
-To discover all the available properties of a user's profile, see [Auth0 Normalized User Profile](/user-profile). Note that the properties available depend on the social provider used.
-
-## 5. Implement the Logout
-
-To log out, you simply need to send the `logout` action to the Auth0 driver.
-
-${snippet(meta.snippets.logout)}
-
-<%= include('../_includes/_persisting_state') %>
diff --git a/articles/quickstart/spa/cyclejs/index.yml b/articles/quickstart/spa/cyclejs/index.yml
deleted file mode 100644
index 2a332084bb..0000000000
--- a/articles/quickstart/spa/cyclejs/index.yml
+++ /dev/null
@@ -1,24 +0,0 @@
-title: Cycle
-author:
-  community: true
-alias:
-  - cyclejs
-language:
-  - JavaScript
-framework:
-  - Cycle.js
-image: /media/platforms/cyclejs.svg
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/cyclejs/dependencies
-  setup: application-platforms/cyclejs/setup
-  configure: application-platforms/cyclejs/configure
-  securize: application-platforms/cyclejs/securize
-  query: application-platforms/cyclejs/query
-  use: application-platforms/cyclejs/use
-  logout: application-platforms/cyclejs/logout
-seo_alias: cyclejs
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/spa/ember/01-login.md b/articles/quickstart/spa/ember/01-login.md
deleted file mode 100644
index 0bfcff992e..0000000000
--- a/articles/quickstart/spa/ember/01-login.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-ember-samples',
-  path: '01-Login'
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Ember', callback: 'http://localhost:3000' }) %>
-
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/ember/_includes/_centralized_login.md b/articles/quickstart/spa/ember/_includes/_centralized_login.md
deleted file mode 100644
index a77de48573..0000000000
--- a/articles/quickstart/spa/ember/_includes/_centralized_login.md
+++ /dev/null
@@ -1,226 +0,0 @@
-<%= include('../../_includes/_login_preamble', { library: 'Ember' }) %>
-
-## Create an Authentication Service
-
-The best way to manage and coordinate the tasks necessary for user authentication is to create a reusable service. With the service in place, you'll be able to call its methods throughout your application. The name for it is at your discretion, but in these examples it will be called `auth` and the filename will be `auth.js`. An instance of the `WebAuth` object from **auth0.js** can be created in the service.
-
-Create a service and instantiate `auth0.WebAuth`. Provide a method called `login` which calls the `authorize` method from auth0.js.
-
-```js
-// app/services/auth.js
-
-import Ember from 'ember';
-import config from 'auth0-ember-samples/config/environment';
-
-const {
-  computed,
-  Service,
-  get
-} = Ember;
-
-export default Service.extend({
-  auth0: computed(function () {
-    return new auth0.WebAuth({
-      domain: '${account.namespace}',
-      clientID: '${account.clientId}',
-      redirectUri: 'http://localhost:3000',
-      audience: 'https://${account.namespace}/userinfo',
-      responseType: 'token id_token',
-      scope: 'openid'
-    });
-  }),
-
-  login() {
-    get(this, 'auth0').authorize();
-  }
-});
-```
-
-::: note
-**Checkpoint:** Try calling the `login` method from somewhere in your application. This could be from a button click or in some lifecycle event, just something that will trigger the method so you can see the login page.
-:::
-
-![hosted login](/media/articles/web/hosted-login.png)
-
-### Finish Out the Authentication Functions
-
-Add some additional methods to the `auth` service to fully handle authentication in the app.
-
-```js
-// app/services/auth.js
-
-import Ember from 'ember';
-import config from 'auth0-ember-samples/config/environment';
-
-const {
-  computed,
-  Service,
-  get,
-  RSVP,
-  isPresent,
-} = Ember;
-
-export default Service.extend({
-
-  // ...
-  handleAuthentication() {
-    return new RSVP.Promise((resolve, reject) => {
-      get(this, 'auth0').parseHash((err, authResult) => {
-        if (authResult && authResult.accessToken && authResult.idToken) {
-          this.setSession(authResult);
-        } else if (err) {
-          return reject(err);
-        }
-
-        return resolve();
-      });
-    });
-  },
-
-  isAuthenticated: computed(function() {
-    return isPresent(this.getSession().access_token) && this.isNotExpired();
-  }).volatile(),
-
-  getSession() {
-    return {
-      access_token: localStorage.getItem('access_token'),
-      id_token: localStorage.getItem('id_token'),
-      expires_at: localStorage.getItem('expires_at')
-    };
-  },
-
-  setSession(authResult) {
-    if (authResult && authResult.accessToken && authResult.idToken) {
-      // Set the time that the Access Token will expire at
-      let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-      localStorage.setItem('access_token', authResult.accessToken);
-      localStorage.setItem('id_token', authResult.idToken);
-      localStorage.setItem('expires_at', expiresAt);
-    }
-  },
-
-  logout() {
-    // Clear Access Token and ID Token from local storage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-  },
-
-  isNotExpired() {
-    // Check whether the current time is past the
-    // Access Token's expiry time
-    let expiresAt = this.getSession().expires_at;
-    return new Date().getTime() < expiresAt;
-  }
-});
-
-```
-
-The file now includes several other methods for handling authentication.
-
-* `handleAuthentication` - looks for an authentication result in the URL hash and processes it with the `parseHash` method from auth0.js
-* `setSession` - sets the user's `access_token`, `id_token`, and a time at which the `access_token` will expire
-* `logout` - removes the user's tokens from browser storage
-* `isAuthenticated` - checks whether the expiry time for the `access_token` has passed
-
-### About the Authentication Service
-
-<%= include('../../_includes/_auth_service_method_description_auth0js') %>
-
-## Provide a Login Control
-
-Provide a template with controls for the user to log in and log out.
-
-```html
-
-
-
        
-  
-
        
-```
-
-The `action` added to the **Log In** control makes the appropriate call to the `login` method in `auth.js` to allow the user to log in. When the **Log In** control is clicked, the user will be redirected to the login page.
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Process the Authentication Result
-
-When a user authenticates at the login page and is then redirected back to your application, their authentication information will be contained in a URL hash fragment. The `handleAuthentication` function in `auth.js` is responsbile for processing the hash.
-
-Call `handleAuthentication` in `app.js` so that the authentication hash fragment can be processed when the app first loads after the user is redirected back to it.
-
-```js
-// app/routes/application.js
-
-import Ember from 'ember';
-
-const {
-  Route,
-  inject: {
-    service,
-  },
-  get,
-} = Ember;
-
-export default Route.extend({
-  auth: service(),
-  beforeModel() {
-    if (get(this, 'auth.isAuthenticated')) {
-      return;
-    }
-
-    return get(this, 'auth')
-      .handleAuthentication()
-      .then(() => {
-        if (get(this, 'auth.isAuthenticated')) {
-          this.transitionTo('protected')
-        }
-      });
-  },
-});
-```
-
-## Create a Protected Route
-
-After a user authenticates and returns to your application, you may wish to send them to a protected route. The transition logic is demonstrated above in the `transitionTo` call after authentication. Add a new route called `protected` and check whether the user is authenticated before allowing them to see it.
-
-```js
-// app/routes/protected.js
-
-import Ember from 'ember';
-
-const {
-  Route,
-  inject: {
-    service,
-  },
-  get,
-} = Ember;
-
-export default Route.extend({
-  auth: service(),
-  beforeModel() {
-    if (!get(this, 'auth.isAuthenticated')) {
-      return this.replaceWith('application');
-    }
-  }
-});
-```
-
-Add a template for this route.
-
-```html
-
-
-
-    Log Out
-
-
        
-
        You are logged in!
        
-```
-
-Notice that there is also a `Log Out` control in this route which has an `action` of `logout`. This will call the `logout` method on the `auth` service allowing the user to log out.
-
-## Embedded Login
-
-Auth0's universal login provides the fastest, most secure, and most feature-rich way to implement authentication in your app. If required, the Lock widget can also be embedded directly into your application, but certain features such as single sign-on won't be accessible. It is highly recommended that you use the login page (as covered in this tutorial), but if you wish to embed the Lock widget directly in your application, follow the [Embedded Login sample](https://github.com/auth0-community/ember-simple-auth-auth0/tree/develop/tests/dummy).
diff --git a/articles/quickstart/spa/ember/dashboard-default.md b/articles/quickstart/spa/ember/dashboard-default.md
deleted file mode 100644
index d9fad0ab13..0000000000
--- a/articles/quickstart/spa/ember/dashboard-default.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add user login to your application with Auth0
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-ember-samples',
-  path: '01-Login'
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/ember/index.yml b/articles/quickstart/spa/ember/index.yml
deleted file mode 100644
index 0b2d649065..0000000000
--- a/articles/quickstart/spa/ember/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: Ember
-author:
-  community: true
-alias:
-  - ember
-  - emberjs
-language:
-  - Javascript
-framework:
-  - Ember
-image: /media/platforms/emberjs.png
-tags:
-  - quickstart
-seo_alias: emberjs
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/spa/flutter/01-login.md b/articles/quickstart/spa/flutter/01-login.md
new file mode 100644
index 0000000000..bd12f7fd13
--- /dev/null
+++ b/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.
+
+:::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 application up and running. If not, check out the Flutter "getting started" guides to get started with a simple app.
+
+You should also be familiar with the Flutter command line tool.
+
+<%= 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 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, 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 or visit our community page 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.
+
+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 or visit our community page 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 or visit our community page to get more help.
+:::
+::::
diff --git a/articles/quickstart/spa/flutter/_install_sdk.md b/articles/quickstart/spa/flutter/_install_sdk.md
new file mode 100644
index 0000000000..63b1fb626d
--- /dev/null
+++ b/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/articles/quickstart/spa/flutter/download.md b/articles/quickstart/spa/flutter/download.md
new file mode 100644
index 0000000000..9d3470dc0c
--- /dev/null
+++ b/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 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 CLIs `run` command to run the app:
+
+```sh
+flutter run
+```
diff --git a/articles/quickstart/spa/flutter/files/main.md b/articles/quickstart/spa/flutter/files/main.md
new file mode 100644
index 0000000000..a1241cf2bf
--- /dev/null
+++ b/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/articles/quickstart/spa/flutter/files/main_view.md b/articles/quickstart/spa/flutter/files/main_view.md
new file mode 100644
index 0000000000..3d1a6f111c
--- /dev/null
+++ b/articles/quickstart/spa/flutter/files/main_view.md
@@ -0,0 +1,58 @@
+---
+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/articles/quickstart/spa/flutter/files/profile.md b/articles/quickstart/spa/flutter/files/profile.md
new file mode 100644
index 0000000000..16d93d8620
--- /dev/null
+++ b/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/articles/quickstart/spa/flutter/files/profile_view.md b/articles/quickstart/spa/flutter/files/profile_view.md
new file mode 100644
index 0000000000..34ada342a4
--- /dev/null
+++ b/articles/quickstart/spa/flutter/files/profile_view.md
@@ -0,0 +1,26 @@
+---
+name: profile_view.dart
+language: javascript
+---
+    
+```javascript
+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/articles/quickstart/spa/flutter/index.yml b/articles/quickstart/spa/flutter/index.yml
new file mode 100644
index 0000000000..d03c069e04
--- /dev/null
+++ b/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: 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 Actions
+        icon: 345
+        href: '/customize/actions'
diff --git a/articles/quickstart/spa/flutter/interactive.md b/articles/quickstart/spa/flutter/interactive.md
new file mode 100644
index 0000000000..1b0393eb7a
--- /dev/null
+++ b/articles/quickstart/spa/flutter/interactive.md
@@ -0,0 +1,77 @@
+---
+title: Add Login to Your Flutter Application
+description: This guide demonstrates how to integrate Auth0 with a Flutter application using the Auth0 Flutter SDK.
+interactive:  true
+files:
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: en-US
+---
+
+# 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.
        The Flutter SDK currently only supports Flutter applications running on Android, iOS, or Web platforms.
        This quickstart assumes you already have a Flutter application up and running. If not, check out the Flutter "getting started" guides to get started with a simple app.
        You should also be familiar with the Flutter command line tool.
        
+
+## Configure Auth0
+
+
+
        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 section in the Auth0 dashboard.
        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 you download the sample from the top of this page, these details are filled out for you.
        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. If this field is not set, users will be unable to log in to the application and will get an error.
        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 http://localhost:3000.
        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. If this field is not set, users will be unable to log out from the application and will get an error.
        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 http://localhost:3000.
        Configure Allowed Web Origins
        You need to add the URL for your app to the Allowed Web Origins field in your Application 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.
        If you are following along with the sample project you downloaded from the top of this page, you should set the Allowed Web Origins to http://localhost:3000.
        
+
+## Install the Auth0 Flutter SDK
+
+
+
        Add the Auth0 Flutter SDK into the project:
        flutter pub add auth0_flutter
+
+
        
+
+
        Add the following script tag to your index.html page:
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js" defer></script>
+
+
        
+
+
        
+
+## Add login to your application {{{ data-action="code" data-code="main_view.dart" }}}
+
+
+
        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().
        You will normally need to specify the redirectUrl parameter to loginWithRedirect. Omitting this will cause Auth0 to use the default login route, 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:
        auth0.onLoad().then((final credentials) => setState(() {
+
+    // Handle or store credentials here
+
+    _credentials = credentials;
+
+  }));
+
+
        
+
+
        Flutter web step 3 checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add logout to your application
+
+
+
        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.
        You will normally want to specify returnToUrl when calling logout, otherwise Auth0 will default to the first URL in the Allowed Logout URLs list.
        Flutter web step 4 checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        Flutter web step 5 checkpoint 
        Log in and inspect the user property on the result. Verify the current user's profile information, such as email or name.
        
+
+  
        
+
+  
        If your application did not return user profile information:
        • Verify the ID token is valid
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/spa/jquery/01-login.md b/articles/quickstart/spa/jquery/01-login.md
deleted file mode 100644
index 6d720ec7e7..0000000000
--- a/articles/quickstart/spa/jquery/01-login.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '01-Login',
-  requirements: [
-    'jQuery 3.2.1'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'jQuery', callback: 'http://localhost:3000' }) %>
-
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/jquery/02-user-profile.md b/articles/quickstart/spa/jquery/02-user-profile.md
deleted file mode 100644
index 5f750ea7c6..0000000000
--- a/articles/quickstart/spa/jquery/02-user-profile.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch a user's information from Auth0
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '02-User-Profile',
-  requirements: [
-    'jQuery 3.2.1'
-  ]
-}) %>
-
-<%= include('../_includes/_user_profile_preamble') %>
-
-## Request the Profile Scope
-
-To retrieve user information, request a scope of `openid profile` in the instance of the `WebAuth` object.
-
-```js
-// app.js
-
-var webAuth = new auth0.WebAuth({
-  // ...
-  scope: 'openid profile'
-});
-``` 
-
-## Make a Call for the User's Information
-
-<%= include('../_includes/_user_profile_auth0js_method') %>
-
-Add a function that calls the `client.userInfo` function to the `Auth` service.
-
-```js
-// app.js
-
-var userProfile;
-
-function getProfile() {
-  if (!userProfile) {
-    var accessToken = localStorage.getItem('access_token');
-
-    if (!accessToken) {
-      console.log('Access Token must exist to fetch profile');
-    }
-
-    webAuth.client.userInfo(accessToken, function(err, profile) {
-      if (profile) {
-        userProfile = profile;
-        displayProfile();
-      }
-    });
-  } else {
-    displayProfile();
-  }
-}
-
-function displayProfile() {
-  // display the profile
-  $('#profile-view .nickname').text(userProfile.nickname);
-  $('#profile-view .full-profile').text(JSON.stringify(userProfile, null, 2));
-  $('#profile-view img').attr('src', userProfile.picture);
-}
-```
-
-<%= include('../_includes/_user_profile_in_memory') %>
-
-## Add a Profile Template
-
-Add a template to display the user's profile.
-
-```html
-
-
-
        
-  
-  
        
-    
        
-  
        
-
-  
-  
        
-    
        Profile
        
-      
        
-        avatar
-        
        
-          
-          
        
-        
        
-        
        
-      
        
-  
        
-
        
-```
-
-<%= include('../_includes/_user_profile_additional_info') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/03-calling-an-api.md b/articles/quickstart/spa/jquery/03-calling-an-api.md
deleted file mode 100644
index 952aa5d6e4..0000000000
--- a/articles/quickstart/spa/jquery/03-calling-an-api.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Calling an API
-description: This tutorial demonstrates how to make API calls for protected resources on your server
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '03-Calling-an-API',
-  requirements: [
-    'jQuery 3.2.1'
-  ]
-}) %>
-
-<%= include('../_includes/_calling_api_preamble') %>
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Set the Audience and Scope in `auth0.WebAuth`
-
-In your `auth0.WebAuth` instance, enter your API identifier as the value for `audience`. Add your scopes to the `scope` key. 
-
-```js
-// app.js
-
-var webAuth = new auth0.WebAuth({
-  // ...
-  audience: '${apiIdentifier}',
-  scope: 'openid profile read:messages'
-});
-```
-
-<%= include('../_includes/_calling_api_use_rules') %>
-
-## Configure a Custom XHR Request
-
-<%= include('../_includes/_calling_api_access_token') %>
-
-To attach the user's Access Token to HTTP calls as an `Authorization` header, add the header as an option to your requests.
-
-::: note
-We recommend you implement a custom function that adds the header automatically. 
-:::
-
-Create a new function called `callAPI` which wraps a jQuery `$.ajax` request. If you want to secure the request, you can do it if there is a user's Access Token in local storage. To secure the request, attach the Access Token as the `Authorization` header.
-
-```js
-// app.js
-
-var apiUrl = 'http://localhost:3001/api';
-
-// ...
-function callAPI(endpoint, secured) {
-  var url = apiUrl + endpoint;
-  var accessToken = localStorage.getItem('access_token');
-
-  var headers;
-  if (secured && accessToken) {
-    headers = { Authorization: 'Bearer ' + accessToken };
-  }
-
-  $.ajax({
-    url: url,
-    headers: headers
-  })
-    .done(function(result) {
-      $('#ping-view h2').text(result.message);
-    })
-    .fail(function(err) {
-      $('#ping-view h2').text('Request failed: ' + err.statusText);
-    });
-}
-```
-
-<%= include('../_includes/_calling_api_protect_resources') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/04-authorization.md b/articles/quickstart/spa/jquery/04-authorization.md
deleted file mode 100644
index e25aa9a9a8..0000000000
--- a/articles/quickstart/spa/jquery/04-authorization.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization and access control to your application
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '04-Authorization',
-  requirements: [
-    'jQuery 3.2.1'
-  ]
-}) %>
-
-<%= include('../_includes/_authz_preamble') %>
-
-<%= include('../_includes/_authz_determining_scopes') %>
-
-## Handle Scopes
-
-Adjust your `app.js` file to use a local variable with any scopes you want like to request when users log in. Use this variable in the instance of the `auth0.WebAuth` object.
-
-
-```js
-// app.js
-
-var requestedScopes = 'openid profile read:messages write:messages';
-
-var auth0 = new auth0.WebAuth({
-  // ...
-  scope: requestedScopes
-});
-``` 
-
-<%= include('../_includes/_authz_set_session') %>
-
-```js
-// app.js
-
-function setSession(authResult) {
-  
-  const scopes = authResult.scope || requestedScopes || '';
-
-  // ...
-  localStorage.setItem('scopes', JSON.stringify(scopes));
-}
-```
-
-Add a function called `userHasScopes` that checks for scopes in local storage. The function takes an array of strings and checks if the array of scopes saved in local storage contains those values. 
-
-You can use this function to conditionally hide and show UI elements to the user and to limit route access.
-
-```js
-// app.js
-
-function userHasScopes(scopes) {
-  var savedScopes = JSON.parse(localStorage.getItem('scopes'));
-  if (!savedScopes) return false;
-  var grantedScopes = savedScopes.split(' ');
-  for (var i = 0; i < scopes.length; i++) {
-    if (grantedScopes.indexOf(scopes[i]) < 0) {
-      return false;
-    }
-  }
-  return true;
-}
-```
-
-## Conditionally Display UI Elements
-
-You can use the `userHasScopes` function with the `isAuthenticated` function to conditionally show and hide certain UI elements.
-
-```js
-// app.js
-
-// ...
-function displayButtons() {
-  // ...
-  if (!isAuthenticated() || !userHasScopes(['write:messages'])) {
-    adminViewBtn.css('display', 'none');
-  } else {
-    adminViewBtn.css('display', 'inline-block');
-  }
-}
-```
-
-## Protect Client-Side Routes
-
-You may want to give access to some routes in your application only to authenticated users. You can check if the user is authenticated with the `userHasScopes` function.
-
-Depending on the routing library you use, you apply the `userHasScopes` function differently. Some routing libraries provide hooks which run a function before the route is activated. This kind of hook might be called something like `beforeEnter` or `onEnter`. This is a good place to run the `userHasScopes` function to check whether the user has the scopes required to enter the route.
-
-<%= include('../_includes/_authz_conditionally_assign_scopes') %>
-
-<%= include('../_includes/_authz_client_routes_disclaimer') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/05-token-renewal.md b/articles/quickstart/spa/jquery/05-token-renewal.md
deleted file mode 100644
index 452fa61d3d..0000000000
--- a/articles/quickstart/spa/jquery/05-token-renewal.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Token Renewal
-description: This tutorial demonstrates how to add automatic Access Token renewal to an application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '05-Token-Renewal',
-  requirements: [
-    'jQuery 3.2.1'
-  ]
-}) %>
-
-<%= include('../_includes/_token_renewal_preamble') %>
-
-## Add Token Renewal
-
-To the `app.js` file, add a function that calls the `checkSession` method from auth0.js. If the renewal is successful, use the existing `setSession` method to set the new tokens in local storage.
-
-```js
-// app.js
-
-function renewToken() {
-  webAuth.checkSession({},
-    function(err, result) {
-      if (err) {
-        console.log(err);
-      } else {
-        setSession(result);
-      }
-    }
-  );
-}
-```
-
-The access should be renewed when it expires. In this tutorial, the expiry time of the token is stored in local storage as `expires_at`. 
-
-::: note
-You can define any timing mechanism you want. You can choose any library that handles timers. This example shows how to use a simple `setTimeout` call. 
-:::
-
-To the `app.js` file, add a variable called `tokenRenewalTimeout`. The variable refers to the `setTimeout` call used to schedule the renewal. Next, add a function called `scheduleRenewal` to set up the time when authentication is silently renewed.
-
-The function subtracts the current time from the Access Token's expiry time and calculates delay. 
-
-The `setTimeout` call uses the calculated delay and makes a call to `renewToken`. 
-
-The `setTimeout` call is assigned to the `tokenRenewalTimeout` property. When the user logs out, the timeout is cleared. 
-
-```js
-// app.js
-
-var tokenRenewalTimeout;
-// ...
-function scheduleRenewal() {
-  var expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-  var delay = expiresAt - Date.now();
-  if (delay > 0) {
-    tokenRenewalTimeout = setTimeout(function() {
-      renewToken();
-    }, delay);
-  }
-}
-```
-
-You can now include a call to the `scheduleRenewal` function in the `setSession` function.
-
-```js
-// app.js
-
-// ...
-function setSession(authResult) {
-  // Set the time that the Access Token will expire at
-  var expiresAt = JSON.stringify(
-    authResult.expiresIn * 1000 + new Date().getTime()
-  );
-  localStorage.setItem('access_token', authResult.accessToken);
-  localStorage.setItem('id_token', authResult.idToken);
-  localStorage.setItem('expires_at', expiresAt);
-  scheduleRenewal();
-}
-```
-
-To schedule renewing the tokens when the page is refreshed, add a call to the `scheduleRenewal` function immediately when the page loads.
-
-```js
-// app.js
-
-window.addEventListener('load', function() {
-  // ...
-  scheduleRenewal();
-});
-```
-
-Since client-side sessions should not be renewed after the user logs out, use `clearTimeout` in the `logout` method to cancel the renewal.
-
-```js
-// app.js
-
-function logout() {
-  // ...
-  clearTimeout(tokenRenewalTimeout);
-}
-```
-
-<%= include('../_includes/_token_renewal_troubleshooting') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/_includes/_centralized_login.md b/articles/quickstart/spa/jquery/_includes/_centralized_login.md
deleted file mode 100644
index 0687124c37..0000000000
--- a/articles/quickstart/spa/jquery/_includes/_centralized_login.md
+++ /dev/null
@@ -1,194 +0,0 @@
-<%= include('../../_includes/_login_preamble', { library: 'jQuery', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-jquery-samples/tree/embedded-login/01-Embedded-Login'}) %>
-
-## Create an Authentication Service
-
-Add a new file and name it `app.js`. You can use the file to create and manage an instance of the `auth0.WebAuth` object and hold logic to hide and display DOM elements.
-
-```js
-// app.js
-
-$('document').ready(function() {
-
-  var webAuth = new auth0.WebAuth({
-    domain: AUTH0_DOMAIN,
-    clientID: AUTH0_CLIENT_ID,
-    redirectUri: AUTH0_CALLBACK_URL,
-    audience: 'https://' + AUTH0_DOMAIN + '/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  var loginBtn = $('#btn-login');
-
-  loginBtn.click(function(e) {
-    e.preventDefault();
-    webAuth.authorize();
-  });
-
-});
-```
-
-::: note
-**Checkpoint:** Add a button with the `btn-login` ID to your app. This will call the `authorize` method from auth0.js, so you can see the login page.
-:::
-
-![hosted login](/media/articles/web/hosted-login.png)
-
-### Finish the Authentication Functions
-
-Add more functions to the `app.js` file to handle authentication in the app.
-
-The example below shows the following methods:
-* `handleAuthentication`: looks for the result of authentication in the URL hash. Then, the result is processed with the `parseHash` method from auth0.js
-* `setSession`: stores the user's Access Token, ID Token, and the Access Token's expiry time in browser storage
-* `logout`: removes the user's tokens and expiry time from browser storage
-* `isAuthenticated`: checks whether the expiry time for the user's Access Token has passed
-
-```js
-// app.js
-
-$('document').ready(function() {
-
-  // ...
-  var loginStatus = $('.container h4');
-  var loginView = $('#login-view');
-  var homeView = $('#home-view');
-
-  // buttons and event listeners
-  var homeViewBtn = $('#btn-home-view');
-  var loginBtn = $('#btn-login');
-  var logoutBtn = $('#btn-logout');
-
-  homeViewBtn.click(function() {
-    homeView.css('display', 'inline-block');
-    loginView.css('display', 'none');
-  });
-
-  loginBtn.click(function(e) {
-    e.preventDefault();
-    webAuth.authorize();
-  });
-
-  logoutBtn.click(logout);
-
-  function setSession(authResult) {
-    // Set the time that the Access Token will expire at
-    var expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  function logout() {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    displayButtons();
-  }
-
-  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;
-  }
-
-  function handleAuthentication() {
-    webAuth.parseHash(function(err, authResult) {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        setSession(authResult);
-        loginBtn.css('display', 'none');
-        homeView.css('display', 'inline-block');
-      } else if (err) {
-        homeView.css('display', 'inline-block');
-        console.log(err);
-        alert(
-          'Error: ' + err.error + '. Check the console for further details.'
-        );
-      }
-      displayButtons();
-    });
-  }
-
-  function displayButtons() {
-    if (isAuthenticated()) {
-      loginBtn.css('display', 'none');
-      logoutBtn.css('display', 'inline-block');
-      loginStatus.text('You are logged in!');
-    } else {
-      loginBtn.css('display', 'inline-block');
-      logoutBtn.css('display', 'none');
-      loginStatus.text('You are not logged in! Please log in to continue.');
-    }
-  }
-
-});
-```
-
-## Provide a Login Control
-
-Provide a template with controls for the user to log in and out.
-
-```html
-
-
-
        
-  
-
-  
        
-    
-    
        
-      
        
-    
        
-    
-  
        
-
-
        
-```
-
-::: note
-This example uses Bootstrap styles. You can use any style library, or not use one at all.
-:::
-
-Depending on whether the user is authenticated or not, they see the **Log In** or **Log Out** button. The `click` event listeners on the buttons make calls to functions in the `app.js` file to let the user log in or out. When the user clicks **Log In**, the user is redirected to the login page.
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Process the Authentication Result
-
-When a user authenticates at the login page, they are redirected to your application. Their URL contains a hash fragment with their authentication information. The `handleAuthentication` function in the `app.js` file processes the hash.
-
-Call the `handleAuthentication` function in the `app.js` file. The function processes the authentication hash while your app loads. 
-
-```js
-// app.js
-
-$('document').ready(function() {
-
-  // ...
-  handleAuthentication();
-});
-```
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/dashboard-default.md b/articles/quickstart/spa/jquery/dashboard-default.md
deleted file mode 100644
index 89ed961cc5..0000000000
--- a/articles/quickstart/spa/jquery/dashboard-default.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use Auth0 to add authentication and authorization to your web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-jquery-samples',
-  path: '01-Login'
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/jquery/index.yml b/articles/quickstart/spa/jquery/index.yml
deleted file mode 100644
index a01344504f..0000000000
--- a/articles/quickstart/spa/jquery/index.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-title: jQuery
-alias:
-  - jquery
-language:
-  - Javascript
-framework:
-  - jQuery
-image: /media/platforms/jquery.svg
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/jquery/dependencies
-  setup: application-platforms/jquery/setup
-  use: application-platforms/jquery/use
-seo_alias: jquery
-default_article: dashboard-default
-articles:
-  - 01-login
-  - 02-user-profile
-  - 03-calling-an-api
-  - 04-authorization
-  - 05-token-renewal
\ No newline at end of file
diff --git a/articles/quickstart/spa/react/01-login.md b/articles/quickstart/spa/react/01-login.md
index 5a37d36cdf..9c4223667a 100644
--- a/articles/quickstart/spa/react/01-login.md
+++ b/articles/quickstart/spa/react/01-login.md
@@ -1,18 +1,152 @@
 ---
 title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
+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
 ---
+
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '01-Login',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
+:::note
+Visit the React Authentication By Example 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/callback' }) %>
+<%= 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 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 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 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. 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://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 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 within a component correctly after you have logged in.
+:::                                              
 
-<%= include('_includes/_centralized_login') %>
diff --git a/articles/quickstart/spa/react/02-calling-an-api.md b/articles/quickstart/spa/react/02-calling-an-api.md
new file mode 100644
index 0000000000..a7189dd38c
--- /dev/null
+++ b/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 section of the React Authentication By Example 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, 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 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 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 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 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 with Auth0.
+:::
+
+The actions that your React application can perform on the API depend on the scopes 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 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()` method from the `useAuth0()` 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 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 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. To get a refresh token when a user logs in, pass `useRefreshTokens={true}` as a prop to `Auth0Provider`. 
+:::
+
+As a final reminder, consult the Auth0 API quickstarts to learn how to integrate Auth0 with your backend platform.
+
diff --git a/articles/quickstart/spa/react/02-custom-login.md b/articles/quickstart/spa/react/02-custom-login.md
deleted file mode 100644
index e1dc33fa03..0000000000
--- a/articles/quickstart/spa/react/02-custom-login.md
+++ /dev/null
@@ -1,282 +0,0 @@
----
-title: Custom Login
-description: This tutorial demonstrates how to use the auth0.js library to add custom authentication and authorization to your ReactJS web application
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-sample',
-  path: '02-Custom-Login',
-  requirements: [
-    'React 15.3'
-  ]
-}) %>
-
-In the [previous step](/quickstart/spa/react/01-login), we enabled login with Auth0's Lock widget. You can also build your own UI with a custom design for authentication if you like. To do this, use the [auth0.js library](https://github.com/auth0/auth0.js).
-
-::: panel Version Requirements
-This quickstart and the accompanying sample demonstrate custom login with auth0.js version 8. If you are using auth0.js version 7, please see the [reference guide](https://auth0.com/docs/libraries/auth0js/v7) for the library, as well as the [legacy React custom login sample](https://github.com/auth0-samples/auth0-react-sample/tree/auth0js-v7/02-Custom-Login).
-:::
-
-## Getting Started
-
-The auth0.js library can either be retrieved from Auth0's CDN or from npm.
-
-**CDN Link**
-
-```html
-
-```
-
-**npm**
-
-```bash
-npm install --save auth0-js
-```
-
-## Create a Login Component
-
-At a basic level, two items are required for a custom login UI: the component and template to power the interface itself, and a service to call the appropriate authentication transaction methods from auth0.js.
-
-Create a component which has a template with a `form` and controls for submitting a `login`, `signup`, and `loginWithGoogle` request. The `AuthService` that is used in this component will be created later.
-
-```js
-import React, { PropTypes as T } from 'react'
-import ReactDOM from 'react-dom'
-import {Form, FormGroup, FormControl, ControlLabel, Button, ButtonToolbar} from 'react-bootstrap'
-import AuthService from 'utils/AuthService'
-import styles from './styles.module.css'
-
-export class Login extends React.Component {
-  static contextTypes = {
-    router: T.object
-  }
-
-  static propTypes = {
-    location: T.object,
-    auth: T.instanceOf(AuthService)
-  }
-
-  getAuthParams() {
-    return {
-      email: ReactDOM.findDOMNode(this.refs.email).value,
-      password: ReactDOM.findDOMNode(this.refs.password).value
-    }
-  }
-
-  login(e) {
-    e.preventDefault()
-    const { email, password } = this.getAuthParams()
-    this.props.auth.login(email, password)
-  }
-
-  signup() {
-    const { email, password } = this.getAuthParams()
-    this.props.auth.signup(email, password)
-  }
-
-  loginWithGoogle() {
-    this.props.auth.loginWithGoogle();
-  }
-
-  render() {
-    return (
-      
        
-        
        Login
        
-        
        
-          
-            Email
-            
-          
-
-          
-            Password
-            
-          
-
-          
-            
-            
-            
-          
-        
        
-      
        
-    )
-  }
-}
-
-export default Login;
-```
-
-This component has a form with inputs for users to submit their username and password, buttons for handling the `login` and `signup` cases, and a control for the user to initiate a social authentication flow with Google.
-
-The `onClick` handlers attached to these controls call the component methods which, in turn, make calls to the `AuthService`. It's within the `AuthService` that auth0.js will be called and the user's credentials passed along to complete authentication transactions.
-
-
-## Create the AuthService Class
-
-All authentication transactions should be handled from a service. The service requires methods named `login`, `signup`, and `loginWithGoogle` which all make calls to the appropriate auth0.js methods to handle those actions. These methods are called from the `login` component above.
-
-The auth0.js methods for making authentication requests come from the `WebAuth` object. Create an instance of `auth0.WebAuth` and provide the domain, client ID, and callback URL (as the redirect URI) for your application. A `responseType` of `token id_token` should also be specified.
-
-The `login` and `signup` methods should take the username and password input supplied by the user and pass it to the appropriate auth0.js methods. In the case of `login`, these values are passed to the `redirect.loginWithCredentials` method, and for `signup`, they are passed to `redirect.signupAndLogin`.
-
-These methods are redirect-based and the authentication result is handled by the `parseHash` method. This method looks for an Access Token and ID Token in the URL hash when the user is redirected back to the application. If those tokens are found, they are saved into local storage and the user is redirected to the home route.
-
-```javascript
-// src/utils/AuthService.js
-
-import { EventEmitter } from 'events'
-import { isTokenExpired } from './jwtHelper'
-import { browserHistory } from 'react-router'
-import auth0 from 'auth0-js'
-
-export default class AuthService extends EventEmitter {
-  constructor(clientId, domain) {
-    super()
-    // Configure Auth0
-    this.auth0 = new auth0.WebAuth({
-      clientID: '${account.clientId}',
-      domain: '${account.namespace}',
-      responseType: 'token id_token',
-      redirectUri: 'http://localhost:3000/login'
-    })
-
-    this.login = this.login.bind(this)
-    this.signup = this.signup.bind(this)
-    this.loginWithGoogle = this.loginWithGoogle.bind(this)
-  }
-
-  login(username, password) {
-    this.auth0.redirect.loginWithCredentials({
-      connection: 'Username-Password-Authentication',
-      username,
-      password
-    }, err => {
-      if (err) return alert(err.description)
-    })
-  }
-
-  signup(email, password){
-    this.auth0.redirect.signupAndLogin({
-      connection: 'Username-Password-Authentication',
-      email,
-      password,
-    }, function(err) {
-      if (err) {
-        alert('Error: ' + err.description)
-      }
-    })
-  }
-
-  loginWithGoogle() {
-    this.auth0.authorize({
-      connection: 'google-oauth2'
-    })
-  }
-
-  parseHash(hash) {
-    this.auth0.parseHash({ hash, _idTokenVerification: false }, (err, authResult) => {
-      if (err) {
-        alert(`Error: <%= "${err.errorDescription}" %>`)
-      }
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setToken(authResult.accessToken, authResult.idToken)
-        this.auth0.client.userInfo(authResult.accessToken, (error, profile) => {
-          if (error) {
-            console.log('Error loading the Profile', error)
-          } else {
-            this.setProfile(profile)
-            browserHistory.replace('/home')
-          }
-        })
-      }
-    })
-  }
-
-  loggedIn() {
-    // Checks if there is a saved token and it's still valid
-    const token = this.getToken()
-    return !!token && !isTokenExpired(token)
-  }
-
-  setToken(accessToken, idToken) {
-    // Saves user Access Token and ID Token into local storage
-    localStorage.setItem('access_token', accessToken)
-    localStorage.setItem('id_token', idToken)
-  }
-
-  setProfile(profile) {
-    // Saves profile data to localStorage
-    localStorage.setItem('profile', JSON.stringify(profile))
-    // Triggers profile_updated event to update the UI
-    this.emit('profile_updated', profile)
-  }
-
-  getProfile() {
-    // Retrieves the profile data from localStorage
-    const profile = localStorage.getItem('profile')
-    return profile ? JSON.parse(localStorage.profile) : {}
-  }
-
-  getToken() {
-    // Retrieves the user token from localStorage
-    return localStorage.getItem('id_token')
-  }
-
-  logout() {
-    // Clear user token and profile data from localStorage
-    localStorage.removeItem('access_token')
-    localStorage.removeItem('id_token')
-    localStorage.removeItem('profile')
-  }
-}
-```
-
-The service has several other utility methods that are necessary to complete authentication transactions.
-
-* The `parseHash` method is necessary to get the authentication result from the URL in redirect-based authentication transactions.
-* The `logout` method removes the user's tokens from local storage which effectively logs them out of the application.
-* The `setToken` method takes an authentication result object and sets the Access Token and ID Token values into local storage
-* The `loggedIn` method uses the `isTokenExpired` utility from a `jwtHelper` file to check whether the user's ID Token is expired. This is done to determine whether the user should be able to access the `Home` route.
-
-
-## Check the Authentication Hash and Protect Private Routes
-
-When a redirect-based authentication flow is completed, such as the `signup` and `loginWithGoogle` transactions above, the authentication result comes back in a URL hash. This hash can be read using the `parseHash` method from auth0.js, after which the tokens that come back in it can be saved in local storage and the user can be considered logged in.
-
-The URL hash should be checked when the user enters the `Login` route because this is the route that is assigned as a `callbackUri` on the `auth0.WebAuth` instance. To check for this, set up a function which is run when the `Login` route is entered.
-
-Routes can also be configured to dissallow access if the user is not authenticated. Create a `requireAuth` function which uses the `AuthService` to check whether the user is currently logged in and, if they are not, redirects them to the `Login` route.
-
-```js
-// src/views/Main/routes.js
-
-// ...
-
-// onEnter callback to validate authentication in private routes
-const requireAuth = (nextState, replace) => {
-  if (!auth.loggedIn()) {
-    replace({ pathname: '/login' })
-  }
-}
-
-const parseAuthHash = (nextState, replace) => {
-  if (/access_token|id_token|error/.test(nextState.location.hash)) {
-    auth.parseHash(nextState.location.hash)
-  }
-}
-
-export const makeMainRoutes = () => {
-  return (
-    
-      
-      
-      
-    
-  )
-}
-```
diff --git a/articles/quickstart/spa/react/02-user-profile.md b/articles/quickstart/spa/react/02-user-profile.md
deleted file mode 100644
index e6df8704ad..0000000000
--- a/articles/quickstart/spa/react/02-user-profile.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch a user's information from Auth0
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '02-User-Profile',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
-
-<%= include('../_includes/_user_profile_preamble') %>
-
-## Request the Profile Scope
-
-To retrieve user information, request a scope of `openid profile` in the instance of the `auth0.WebAuth` object. 
-
-```js
-// src/Auth/Auth.js
-
-auth0 = new auth0.WebAuth({
-  // ...
-  scope: 'openid profile'
-});
-``` 
-
-## Make a Call for the User's Information
-
-<%= include('../_includes/_user_profile_auth0js_method') %>
-
-Add a method that calls the `client.userInfo` method to the `Auth` service.
-
-```js
-// src/Auth/Auth.js
-
-constructor() {
-  // ...
-  this.getProfile = this.getProfile.bind(this);
-}
-
-// ...
-userProfile;
-
-// ...
-
-getAccessToken() {
-    const accessToken = localStorage.getItem('access_token');
-    if (!accessToken) {
-      throw new Error('No Access Token found');
-    }
-    return accessToken;
-  }
-
-//...
-getProfile(cb) {
-  let accessToken = this.getAccessToken();
-  this.auth0.client.userInfo(accessToken, (err, profile) => {
-    if (profile) {
-      this.userProfile = profile;
-    }
-    cb(err, profile);
-  });
-}
-```
-
-<%= include('../_includes/_user_profile_in_memory') %>
-
-## Add a Profile Component
-
-Some applications have a dedicated profile section for displaying user information. The example below shows how to set it up. 
-
-Create a new component called `ProfileComponent`.
-
-```js
-// src/Profile/Profile.js
-
-import React, { Component } from 'react';
-import { Panel, ControlLabel, Glyphicon } from 'react-bootstrap';
-import './Profile.css';
-
-class Profile extends Component {
-  componentWillMount() {
-    this.setState({ profile: {} });
-    const { userProfile, getProfile } = this.props.auth;
-    if (!userProfile) {
-      getProfile((err, profile) => {
-        this.setState({ profile });
-      });
-    } else {
-      this.setState({ profile: userProfile });
-    }
-  }
-  render() {
-    const { profile } = this.state;
-    return (
-      
        
-        
        
-          
        {profile.name}
        
-          
-            profile
-            
        
-               Nickname
-              
        {profile.nickname}
        
-            
        
-            
        {JSON.stringify(profile, null, 2)}
        
-                  
-        
        
-      
        
-    );
-  }
-}
-
-export default Profile;
-```
-
-The component first looks for a profile cached on the service. If it doesn't find the profile, the component makes a call to `getProfile` to get the user's information.
-
-<%= include('../_includes/_user_profile_additional_info') %>
diff --git a/articles/quickstart/spa/react/03-calling-an-api.md b/articles/quickstart/spa/react/03-calling-an-api.md
deleted file mode 100644
index f063ded662..0000000000
--- a/articles/quickstart/spa/react/03-calling-an-api.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Calling an API
-description: This tutorial demonstrates how to make API calls for protected resources on your server
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '03-Calling-an-API',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
-
-<%= include('../_includes/_calling_api_preamble') %>
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Set the Audience and Scope in `auth0.WebAuth`
-
-In your `auth0.WebAuth` instance, enter your API identifier as the value for `audience`.
-Add your scopes to the `scope` key.
-
-```js
-// src/Auth/Auth.js
-
-auth0 = new auth0.WebAuth({
-  // ...
-  audience: '${apiIdentifier}',
-  scope: 'openid profile read:messages'
-});
-```
-
-<%= include('../_includes/_calling_api_use_rules') %>
-
-## Send Authenticated HTTP Requests
-
-<%= include('../_includes/_calling_api_access_token') %>
-
-::: note
-The example below shows how to add the user's Access Token as the `Authorization` header to HTTP calls using [**axios**](https://github.com/mzabriskie/axios). 
-You can use any HTTP client you want.
-:::
-
-```js
-// src/Ping/Ping.js
-
-import React, { Component } from 'react';
-import axios from 'axios';
-
-// ...
-class Ping extends Component {
-  // ...
-  securedPing() {
-    const { getAccessToken } = this.props.auth;
-    const API_URL = 'http://.com/api';
-    const headers = { 'Authorization': `Bearer <%= "${getAccessToken()}" %>`}
-    axios.get(`<%= "${API_URL}" %>/private`, { headers })
-      .then(response => this.setState({ message: response.data.message }))
-      .catch(error => this.setState({ message: error.message }));
-  }
-  securedScopedPing() {
-      const { getAccessToken } = this.props.auth;
-      const headers = { 'Authorization': `Bearer <%= "${getAccessToken()}" %>`}
-      axios.get(`<%= "${API_URL}" %>/private-scoped`, { headers })
-        .then(response => this.setState({ message: response.data.message }))
-        .catch(error => this.setState({ message: error.message }));
-  }
-}
-
-export default Ping;
-```
-
-<%= include('../_includes/_calling_api_protect_resources') %>
diff --git a/articles/quickstart/spa/react/04-authorization.md b/articles/quickstart/spa/react/04-authorization.md
deleted file mode 100644
index 0e0664cc09..0000000000
--- a/articles/quickstart/spa/react/04-authorization.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization and access control to your application
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '04-Authorization',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
-
-<%= include('../_includes/_authz_preamble') %>
-
-<%= include('../_includes/_authz_determining_scopes') %>
-
-## Handle Scopes in the `Auth` Service
-
-Add a local member to your `Auth` service and intialize it with all the scopes you want to request when users log in. Use this member when initializing your instance of the `auth0.WebAuth` object.
-
-```js
-// src/Auth/Auth.js
-
-requestedScopes = 'openid profile read:messages write:messages';
-
-auth0 = new auth0.WebAuth({
-  // ...
-  scope: this.requestedScopes
-});
-``` 
-
-<%= include('../_includes/_authz_set_session') %>
-
-```js
-// src/Auth/Auth.js
-
-setSession(authResult) {
-
-  const scopes = authResult.scope || this.requestedScopes || '';
-
-  // ...
-  localStorage.setItem('scopes', JSON.stringify(scopes));
-}
-```
-
-<%= include('../_includes/_authz_user_has_scopes') %>
-
-```js
-// src/Auth/Auth.js
-
-userHasScopes(scopes) {
-  const grantedScopes = JSON.parse(localStorage.getItem('scopes')).split(' ');
-  return scopes.every(scope => grantedScopes.includes(scope));
-}
-```
-
-## Conditionally Display UI Elements
-
-You can use the `userHasScopes` method with the `isAuthenticated` method to show and hide certain UI elements.
-
-```js
-// src/App.js
-
-// ...
-render() {
-  const { isAuthenticated, userHasScopes } = this.props.auth;
-
-  return (
-    
        
-      // ...
-      {
-        isAuthenticated() &&  userHasScopes(['write:messages']) && (
-            
-          )
-      }
-    
        
-  );
-}
-```
-
-## Protect Client-Side Routes
-
-You may want to give access to some routes in your application only to authenticated users. You can check if the user is authenticated with the `render` function.
-
-```js
-// src/routes.js
-
- (
-  !auth.isAuthenticated() ? (
-    
-  ) : (
-    
-  )
-)} />
-```
-
-In this example, if an unauthenticated user tries to access the `/ping` route, they are redirected to the `/home` route.
-
-### Limit Route Access Based on Scopes
-
-To prevent access to client-side routes based on a particular scope, make a call to the `userHasScopes` method in the route's `render` function.
-
-If the user does not have the `write:messages` scope, they are redirected to the main route.
-
-```js
-// src/routes.js
-
- (
-  !auth.isAuthenticated() || !auth.userHasScopes(['write:messages']) ? (
-    
-  ) : (
-    
-  )
-)} />
-```
-
-<%= include('../_includes/_authz_conditionally_assign_scopes') %>
-
-<%= include('../_includes/_authz_client_routes_disclaimer') %>
diff --git a/articles/quickstart/spa/react/05-token-renewal.md b/articles/quickstart/spa/react/05-token-renewal.md
deleted file mode 100644
index 8e7df0e92d..0000000000
--- a/articles/quickstart/spa/react/05-token-renewal.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: Token Renewal
-description: This tutorial demonstrates how to add automatic Access Token renewal to an application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '05-Token-Renewal',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
-
-<%= include('../_includes/_token_renewal_preamble') %>
-
-## Add Token Renewal
-
-To the `Auth` service, add a method which calls the `checkSession` method from auth0.js. If the renewal is successful, use the existing `setSession` method to set new tokens in local storage.
-
-```js
-// src/Auth/Auth.js
-
-renewToken() {
-  this.auth0.checkSession({}, (err, result) => {
-      if (err) {
-        console.log(err);
-      } else {
-        this.setSession(result);
-      }
-    }
-  );
-}
-```
-
-The Access Token should be renewed when it expires. In this tutorial, the expiry time of the token is stored in local storage as `expires_at`.
-
-Define a timing mechanism for renewing the token. 
-
-::: note
-You can define any timing mechanism you want. You can choose any library that handles timers. This example shows how to use a `setTimeout` call.
-:::
-
-In the `Auth` service, add a property called `tokenRenewalTimeout` which refers to the `setTimeout` call. 
-
-Add a method called `scheduleRenewal` to set up the time when the authentication is silently renewed. The method subtracts the current time from the Access Token's expiry time and calculates delay. The `setTimeout` call uses the calculated delay and makes a call to `renewToken`.
-
-The `setTimeout` call call is assigned to the `tokenRenewalTimeout` property. When the user logs out, the timeout is cleared. 
-
-```js
-// src/Auth/Auth.js
-
-tokenRenewalTimeout
-// ...
-scheduleRenewal() {
-  const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-  const delay = expiresAt - Date.now();
-  if (delay > 0) {
-    this.tokenRenewalTimeout = setTimeout(() => {
-      this.renewToken();
-    }, delay);
-  }
-}
-```
-
-You can now include a call to the `scheduleRenewal` method in the `setSession` method.
-
-```js
-// src/Auth/Auth.js
-
-// ...
-setSession(authResult) {
-  // Set the time that the Access Token will expire at
-  let expiresAt = JSON.stringify(
-    authResult.expiresIn * 1000 + new Date().getTime()
-  );
-
-  localStorage.setItem('access_token', authResult.accessToken);
-  localStorage.setItem('id_token', authResult.idToken);
-  localStorage.setItem('expires_at', expiresAt);
-
-  // schedule a token renewal
-  this.scheduleRenewal();
-
-  // navigate to the home route
-  history.replace('/home');
-}
-```
-
-To schedule renewing the tokens when the page is refreshed, in the constructor of the `Auth` service, add a call to the `scheduleRenewal` method.
-
-```js
-// src/Auth/Auth.js
-
-// ...
-constructor() {
-  // ...
-  this.scheduleRenewal();
-}
-```
-
-Since client-side sessions should not be renewed after the user logs out, call `clearTimeout` in the `logout` method to cancel the renewal.
-
-```js
-// src/Auth/Auth.js
-
-logout() {
-  // ...
-  clearTimeout(this.tokenRenewalTimeout);
-}
-```
-
-<%= include('../_includes/_token_renewal_troubleshooting') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/react/_includes/_centralized_login.md b/articles/quickstart/spa/react/_includes/_centralized_login.md
deleted file mode 100644
index a4a696454f..0000000000
--- a/articles/quickstart/spa/react/_includes/_centralized_login.md
+++ /dev/null
@@ -1,218 +0,0 @@
-<%= include('../../_includes/_login_preamble', { library: 'React', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-react-samples/tree/embedded-login/01-Embedded-Login' }) %>
-
-## Create an Authentication Service
-
-Create a service to manage and coordinate user authentication. You can give the service any name. In the examples below, the service is  `Auth` and the filename is `Auth.js`.
-
-In the service add an instance of the `auth0.WebAuth` object. When creating that instance, you can specify the following:
-<%= include('../../_includes/_auth_service_configure_client_details') %>
-
-::: note
-In this tutorial, the route is `/callback`, which is implemented in the [Add a Callback Component](#add-a-callback-component) step. 
-:::
-
-Add a `login` method that calls the `authorize` method from auth0.js.
-
-```js
-// src/Auth/Auth.js
-
-import auth0 from 'auth0-js';
-
-export default class Auth {
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:3000/callback',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  login() {
-    this.auth0.authorize();
-  }
-}
-```
-
-::: panel Checkpoint
-Try to import the `Auth` service from somewhere in your application. Call the `login` method from the service to see the login page.
-For example:
-
-```js
-// App.js
-import Auth from './Auth/Auth.js';
-
-const auth = new Auth();
-auth.login();
-```
-
-:::
-
-![hosted login](/media/articles/web/hosted-login.png)
-
-### Finish the Service
-
-Add more methods to the `Auth` service to handle authentication in the app.
-
-The example below shows the following methods:
-* `handleAuthentication`: looks for the result of authentication in the URL hash. Then, the result is processed with the `parseHash` method from auth0.js
-* `setSession`: sets the user's Access Token, ID Token, and the Access Token's expiry time 
-* `logout`: removes the user's tokens and expiry time from browser storage
-* `isAuthenticated`: checks whether the expiry time for the user's Access Token has passed
-
-```js
-// src/Auth/Auth.js
-
-import history from '../history';
-
-// ...
-export default class Auth {
-  // ...
-  constructor() {
-    this.login = this.login.bind(this);
-    this.logout = this.logout.bind(this);
-    this.handleAuthentication = this.handleAuthentication.bind(this);
-    this.isAuthenticated = this.isAuthenticated.bind(this);
-  }
-
-  handleAuthentication() {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-        history.replace('/home');
-      } else if (err) {
-        history.replace('/home');
-        console.log(err);
-      }
-    });
-  }
-
-  setSession(authResult) {
-    // Set the time that the Access Token will expire at
-    let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-    // navigate to the home route
-    history.replace('/home');
-  }
-
-  logout() {
-    // Clear Access Token and ID Token from local storage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // navigate to the home route
-    history.replace('/home');
-  }
-
-  isAuthenticated() {
-    // Check whether the current time is past the 
-    // Access Token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-}
-```
-
-```js
-// src/history.js
-
-import createHistory from 'history/createBrowserHistory'
-
-export default createHistory()
-```
-
-## Provide a Login Control
-
-Provide a component with controls for the user to log in and log out.
-
-${snippet(meta.snippets.use)}
-
-::: note
-This example uses Bootstrap styles. You can use any style library you want, or not use one at all.
-:::
-
-Depending on whether the user is authenticated or not, they see the **Log In** or **Log Out** button. The `click` events on the buttons make calls to the `Auth` service to let the user log out or log in. When the user clicks the **Log In** button, they are redirected to the login page. 
-
-<%= include('../../_includes/_hosted_login_customization' }) %>
-
-## Add a Callback Component
-
-When you use the login page, your users are taken away from your application. After they authenticate, the users automatically return to your application and a client-side session is set for them. 
-
-::: note
-This example assumes you are using path-based routing with ``. If you are using hash-based routing, you will not be able to specify a dedicated callback route. The URL hash will be used to hold the user's authentication information.
-:::
-
-<%= include('../../_includes/_callback_component') %>
-
-Create a component named `CallbackComponent` and add a loading indicator.
-
-::: note
-To display a loading indicator, you need a loading spinner or another indicator in the `assets` directory. See the downloadable sample for demonstration. 
-:::
-
-```js
-// src/Callback/Callback.js
-
-import React, { Component } from 'react';
-import loading from './loading.svg';
-
-class Callback extends Component {
-  render() {
-    const style = //...
-
-    return (
-      
        
-        loading
-      
        
-    );
-  }
-}
-
-export default Callback;
-```
-
-After authentication, your users are taken to the `/callback` route. They see the loading indicator while the application sets up a client-side session for them. After the session is set up, the users are redirected to the `/home` route.
-
-## Process the Authentication Result
-
-When a user authenticates at the login page, they are redirected to your application. Their URL contains a hash fragment with their authentication information. The `handleAuthentication` method in the `Auth` service processes the hash. 
-
-Call the `handleAuthentication` method after you render the `Callback` route. The method processes the authentication hash fragment when the `Callback` component initializes.
-
-```js
-// src/routes.js
-
-import React from 'react';
-import { Route, Router } from 'react-router-dom';
-import App from './App';
-import Home from './Home/Home';
-import Callback from './Callback/Callback';
-import Auth from './Auth/Auth';
-import history from './history';
-
-const auth = new Auth();
-
-const handleAuthentication = (nextState, replace) => {
-  if (/access_token|id_token|error/.test(nextState.location.hash)) {
-    auth.handleAuthentication();
-  }
-}
-
-export const makeMainRoutes = () => {
-  return (
-    
-      
        
-         } />
-         } />
-         {
-          handleAuthentication(props);
-          return  
-        }}/>
-      
        
-            
-  );
-}
-```
diff --git a/articles/quickstart/spa/react/dashboard-default.md b/articles/quickstart/spa/react/dashboard-default.md
deleted file mode 100644
index f485b65f6c..0000000000
--- a/articles/quickstart/spa/react/dashboard-default.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add user login to your application with Auth0
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-react-samples',
-  path: '01-Login',
-  requirements: [
-    'React 15.5'
-  ]
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000/callback
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/react/download.md b/articles/quickstart/spa/react/download.md
new file mode 100644
index 0000000000..cec2290b43
--- /dev/null
+++ b/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 to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the Application Settings to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the Application Settings to
+```text
+http://localhost:3000
+```
+4) Make sure Node.JS LTS 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 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/articles/quickstart/spa/react/files/app.md b/articles/quickstart/spa/react/files/app.md
new file mode 100644
index 0000000000..7e4b2f7e01
--- /dev/null
+++ b/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/articles/quickstart/spa/react/files/index.md b/articles/quickstart/spa/react/files/index.md
new file mode 100644
index 0000000000..2efeee2d47
--- /dev/null
+++ b/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(
+
+    
+  ,
+);
+```
diff --git a/articles/quickstart/spa/react/files/login.md b/articles/quickstart/spa/react/files/login.md
new file mode 100644
index 0000000000..f490be840d
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/spa/react/files/logout.md b/articles/quickstart/spa/react/files/logout.md
new file mode 100644
index 0000000000..466de32532
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/spa/react/files/profile.md b/articles/quickstart/spa/react/files/profile.md
new file mode 100644
index 0000000000..032891f7bb
--- /dev/null
+++ b/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;
+```
diff --git a/articles/quickstart/spa/react/index.yml b/articles/quickstart/spa/react/index.yml
index 3bbb24b49f..591b6725fe 100644
--- a/articles/quickstart/spa/react/index.yml
+++ b/articles/quickstart/spa/react/index.yml
@@ -1,23 +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
-image: /media/platforms/react.png
-tags:
+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: dashboard-default
+default_article: "01-login"
 articles:
-  - 01-login
-  - 02-user-profile
-  - 03-calling-an-api
-  - 04-authorization
-  - 05-token-renewal
\ No newline at end of file
+  - "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/articles/quickstart/spa/react/interactive.md b/articles/quickstart/spa/react/interactive.md
new file mode 100644
index 0000000000..148042b826
--- /dev/null
+++ b/articles/quickstart/spa/react/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Add Login to your React Application
+description: 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
+locale: en-US
+---
+
+# 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. Test
        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.
        Visit the React Authentication By Example 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.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Install the Auth0 React SDK {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Auth0 provides a React SDK (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:
        cd <your-project-directory>
+
+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, 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.
        React Quickstart - Step 2 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application {{{ data-action="code" data-code="login.js" }}}
+
+
+
        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.
        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.
        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.
        React Quickstart - Step 3 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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. Create a logout button using the SDK’s logout() method. When users log out, they will be redirected to your Auth0 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.
        React Quickstart - Step 4 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Show User Profile Information {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        Now that your users can log in and log out, you will likely want to be able to retrieve the profile information 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.
        React Quickstart - Step 5 Checkpoint 
        Verify that:
        • You can display the user.name or any other user property within a component correctly after you have logged in.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/spa/socket-io/01-login.md b/articles/quickstart/spa/socket-io/01-login.md
deleted file mode 100644
index 3dbd877c5b..0000000000
--- a/articles/quickstart/spa/socket-io/01-login.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Socket.io SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-## 1. Set up the Allowed Origin (CORS) in Auth0
-
-
        
-
        Go to the Application Settings section in the Auth0 dashboard and make sure to add your URL as an Allowed Origin (CORS). If you're testing it locally, it should contain the following value:
        
-
-
        http://localhost:3001
        
-
-
        
-
-## 2. Installation
-
-Install [socketio-jwt](https://github.com/auth0/socketio-jwt) from npm and save it to your `package.json` using
-
-```text
-npm install --save socketio-jwt
-```
-
-## 3. Add the Auth0 Script and Set the Viewport
-
-Add the code below to the `index.html` file to include the Auth0 `lock` script and set the viewport:
-
-${snippet(meta.snippets.dependencies)}
-
-## 4. Configure Auth0Lock
-
-Configure Auth0Lock with your `clientId` and `domain`:
-
-${snippet(meta.snippets.setup)}
-
-To discover all the available options, see [User configurable options](/libraries/lock/v10/customization).
-
-## 5. Implement the Login
-
-To implement the login, call the `.show()` method of Auth0's `lock` instance when a user clicks the login button, and save the JWT token to `localStorage` for later use in calling a server or an API:
-
-${snippet(meta.snippets.use)}
diff --git a/articles/quickstart/spa/socket-io/index.yml b/articles/quickstart/spa/socket-io/index.yml
deleted file mode 100644
index 3d55f1dbd4..0000000000
--- a/articles/quickstart/spa/socket-io/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Socket.io
-author:
-  community: true
-alias:
-  - socket.io
-language:
-  - Javascript
-framework:
-  - socket.io
-image: /media/platforms/socketio.svg
-tags:
-  - quickstart
-snippets:
-  dependencies: application-platforms/socket-io/dependencies
-  setup: application-platforms/socket-io/setup
-  use: application-platforms/socket-io/use
-seo_alias: socket-io
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/spa/vanillajs/01-login.md b/articles/quickstart/spa/vanillajs/01-login.md
index 381f8c8524..dc9497c854 100644
--- a/articles/quickstart/spa/vanillajs/01-login.md
+++ b/articles/quickstart/spa/vanillajs/01-login.md
@@ -1,15 +1,20 @@
 ---
 title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '01-Login'
-}) %>
+
 
-<%= include('../_includes/_getting_started', { library: 'JavaScript', callback: 'http://localhost:3000' }) %>
+<%= 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/articles/quickstart/spa/vanillajs/02-calling-an-api.md b/articles/quickstart/spa/vanillajs/02-calling-an-api.md
new file mode 100644
index 0000000000..054a024fc8
--- /dev/null
+++ b/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 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` - 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. 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. 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/articles/quickstart/spa/vanillajs/02-user-profile.md b/articles/quickstart/spa/vanillajs/02-user-profile.md
deleted file mode 100644
index 2fde731de6..0000000000
--- a/articles/quickstart/spa/vanillajs/02-user-profile.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch a user's information from Auth0
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '02-User-Profile'
-}) %>
-
-<%= include('../_includes/_user_profile_preamble') %>
-
-## Request the Profile Scope
-
-To retrieve user information, request a scope of `openid profile` in the instance of the `auth0WebAuth` object. 
-
-```js
-// app.js
-
-var webAuth = new auth0.WebAuth({
-  // ...
-  scope: 'openid profile'
-});
-``` 
-
-## Make a Call for the User's Information
-
-<%= include('../_includes/_user_profile_auth0js_method') %>
-
-Add a function which calls `client.userInfo` to the `Auth` service.
-
-```js
-// app.js
-
-var userProfile;
-
-function getProfile() {
-  if (!userProfile) {
-    var accessToken = localStorage.getItem('access_token');
-
-    if (!accessToken) {
-      console.log('Access Token must exist to fetch profile');
-    }
-
-    webAuth.client.userInfo(accessToken, function(err, profile) {
-      if (profile) {
-        userProfile = profile;
-        displayProfile();
-      }
-    });
-  } else {
-    displayProfile();
-  }
-}
-
-function displayProfile() {
-  // display the profile
-  document.querySelector('#profile-view .nickname').innerHTML =
-    userProfile.nickname;
-    
-  document.querySelector(
-    '#profile-view .full-profile'
-  ).innerHTML = JSON.stringify(userProfile, null, 2);
-
-  document.querySelector('#profile-view img').src = userProfile.picture;
-}
-```
-
-<%= include('../_includes/_user_profile_in_memory') %>
-
-## Add a Profile Template
-
-Add a template to display the user's profile.
-
-```html
-
-
-
        
-  
-  
        
-    
        
-  
        
-
-  
-  
        
-    
        Profile
        
-      
        
-        avatar
-        
        
-          
-          
        
-        
        
-        
        
-      
        
-  
        
-
        
-```
-
-<%= include('../_includes/_user_profile_additional_info') %>
diff --git a/articles/quickstart/spa/vanillajs/03-calling-an-api.md b/articles/quickstart/spa/vanillajs/03-calling-an-api.md
deleted file mode 100644
index a71d096b65..0000000000
--- a/articles/quickstart/spa/vanillajs/03-calling-an-api.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Calling an API
-description: This tutorial demonstrates how to make API calls for protected resources on your server
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '03-Calling-an-API'
-}) %>
-
-<%= include('../_includes/_calling_api_preamble') %>
-
-<%= include('../_includes/_calling_api_create_api') %>
-
-<%= include('../_includes/_calling_api_create_scope') %>
-
-## Set the Audience and Scope in `auth0.WebAuth`
-
-In your `auth0.WebAuth` instance, enter your API identifier as the value for `audience`.
-Add your scopes to the `scope` key.
-
-```js
-// app.js
-
-var webAuth = new auth0.WebAuth({
-  // ...
-  audience: '${apiIdentifier}',
-  scope: 'openid profile read:messages'
-});
-```
-
-<%= include('../_includes/_calling_api_use_rules') %>
-
-## Configure a Custom XHR Request
-
-<%= include('../_includes/_calling_api_access_token') %>
-
-To attach the user's Access Token to HTTP calls as an `Authorization` header, add the header as an option to your requests. 
-
-::: note
-We recommend you implement a custom function which adds the header automatically.
-:::
-
-Create a new function called `callAPI`. The function wraps an XHR request with the user's Access Token included as the `Authorization` header.
-
-```js
-// app.js
-
-var apiUrl = 'http://localhost:3001/api';
-
-// ...
-function callAPI(endpoint, secured) {
-  var url = apiUrl + endpoint;
-  var xhr = new XMLHttpRequest();
-  xhr.open('GET', url);
-  if (secured) {
-    xhr.setRequestHeader(
-      'Authorization',
-      'Bearer ' + localStorage.getItem('access_token')
-    );
-  }
-  xhr.onload = function() {
-    if (xhr.status == 200) {
-      // update message
-      document.querySelector('#ping-view h2').innerHTML = JSON.parse(
-        xhr.responseText
-      ).message;
-    } else {
-      alert('Request failed: ' + xhr.statusText);
-    }
-  };
-  xhr.send();
-}
-```
-
-<%= include('../_includes/_calling_api_protect_resources') %>
diff --git a/articles/quickstart/spa/vanillajs/04-authorization.md b/articles/quickstart/spa/vanillajs/04-authorization.md
deleted file mode 100644
index 7a6a53967d..0000000000
--- a/articles/quickstart/spa/vanillajs/04-authorization.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how to add authorization and access control to your application
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '04-Authorization'
-}) %>
-
-<%= include('../_includes/_authz_preamble') %>
-
-<%= include('../_includes/_authz_determining_scopes') %>
-
-## Handle Scopes in the `app.js` File
-
-Adjust your `app.js` file, so it uses a local member with any scopes you want to request when users log in. Use this member in your instance of the `auth0.WebAuth` object.
-
-```js
-// app.js
-
-var requestedScopes = 'openid profile read:messages write:messages';
-
-var auth0 = new auth0.WebAuth({
-  // ...
-  scope: requestedScopes
-});
-``` 
-
-<%= include('../_includes/_authz_set_session') %>
-
-```js
-// app.js
-
-function setSession(authResult) {
-  
-  const scopes = authResult.scope || requestedScopes || '';
-
-  // ...
-  localStorage.setItem('scopes', JSON.stringify(scopes));
-}
-```
-
-Add a function called `userHasScopes` that checks for scopes in local storage. Add an array of strings to the method. Check if the array of scopes saved in local storage contains those values. 
-You can use this method to conditionally hide and show UI elements to the user and to limit route access.
-
-```js
-// app.js
-
-function userHasScopes(scopes) {
-  var savedScopes = JSON.parse(localStorage.getItem('scopes'));
-  if (!savedScopes) return false;
-  var grantedScopes = savedScopes.split(' ');
-  for (var i = 0; i < scopes.length; i++) {
-    if (grantedScopes.indexOf(scopes[i]) < 0) {
-      return false;
-    }
-  }
-  return true;
-}
-```
-
-## Conditionally Display UI Elements
-
-You can use the `userHasScopes` function with the `isAuthenticated` function to show and hide certain UI elements.
-
-```js
-// app.js
-
-// ...
-function displayButtons() {
-  // ...
-  if (!isAuthenticated || !userHasScopes(['write:messages'])) {
-    adminViewBtn.style.display = 'none';
-  } else {
-    adminViewBtn.style.display = 'inline-block';
-  }
-}
-```
-
-## Protect Client-Side Routes
-
-You may want to give access to some routes in your application only to authenticated users. You can check if the user is authenticated with the `userHasScopes` function.
-
-Depending on the routing library you use, you apply the `userHasScopes` function differently. 
-
-Some routing libraries provide hooks which run a function before the route is activated. This kind of hook might be called something like `beforeEnter` or `onEnter`. This is a good place to run the `userHasScopes` function to check whether the user has the scopes required to enter the route.
-
-<%= include('../_includes/_authz_conditionally_assign_scopes') %>
-
-<%= include('../_includes/_authz_client_routes_disclaimer') %>
diff --git a/articles/quickstart/spa/vanillajs/05-token-renewal.md b/articles/quickstart/spa/vanillajs/05-token-renewal.md
deleted file mode 100644
index 358c4c3a53..0000000000
--- a/articles/quickstart/spa/vanillajs/05-token-renewal.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Token Renewal
-description: This tutorial demonstrates how to add automatic Access Token renewal to an application with Auth0
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '05-Token-Renewal'
-}) %>
-
-<%= include('../_includes/_token_renewal_preamble') %>
-
-## Add Token Renewal
-
-In the `app.js` file, add a function which calls the `checkSession` method from auth0.js. If the renewal is successful, use the existing `setSession` method to set the new tokens in local storage.
-
-```js
-// app.js
-
-function renewToken() {
-  webAuth.checkSession({},
-    function(err, result) {
-      if (err) {
-        console.log(err);
-      } else {
-        setSession(result);
-      }
-    }
-  );
-}
-```
-
-The Access Token should be renewed when it expires. In this tutorial, the expiry time of the token is stored in local storage as `expires_at`.
-
-::: note
-You can define any timing mechanism you want. You can choose any library that handles timers. This example shows how to use a `setTimeout` call. 
-:::
-
-In the `app.js` file, add a variable called `tokenRenewalTimeout`. The variable refers to the `setTimeout` call used to schedule the renewal. Next, add a function called `scheduleRenewal` to set up the time when authentication is silently renewed.
-
-The method subtracts the current time from the Access Token's expiry time and calculates delay. 
-The `setTimeout` call uses the calculated delay and makes a call to `renewToken`.
-
-The `setTimeout` call is assigned to the `tokenRenewalTimeout` property. When the user logs out, the timeout is cleared. 
-
-```js
-// app.js
-
-var tokenRenewalTimeout;
-// ...
-function scheduleRenewal() {
-  var expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-  var delay = expiresAt - Date.now();
-  if (delay > 0) {
-    tokenRenewalTimeout = setTimeout(function() {
-      renewToken();
-    }, delay);
-  }
-}
-```
-
-You can now include a call to the `scheduleRenewal` method in the `setSession` function.
-
-
-```js
-// app.js
-
-// ...
-function setSession(authResult) {
-  // Set the time that the Access Token will expire at
-  var expiresAt = JSON.stringify(
-    authResult.expiresIn * 1000 + new Date().getTime()
-  );
-  localStorage.setItem('access_token', authResult.accessToken);
-  localStorage.setItem('id_token', authResult.idToken);
-  localStorage.setItem('expires_at', expiresAt);
-  scheduleRenewal();
-}
-```
-
-To schedule renewing the tokens when the page is refreshed, add a call to the `scheduleRenewal` method immediately when the page loads.
-
-```js
-// app.js
-
-window.addEventListener('load', function() {
-  // ...
-  scheduleRenewal();
-});
-```
-
-Since client-side sessions should not be renewed after the user logs out, use `clearTimeout` in the `logout` method to cancel the renewal.
-
-```js
-// app.js
-
-function logout() {
-  // ...
-  clearTimeout(tokenRenewalTimeout);
-}
-```
-
-<%= include('../_includes/_token_renewal_troubleshooting') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md b/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
index a77fd7d40f..8d85dd25fe 100644
--- a/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
+++ b/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
@@ -1,197 +1,401 @@
-<%= include('../../_includes/_login_preamble', { library: 'JavaScript', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-javascript-samples/tree/embedded-login/01-Embedded-Login'}) %>
+
 
-## Create an Authentication Service
+<%= include('../../_includes/_login_preamble', { library: 'JavaScript' }) %>
 
-Add a new file called `app.js`. In the file, you can create and manage an instance of the `auth0.WebAuth` object. In that instance, you can define the following:
+## Setting Up the Application
 
-<%= include('../../_includes/_auth_service_configure_client_details') %>
+### Create a basic HTML page
 
-::: note
-In this case, the route is the main URL for your application.
+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. 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 as configured above.
+
+```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.
 :::
 
-You can also use it to hold logic for hiding and displaying DOM elements.
+## Create the server
 
-```js
-// app.js
+In this section you will create a basic web server using ExpressJS. This will be used to serve our HTML page, along with any assets that it requires (JavaScript, CSS, etc).
 
-window.addEventListener('load', function() {
+Run the following command in the same folder as the `index.html` file you created earlier:
 
-  var webAuth = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    responseType: 'token id_token',
-    audience: 'https://${account.namespace}/userinfo',
-    scope: 'openid',
-    redirectUri: window.location.href
-  });
+```bash
+npm init -y
+```
 
-  var loginBtn = document.getElementById('btn-login');
+This will initialize a new NPM project and get us ready to install dependencies.
 
-  loginBtn.addEventListener('click', function(e) {
-    e.preventDefault();
-    webAuth.authorize();
-  });
+### 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` 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"));
 ```
 
-::: note
-**Checkpoint:** Try to add a button with the `btn-login` ID to your app. This will call the `authorize` method from auth0.js so you can see the login page.
-:::
+The server provides two endpoints:
 
-![hosted login](/media/articles/web/hosted-login.png)
+- 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
 
-### Finish the Authentication Functions
+The app also serves all of the static files, such as the `.js` and `.css` files from the `/public` folder.
 
-Add more functions to the `app.js` file to handle authentication in the app.
+## Initialize the SDK
 
-The example below shows the following functions:
-* `handleAuthentication`: looks for the result of authentication in the URL hash and processes it with the `parseHash` method from auth0.js
-* `setSession`: sets the user's Access Token, ID Token, and the Access Token's expiry time 
-* `logout`: removes the user's tokens and expiry time from browser storage
-* `isAuthenticated`: checks whether the expiry time for the user's Access Token has passed
+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
-// app.js
+let auth0Client = null;
+```
 
-window.addEventListener('load', function() {
+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:
 
-  // ...
-  var loginStatus = document.querySelector('.container h4');
-  var loginView = document.getElementById('login-view');
-  var homeView = document.getElementById('home-view');
-
-  // buttons and event listeners
-  var homeViewBtn = document.getElementById('btn-home-view');
-  var loginBtn = document.getElementById('btn-login');
-  var logoutBtn = document.getElementById('btn-logout');
-
-  homeViewBtn.addEventListener('click', function() {
-    homeView.style.display = 'inline-block';
-    loginView.style.display = 'none';
+```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
   });
+};
+```
 
-  logoutBtn.addEventListener('click', logout);
-
-  function handleAuthentication() {
-    webAuth.parseHash(function(err, authResult) {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        setSession(authResult);
-        loginBtn.style.display = 'none';
-        homeView.style.display = 'inline-block';
-      } else if (err) {
-        homeView.style.display = 'inline-block';
-        console.log(err);
-        alert(
-          'Error: ' + err.error + '. Check the console for further details.'
-        );
-      }
-      displayButtons();
-    });
-  }
+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.
 
-  function setSession(authResult) {
-    // Set the time that the Access Token will expire at
-    var expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
+Add a handler for the `window.onload` function that will then make this call to initialize the application:
 
-  function logout() {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    displayButtons();
-  }
+```js
+// ..
 
-  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;
-  }
+window.onload = async () => {
+  await configureClient();
+}
+```
+
+Now go and access it at 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.
 
-  function displayButtons() {
-    if (isAuthenticated()) {
-      loginBtn.style.display = 'none';
-      logoutBtn.style.display = 'inline-block';
-      loginStatus.innerHTML = 'You are logged in!';
-    } else {
-      loginBtn.style.display = 'inline-block';
-      logoutBtn.style.display = 'none';
-      loginStatus.innerHTML =
-        'You are not logged in! Please log in to continue.';
+## Log In to the Application
+
+Authentication is achieved through a redirect to the Auth0 Universal Login Page. 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
     }
-  }
-});
+  });
+};
 ```
 
-## Provide a Login Control
+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:
 
-Provide a template with controls for the user to log in and out.
+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.
 
-```html
-
-
-
        
-  
-
-  
        
-    
-    
        
-      
        
-    
        
+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, "/");
+  }
+};
+
+// ..
 ```
 
-::: note
-This example uses Bootstrap styles. You can use any style library, or not use one at all.
+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.
 :::
 
-Depending on whether the user is authenticated or not, they see the **Log In** or **Log Out** button. The `click` event listeners on the buttons make calls to functions in the `app.js` file to let the user log in or out. When the user clicks **Log In**, they are redirected to the login page. 
+## 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
+    }
+  });
+};
+```
 
-<%= include('../../_includes/_hosted_login_customization' }) %>
+> **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.
 
-## Process the Authentication Result
+If you see any errors from the Auth0 server, check that you have not forgotten to register the logout URL as explained initially.
 
-When a user authenticates at the login page, they are redirected to your application. Their URL contains a hash fragment with their authentication information. The `handleAuthentication` method in the `app.js` file processes the hash. 
+## Read the User Profile
 
-Call the `handleAuthentication` method in the `app.js` file. The method processes the authentication hash while your app loads. 
+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
-// app.js
+// ...
 
-window.addEventListener('load', function() {
+const updateUI = async () => { 
+  const isAuthenticated = await auth0Client.isAuthenticated();
 
-  // ...
-  handleAuthentication();
-});
+  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/articles/quickstart/spa/vanillajs/dashboard-default.md b/articles/quickstart/spa/vanillajs/dashboard-default.md
deleted file mode 100644
index f03c22cdd0..0000000000
--- a/articles/quickstart/spa/vanillajs/dashboard-default.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use Auth0 to add authentication and authorization to your web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-javascript-samples',
-  path: '01-Login'
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/vanillajs/download.md b/articles/quickstart/spa/vanillajs/download.md
new file mode 100644
index 0000000000..cec2290b43
--- /dev/null
+++ b/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 to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the Application Settings to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the Application Settings to
+```text
+http://localhost:3000
+```
+4) Make sure Node.JS LTS 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 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/articles/quickstart/spa/vanillajs/files/app.md b/articles/quickstart/spa/vanillajs/files/app.md
new file mode 100644
index 0000000000..52be06a92e
--- /dev/null
+++ b/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/articles/quickstart/spa/vanillajs/index.yml b/articles/quickstart/spa/vanillajs/index.yml
index 944a21b9b4..69ef28e4e9 100644
--- a/articles/quickstart/spa/vanillajs/index.yml
+++ b/articles/quickstart/spa/vanillajs/index.yml
@@ -1,9 +1,22 @@
 title: JavaScript
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/html5.png
+logo: javascript
 language:
   - JavaScript
-image: /media/platforms/html5.png
-tags:
+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
@@ -17,10 +30,34 @@ alias:
   - backendless
   - javascript-app
 seo_alias: vanillajs
-default_article: dashboard-default
+default_article: 01-login
+hidden_articles:
+  - interactive
 articles:
   - 01-login
-  - 02-user-profile
-  - 03-calling-an-api
-  - 04-authorization
-  - 05-token-renewal
+  - 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/articles/quickstart/spa/vanillajs/interactive.md b/articles/quickstart/spa/vanillajs/interactive.md
new file mode 100644
index 0000000000..6e52ab3a31
--- /dev/null
+++ b/articles/quickstart/spa/vanillajs/interactive.md
@@ -0,0 +1,80 @@
+---
+title: Add Login to Your JavaScript Application
+description: 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.
+interactive:  true
+files:
+ - files/app
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# 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.
        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.
        This quickstart assumes you are adding Auth0 to a plain JavaScript application, as opposed to using a framework such as React or Angular.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## 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:
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js"></script>
+
+
        
+
+
        
+
+## 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.
        Javascript quickstart step 4 checkpoint 
        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 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
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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.
        Javascript quickstart step 5 checkpoint 
        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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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. 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, 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.
        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.
        javascript quickstart step 6 checkpoint 
        
+
+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.
        
+
+  
        
+
+  
        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 for further errors
        Still having issues? To get more help, check out our documentation or visit our community page.
        
+
+  
        
+
+## 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 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.
        Javascript quickstart step 7 checkpoint 
        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.
        
+
+  
        
+
+  
        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 for further errors relating to silent authentication
        Still having issues? To get more help, check out our documentation or visit our community page.
        
+
+  
        
diff --git a/articles/quickstart/spa/vuejs/01-login.md b/articles/quickstart/spa/vuejs/01-login.md
index 3f93f65af6..3ba7176094 100644
--- a/articles/quickstart/spa/vuejs/01-login.md
+++ b/articles/quickstart/spa/vuejs/01-login.md
@@ -1,18 +1,29 @@
 ---
 title: Login
-description: This tutorial demonstrates how to add user login to your application with Auth0
+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
 ---
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-vue-samples',
-  path: '01-Login',
-  requirements: [
-    'Vue 2.0'
-  ]
-}) %>
+
+:::note
+Visit the Vue.js Authentication By Example 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.
+:::
 
-<%= include('../_includes/_getting_started', { library: 'Vue.js', callback: 'http://localhost:3000/callback' }) %>
+::: warning
+This quickstart is designed for using Auth0 Vue with Vue 3 applications. If you are using Vue 2, please check out the Vue 2 Tutorial with Auth0 SPA SDK instead or visit the Vue.js Authentication 2 By Example guide.
+:::
 
-<%= include('_includes/_centralized_login') %>
+<%= 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/articles/quickstart/spa/vuejs/02-calling-an-api.md b/articles/quickstart/spa/vuejs/02-calling-an-api.md
new file mode 100644
index 0000000000..3f9ca61b25
--- /dev/null
+++ b/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 section of the Vue.js Authentication By Example 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/articles/quickstart/spa/vuejs/_includes/_centralized_login.md b/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
index c70a302191..878c0ed504 100644
--- a/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
+++ b/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
@@ -1,199 +1,203 @@
-<%= include('../../_includes/_login_preamble', { library: 'Vue.js', embeddedLoginLink: 'https://github.com/auth0-samples/auth0-vue-samples/tree/embedded-login/01-Embedded-Login'}) %>
+
 
-## Create an Authentication Service
+## Install the SDK
 
-The best way to manage and coordinate the tasks necessary for user authentication is to create a reusable service. With the service in place, you'll be able to call its methods throughout your application. The name for it is at your discretion, but in these examples it will be called `AuthService` and the filename will be `AuthService.js`. An instance of the `WebAuth` object from **auth0.js** can be created in the service.
+Install the Auth0 Vue SDK using npm:
 
-Create a service and instantiate `auth0.WebAuth`. Provide a method called `login` which calls the `authorize` method from auth0.js.
+```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
-// src/Auth/AuthService.js
-
-import auth0 from 'auth0-js'
-import { AUTH_CONFIG } from './auth0-variables'
-import EventEmitter from 'eventemitter3'
-import router from './../router'
-
-export default class AuthService {
-
-  constructor () {
-    this.login = this.login.bind(this)
-    this.setSession = this.setSession.bind(this)
-    this.logout = this.logout.bind(this)
-    this.isAuthenticated = this.isAuthenticated.bind(this)
-  }
-
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:3000/callback',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  })
+import { createAuth0 } from '@auth0/auth0-vue';
 
-  login () {
-    this.auth0.authorize()
-  }
-}
-```
+const app = createApp(App);
 
-::: note
-**Checkpoint:** Try calling the `login` method from somewhere in your application. This could be from a button click or in some lifecycle event, just something that will trigger the method so you can see the login page.
-:::
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  })
+);
 
-![hosted login](/media/articles/web/hosted-login.png)
+app.mount('#app');
+```
 
-### Finish Out the Service
+The plugin will register the SDK using both `provide` and `app.config.globalProperties`, allowing the SDK to be used with both the Composition API and Options API.
 
-Add some additional methods to the `Auth` service to fully handle authentication in the app. 
+## Add Login to Your Application
 
-Install the EventEmitter required by the service.
+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.
 
-`npm install --save EventEmitter`
+```html
+
+
 ```
 
-The service now includes several other methods for handling authentication.
+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.
 
-* `handleAuthentication` - looks for an authentication result in the URL hash and processes it with the `parseHash` method from auth0.js
-* `setSession` - sets the user's `access_token`, `id_token`, and a time at which the `access_token` will expire
-* `logout` - removes the user's tokens from browser storage
-* `isAuthenticated` - checks whether the expiry time for the `access_token` has passed
+#### 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.
 
-### About the Authentication Service
+```html
+
 
-<%= include('../../_includes/_auth_service_method_description_auth0js') %>
+
+```
+
+## 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.
 
-## Provide a Login Control
+```html
+
+
+```
 
-${snippet(meta.snippets.use)}
+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
-This example uses Bootstrap styles, but that's unimportant. Use whichever style library you like, or don't use one at all.
+:::note
+To log the user out of your application but not from Auth0, use `logout({ localOnly: true })`.
 :::
 
-The `@click` events on the **Log In** and **Log Out** buttons make the appropriate calls to the `AuthService` to allow the user to log in and log out. Notice that these buttons are conditionally hidden and shown depending on whether or not the user is currently authenticated.
+#### 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.
 
-When the **Log In** button is clicked, the user will be redirected to login page.
+```html
+
 
-<%= include('../../_includes/_hosted_login_customization' }) %>
+
+```
 
-## Add a Callback Component
+## Show User Profile Information
 
-Using universal login means that users are taken away from your application to a login page hosted by Auth0. After they successfully authenticate, they are returned to your application where a client-side session is set for them.
+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.
 
-<%= include('../../_includes/_callback_component') %>
+```html
+
+
+```
 
-Create a component named `CallbackComponent` and populate it with a loading indicator. The component should also call `handleAuthentication` from the `AuthService`.
+:::note
+Ensure the user is authenticated by implementing login in your application before accessing the user's profile.
+:::
 
-```js
-// src/components/Callback.vue
+#### 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
 
 
 
-
-
 ```
-
-::: note
-This example assumes some kind of loading spinner is available in the `assets` directory. See the downloadable sample for a demonstration.
-:::
-
-After authentication, users will be taken to the `/callback` route for a brief time where they will be shown a loading indicator. During this time, their client-side session will be set, after which they will be redirected to the `/home` route.
-
-::: note
-This example assumes you are using path-based routing with `mode: 'history'`. If you are using hash-based routing, you won't be able to specify a dedicated callback route because the URL hash will be used to hold the user's authentication information.
-:::
diff --git a/articles/quickstart/spa/vuejs/dashboard-default.md b/articles/quickstart/spa/vuejs/dashboard-default.md
deleted file mode 100644
index 369d940078..0000000000
--- a/articles/quickstart/spa/vuejs/dashboard-default.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add user login to your application with Auth0
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-vue-samples',
-  path: '01-Login',
-  requirements: [
-    'Vue 2.0'
-  ]
-}) %>
-
-<%= include('../../../_includes/_callback_url') %>
-
-If you are following along with the downloadable sample projects for this tutorial directly, the **Callback URL** should be set to
-
-```bash
-http://localhost:3000/callback
-```
-
-<%= include('../_includes/_install_auth0js') %>
-
-<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/articles/quickstart/spa/vuejs/download.md b/articles/quickstart/spa/vuejs/download.md
new file mode 100644
index 0000000000..3f5a35beed
--- /dev/null
+++ b/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 to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the Application Settings to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the Application Settings to 
+
+```text
+http://localhost:3000
+```
+4) Make sure Node.JS LTS 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 image with the following commands:
+
+```bash
+# In Linux / macOS         
+sh exec.sh                 
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/spa/vuejs/files/index.md b/articles/quickstart/spa/vuejs/files/index.md
new file mode 100644
index 0000000000..7f2f476128
--- /dev/null
+++ b/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');
+```
diff --git a/articles/quickstart/spa/vuejs/files/login.md b/articles/quickstart/spa/vuejs/files/login.md
new file mode 100644
index 0000000000..21ef76110f
--- /dev/null
+++ b/articles/quickstart/spa/vuejs/files/login.md
@@ -0,0 +1,37 @@
+---
+name: login.js
+language: javascript
+---
+    
+```javascript
+
+
+```
diff --git a/articles/quickstart/spa/vuejs/files/logout.md b/articles/quickstart/spa/vuejs/files/logout.md
new file mode 100644
index 0000000000..6e0420788f
--- /dev/null
+++ b/articles/quickstart/spa/vuejs/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.js
+language: javascript
+---
+    
+```javascript
+
+
+```
diff --git a/articles/quickstart/spa/vuejs/files/profile.md b/articles/quickstart/spa/vuejs/files/profile.md
new file mode 100644
index 0000000000..97966a2320
--- /dev/null
+++ b/articles/quickstart/spa/vuejs/files/profile.md
@@ -0,0 +1,50 @@
+---
+name: profile.js
+language: javascript
+---
+    
+```javascript
+
+
+```
diff --git a/articles/quickstart/spa/vuejs/index.yml b/articles/quickstart/spa/vuejs/index.yml
index bb4a07a0a6..ead0c3b600 100644
--- a/articles/quickstart/spa/vuejs/index.yml
+++ b/articles/quickstart/spa/vuejs/index.yml
@@ -1,11 +1,24 @@
 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
-image: /media/platforms/vue.png
-tags:
+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
@@ -15,6 +28,33 @@ alias:
   - vuejs
   - vue.js
 seo_alias: vuejs
-default_article: dashboard-default
+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/articles/quickstart/spa/vuejs/interactive.md b/articles/quickstart/spa/vuejs/interactive.md
new file mode 100644
index 0000000000..79579ff02b
--- /dev/null
+++ b/articles/quickstart/spa/vuejs/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Add Login to Your Vue Application
+description: This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Vue application using the Auth0 Vue SDK.
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# 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.
        This quickstart is designed for using Auth0 Vue with Vue 3 applications. If you are using Vue 2, please check out the Vue 2 Tutorial with Auth0 SPA SDK instead or visit the Vue.js Authentication 2 By Example 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.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Install the Auth0 Vue SDK {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Auth0 provides a Vue SDK 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:
        cd <your-project-directory>
+
+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, 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 and Options API.
        vue quickstart step 2 checkpoint 
        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
        
+
+  
        
+
+  
        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 or visit our community page 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.
        Vue quickstart step 3 checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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 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.
        Using the Options API
        With the Options API, you can use the same logout method from the global $auth0 property through the this accessor.
        vue quickstart step 4 checkpoint 
        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
        
+
+  
        
+
+  
        
+
+  
        
+
+## Show user profile information {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        Next, you will configure how to retrieve the profile information 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.
        vue step 5 checkpoint 
        Verify that:
        • you can display the user or any of the user properties within a component correctly after you have logged in
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md b/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md
new file mode 100644
index 0000000000..5d4e22286d
--- /dev/null
+++ b/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. 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 document.
+:::
diff --git a/articles/quickstart/webapp/_includes/_create_and_assign_roles.md b/articles/quickstart/webapp/_includes/_create_and_assign_roles.md
new file mode 100644
index 0000000000..f3e0826c9d
--- /dev/null
+++ b/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 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 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 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, 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.
+:::
\ No newline at end of file
diff --git a/articles/quickstart/webapp/_includes/_getting_started.md b/articles/quickstart/webapp/_includes/_getting_started.md
index 4bdc8892af..cf81e08a55 100644
--- a/articles/quickstart/webapp/_includes/_getting_started.md
+++ b/articles/quickstart/webapp/_includes/_getting_started.md
@@ -1,14 +1,13 @@
-## Before you start
+
 
-This guide walks you through setting up authentication and authorization in your ${library} apps with Auth0. If you are new to Auth0 we suggest you check our [Overview](/overview). For a complete picture of authentication and authorization for regular web apps, check our [Single Sign-On for Regular Web Apps](/architecture-scenarios/application/web-app-sso#authentication-flow) documentation.
-
-Auth0 uses OAuth. If you want to learn more about the OAuth flows used by regular web apps, read about [Authentication for Server-side Web Apps](/application-auth/current/server-side-web).
+::: note
+**New to Auth?** Learn How Auth0 works, how it integrates with Regular Web Applications and which protocol it uses.
+:::
 
-<%= include('../../../_includes/_new_app') %>
+<%= 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, **Callback URL** should be set to
-`${callback}`.
+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/articles/quickstart/webapp/_includes/_mfa-enable.md b/articles/quickstart/webapp/_includes/_mfa-enable.md
index 187dca8f25..4814dee4fc 100644
--- a/articles/quickstart/webapp/_includes/_mfa-enable.md
+++ b/articles/quickstart/webapp/_includes/_mfa-enable.md
@@ -1,5 +1,5 @@
-To enable the Auth0 MFA feature, open the [Multifactor Auth With Guardian](${manage_url}/#/guardian) page and enable the __Push Notifications__ option as shown below:
+To enable the Auth0 MFA feature, open the Multi-factor Auth With 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 Multifactor authentication in your application.
\ No newline at end of file
+Click __Save__ and you are ready to test Multi-factor authentication in your application.
\ No newline at end of file
diff --git a/articles/quickstart/webapp/_includes/_mfa-introduction.md b/articles/quickstart/webapp/_includes/_mfa-introduction.md
index 2be68687f7..2a60dfc0f4 100644
--- a/articles/quickstart/webapp/_includes/_mfa-introduction.md
+++ b/articles/quickstart/webapp/_includes/_mfa-introduction.md
@@ -1 +1 @@
-Multifactor 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 will be required. Currently, Auth0 supports [Auth0 Guardian](/multifactor-authentication/guardian), Google Authenticator and Duo. For more details, see [Multifactor Authentication in Auth0](/multifactor-authentication).
+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.
diff --git a/articles/quickstart/webapp/_includes/_mfa-login.md b/articles/quickstart/webapp/_includes/_mfa-login.md
index e868c33478..0e91d41282 100644
--- a/articles/quickstart/webapp/_includes/_mfa-login.md
+++ b/articles/quickstart/webapp/_includes/_mfa-login.md
@@ -1,7 +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).
+There is no need to update the code you created in the Login 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: [How to Use the Guardian App](/multifactor-authentication/guardian/user-guide).
+For detailed instructions on using Guardian to authenticate users, see Guardian.
 
-For advanced management of the multifactor authentication for your users, see [Step-up Authentication](/multifactor-authentication/developer/step-up-with-acr).
diff --git a/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md b/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
index 07cd50cfe0..9dfb6eee06 100644
--- a/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
+++ b/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
@@ -1 +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
+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.
\ No newline at end of file
diff --git a/articles/quickstart/webapp/apache/01-login.md b/articles/quickstart/webapp/apache/01-login.md
index e31ce82483..106a587320 100644
--- a/articles/quickstart/webapp/apache/01-login.md
+++ b/articles/quickstart/webapp/apache/01-login.md
@@ -3,6 +3,13 @@ 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
@@ -16,9 +23,9 @@ This tutorial and seed project have been tested with the following:
 
 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)
+You can get the binaries from Github and install them for your OS. If your OS isn't compatible with any of the binaries, you can still build it from source
 
-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)
+Once you've installed it, you just need to enable it for Apache (If you are using Windows, you can use this to get `a2enmod` working on your system)
 
 ${snippet(meta.snippets.dependencies)}
 
diff --git a/articles/quickstart/webapp/apache/files/auth_openidc.md b/articles/quickstart/webapp/apache/files/auth_openidc.md
new file mode 100644
index 0000000000..44d311ab8e
--- /dev/null
+++ b/articles/quickstart/webapp/apache/files/auth_openidc.md
@@ -0,0 +1,23 @@
+---
+name: auth_openidc.conf
+language: 
+---
+    
+```
+OIDCProviderMetadataURL https://${account.namespace}/.well-known/openid-configuration OIDCClientID ${account.clientId} 
+OIDCClientSecret ${account.clientSecret}
+OIDCScope "openid name email" 
+OIDCRedirectURI https://your_apache_server/your_path/redirect_uri/ OIDCCryptoPassphrase  
+
+ 
+   AuthType openid-connect 
+   Require valid-user 
+   LogLevel debug 
+
+
+ 
+   AuthType openid-connect 
+   #Require valid-user 
+   Require claim folder:admin 
+
+```
diff --git a/articles/quickstart/webapp/apache/index.yml b/articles/quickstart/webapp/apache/index.yml
index 4b8f60e0e6..867ba92073 100644
--- a/articles/quickstart/webapp/apache/index.yml
+++ b/articles/quickstart/webapp/apache/index.yml
@@ -1,8 +1,10 @@
 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
-image: /media/platforms/apache.jpg
-tags:
+topics:
   - quickstart
 snippets:
   dependencies: server-platforms/apache/dependencies
@@ -12,3 +14,7 @@ seo_alias: apache
 default_article: 01-login
 articles:
   - 01-login
+hidden_articles:
+  - interactive
+contentType: tutorial
+useCase: quickstart
diff --git a/articles/quickstart/webapp/apache/interactive.md b/articles/quickstart/webapp/apache/interactive.md
new file mode 100644
index 0000000000..7fa4dd02c3
--- /dev/null
+++ b/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,49 @@
+---
+title: Apache
+description: This tutorial demonstrates how to configure Apache to add authentication and authorization to your web app.
+interactive:  true
+files:
+ - files/auth_openidc
+locale: en-US
+---
+
+# Apache
+
+
+
        This tutorial demonstrates how to configure Apache to add authentication and authorization to your web app. We recommend that you log in to follow this quickstart with examples configured for your account.
        System Requirements
        This tutorial and sample project have been tested with the following:
        • Apache 2.4
        
+
+## Install and Enable mod_auth_openidc Module
+
+
+
        First, install the mod_auth_openidc module for Apache.
        You can get the binaries from GitHub and install them for your OS. If your OS isn't compatible with any of the binaries, you can still build it from source.
        Once you've installed the module, enable it for Apache with the a2enmod command. To learn more, read a2enmod on Ubuntu Manpage:
        a2enmod auth_openidc
        For Windows, you can use this Powershell script to get a2enmod working on your system.
        
+
+## Configure the Module with Your Auth0 Account Information {{{ data-action="code" data-code="auth_openidc.conf#1:12" }}}
+
+
+
        Update your new configuration file (auth_openidc.conf), located in the /etc/apache2/mods-available folder.
        For Windows, you must use the /apache/conf/httpd.conf file.
        
+
+## Configure Auth0
+
+
+
        In the Auth0 Dashboard:
        1. Go to Applications > Applications, and then select your application from the list.
        2. Switch to the Settings view, and then locate the Application URIs section.
        3. Add the value of OIDCRedirectURI to Allowed Callback URLs.
        4. Locate Advanced Settings at the bottom of the page.
        5. Switch to the OAuth view.
        6. Set JSON Web Token (JWT) Signature Algorithm to RS256.
        
+
+## Authorization {{{ data-action="code" data-code="auth_openidc.conf#14:18" }}}
+
+
+
        You can configure Apache to protect a specific location based on the value of a claim in the user’s ID token by adding a Location block to your auth_openidc.conf file.
        For example, you could create an Action that reads the user’s roles, and then adds a claim that grants access to a protected location:
        exports.onExecutePostLogin = async (event, api) => {
+
+  const roles = event.authorization.roles; // ['user', 'admin']
+
+
+
+  if (roles.includes('admin')) {
+
+    api.idToken.setCustomClaim('folder', 'admin');
+
+  }
+
+};
+
+
        
+
+
        
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md b/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md
new file mode 100644
index 0000000000..d89302827e
--- /dev/null
+++ b/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, this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate Auth0
+
+Universal 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
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/download.md b/articles/quickstart/webapp/aspnet-core-blazor-server/download.md
new file mode 100644
index 0000000000..716f07b7a3
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback,https://localhost:7113/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://localhost:3000,https://localhost:7113
+```
+
+3) Make sure .NET Core is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a Docker image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.md
new file mode 100644
index 0000000000..bc1fc7b36d
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md
new file mode 100644
index 0000000000..9e54f3d16d
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md
new file mode 100644
index 0000000000..bb161024d6
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md
new file mode 100644
index 0000000000..c2f7bf7a8a
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md
new file mode 100644
index 0000000000..8ba8d1d890
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
new file mode 100644
index 0000000000..b20d6763a5
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
@@ -0,0 +1,37 @@
+---
+name: Profile.razor
+language: 
+---
+    
+```
+@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();
+    }
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md b/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md
new file mode 100644
index 0000000000..80c23e3cb0
--- /dev/null
+++ b/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();
+```
diff --git a/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml b/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml
new file mode 100644
index 0000000000..96471ac09d
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md b/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
new file mode 100644
index 0000000000..cd6cb2111d
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
@@ -0,0 +1,61 @@
+---
+title: Add Login to your Blazor Server Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Blazor Server application using the Auth0.AspNetCore.Authentication SDK.
+interactive:  true
+files:
+ - files/Login.cshtml
+ - files/Logout.cshtml
+ - files/Profile
+ - files/Program
+github:
+  path: Quickstart/Sample
+locale: en-US
+---
+
+# 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.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to 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 to your application.
        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.
        ASP.NET Core Blazor Server - Step 3 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        ASP.NET Core Blazor Server - Step 4 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        ASP.NET Core Blazor Server - Step 5 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/00-intro.md b/articles/quickstart/webapp/aspnet-core-v1_1/00-intro.md
deleted file mode 100644
index 99f068ce3a..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/00-intro.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Introduction
-name: Introduction to the quickstart guide and configuring the environment
-description: Introduction to the quickstart guide and configuring the environment.
-budicon: 715
----
-
-::: panel System Requirements
-This tutorial and seed project have been tested with the following:
-
-* .NET Core 1.1.0
-* ASP.NET Core 1.1.1
-
-This tutorial can be completed with the command line tools and your code editor of choice, or alternatively you can use Microsoft Visual Studio 2017 Update 3. For more details on how to use .NET Core on your platform, please see [the .NET Core Website](https://www.microsoft.com/net/core).
-:::
-
-This quickstart guide will walk you through the various tasks related to integrating Auth0 into your ASP.NET Core MVC application.
-
-## Sample Projects
-
-If you would like to follow along with this Quickstart you can download the [seed project](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/v1/Quickstart/00-Starter-Seed). This is just a regular ASP.NET MVC application with a home page and some of the NuGet packages which will be needed included. It also contains an `appSettings.json` file where you can configure the various Auth0-related settings for your application.
-
-The final project after each of the steps is also available in the Quickstart folder of the [ASP.NET Core MVC Samples repository](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/v1/Quickstart). You can find the final result for each step in the relevant folder inside the repository.
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-Please continue with the [Login](/quickstart/webapp/aspnet-core/v1/01-login) tutorial for instruction on how to implement basic login.
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/01-login.md b/articles/quickstart/webapp/aspnet-core-v1_1/01-login.md
deleted file mode 100644
index a4ffa7e6cb..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/01-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-description: This tutorial will show you how to use the standard OpenID Connect middleware to add authentication to your web app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  branch: 'v1',
-  path: 'Quickstart/01-Login',
-  requirements: [
-    '.NET Core 1.1.0',
-    'ASP.NET Core 1.1.1',
-    'Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.1'
-  ]
-}) %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/02-user-profile.md b/articles/quickstart/webapp/aspnet-core-v1_1/02-user-profile.md
deleted file mode 100644
index 7ee1ded5aa..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/02-user-profile.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: User Profile
-description: This tutorial will show you how to display get the user's profile and display it.
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  branch: 'v1',
-  path: 'Quickstart/03-User-Profile',
-  requirements: [
-    '.NET Core 1.1.0',
-    'ASP.NET Core 1.1.1',
-    'Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.1'
-  ]
-}) %>
-
-## Getting the Profile
-
-As mentioned in the previous step, the OIDC middleware will automatically extract the user's information from the ID Token and add it as claims to the `ClaimsIdentity`.
-
-The seed project contains a controller action and view which will display the claims associated with a particular user. Once a user has signed in, you can simply go to `/Account/Claims` to see these claims.
-
-You may also want to create a nicer looking user profile page which will display a user's name, email address and profile image.
-
-First create view model which will contain the basic user profile information, such as a `Name`, `EmailAddress` and `ProfileImage`:
-
-```csharp
-// ViewModels/UserProfileViewModel.cs
-
-public class UserProfileViewModel
-{
-  public string EmailAddress { get; set; }
-
-  public string Name { get; set; }
-
-  public string ProfileImage { get; set; }
-}
-```
-
-Add a new `Profile` action to the `AccountController` and extract the relevant claims and add them to a new instance of `UserProfileViewModel` which is then passed to the view. Be sure to dectorate the action with the `[Authorize]` attribute so only authenticated users can access the action:
-
-```csharp
-// Controllers/AccountController.cs
-
-[Authorize]
-public IActionResult Profile()
-{
-  return View(new UserProfileViewModel()
-  {
-    Name = User.Identity.Name,
-    EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
-    ProfileImage = User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value
-  });
-}
-```
-
-The `User.Identity.Name` property will look for a claim of type `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` on the user object. Auth0 passes the name of the user in the `name` claim of the `id_token`, but this does not get automatically matched the the `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` claim type, and therefore `User.Identity.Name` will return null.
-
-There is however a way to control the claim type which ASP.NET Core should retrieve when accessing the name through `User.Identity.Name`. To do this you need to update the OIDC middleware registration in the `Startup` class and set the `NameClaimType` of the `TokenValidationParameters` property. By setting this value to `name`, ASP.NET Core will retrieve the value of the `name` claim which was passed in the `id_token` whenever you access the name of the user using the `User.Identity.Name` property.
-
-You will also need to update the list of scopes to ensure that your request the `profile` scope. This will ensure the user's profile information is returned as claims in the `id_token`.
-
-
-```csharp
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IOptions auth0Settings)
-{
-  [...] // code omitted for brevity
-
-  var options = new OpenIdConnectOptions("Auth0")
-  {
-    [...] // code omitted for brevity
-
-    // Set the correct name claim type
-    TokenValidationParameters = new TokenValidationParameters
-    {
-      NameClaimType = "name"
-    },
-
-    Events = new OpenIdConnectEvents
-    {
-      // handle the logout redirection 
-      OnRedirectToIdentityProviderForSignOut = (context) =>
-      {
-          [...] // code omitted for brevity
-      }
-    }
-  };
-  options.Scope.Clear();
-  options.Scope.Add("openid");
-  options.Scope.Add("profile");
-  app.UseOpenIdConnectAuthentication(options);
-}
-```
-
-Next create a view. For the view, display a user profile card at the top with the user's name, email address and profile image.
-
-```html
-
-
-@model SampleMvcApp.ViewModels.UserProfileViewModel
-@{
-  ViewData["Title"] = "User Profile";
-}
-
-
        
-  
        
-    
        
-      
        @ViewData["Title"].
        
-
-      
        
-        
-      
        
-      
        
-        
        @Model.Name
        
-        
        
-           @Model.EmailAddress
-        
        
-      
        
-    
        
-  
        
-
        
-```
-
-Now when you log in and then go to the URL `/Account/Profile` you will see all the user's profile displayed.
-
-## Displaying the User's Name in the Navigation Bar
-
-You may also want to put a link in the top navigation bar to display the user's name, and when the user clicks on that you can navigate them to their Profile page.
-
-Go to the `Views/Shared/_Layout.cshtml` file and update the Navbar section which displays the Login and Logout options to also display the user's name and link to the `Profile` action in the `AccountController`:
-
-```html
-
-
-
-```
-
-Now, after the user has signed it you will be able to see the user's name in the top right corner of the Navbar:
-
-![](/media/articles/server-platforms/aspnet-core/navbar-userprofile.png)
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/03-authorization.md b/articles/quickstart/webapp/aspnet-core-v1_1/03-authorization.md
deleted file mode 100644
index cfdfe2d306..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/03-authorization.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: Authorization
-description: This tutorial will show you how assign roles to your users, and use those claims to authorize or deny a user to access certain routes in the app.
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  branch: 'v1',
-  path: 'Quickstart/04-Authorization',
-  requirements: [
-    '.NET Core 1.1.0',
-    'ASP.NET Core 1.1.1',
-    'Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.1'
-  ]
-}) %>
-
-ASP.NET Core supports [Role based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles) which allows you to limit access of users based on their role in the application. In this tutorial we will look at how you can amend your user's `id_token` by adding role information and then use that information inside your application to limit a user's access.
-
-::: note
-This tutorial assumes that you are familiar with [Rules](/rules/current).
-:::
-
-### Create a Rule to assign roles
-
-First, we will create a rule that assigns our users either an `admin` role, or a `user` role based on the email domain. 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:
-
-```js
-function (user, context, callback) {
-  var addRolesToUser = function(user, cb) {
-    if (user.email.indexOf('@example.com') > -1) {
-      cb(null, ['admin']);
-    } else {
-      cb(null, ['user']);
-    }
-  };
-
-  addRolesToUser(user, function(err, roles) {
-    if (err) {
-      callback(err);
-    } else {
-      context.idToken["https://schemas.quickstarts.com/roles"] = roles;     
-      callback(null, user, context);
-    }
-  });
-}
-```
-
-Update the code to check for your own email domain, or match the condition according to your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-This quickstart uses `https://schemas.quickstarts.com` for the claim namespace, 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`.
-
-::: note
-For more information on custom claims please see [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
-:::
-
-## Restrict an Action Based on a User's Roles
-
-Next you will need to configure the OIDC middleware registration inside your ASP.NET application to inform it which claim in the `id_token` contains the role information. Alter your OIDC middleware registration to specify the `RoleClaimType` inside the `TokenValidationParameters`. Ensure that this matches the namespace you used inside your Rule.
-
-```csharp
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IOptions auth0Settings)
-{
-  [...] // code omitted for brevity
-
-  var options = new OpenIdConnectOptions("Auth0")
-  {
-    [...] // code omitted for brevity
-
-    // Set the correct name claim type
-    TokenValidationParameters = new TokenValidationParameters
-    {
-      NameClaimType = "name",
-      RoleClaimType = "https://schemas.quickstarts.com/roles"
-    },
-
-    Events = new OpenIdConnectEvents
-    {
-      // handle the logout redirection 
-      OnRedirectToIdentityProviderForSignOut = (context) =>
-      {
-          [...] // code omitted for brevity
-      }
-    }
-  };
-  options.Scope.Clear();
-  options.Scope.Add("openid");
-  options.Scope.Add("profile");
-  app.UseOpenIdConnectAuthentication(options);
-}
-```
-
-At this point the you have integrated with the the [Role based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles) mechanism of ASP.NET Core, which means that your can ensure that a user belongs to a particular role by simply decorating your controller actions with the `[Authorize(Roles = ?)]` attribute.
-
-The sample code below will restrict the particular action only to users who have the "admin" role:
-
-```csharp
-// Controllers/HomeController.cs
-
-[Authorize(Roles = "admin")]
-public IActionResult Admin()
-{
-  return View();
-}
-```
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_login.md b/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_login.md
deleted file mode 100644
index 5293ad870c..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_login.md
+++ /dev/null
@@ -1,297 +0,0 @@
-## Add Authentication with 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.
-
-::: note
-You can also create a custom login for prompting the user for their username and password. To learn how to do this in your application, follow the [Custom Login sample](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/v1/Samples/custom-login).
-:::
-
-## Configure OpenID Connect Middleware
-
-The easiest way to enable authentication with Auth0 in your ASP.NET Core application is to use the OpenID Connect middleware. First, go to the `ConfigureServices` method of your `Startup` class and add the authentication services by calling the `AddAuthentication` method:
-
-```cs
-// Startup.cs
-
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(
-        options => options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme);
-
-    // Add framework services.
-    services.AddMvc();
-
-    // Add functionality to inject IOptions
-    services.AddOptions();
-
-    // Add the Auth0 Settings object so it can be injected
-    services.Configure(Configuration.GetSection("Auth0"));
-}
-```
-
-Next, in the `Configure` method of the `Startup` class add the cookie middleware and the OpenID Connect middleware. Middleware executes in the order they are registered so it is important to register the cookie middleware first, and then the OIDC middleware. 
-
-Both of these middleware should be registered before your MVC middleware in order for your controllers to be protected. The OIDC middleware is required in order to authenticate the user with Auth0. Once the user has authenticated they will be signed into the Cookie middleware which will be used to authenticate all subsequent requests.
-
-```csharp
-// Startup.cs
-
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IOptions auth0Settings)
-{
-    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
-    loggerFactory.AddDebug();
-
-    if (env.IsDevelopment())
-    {
-        app.UseDeveloperExceptionPage();
-        app.UseBrowserLink();
-    }
-    else
-    {
-        app.UseExceptionHandler("/Home/Error");
-    }
-
-    app.UseStaticFiles();
-
-    // Add the cookie middleware
-    app.UseCookieAuthentication(new CookieAuthenticationOptions
-    {
-        AutomaticAuthenticate = true,
-        AutomaticChallenge = true
-    });
-
-    // Add the OIDC middleware
-    var options = new OpenIdConnectOptions("Auth0")
-    {
-        // Set the authority to your Auth0 domain
-        Authority = $"https://{auth0Settings.Value.Domain}",
-
-        // Configure the Auth0 Client ID and Client Secret
-        ClientId = auth0Settings.Value.ClientId,
-        ClientSecret = auth0Settings.Value.ClientSecret,
-
-        // Do not automatically authenticate and challenge
-        AutomaticAuthenticate = false,
-        AutomaticChallenge = false,
-
-        // Set response type to code
-        ResponseType = "code",
-
-        // Set the callback path, so Auth0 will call back to http://localhost:5000/signin-auth0 
-        // Also ensure that you have added the URL as an Allowed Callback URL in your Auth0 dashboard 
-        CallbackPath = new PathString("/signin-auth0"),
-
-        // Configure the Claims Issuer to be Auth0
-        ClaimsIssuer = "Auth0"
-    };
-    options.Scope.Clear();
-    options.Scope.Add("openid");
-    app.UseOpenIdConnectAuthentication(options);
-
-    app.UseMvc(routes =>
-    {
-        routes.MapRoute(
-            name: "default",
-            template: "{controller=Home}/{action=Index}/{id?}");
-    });
-}
-```
-
-Also note above that the list of scopes is cleared and only the `openid` scope is requested. By default the OIDC middleware will request both the `openid` and the `profile` scopes and can result in a large `id_token` being returned. It is suggested that you be more explicit about the scopes you want to be returned and not ask for the entire profile to be returned. Requesting additional scopes is discussed later in the [User Profile step](/quickstart/webapp/aspnet-core/04-user-profile). 
-
-### Obtaining an Access Token for calling an API
-
-You may want to call an API from your MVC application, in which case you need to obtain an `access_token` which was issued for the particular API you want to call. In this case you will need to pass an extra `audience` parameter containing the API Identifier to the Auth0 authorization endpoint. 
-
-If you want to do this, simply handle the `OnRedirectToIdentityProvider` event when configuring the `OpenIdConnectOptions` object, and add the `audience` parameter to the `ProtocolMessage`
-
-```csharp
-var options = new OpenIdConnectOptions("Auth0")
-{
-    // Other configuration and standard parameters
-    // ...
-    Events = new OpenIdConnectEvents
-    {
-        OnRedirectToIdentityProvider = context =>
-        {
-            context.ProtocolMessage.SetParameter("audience", "${apiIdentifier}");
-
-            return Task.FromResult(0);
-        }
-    }
-};
-```
-
-## Add Login and Logout Methods
-
-Next, you will need to add `Login` and `Logout` actions to the `AccountController`. 
-
-For the Login, you will need to return a `ChallengeResult` and specify "Auth0" as the authentication scheme which will be challenged. This will invoke the OIDC middleware you registered in the `Configure` method.
-
-After the OIDC middleware has signed the user in, the user will automatically be signed into the cookie middleware as well to authenticate them on subsequent requests. So, for the `Logout` action you will need to sign the user out of both the OIDC and the cookie middleware: 
-
-```cs
-// Controllers/AccountController.cs
-
-public class AccountController : Controller
-{
-    public IActionResult Login()
-    {
-        return new ChallengeResult("Auth0", new AuthenticationProperties() { RedirectUri = "/" });
-    }
-
-    public async Task Logout()
-    {
-        await HttpContext.Authentication.SignOutAsync("Auth0", new AuthenticationProperties
-        {
-            RedirectUri = Url.Action("Index", "Home")
-        });
-        await HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
-    }
-}
-```
-
-At this point ASP.NET Core will call `SignOutAsync` for the **Auth0** authentication scheme (such as the OIDC middleware), but the OIDC middleware does not know what the actual Logout URL is it should call to log the user out of Auth0. To do this you should handle the `OnRedirectToIdentityProviderForSignOut` event when registering the OIDC middleware.
-
-So back in the `Startup.cs` file, update the instantiation of `OpenIdConnectOptions` with the following code:
-
-```csharp
-// Startup.cs
-
-var options = new OpenIdConnectOptions("Auth0")
-{
-    // some code omitted for brevity...
-
-    Events = new OpenIdConnectEvents
-    {
-        // handle the logout redirection 
-        OnRedirectToIdentityProviderForSignOut = (context) =>
-        {
-            var logoutUri = $"https://{auth0Settings.Value.Domain}/v2/logout?client_id={auth0Settings.Value.ClientId}";
-
-            var postLogoutUri = context.Properties.RedirectUri;
-            if (!string.IsNullOrEmpty(postLogoutUri))
-            {
-                if (postLogoutUri.StartsWith("/"))
-                {
-                    // transform to absolute
-                    var request = context.Request;
-                    postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
-                }
-                logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
-            }
-
-            context.Response.Redirect(logoutUri);
-            context.HandleResponse();
-
-            return Task.CompletedTask;
-        }
-    }
-};
-```
-
-This will ensure that when `SignOutAsync` is called for the OIDC Middleware, that the `/v2/logout` endpoint of the Auth0 Authentication API is called to log the user out of Auth0. 
-
-It will also pass along the Redirect URL (when specified) in the `returnTo` parameter. You must therefore ensure that you have specified this URL in the **Allowed Logout URLs** for your application in the Auth0 Dashboard.
-
-## Add Login and Logout Links
-
-Lastly, add Login and Logout links to the navigation bar. To do that, head over to `/Views/Shared/_Layout.cshtml` and add code to the navigation bar section which displays a Logout link when the user is authenticated, otherwise a Login link. These will link to the `Logout` and `Login` actions of the `AccountController` respectively:  
-
-```html
-
-
-
        
-    
        
-        
        
-            
-            SampleMvcApp
-        
        
-        
        
-            
-            
          
-                @if (User.Identity.IsAuthenticated)
-                {
-                    
        • Logout
          • 
-                }
-                else
-                {
-                    
        • Login
          • 
-                }
-            
        
-        
        
-    
        
-
        
-```
-
-## Run the Application
-
-Now, when you run the application you can select the Login link to log into the application. This will challenge the OIDC middleware which will subsequently redirect you to the hosted version of Lock on your Auth0 domain.
-
-::: panel Understanding the Login Flow
-
-1. The user clicks on the Login link and is directed to the `Login` route
-2. This returns a `ChallengeResult` which instructs the ASP.NET Authentication middleware to issue a challenge to the Authentication middleware which is registered with the `authenticationScheme` of `Auth0`. (When we created the instance of `OpenIdConnectOptions` in the `Startup` class we passed a value of **Auth0** to the constructor. This is the authentication scheme, so that is why the authentication middleware knows to challege this OIDC middleware to authenticate the user.)
-3. At this point the OIDC middleware is challenged, and it will redirect the user to the Auth0 `/authorize` endpoint, which will display Lock and require the user to log in - whether it be with username/password, social provider or any other Identity Provider.
-4. Once the user has logged in, Auth0 will call back to the `/signin-auth0` endpoint in your application and pass along an authorization code.
-5. The OIDC middleware will "listen" for any request made to the `/signin-auth0` path and intercept it. It will look for the authorization code which Auth0 sent in the query string and then call the `/oauth/token` endpoint to exchange the authorization code for an `id_token` and `access_token`.
-6. The OIDC middleware will look at the `id_token` and extract the user information from the claims on the token.
-7. Finally the OIDC middleware will return a successful authentication response, which will result in a cookie being stored indicating that the user is authenticated, and the cookie will also contain claims with the user's information. This means that on all subsequent requests the cookie middleware will automatically authenticate the user, and no further requests will be made to the OIDC middleware (unless explicitly challenged).
-:::
-
-## Storing the Tokens
-
-The OIDC middleware in ASP.NET Core will automatically Decode the ID Token returned from Auth0 and will automatically add the claims contained in the ID Token as claims on the `ClaimsIdentity`. This means that inside any of the actions in your controllers you can simply use `User.Claims.FirstOrDefault("").Value` to obtain the value of a particular claim.
-
-The seed project contains a controller action and view which will display the claims associated with a particular user. Once a user has signed in, you can simply go to `/Account/Claims` to see these claims.
-
-Sometimes you may want to access the tokens received from Auth0. For example, you may want to get the `access_token` to authenticate against API calls. In order to do this, you will need to set the `SaveTokens` property of `OpenIdConnectOptions` to true. This will save the tokens to the `AuthenticationProperties`:
-
-```csharp
-// Startup.cs
-
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory,
-    IOptions auth0Settings)
-{
-    // Some code was omitted for brevity...
-
-    var options = new OpenIdConnectOptions("Auth0")
-    {
-        [...]
-
-        // Saves tokens to the AuthenticationProperties
-        SaveTokens = true,
-
-        Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection
-            OnRedirectToIdentityProviderForSignOut = [...] // omitted for brevity
-        }
-    };
-    options.Scope.Clear();
-    options.Scope.Add("openid");
-    app.UseOpenIdConnectAuthentication(options);
-}
-```
-
-To subsequently retrieve either of the tokens you can call `GetAuthenticateInfoAsync` to retrieve the `AuthenticateInfo`. The tokens will be available in the `Properties` of the `AuthenticateInfo` object, stored in the format `.Token.`:
-
-```csharp
-// Inside one of your controller actions
-if (User.Identity.IsAuthenticated)
-{
-    var authenticateInfo = await HttpContext.Authentication.GetAuthenticateInfoAsync("Auth0");
-    string accessToken = authenticateInfo.Properties.Items[".Token.access_token"];
-    string idToken = authenticateInfo.Properties.Items[".Token.id_token"];
-}
-```
-
-For general information on using APIs with web applications, please read [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code).
\ No newline at end of file
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_setup.md b/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_setup.md
deleted file mode 100644
index b9d7102af8..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/_includes/_setup.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## 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 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:60856/signin-auth0` if you use IIS Express, or `http://localhost:5000/signin-auth0` if you use Kestrel, so be sure to add this to the **Allowed Callback URLs** section of your application.
-
-If you deploy your application to a different URL you will also need to ensure to add that URL to the **Allowed Callback URLs**. For ASP.NET Core this URL will take the format `http://YOUR_APPLICATION_URL/signin-auth0`  
-
-## Configure JSON Web Token Signature Algorithm
-
-The ASP.NET Core OpenID Connect (OIDC) middleware which will be used to authenticate the user, requires that the JSON Web Token (JWT) be signed with an asymmetric key. To configure this go to the settings for your application in the Auth0 Dashboard, scroll down and click on **Show Advanced Settings**. Go to the **OAuth** tab and set the **JsonWebToken Signature Algorithm** to **RS256**.
-
-Save your changes.     
-
-## Dependencies
-
-To integrate Auth0 with ASP.NET Core you will use the Cookie and OpenID Connect (OIDC) Middleware. Add the `Microsoft.AspNetCore.Authentication.Cookies` and `Microsoft.AspNetCore.Authentication.OpenIdConnect` packages to your application.
-
-```bash
-Install-Package Microsoft.AspNetCore.Authentication.Cookies
-Install-Package Microsoft.AspNetCore.Authentication.OpenIdConnect
-```
\ No newline at end of file
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/dashboard-default.md b/articles/quickstart/webapp/aspnet-core-v1_1/dashboard-default.md
deleted file mode 100644
index 4399a27197..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/dashboard-default.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial will show you how to use the standard OpenID Connect middleware to add authentication to your web app.
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  path: 'Quickstart/01-Login',
-  requirements: [
-    '.NET Core 1.1.0',
-    'ASP.NET Core 1.1.1',
-    'Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.1'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/aspnet-core-v1_1/index.yml b/articles/quickstart/webapp/aspnet-core-v1_1/index.yml
deleted file mode 100644
index 0c5367e544..0000000000
--- a/articles/quickstart/webapp/aspnet-core-v1_1/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: ASP.NET Core v1.1
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/aspnet-core/dependencies
-alias:
-  - aspnetcore-1.1
-  - aspnetcore
-seo_alias: aspnet-core-1.1
-default_article: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 02-user-profile
-  - 03-authorization
\ No newline at end of file
diff --git a/articles/quickstart/webapp/aspnet-core/00-intro.md b/articles/quickstart/webapp/aspnet-core/00-intro.md
deleted file mode 100644
index 9fa5a2fa37..0000000000
--- a/articles/quickstart/webapp/aspnet-core/00-intro.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Introduction
-name: Introduction to the quickstart guide and configuring the environment
-description: Introduction to the quickstart guide and configuring the environment.
-budicon: 715
----
-
-::: panel System requirements
-This tutorial and seed project have been tested with the following:
-* .NET Core SDK 2.0
-* .NET Core 2.0
-* ASP.NET Core 2.0
-
-To complete this tutorial, you can use command line tools and any code editor. Alternatively, you can use Microsoft Visual Studio 2017 Update 3. For more details on how to use .NET Core on your platform, read the [.NET Core](https://www.microsoft.com/net/core) documentation.
-:::
-
-This quickstart guide walks you through integrating Auth0 into your ASP.NET Core MVC application.
-
-## Seed Project
-
-If you want to follow along with this quickstart guide, you can download the [seed project](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Quickstart/00-Starter-Seed). The sample contains an ASP.NET MVC application with a home page and some NuGet packages. It also contains an `appSettings.json` file, where you can configure the Auth0-related settings for your application.
-
-To see what the project looks like after each step, check the [Quickstart folder](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Quickstart) in the ASP.NET Core MVC Samples repository.
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('./_includes/_setup') %>
diff --git a/articles/quickstart/webapp/aspnet-core/01-login.md b/articles/quickstart/webapp/aspnet-core/01-login.md
index 709cc417d7..deaadad0c4 100644
--- a/articles/quickstart/webapp/aspnet-core/01-login.md
+++ b/articles/quickstart/webapp/aspnet-core/01-login.md
@@ -1,19 +1,160 @@
 ---
 title: Login
-description: This tutorial will show you how to use the standard OpenID Connect middleware to add authentication to your web app.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  path: 'Quickstart/01-Login',
-  branch: 'master',
-  requirements: [
-    '.NET Core SDK 2.0',
-    '.NET Core 2.0',
-    'ASP.NET Core 2.0'
-  ]
-}) %>
-
-<%= include('./_includes/_login') %>
+
+
+<%= 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, this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate 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. 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 in order to (make cookies with SameSite=None work over HTTP when using Chrome). 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
+- Obtain an Access Token for Calling an API
+- Adding Role-based authorization
diff --git a/articles/quickstart/webapp/aspnet-core/02-user-profile.md b/articles/quickstart/webapp/aspnet-core/02-user-profile.md
deleted file mode 100644
index 5c6ecf0be7..0000000000
--- a/articles/quickstart/webapp/aspnet-core/02-user-profile.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: User Profile
-description: This tutorial will show you how to display get the user's profile and display it.
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  path: 'Quickstart/03-User-Profile',
-  branch: 'master',
-  requirements: [
-    '.NET Core SDK 2.0',
-    '.NET Core 2.0',
-    'ASP.NET Core 2.0'
-  ]
-}) %>
-
-## Get the Profile
-
-The OIDC middleware extracts the user's information from the ID Token and adds it as claims to the `ClaimsIdentity`.
-
-The seed project contains a controller action and view which display the claims associated with a user. Once a user has logged in, you can go to `/Account/Claims` to see these claims.
-
-You can create a custom user profile page for displaying a user's name, email address and profile image.
-
-Create a view model containing the basic user profile information:
-
-```csharp
-// ViewModels/UserProfileViewModel.cs
-
-public class UserProfileViewModel
-{
-  public string EmailAddress { get; set; }
-
-  public string Name { get; set; }
-
-  public string ProfileImage { get; set; }
-}
-```
-
-Add a new `Profile` action to the `AccountController` and extract the relevant claims. Add the claims to a new instance of `UserProfileViewModel` passed to the view. Add the `[Authorize]` attribute to the action so only authenticated users can access the action:
-
-```csharp
-// Controllers/AccountController.cs
-
-[Authorize]
-public IActionResult Profile()
-{
-    return View(new UserProfileViewModel()
-    {
-        Name = User.Identity.Name,
-        EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
-        ProfileImage = User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value
-    });
-}
-```
-
-The `User.Identity.Name` property looks for a claim of a type `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` on the user object. Auth0 passes the name of the user in the `name` claim of the ID Token, but this does not get automatically matched to the  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` type. This means that `User.Identity.Name` will return null.
-
-You can control the claim type that ASP.NET Core retrieves when accessing the name through `User.Identity.Name`. To achieve this, update the OIDC authentication handler registration in the `Startup` class. Set the `NameClaimType` of the `TokenValidationParameters` property to `name`. ASP.NET Core will retrieve the value of the `name` claim passed in the ID Token when you access the name of the user with the `User.Identity.Name` property.
-
-You must update the list of scopes to request the `profile` scope. The user's profile information is returned as claims in the ID Token.
-
-```csharp
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie()
-    .AddOpenIdConnect("Auth0", options => {
-        // ...
-
-        // Configure the scope
-        options.Scope.Clear();
-        options.Scope.Add("openid");
-        options.Scope.Add("profile");
-
-        // Set the correct name claim type
-        options.TokenValidationParameters = new TokenValidationParameters
-        {
-            NameClaimType = "name"
-        };
-
-        options.Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection 
-            OnRedirectToIdentityProviderForSignOut = (context) =>
-            {
-                //...
-            }
-        };   
-    });
-}
-```
-
-Next create a view. For the view, display user's profile card at the top with the user's name, email address and profile image.
-
-```html
-
-
-@model SampleMvcApp.ViewModels.UserProfileViewModel
-@{
-  ViewData["Title"] = "User Profile";
-}
-
-
        
-  
        
-    
        
-      
        @ViewData["Title"].
        
-
-      
        
-        
-      
        
-      
        
-        
        @Model.Name
        
-        
        
-           @Model.EmailAddress
-        
        
-      
        
-    
        
-  
        
-
        
-```
-
-Now when you log in and go to the URL `/Account/Profile`, you will see the user's profile with the information.
-
-## Display the User's Name in the Navigation Bar
-
-You can put a link in the top navigation bar to display the user's name. When the user clicks on their name, you can navigate them to their profile page.
-
-Go to the `Views/Shared/_Layout.cshtml` file and update the `Navbar` section to display the user's name and link to the `Profile` action in the `AccountController`:
-
-```html
-
-
-
-```
-
-Now, after the user has logged in, the user's name is displayed in the top-right corner of the navigation bar:
-
-![](/media/articles/server-platforms/aspnet-core/navbar-userprofile.png)
diff --git a/articles/quickstart/webapp/aspnet-core/03-authorization.md b/articles/quickstart/webapp/aspnet-core/03-authorization.md
deleted file mode 100644
index 7ab3d3ff1e..0000000000
--- a/articles/quickstart/webapp/aspnet-core/03-authorization.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: Authorization
-description: This tutorial will show you how assign roles to your users, and use those claims to authorize or deny a user to access certain routes in the app.
-budicon: 546
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  path: 'Quickstart/04-Authorization',
-  branch: 'master',
-  requirements: [
-    '.NET Core SDK 2.0',
-    '.NET Core 2.0',
-    'ASP.NET Core 2.0'
-  ]
-}) %>
-
-ASP.NET Core supports [Role based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles) which allows you to limit access to your application based on the user's role. This tutorial shows how to add role information to the user's ID Token and then use it to limit access to your application. 
-
-::: note
-To follow the tutorial, make sure you are familiar with [Rules](/rules/current).
-:::
-
-## Create a Rule to Assign Roles
-
-Create a rule that assigns the following access roles to your user:
-* An admin role
-* A regular user role
-
-To assign roles, go to the [New rule page](${manage_url}/#/rules/new). In the **Access Control** section, create an empty rule. 
-
-Use the following code for your rule:
-
-```js
-function (user, context, callback) {
-  var addRolesToUser = function(user, cb) {
-    if (user.email.indexOf('@example.com') > -1) {
-      cb(null, ['admin']);
-    } else {
-      cb(null, ['user']);
-    }
-  };
-
-  addRolesToUser(user, function(err, roles) {
-    if (err) {
-      callback(err);
-    } else {
-      context.idToken["https://schemas.quickstarts.com/roles"] = roles;     
-      callback(null, user, context);
-    }
-  });
-}
-```
-
-Update the code to check for your own email domain, or match your custom condition.
-
-::: note
-You can define more roles other than `admin` and `user`, or customize the whole rule, depending on your product requirements.
-:::
-
-This quickstart guide uses `https://schemas.quickstarts.com` for the claim namespace. We recommend that you use a namespace related to your own Auth0 tenant for your claims, for example, `https://schemas.YOUR_TENANT_NAME.com`.
-
-::: note
-For more information on custom claims, read [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
-:::
-
-## Restrict Access Based on User Roles
-
-Configure the OIDC authentication handler registration inside your ASP.NET application to inform it which claim in the ID Token contains the role information. Specify the `RoleClaimType` inside `TokenValidationParameters`. The value you specify must match the namespace you used in your rule.
-
-```csharp
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie())
-    .AddOpenIdConnect("Auth0", options => {
-        // ...
-
-        // Configure the scope
-        options.Scope.Clear();
-        options.Scope.Add("openid");
-        options.Scope.Add("profile");
-        options.Scope.Add("email");
-
-        // Set the correct name claim type
-        options.TokenValidationParameters = new TokenValidationParameters
-        {
-            NameClaimType = "name",
-            RoleClaimType = "https://schemas.quickstarts.com/roles"
-        };
-
-        options.Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection 
-            OnRedirectToIdentityProviderForSignOut = (context) =>
-            {
-                // ...
-            }
-        };   
-    });
-}
-```
-
-You can use the [Role based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles) mechanism to make sure that only the users with specific roles can access certain actions. Add the `[Authorize(Roles = ?)]` attribute to your controller action.
-
-The sample code below restricts the action only to users who have the `admin` role:
-
-```csharp
-// Controllers/HomeController.cs
-
-[Authorize(Roles = "admin")]
-public IActionResult Admin()
-{
-  return View();
-}
-```
diff --git a/articles/quickstart/webapp/aspnet-core/_includes/_login.md b/articles/quickstart/webapp/aspnet-core/_includes/_login.md
deleted file mode 100644
index c697591761..0000000000
--- a/articles/quickstart/webapp/aspnet-core/_includes/_login.md
+++ /dev/null
@@ -1,353 +0,0 @@
-## Add Authentication with 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.
-
-::: note
-You can also create a custom login for prompting the user for their username and password. To learn how to do this in your application, follow the [Custom Login sample](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Samples/custom-login).
-:::
-
-## Configure OpenID Connect Middleware
-
-To enable authentication in your ASP.NET Core application, use the OpenID Connect (OIDC) middleware.
-Go to the `ConfigureServices` method of your `Startup` class. To add the authentication services, call the `AddAuthentication` method. To enable cookie authentication, call the `AddCookie` method. 
-
-Next, configure the OIDC authentication handler. Add a call to `AddOpenIdConnect`. To configure the authentication scheme, pass "Auth0" as the `authenticationScheme` parameter. You will use this value later to challenge the OIDC middleware.
-
-Configure other parameters, such as `ClientId`, `ClientSecret` or `ResponseType`. 
-
-By default, the OIDC middleware requests both the `openid` and `profile` scopes. Because of that, you may get a large ID Token in return. We suggest that you ask only for the scopes you need. You can read more about requesting additional scopes in the [User Profile step](/quickstart/webapp/aspnet-core/v2/04-user-profile).
-
-::: note
-In the code sample below, only the `openid` scope is requested.
-:::
-
-```cs
-// Startup.cs
-
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie()
-    .AddOpenIdConnect("Auth0", options => {
-        // Set the authority to your Auth0 domain
-        options.Authority = $"https://{Configuration["Auth0:Domain"]}";
-
-        // Configure the Auth0 Client ID and Client Secret
-        options.ClientId = Configuration["Auth0:ClientId"];
-        options.ClientSecret = Configuration["Auth0:ClientSecret"];
-
-        // Set response type to code
-        options.ResponseType = "code";
-
-        // Configure the scope
-        options.Scope.Clear();
-        options.Scope.Add("openid");
-
-        // Set the callback path, so Auth0 will call back to http://localhost:5000/signin-auth0 
-        // Also ensure that you have added the URL as an Allowed Callback URL in your Auth0 dashboard 
-        options.CallbackPath = new PathString("/signin-auth0");
-
-        // Configure the Claims Issuer to be Auth0
-        options.ClaimsIssuer = "Auth0";
-
-        options.Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection 
-            OnRedirectToIdentityProviderForSignOut = (context) =>
-            {
-                var logoutUri = $"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";
-
-                var postLogoutUri = context.Properties.RedirectUri;
-                if (!string.IsNullOrEmpty(postLogoutUri))
-                {
-                    if (postLogoutUri.StartsWith("/"))
-                    {
-                        // transform to absolute
-                        var request = context.Request;
-                        postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
-                    }
-                    logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
-                }
-
-                context.Response.Redirect(logoutUri);
-                context.HandleResponse();
-
-                return Task.CompletedTask;
-            }
-        };   
-    });
-
-    // Add framework services.
-    services.AddMvc();
-}
-```
-
-Next, add the authentication middleware. In the `Configure` method of the `Startup` class, call the `UseAuthentication` method.
-
-```csharp
-// Startup.cs
-
-public void Configure(IApplicationBuilder app, IHostingEnvironment env)
-{
-    if (env.IsDevelopment())
-    {
-        app.UseDeveloperExceptionPage();
-    }
-    else
-    {
-        app.UseExceptionHandler("/Home/Error");
-    }
-
-    app.UseStaticFiles();
-
-    app.UseAuthentication();
-
-    app.UseMvc(routes =>
-    {
-        routes.MapRoute(
-            name: "default",
-            template: "{controller=Home}/{action=Index}/{id?}");
-    });
-}
-
-}
-```
-
-## Obtain an Access Token for Calling an API
-
-If you want to call an API from your MVC application, you need to obtain an Access Token issued for the API you want to call. To obtain the token, pass an additional `audience` parameter containing the API identifier to the Auth0 authorization endpoint.
-
-In the configuration for the `OpenIdConnectOptions` object, handle the `OnRedirectToIdentityProvider` event and add the `audience` parameter to `ProtocolMessage`.
-
-```csharp
-// Startup.cs
-
-public void ConfigureServices(IServiceCollection services)
-{
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie()
-    .AddOpenIdConnect("Auth0", options => {
-        // ...
-
-        options.Events = new OpenIdConnectEvents
-        {
-            OnRedirectToIdentityProvider = context =>
-            {
-                context.ProtocolMessage.SetParameter("audience", "${apiIdentifier}");
-
-                return Task.FromResult(0);
-            }
-        };   
-    });
-}
-```
-
-## Add the `Login` and `Logout` Methods
-
-Add the `Login` and `Logout` actions to `AccountController`. 
-
-To add the `Login` action, call `ChallengeAsync` and pass "Auth0" as the authentication scheme. This will invoke the OIDC authentication handler you registered in the `ConfigureServices` method.
-
-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. 
-
-For the `Logout` action, you need to sign the user out of both middlewares.
-
-The `RedirectUri` passed in both instances indicates where the user is redirected after they log in or fail to log in. 
-
-```cs
-// Controllers/AccountController.cs
-
-using Microsoft.AspNetCore.Authentication;
-using Microsoft.AspNetCore.Authentication.Cookies;
-
-public class AccountController : Controller
-{
-    public async Task Login(string returnUrl = "/")
-    {
-        await HttpContext.ChallengeAsync("Auth0", new AuthenticationProperties() { RedirectUri = returnUrl });
-    }
-
-    [Authorize]
-    public async Task Logout()
-    {
-        await HttpContext.SignOutAsync("Auth0", new AuthenticationProperties
-        {
-            // Indicate here where Auth0 should redirect the user after a logout.
-            // Note that the resulting absolute Uri must be whitelisted in the 
-            // **Allowed Logout URLs** settings for the app.
-            RedirectUri = Url.Action("Index", "Home")
-        });
-        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
-    }
-}
-```
-
-ASP.NET Core calls `SignOutAsync` for the "Auth0" authentication scheme. You need to provide the OIDC middleware with the URL for logging the user out of Auth0. To set the URL, handle the `OnRedirectToIdentityProviderForSignOut` event when you register the OIDC authentication handler.
-
-When the application calls `SignOutAsync` for the OIDC middleware, it also calls the `/v2/logout` endpoint of the Auth0 Authentication API. The user is logged out of Auth0.
-
-If you specify the `returnTo` parameter, the users will be redirected there after they are logged out. Specify the URL for redirecting users in the **Allowed Logout URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
-
-In the `Startup.cs` file, update the call to `AddOpenIdConnect` with the following code:
-
-```csharp
-// Startup.cs
-// some code was omitted for brevity...
-
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie()
-    .AddOpenIdConnect("Auth0", options => {
-        // ...
-
-        options.Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection 
-            OnRedirectToIdentityProviderForSignOut = (context) =>
-            {
-                var logoutUri = $"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";
-
-                var postLogoutUri = context.Properties.RedirectUri;
-                if (!string.IsNullOrEmpty(postLogoutUri))
-                {
-                    if (postLogoutUri.StartsWith("/"))
-                    {
-                        // transform to absolute
-                        var request = context.Request;
-                        postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
-                    }
-                    logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
-                }
-
-                context.Response.Redirect(logoutUri);
-                context.HandleResponse();
-
-                return Task.CompletedTask;
-            }
-        };   
-    });
-}
-```
-
-## Add the Log In and Log Out Buttons
-
-Add the **Log In** and **Log Out** buttons to the navigation bar. In the `/Views/Shared/_Layout.cshtml` file, in the navigation bar section, add code that displays the **Log Out** button when the user is authenticated and the **Log In** button if not. The buttons link to the `Logout` and `Login` actions in the `AccountController`:  
-
-```html
-
-
-
        
-    
        
-        
        
-            
-            SampleMvcApp
-        
        
-        
        
-            
-            
          
-                @if (User.Identity.IsAuthenticated)
-                {
-                    
        • Logout
          • 
-                }
-                else
-                {
-                    
        • Login
          • 
-                }
-            
        
-        
        
-    
        
-
        
-```
-
-## Run the Application
-
-When the user selects the **Log In** button, the OIDC middleware redirects them to the hosted version of the [Lock](/libraries/lock/v10/customization) widget in your Auth0 domain. 
-
-### About the login flow
-
-1. The user clicks on the **Log In** button and is directed to the `Login` route. 
-2. The `ChallengeAsync` tells the ASP.NET authentication middleware to issue a challenge to the authentication handler registered with the Auth0 `authenticationScheme` parameter. The parameter uses the "Auth0" value you passed in the call to `AddOpenIdConnect` in the `Startup` class.
-3. The OIDC handler redirects the user to the Auth0 `/authorize` endpoint, which displays the Lock widget. The user can log in with their username and password, social provider or any other identity provider.
-4. Once the user has logged in, Auth0 calls back to the `/signin-auth0` endpoint in your application and passes along an authorization code.
-5. The OIDC handler intercepts requests made to the `/signin-auth0` path. 
-6. The handler looks for the authorization code, which Auth0 sent in the query string.
-7. The OIDC handler calls the `/oauth/token` endpoint to exchange the authorization code for the user's ID and Access Tokens.
-8. The OIDC middleware extracts the user information from the claims on the ID Token.
-9. The OIDC middleware returns a successful authentication response and a cookie which indicates that the user is authenticated. The cookie contains claims with the user's information. The cookie is stored, so that the cookie middleware will automatically authenticate the user on any future requests. The OIDC middleware receives no more requests, unless it is explicitly challenged.
-
-## Store the Tokens
-
-The OIDC middleware in ASP.NET Core automatically decodes the ID Token returned from Auth0 and adds the claims from the ID Token as claims in the `ClaimsIdentity`. This means that you can use `User.Claims.FirstOrDefault("").Value` to obtain the value of any claim inside any action in your controllers.
-
-The seed project contains a controller action and view that display the claims associated with a user. Once a user has logged in, you can go to `/Account/Claims` to see these claims.
-
-You may want to Access Tokens received from Auth0. For example, you can use the Access Token to authenticate the user in calls to your API. To achieve this, when calling `AddOpenIdConnect`, set the `SaveTokens` property to `true`. This saves the tokens to `AuthenticationProperties`:
-
-```csharp
-// Startup.cs
-
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add authentication services
-    services.AddAuthentication(options => {
-        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
-    })
-    .AddCookie()
-    .AddOpenIdConnect("Auth0", options => {
-        // ...
-
-        // Saves tokens to the AuthenticationProperties
-        options.SaveTokens = true;
-
-        options.Events = new OpenIdConnectEvents
-        {
-            // handle the logout redirection 
-            OnRedirectToIdentityProviderForSignOut = (context) =>
-            {
-                //...
-            }
-        };   
-    });
-}
-```
-
-To retrieve the tokens, you can call `GetTokenAsync`:
-
-```csharp
-// Inside one of your controller actions
-
-if (User.Identity.IsAuthenticated)
-{
-    string accessToken = await HttpContext.GetTokenAsync("access_token");
-    string idToken = await HttpContext.GetTokenAsync("id_token");
-
-    // Now you can use them. For more info on when and how to use the 
-    // access_token and id_token, see https://auth0.com/docs/tokens
-}
-```
-
-For general information on using APIs with web applications, see the [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code) article.
diff --git a/articles/quickstart/webapp/aspnet-core/_includes/_setup.md b/articles/quickstart/webapp/aspnet-core/_includes/_setup.md
deleted file mode 100644
index 15ae4d709d..0000000000
--- a/articles/quickstart/webapp/aspnet-core/_includes/_setup.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 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 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:60856/signin-auth0` if you use IIS Express, or `http://localhost:5000/signin-auth0` if you use Kestrel, so be sure to add this to the **Allowed Callback URLs** section of your application.
-
-If you deploy your application to a different URL you will also need to ensure to add that URL to the **Allowed Callback URLs**. For ASP.NET Core this URL will take the format `http://YOUR_APPLICATION_URL/signin-auth0`  
-
-## Configure JSON Web Token Signature Algorithm
-
-The ASP.NET Core OpenID Connect (OIDC) middleware which will be used to authenticate the user, requires that the JSON Web Token (JWT) be signed with an asymmetric key. To configure this go to the settings for your application in the Auth0 Dashboard, scroll down and click on **Show Advanced Settings**. Go to the **OAuth** tab and set the **JsonWebToken Signature Algorithm** to **RS256**.
-
-Save your changes.     
-
-## Dependencies
-
-To integrate Auth0 with ASP.NET Core you will use the Cookie and OpenID Connect (OIDC) authentication handlers. The seed project already references the ASP.NET Core metapackage (`Microsoft.AspNetCore.All`) which includes **all** NuGet packages shipped by Microsoft as part of ASP.NET Core 2.0, including the packages for the Cookie and OIDC authentication handlers.
-
-If you are adding this to your own existing project, and you have note referenced the metapackage, then please make sure that you add the `Microsoft.AspNetCore.Authentication.Cookies` and `Microsoft.AspNetCore.Authentication.OpenIdConnect` packages to your application.
-
-```bash
-Install-Package Microsoft.AspNetCore.Authentication.Cookies
-Install-Package Microsoft.AspNetCore.Authentication.OpenIdConnect
-```
\ No newline at end of file
diff --git a/articles/quickstart/webapp/aspnet-core/dashboard-default.md b/articles/quickstart/webapp/aspnet-core/dashboard-default.md
deleted file mode 100644
index 4399a27197..0000000000
--- a/articles/quickstart/webapp/aspnet-core/dashboard-default.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial will show you how to use the standard OpenID Connect middleware to add authentication to your web app.
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-mvc-samples',
-  path: 'Quickstart/01-Login',
-  requirements: [
-    '.NET Core 1.1.0',
-    'ASP.NET Core 1.1.1',
-    'Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.1'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/aspnet-core/download.md b/articles/quickstart/webapp/aspnet-core/download.md
new file mode 100644
index 0000000000..5b15cbb798
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure .NET Core is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a Docker image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/aspnet-core/files/AccountController.md b/articles/quickstart/webapp/aspnet-core/files/AccountController.md
new file mode 100644
index 0000000000..52bd2b6799
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core/files/AccountController.md
@@ -0,0 +1,62 @@
+---
+name: AccountController.cs
+language: javascript
+---
+    
+```javascript
+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
+    );
+  }
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-core/files/account.controller.md b/articles/quickstart/webapp/aspnet-core/files/account.controller.md
new file mode 100644
index 0000000000..7e773fd254
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core/files/appsettings.md b/articles/quickstart/webapp/aspnet-core/files/appsettings.md
new file mode 100644
index 0000000000..8e344581e6
--- /dev/null
+++ b/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}"
+  }
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-core/files/program.md b/articles/quickstart/webapp/aspnet-core/files/program.md
new file mode 100644
index 0000000000..9383bb20e1
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: javascript
+---
+    
+```javascript
+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();
+```
diff --git a/articles/quickstart/webapp/aspnet-core/index.yml b/articles/quickstart/webapp/aspnet-core/index.yml
index c3364ac682..3b3a20f345 100644
--- a/articles/quickstart/webapp/aspnet-core/index.yml
+++ b/articles/quickstart/webapp/aspnet-core/index.yml
@@ -1,16 +1,39 @@
-title: ASP.NET Core v2.0
+title: ASP.NET Core MVC
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/asp.png
-tags:
+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:
-  - aspnetcore
-  - aspnetcore-2.0
+  - net-6
+  - net-7
+  - net-8
 seo_alias: aspnet-core
-default_article: dashboard-default
+default_article: 01-login
 articles:
-  - 00-intro
   - 01-login
-  - 02-user-profile
-  - 03-authorization
\ No newline at end of file
+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/articles/quickstart/webapp/aspnet-core/interactive.md b/articles/quickstart/webapp/aspnet-core/interactive.md
new file mode 100644
index 0000000000..616cd153d6
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-core/interactive.md
@@ -0,0 +1,60 @@
+---
+title: Add Login to Your ASP.NET MVC Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET MVC application using the Auth0.AspNetCore.Authentication SDK.
+interactive:  true
+files:
+ - files/Program
+ - files/appsettings
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: en-US
+---
+
+# 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.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to 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 to your application.
        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" }}}
+
+
+
        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.
        ASP.NET MWC Step 3 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## 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 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.
        ASP.NET MWC Step 4 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Logout
+
+
+
        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.
        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.
        ASP.NET MWC Step 5 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/aspnet-owin/00-intro.md b/articles/quickstart/webapp/aspnet-owin/00-intro.md
deleted file mode 100644
index d3032cca34..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/00-intro.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Introduction
-name: Introduction to the quickstart guide and configuring the environment
-description: This quickstart guide will walk you through the various tasks related to integrating Auth0 into your ASP.NET MVC 5 application.
-budicon: 715
----
-
-::: panel System Requirements
-This tutorial and seed project have been tested with the following:
-
-* Microsoft Visual Studio 2017
-* Auth0-ASPNET-Owin NuGet Package v2.3.0
-:::
-
-This quickstart guide will walk you through the various tasks related to integrating Auth0 into your ASP.NET MVC 5 application.
-
-## Sample Projects
-
-If you would like to follow along with this quickstart, you can download a blank starter [seed project](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples/tree/master/Quickstart/00-Starter-Seed). This is just a regular ASP.NET MVC application with a home page and a `web.config` file where you can configure the various Auth0-related settings for your application.
-
-Each of the steps in this guide contains a sample project download that shows the completion of the step. These projects can also be downloaded from the [ASP.NET (OWIN) MVC samples repository](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples) where you can find the final result for each step in the relevant folder.
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
diff --git a/articles/quickstart/webapp/aspnet-owin/01-login.md b/articles/quickstart/webapp/aspnet-owin/01-login.md
index fd183e7016..15e4c11ef5 100644
--- a/articles/quickstart/webapp/aspnet-owin/01-login.md
+++ b/articles/quickstart/webapp/aspnet-owin/01-login.md
@@ -1,15 +1,204 @@
 ---
 title: Login
-description: This tutorial demonstrates how to use the Auth0 OAuth2 middleware to add authentication to your web app
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-samples',
-  path: 'Quickstart/01-Login'
-}) %>
+<%= include('_includes/_setup') %>
 
-<%= include('_includes/_login') %>
+## Install and configure the OpenID Connect middleware
 
-Continue to the [Storing Tokens step](/quickstart/webapp/aspnet-owin/02-storing-tokens) which will demonstrate how you can store the tokens returned by Auth0.
+::: 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 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.
+
+
+
+
+## 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/articles/quickstart/webapp/aspnet-owin/02-storing-tokens.md b/articles/quickstart/webapp/aspnet-owin/02-storing-tokens.md
deleted file mode 100644
index 77074574db..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/02-storing-tokens.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Storing Tokens
-description: This tutorial demonstrates how store the tokens returned from Auth0 in order to use them later on.
-budicon: 280
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-samples',
-  path: 'Quickstart/02-Storing-Tokens'
-}) %>
-
-
-The Auth0 OAuth2 middleware can automatically add the `id_token` and `access_token` as claims on the `ClaimsIdentity` by setting the `SaveIdToken` and `SaveAccessToken` properties of the `Auth0AuthenticationOptions` to `true`. 
-
-You can also save the Refresh Token by setting the `SaveRefreshToken` property to `true`, but you will need to ensure that Auth0 issues a `refresh_token` by requesting the `offline_access` scope.
-
-Update the registration of the Auth0 middleware in your `Startup.cs` file as follows:
-
-```csharp
-// Startup.cs
-
-public void Configuration(IAppBuilder app)
-{
-    // Configure Auth0 parameters
-    string auth0Domain = ConfigurationManager.AppSettings["auth0:Domain"];
-    string auth0ClientId = ConfigurationManager.AppSettings["auth0:ClientId"];
-    string auth0ClientSecret = ConfigurationManager.AppSettings["auth0:ClientSecret"];
-
-    // Set Cookies as default authentication type
-    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
-    app.UseCookieAuthentication(new CookieAuthenticationOptions
-    {
-        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
-        LoginPath = new PathString("/Account/Login")
-    });
-
-    // Configure Auth0 authentication
-    var options = new Auth0AuthenticationOptions()
-    {
-        Domain = auth0Domain,
-        ClientId = auth0ClientId,
-        ClientSecret = auth0ClientSecret,
-
-        // Save the tokens to claims
-        SaveIdToken = true,
-        SaveAccessToken = true,
-        SaveRefreshToken = true,
-        
-        // If you want to request an access_token to pass to an API, then replace the audience below to 
-        // pass your API Identifier instead of the /userinfo endpoint
-        Provider = new Auth0AuthenticationProvider()
-        {
-            OnApplyRedirect = context =>
-            {
-                string userInfoAudience = $"https://{auth0Domain}/userinfo";
-                string redirectUri = context.RedirectUri + "&audience=" + WebUtility.UrlEncode(userInfoAudience);
-
-                context.Response.Redirect(redirectUri);
-            }
-        }
-    };
-    options.Scope.Add("offline_access"); // Request a refresh_token
-    app.UseAuth0Authentication(options);
-}
-```
-
-To access these token from one of your controllers, simply cast the `User.Identity` property to a `ClaimsIdentity`, and then find the particular claim by querying the `Claims` property.
-
-The sample code below shows how you can extract the claims for the `access_token`, `id_token` and `refresh_token` respectively:
-
-``` csharp
-// Controllers/AccountController.cs
-
-[Authorize]
-public ActionResult Tokens()
-{
-    var claimsIdentity = User.Identity as ClaimsIdentity;
-
-    // Extract tokens
-    string accessToken = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == "access_token")?.Value;
-    string idToken = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == "id_token")?.Value;
-    string refreshToken = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == "refresh_token")?.Value;
-
-    // Now you can use the tokens as appropriate...
-}
-```
diff --git a/articles/quickstart/webapp/aspnet-owin/03-user-profile.md b/articles/quickstart/webapp/aspnet-owin/03-user-profile.md
deleted file mode 100644
index b53338b40d..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/03-user-profile.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to get the user's profile and display it.
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-samples',
-  path: 'Quickstart/03-User-Profile'
-}) %>
-
-## Getting the profile
-
-The Auth0 OAuth2 middleware will automatically retrieve the user's information from Auth0 and add it as claims to the `ClaimsIdentity`. The seed project contains a controller action and view which will display the claims associated with a particular user. Once a user has signed in, you can simply go to `/Account/Claims` to see these claims.
-
-By default, the `email` claim will not be included in the list of claims returned by Auth0. You will need to request it explicitly by requesting the **email** `scope` when your register the Auth0 middleware:
-
-```csharp
-// Startup.cs
-
-public void Configuration(IAppBuilder app)
-{
-    // Some code omitted for brevity...
-
-    // Configure Auth0 authentication
-    var options = new Auth0AuthenticationOptions()
-    {
-        Domain = auth0Domain,
-        ClientId = auth0ClientId,
-        ClientSecret = auth0ClientSecret,
-
-        // Some code omitted for brevity...
-    };
-    options.Scope.Add("email"); // Request user's email address
-    app.UseAuth0Authentication(options);
-}
-```
-
-You may also want to create a nicer looking user profile page which will display a user's name, email address and profile image.
-
-First, create a view model which will contain the basic user profile information, such as a `Name`, `EmailAddress` and `ProfileImage`:
-
-```csharp
-// ViewModels/UserProfileViewModel.cs
-
-public class UserProfileViewModel
-{
-    public string EmailAddress { get; set; }
-
-    public string Name { get; set; }
-
-    public string ProfileImage { get; set; }
-}
-```
-
-Add a new `Profile` action to the `AccountController` and extract the relevant claims and add them to a new instance of `UserProfileViewModel` which is then passed to the view. Be sure to decorate the action with the `[Authorize]` attribute so only authenticated users can access the action:
-
-```csharp
-// Controllers/AccountController.cs
-
-[Authorize]
-public ActionResult UserProfile()
-{
-    var claimsIdentity = User.Identity as ClaimsIdentity;
-
-    return View(new UserProfileViewModel()
-    {
-        Name = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Name)?.Value,
-        EmailAddress = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
-        ProfileImage = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == "picture")?.Value
-    });
-}
-```
-
-Next create a view. For the view, display a user profile card at the top with the user's name, email address and profile image.
-
-```html
-
-
-@model global::MvcApplication.ViewModels.UserProfileViewModel
-@{
-    ViewData["Title"] = "User Profile";
-}
-
-
        
-    
        
-        
        
-            
        @ViewData["Title"].
        
-
-            
        
-                
-            
        
-            
        
-                
        @Model.Name
        
-                
        
-                     @Model.EmailAddress
-                
        
-            
        
-        
        
-    
        
-
        
-```
-
-Now when you log in and then go to the URL `/Account/UserProfile` you will see all the users's profile displayed.
-
-## Displaying the user's name in the navigation bar
-
-You may also want to put a link in the top navigation bar to display the user's name, and when the user clicks on that you can navigate them to their Profile page.
-
-Go to the `Views/Shared/_Layout.cshtml` file and update the Navbar section which displays the Login and Logout options to also display the user's name and link to the `Profile` action in the `AccountController`:
-
-```html
-
-
-
          
-@if (User.Identity.IsAuthenticated)
-{
-    
        • @Html.ActionLink("Hello " + User.Identity.Name, "Profile", "Account")
          • 
-    
        • @Html.ActionLink("Logout", "Logout", "Account")
          • 
-}
-else
-{
-    
        • @Html.ActionLink("Login", "Login", "Account")
          • 
-}
-
        
-```
-
-Now, after the user has logged in you will be able to see their name in the top right corner of the navigation bar:
-
-![](/media/articles/server-platforms/aspnet-owin/navbar-userprofile.png)
diff --git a/articles/quickstart/webapp/aspnet-owin/04-authorization.md b/articles/quickstart/webapp/aspnet-owin/04-authorization.md
deleted file mode 100644
index 82de4639e8..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/04-authorization.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how assign roles to your users, and use those claims to authorize or deny a user to access certain routes in the app.
-budicon: 500
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-samples',
-  path: 'Quickstart/04-Authorization'
-}) %>
-
-Many identity providers will supply access claims, like roles or groups, with the user. You can request these in your token by setting `scope: openid roles` or `scope: openid groups`. However, not every identity provider provides this type of information. Fortunately, Auth0 has an alternative to it, which is creating a rule for assigning different roles to different users.
-
-::: note
-This tutorial assumes that you are familiar with [Rules](/rules/current).
-:::
-
-### Create a Rule to assign roles
-
-First, we will create a rule that assigns our users either an `admin` role, or a single `user` role. 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:
-
-```js
-function (user, context, callback) {
-  var addRolesToUser = function(user, cb) {
-    if (user.email.indexOf('@example.com') > -1) {
-      cb(null, ['admin']);
-    } else {
-      cb(null, ['user']);
-    }
-  };
-
-  addRolesToUser(user, function(err, roles) {
-    if (err) {
-      callback(err);
-    } else {
-      context.idToken["https://schemas.quickstarts.com/roles"] = roles;     
-      callback(null, user, context);
-    }
-  });
-}
-```
-
-Update the code to check for your own email domain, or match the condition according to your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-This quickstart uses `https://schemas.quickstarts.com` for the claim namespace, 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`
-
-## Restrict an action based on a user's roles
-
-As with the country property which was added in the previous step, you will also need to manually extract the roles from the user in the `OnAuthenticated` event and add the appropriate claims. For each role, you can add a role of the type `ClaimTypes.Role`.
-
-This will ensure proper integration with the existing role-based authorization in ASP.NET MVC and allow you to restrict access to a controller by simply decorating your controller actions with the `[Authorize(Roles = ?)]` attribute
-
-So change the existing middleware registration in the `Startup` class to extract the roles and add the claims:
-
-```csharp
-// Startup.cs
-
-var options = new Auth0AuthenticationOptions()
-{
-  Domain = auth0Domain,
-  ClientId = auth0ClientId,
-  ClientSecret = auth0ClientSecret,
-
-  Provider = new Auth0AuthenticationProvider
-  {
-    OnApplyRedirect = context =>
-    {
-        string userInfoAudience = $"https://{auth0Domain}/userinfo";
-        string redirectUri = context.RedirectUri + "&audience=" + WebUtility.UrlEncode(userInfoAudience);
-
-        context.Response.Redirect(redirectUri);
-    },
-    OnAuthenticated = context =>
-    {
-        // Get the user's roles
-        var rolesObject = context.User["https://schemas.quickstarts.com/roles"];
-        if (rolesObject != null)
-        {
-            string[] roles = rolesObject.ToObject();
-            foreach (var role in roles)
-            {
-                context.Identity.AddClaim(new Claim(ClaimTypes.Role, role, ClaimValueTypes.String, context.Connection));
-            }
-        }
-
-
-        return Task.FromResult(0);
-    }
-  }
-};
-app.UseAuth0Authentication(options);
-```
-
-Now you can add a new action to your controller and restrict it by decorating your controller actions with the `[Authorize(Roles = ?)]` attribute.
-
-The sample code below will restrict the particular action only to the user who have the "admin" role:
-
-```csharp
-// Controllers/AccountController.cs
-
-[Authorize(Roles = "admin")]
-public ActionResult Admin()
-{
-    return View();
-}
-```
diff --git a/articles/quickstart/webapp/aspnet-owin/_includes/_login.md b/articles/quickstart/webapp/aspnet-owin/_includes/_login.md
deleted file mode 100644
index 52d8b97287..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/_includes/_login.md
+++ /dev/null
@@ -1,187 +0,0 @@
-## Add Authentication with 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 MVC 5 application.
-
-::: note
-You can also create a custom login for prompting the user for their username and password. To learn how to do this in your application, follow the [Custom Login sample](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples/tree/master/Samples/custom-login).
-:::
-
-## Install and Configure Auth0 OAuth2 Middleware
-
-The easiest way to enable authentication with Auth0 in your ASP.NET MVC application is to use the Auth0 ASP.NET OAuth2 middleware which is available in the `Auth0-ASPNET-Owin` NuGet package, so install that first:
-
-```bash
-Install-Package Auth0-ASPNET-Owin
-```
-
-There is a bug in Microsoft's OWIN implementation for System.Web, which can cause cookies to disappear on some occasions. To work around this issue, you will also need to install the `Kentor.OwinCookieSaver` NuGet package:
-
-```bash
-Install-Package Kentor.OwinCookieSaver
-```
-
-Now go to the `Configuration` method of your `Startup` class and configure the cookie middleware as well as the Auth0 middleware. Also be sure to register the [Kentor OWIN Cookie saver middleware](https://github.com/KentorIT/owin-cookie-saver) which must be added *before* any cookie handling middleware.
-
-```cs
-// Startup.cs
-
-public void Configuration(IAppBuilder app)
-{
-    // Configure Auth0 parameters
-    string auth0Domain = ConfigurationManager.AppSettings["auth0:Domain"];
-    string auth0ClientId = ConfigurationManager.AppSettings["auth0:ClientId"];
-    string auth0ClientSecret = ConfigurationManager.AppSettings["auth0:ClientSecret"];
-
-    // Enable the Cookie saver middleware to work around a bug in the OWIN implementation
-    app.UseKentorOwinCookieSaver();
-
-    // Set Cookies as default authentication type
-    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
-    app.UseCookieAuthentication(new CookieAuthenticationOptions
-    {
-        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
-        LoginPath = new PathString("/Account/Login")
-    });
-
-    // Configure Auth0 authentication
-    var options = new Auth0AuthenticationOptions()
-    {
-        Domain = auth0Domain,
-        ClientId = auth0ClientId,
-        ClientSecret = auth0ClientSecret,
-
-        // If you want to request an access_token to pass to an API, then replace the audience below to 
-        // pass your API Identifier instead of the /userinfo endpoint
-        Provider = new Auth0AuthenticationProvider()
-        {
-            OnApplyRedirect = context =>
-            {
-                string userInfoAudience = $"https://{auth0Domain}/userinfo";
-                string redirectUri = context.RedirectUri + "&audience=" + WebUtility.UrlEncode(userInfoAudience);
-
-                context.Response.Redirect(redirectUri);
-            }
-        }
-    };
-    app.UseAuth0Authentication(options);
-}
-```
-
-It is important that you register both the cookie middleware and the Auth0 middleware, as all of them are required for the authentication to work. The Auth0 middleware will handle the authentication with Auth0. Once the user has authenticated, their identity will be stored in the cookie middleware.
-
-::: note
-We are passing the Auth0 tenant's user info endpoint as the `audience` parameter to the `/authorize` endpoint. This is to ensure that all authentication reponses are [OIDC Conformant](/api-auth/intro).
-:::
-
-## Add Login and Logout Methods
-
-Next, you will need to add `Login` and `Logout` actions to the `AccountController`.
-
-The `Login` action will return a `ChallengeResult` which will instruct the OWIN middleware to challenge the particular piece of Authentication middleware (in the case the "Auth0" middleware) to authenticate. 
-
-For the `Logout` action you will need to sign the user out of the cookie middleware (which will clear the local application session), as well as Auth0. For more information you can refer to the Auth0 [Logout](/logout) documentation.
-
-```cs
-// Controllers/AccountController.cs
-
-public class AccountController : Controller
-{
-    public ActionResult Login(string returnUrl)
-    {
-        return new ChallengeResult("Auth0", returnUrl ?? Url.Action("Index", "Home"));
-    }
-
-    [Authorize]
-    public void Logout()
-    {
-        HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
-        HttpContext.GetOwinContext().Authentication.SignOut(new AuthenticationProperties
-        {
-            RedirectUri = Url.Action("Index", "Home")
-        }, "Auth0");
-    }
-
-    [Authorize]
-    public ActionResult Claims()
-    {
-        return View();
-    }
-}
-```
-
-You will also need to add the following code for the `ChallengeResult` class to your project:
-
-```csharp
-// Controllers/AccountController.cs
-
-internal class ChallengeResult : HttpUnauthorizedResult
-{
-    private const string XsrfKey = "XsrfId";
-
-    public ChallengeResult(string provider, string redirectUri)
-        : this(provider, redirectUri, null)
-    {
-    }
-
-    public ChallengeResult(string provider, string redirectUri, string userId)
-    {
-        LoginProvider = provider;
-        RedirectUri = redirectUri;
-        UserId = userId;
-    }
-
-    public string LoginProvider { get; set; }
-    public string RedirectUri { get; set; }
-    public string UserId { get; set; }
-
-    public override void ExecuteResult(ControllerContext context)
-    {
-        var properties = new AuthenticationProperties { RedirectUri = RedirectUri };
-        if (UserId != null)
-        {
-            properties.Dictionary[XsrfKey] = UserId;
-        }
-        context.HttpContext.GetOwinContext().Authentication.Challenge(properties, LoginProvider);
-    }
-}
-```
-
-## Add Login and Logout Links
-
-Lastly, add Login and Logout links to the navigation bar. To do that, head over to `/Views/Shared/_Layout.cshtml` and add code to the navigation bar section which displays a Logout link when the user is authenticated, otherwise a Login link. These will link to the `Logout` and `Login` actions of the `AccountController` respectively:
-
-```html
-
-
-
        
-    
        
-        
        
-            
-            @Html.ActionLink("Application name", "Index", "Home", new { area = "" }, new { @class = "navbar-brand" })
-        
        
-        
        
-            
          
-                
        • @Html.ActionLink("Home", "Index", "Home")
          • 
-            
        
-            
          
-                @if (User.Identity.IsAuthenticated)
-                {
-                    
        • @Html.ActionLink("Logout", "Logout", "Account")
          • 
-                }
-                else
-                {
-                    
        • @Html.ActionLink("Login", "Login", "Account")
          • 
-                }
-            
        
-        
        
-    
        
-
        
-```
-
-## Run the Application
-
-Now when you run the application you can select the Login link to log in to the application. This will display the Login page with the Auth0 Lock component embedded in the page. The user can enter their username and password to log in, or alternatively log in with any of the social login providers you may have configured.
diff --git a/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md b/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
index db94a99306..5db5d77940 100644
--- a/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
+++ b/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
@@ -1,11 +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 Auth0 OAuth2 middleware to complete the authentication process.
+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:56572/signin-auth0`, so be sure to add this to the **Allowed Callback URLs** section of your application. Also add `http://localhost:56572/` to the **Allowed Logout URLs**.
+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**.
+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!
-
-Please continue with the [Login](/quickstart/webapp/aspnet-owin/01-login) tutorial to know how to implement basic login.
\ No newline at end of file
diff --git a/articles/quickstart/webapp/aspnet-owin/dashboard-default.md b/articles/quickstart/webapp/aspnet-owin/dashboard-default.md
deleted file mode 100644
index 0bf2d3fce0..0000000000
--- a/articles/quickstart/webapp/aspnet-owin/dashboard-default.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 OAuth2 middleware to add authentication to your web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-samples',
-  path: 'Quickstart/01-Login'
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/aspnet-owin/download.md b/articles/quickstart/webapp/aspnet-owin/download.md
new file mode 100644
index 0000000000..2a8ddc0c97
--- /dev/null
+++ b/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 to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+```text
+http://localhost:3000
+```
+
+3) Open the project in Visual Studio.
+
+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/articles/quickstart/webapp/aspnet-owin/files/AccountController.md b/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
new file mode 100644
index 0000000000..0f87e854e3
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
@@ -0,0 +1,47 @@
+---
+name: AccountController.cs
+language: csharp
+---
+    
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+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/articles/quickstart/webapp/aspnet-owin/files/Web.md b/articles/quickstart/webapp/aspnet-owin/files/Web.md
new file mode 100644
index 0000000000..c88062828f
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-owin/files/Web.md
@@ -0,0 +1,14 @@
+---
+name: Web.config
+language: 
+---
+    
+```
+
+
+  
+    
+    
+  
+
+```
diff --git a/articles/quickstart/webapp/aspnet-owin/files/account.controller.md b/articles/quickstart/webapp/aspnet-owin/files/account.controller.md
new file mode 100644
index 0000000000..f3a44a134e
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-owin/files/startup.md b/articles/quickstart/webapp/aspnet-owin/files/startup.md
new file mode 100644
index 0000000000..d1fbe54773
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-owin/files/startup.md
@@ -0,0 +1,82 @@
+---
+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);
+            }
+        }
+    });
+}
+```
diff --git a/articles/quickstart/webapp/aspnet-owin/files/web.config.md b/articles/quickstart/webapp/aspnet-owin/files/web.config.md
new file mode 100644
index 0000000000..02a8c6b911
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-owin/index.yml b/articles/quickstart/webapp/aspnet-owin/index.yml
index 6f09d61a1c..a14bac0006 100644
--- a/articles/quickstart/webapp/aspnet-owin/index.yml
+++ b/articles/quickstart/webapp/aspnet-owin/index.yml
@@ -1,7 +1,15 @@
 title: ASP.NET (OWIN)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/asp.png
-tags:
+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
@@ -10,10 +18,31 @@ alias:
   - aspnetowin
   - owin
 seo_alias: aspnet-owin
-default_article: dashboard-default
+default_article: 01-login
 articles:
-  - 00-intro
   - 01-login
-  - 02-storing-tokens
-  - 03-user-profile
-  - 04-authorization
\ No newline at end of file
+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/articles/quickstart/webapp/aspnet-owin/interactive.md b/articles/quickstart/webapp/aspnet-owin/interactive.md
new file mode 100644
index 0000000000..c1a61a7c79
--- /dev/null
+++ b/articles/quickstart/webapp/aspnet-owin/interactive.md
@@ -0,0 +1,71 @@
+---
+title: Add Login to your ASP.NET OWIN Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET OWIN application using the Microsoft.Owin.Security.OpenIdConnect Nuget package.
+interactive:  true
+files:
+ - files/Web
+ - files/Startup
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: en-US
+---
+
+# 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.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Configure the project {{{ data-action="code" data-code="Web.config" }}}
+
+
+
        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.
        Install-Package Microsoft.Owin.Security.OpenIdConnect
+
+Install-Package Microsoft.Owin.Security.Cookies
+
+
        
+
+
        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 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, 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#18:74" }}}
+
+
+
        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.
        
+
+## Add login to your application {{{ data-action="code" data-code="AccountController.cs#7:16" }}}
+
+
+
        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.
        ASP.NET (OWIN) - Step 4 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        ASP.NET (OWIN) - Step 5 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page 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.
        ASP.NET (OWIN) - Step 6 - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/aspnet/01-login.md b/articles/quickstart/webapp/aspnet/01-login.md
deleted file mode 100644
index c8ac24727b..0000000000
--- a/articles/quickstart/webapp/aspnet/01-login.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 ASP.NET SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'aspnet-samples',
-  path: 'Quickstart/00-Starter-Seed/auth0-aspnet-mvc4-sample/',
-  requirements: [
-    'Microsoft Visual Studio 2017',
-    'Auth0-ASPNET v2.1.0'
-  ]
-}) %>
-
-## Install the Auth0-ASPNET NuGet Package
-
-Install the Auth0-ASPNET package. In the NuGet Package Manager, click **Tools** > **Library package manager** > **Package Manager Console**. In the console, run the command: 
-
-${snippet(meta.snippets.dependencies)}
-
-::: note
-This package adds the `LoginCallback.ashx` file to your project to process the login. 
-:::
-
-## Configure Callback URLs
-
-After authenticating the user on Auth0, send a POST request to the `/LoginCallback.ashx` URL on your website, for example `http://localhost:PORT/LoginCallback.ashx`. 
-
-For security, register this URL in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
-
-![Callback URLs](/media/articles/server-platforms/aspnet/callback_url.png)
-
-## Fill Web.Config With Your Auth0 Settings
-
-The NuGet package creates three settings on ``. Replace them with the following settings:
-
-${snippet(meta.snippets.setup)}
-
-## Authenticate the User
-
-To authenticate the user, redirect them to Auth0's `/authorize` endpoint:
-
-```c#
-// Controllers/AccountController.cs
-public ActionResult Login(string returnUrl)
-{
-    var client = new AuthenticationApiClient(
-        new Uri(string.Format("https://{0}", ConfigurationManager.AppSettings["auth0:Domain"])));
-
-
-    var request = this.Request;
-    var redirectUri = new UriBuilder(request.Url.Scheme, request.Url.Host, this.Request.Url.IsDefaultPort ? -1 : request.Url.Port, "LoginCallback.ashx");
-
-    var authorizeUrlBuilder = client.BuildAuthorizationUrl()
-        .WithClient(ConfigurationManager.AppSettings["auth0:ClientId"])
-        .WithRedirectUrl(redirectUri.ToString())
-        .WithResponseType(AuthorizationResponseType.Code)
-        .WithScope("openid profile")
-        .WithAudience("https://" + @ConfigurationManager.AppSettings["auth0:Domain"] + "/userinfo");
-
-    if (!string.IsNullOrEmpty(returnUrl))
-    {
-        var state = "ru=" + HttpUtility.UrlEncode(returnUrl);
-        authorizeUrlBuilder.WithState(state);
-    }
-
-    return new RedirectResult(authorizeUrlBuilder.Build().ToString());
-}
-```
-
-## Access User Information
-
-When the user logs in to the application, a `ClaimsPrincipal` class is generated. You can access it through the `Current` property:
-
-```cs
-// Controllers/HomeController.cs
-public ActionResult Index()
-{
-  string name = ClaimsPrincipal.Current.FindFirst("name")?.Value;
-}
-```
-
-The user profile you receive is always a normalized user profile. The profile includes the following attributes:
-* `name`
-* `nickname`
-* `picture`
-* `updated_at`
-
-For more information about the user profile, read the [user profile documentation](/user-profile).
-
-## Further Reading
-
-### Handle authorization
-
-On each request, the `LoginCallback.ashx` handler and the `Http` module generate an `IPrincipal`. Because of that, you can use the following authorization methods: 
-* The declarative `[Authorization]` protection
-* The `` protection
-* Code-based checks, for example, `User.Identity.IsAuthenticated`
-
-### Automatically redirect to the login page
-
-If the request is not authenticated, the `[Authorize]` attribute generates a 401 (Unauthorized) error. If you want to automatically redirect users to the login page, you can use the Forms Authentication module. 
-
-In `web.config`, configure the following:
-
-```xml
-
-
-  
-    
-  
-
-```
-
-In the above example, we are redirecting to the `Login` action in an `Account` controller, which in turn redirects to Auth0's `/authorize` endpoint for authentication, as described in [#4](#4-authenticating-the-user).
-
-### Set up logout
-
-To clear the cookie generated on login, use the `FederatedAuthentication.SessionAuthenticationModule.SignOut()` method on the `AccountController\Logout` method.
-
-The example below shows a typical logout action on ASP.Net MVC:
-
-```cs
-// Controllers/AccountController.cs
-public RedirectResult Logout()
-{
-  // Clear the session cookie
-  FederatedAuthentication.SessionAuthenticationModule.SignOut();
-
-  // Redirect to Auth0's logout endpoint
-  var returnTo = Url.Action("Index", "Home", null, protocol: Request.Url.Scheme );
-  return this.Redirect(
-    string.Format(CultureInfo.InvariantCulture,
-      "https://{0}/v2/logout?returnTo={1}",
-      ConfigurationManager.AppSettings["auth0:Domain"],
-      this.Server.UrlEncode(returnTo)));
-}
-```
-
-The destination URL is stored in the `returnTo` value. 
-
-::: note 
-The destination URL must be on the`Allowed Logout URLs` list. Read more about redirecting users after they log out in the [Logout](/logout#redirecting-users-after-logout) article.
-:::
-
-### Link accounts
-
-To allow users to link accounts from different providers, read the [Linking User Accounts](/link-accounts) article.
-
-To link accounts, you need the logged-in user's Access Token. You can get it from:
-
-```
-${'<%= ClaimsPrincipal.Current.FindFirst("access_token").Value %>'}
-```
-
-### Flow the user's identity to a WCF service
-
-If you want to flow the logged-in user's identity to a WCF service or an API, use the `responseType: 'token'` parameter on the login widget constructor. When the parameter is sent, Auth0 generates an ID Token. You can send the ID Token to your service or use it to generate an `ActAs` token. The ID Token is a [JSON Web Token](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06).
-
-### Manage the dev, test and production environments
-
-We recommend that you create one application per environment. For each environment, use a different client ID and secret. To learn more, read about [using Auth0 with Microsoft Azure](/azure-tutorial).
diff --git a/articles/quickstart/webapp/aspnet/index.yml b/articles/quickstart/webapp/aspnet/index.yml
deleted file mode 100644
index e00494e70f..0000000000
--- a/articles/quickstart/webapp/aspnet/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: ASP.NET (System.Web)
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/aspnet/dependencies
-  setup: server-platforms/aspnet/setup
-  use: server-platforms/aspnet/use
-alias:
-  - microsoft-net
-  - aspnet-mvc
-  - net-mvc
-seo_alias: aspnet
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/config.yml b/articles/quickstart/webapp/config.yml
index f74f749e9b..51f64e8751 100644
--- a/articles/quickstart/webapp/config.yml
+++ b/articles/quickstart/webapp/config.yml
@@ -1,21 +1,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 anomaly detection
-      icon: 345
-      href: "/anomaly-detection"
-    - text: Learn about options for storing tokens
-      icon: 345
-      href: "/security/store-tokens"
-    - text: Learn about the user profile structure
-      icon: 345
-      href: "/user-profile/normalized/oidc"
-    - text: In-depth details about user profile
-      icon: 345
-      href: "/user-profile/user-profile-details"
\ No newline at end of file
+sample_download_required_data:
+  - client
diff --git a/articles/quickstart/webapp/django/01-login.md b/articles/quickstart/webapp/django/01-login.md
index d4e340a4e3..542e1a597b 100644
--- a/articles/quickstart/webapp/django/01-login.md
+++ b/articles/quickstart/webapp/django/01-login.md
@@ -1,270 +1,272 @@
 ---
 title: Login
 default: true
-description: This tutorial demonstrates how integrate Auth0 with a Django Web Applcation.
+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' }) %>
 
-You can get started by either downloading the complete project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-django-web-app',
-  path: '01-Login',
-  requirements: [
-    'python 2.7, 3.0 and up',
-    'django 1.11 and up',
-    'social-auth-app-django 1.2.0 and up',
-    'python-jose 1.3.2 and up',
-    'six 1.10.0 and up',
-    'python-dotenv 0.6.5 and up'
-  ]
-}) %>
+## Create application
 
-<%= include('../_includes/_getting_started', { library: 'Django', callback: 'http://localhost:3000/complete/auth0' }) %>
+For this guide we demonstrate how to integrate Auth0 with a Python application using the Django framework and Authlib. Let's start by ensuring Django is installed on your system. From your shell, run the following command:
 
-This guide will use [`social_django`](https://github.com/python-social-auth/social-app-django) which is the Django implementation of [Python Social Auth](http://python-social-auth.readthedocs.io/en/latest/). It adds an OAuth stack to the [user authentication & authorization system](https://docs.djangoproject.com/en/1.11/topics/auth/) bundled by the Django Web Framework.
-
-## Install the Dependencies
-
-Add the following dependencies to your `requirements.txt`:
-
-```text
-django
-social-auth-app-django
-python-dotenv
-requests
+```sh
+pip install django~=4.0
 ```
 
-Once the dependencies are listed in requirements.txt, run the following command:
+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:
 
-```bash
-pip install -r requirements.txt
+```sh
+django-admin startproject webappexample
+cd webappexample
 ```
 
-## Create a Django Project
+## Install dependencies
 
-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/1.11/intro/tutorial01/).
+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:
 
-The sample project was created with the following commands:
+```python
+# 📁 requirements.txt -----
 
-```bash
-$ django-admin startproject webappexample
-$ cd webappexample
-$ python manage.py startapp auth0login
+authlib ~= 1.0
+django ~= 4.0
+python-dotenv ~= 0.19
+requests ~= 2.27
 ```
 
-## Django Settings
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
 
-The `settings.py` file contains the configuration of your Django project. 
+## Configure your `.env` file
 
-Add one entry for `social_django` and for your application into the `INSTALLED_APPS` entry.
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
 
-```python
-# webappexample\settings.py
+```ini
+# 📁 .env -----
 
-INSTALLED_APPS = [
-    'social_django',
-    ''  # such as 'webappexample'
-]
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
 ```
 
-Add your Auth0 domain, the Client Id and the Client Secret. You can get this information the [application settings](/#/applications/${account.clientId}/settings) in the Auth0 Dashboard.
+## 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
+# 📁 webappexample/settings.py -----
 
-SOCIAL_AUTH_TRAILING_SLASH = False                    # Remove end slash from routes
-SOCIAL_AUTH_AUTH0_DOMAIN = '${account.namespace}'
-SOCIAL_AUTH_AUTH0_KEY = '${account.clientId}'
-SOCIAL_AUTH_AUTH0_SECRET = 'YOUR_CLIENT_SECRET'
+import os
+from dotenv import load_dotenv, find_dotenv
 ```
 
-Set the `SOCIAL_AUTH_AUTH0_SCOPE` variable with the scopes the application will request when authenticating. Check the [Scopes documentation](/scopes/current) for more information.
+Next, beneath the 'BASE_DIR' definition, add the following:
 
 ```python
-# webappexample\settings.py
+# 📁 webappexample/settings.py -----
 
-SOCIAL_AUTH_AUTH0_SCOPE = [
-    'openid',
-    'profile'
-]
+# Add the following line after 'BASE_DIR = ...'
+TEMPLATE_DIR = os.path.join(BASE_DIR, "webappexample", "templates")
 ```
 
-## Initialize the Database
+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.
 
-The `social_django` application defined in `INSTALLED_APPS` requires a database. Run the following command to create all the required databases for the applications defined in `INSTALLED_APPS`:
+```python
+# 📁 webappexample/settings.py -----
 
-```bash
-$ python manage.py migrate
+TEMPLATES = [
+    {
+        # Leave other lines as they are; we're just updating `DIRS`.
+        "DIRS": [TEMPLATE_DIR],
+    },
+]
 ```
 
-## Create the Auth0 Authentication Backend
+Finally, at the end of this file, add the following:
 
-The `social_django` application is now configured. The next step is to create an authentication backend that bridges `social_django` with Auth0.
+```python
+# 📁 webappexample/settings.py -----
 
-Create a file to implement the custom `Auth0` authentication backend. 
+# Load environment definition file
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
 
-```python
-# auth0login/auth0backend.py
-
-import requests
-from social_core.backends.oauth import BaseOAuth2
-
-
-class Auth0(BaseOAuth2):
-    """Auth0 OAuth authentication backend"""
-    name = 'auth0'
-    SCOPE_SEPARATOR = ' '
-    ACCESS_TOKEN_METHOD = 'POST'
-    EXTRA_DATA = [
-        ('picture', 'picture')
-    ]
-    
-    def authorization_url(self):
-        """Return the authorization endpoint."""
-        return "https://" + self.setting('DOMAIN') + "/authorize"
-    
-    def access_token_url(self):
-        """Return the token endpoint."""
-        return "https://" + self.setting('DOMAIN') + "/oauth/token"
-    
-    def get_user_id(self, details, response):
-        """Return current user id."""
-        return details['user_id']
-    
-    def get_user_details(self, response):
-        url = 'https://' + self.setting('DOMAIN') + '/userinfo'
-        headers = {'authorization': 'Bearer ' + response['access_token']}
-        resp = requests.get(url, headers=headers)
-        userinfo = resp.json()
-
-        return {'username': userinfo['nickname'],
-                'first_name': userinfo['name'],
-                'picture': userinfo['picture'],
-                'user_id': userinfo['sub']}
+
+# 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")
 ```
 
-::: note
-The callback URL will be calculated by `social-auth` by concatenating `/callback` with the backend `name` property, so it will be `/callback/auth0`.
-:::
+## Setup your application
+
+Now you're ready to start writing your application. Open the `webappexample/views.py` file in your project director.
 
-Register the authentication backends in `settings.py`. Add the custom backend for `Auth0` and `ModelBackend` for users to be able to login with username/password method.
+Begin by importing all the libraries your application will be making use of:
 
 ```python
-# webappexample\settings.py
+# 📁 webappexample/views.py -----
 
-AUTHENTICATION_BACKENDS = {
-    'YOUR_DJANGO_APP_NAME.auth0backend.Auth0',
-    'django.contrib.auth.backends.ModelBackend'
-}
+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
 ```
 
-Configure the login, redirect login and redirect logout URLs as set below. The LOGIN_URL ends with `auth0` as it needs to match the `name` property of the custom backend defined above.
+Now you can configure Authlib to handle your application's authentication with Auth0:
 
 ```python
-# webappexample\settings.py
-
-LOGIN_URL = "/login/auth0"
-LOGIN_REDIRECT_URL = "/dashboard"
-LOGOUT_REDIRECT_URL = "/"
+# 👆 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",
+)
 ```
 
-## Trigger Login with Social-Django
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from their documentation.
+
+## Setup your route handlers
 
-Add a handler for the `index` view in your `views.py` to render the `index.html`
+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
-# auth0login/views.py
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
 
-def index(request):
-    return render(request, 'index.html')
+def login(request):
+    return oauth.auth0.authorize_redirect(
+        request, request.build_absolute_uri(reverse("callback"))
+    )
 ```
 
-Add a link to `/login/auth0` in the `index.html` template.
+### 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.
 
-```html
-
-
-
-```
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
 
-## Access User Information
+def callback(request):
+    token = oauth.auth0.authorize_access_token(request)
+    request.session["user"] = token
+    return redirect(request.build_absolute_uri(reverse("index")))
+```
 
-After the user is logged in, you can access the user information from the `request.user` property. Add a handler for the `/dashboard` endpoint in the `views.py` file.
+### 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
-# auth0login/views.py
+# 👆 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,
+        ),
+    )
+```
 
-from django.shortcuts import render
-from django.contrib.auth.decorators import login_required
-import json
+### 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.
 
-@login_required
-def dashboard(request):
-    user = request.user
-    auth0user = user.social_auth.get(provider="auth0")
-    userdata = {
-        'user_id': auth0user.uid,
-        'name': user.first_name,
-        'picture': auth0user.extra_data['picture']
-    }
-    
-    return render(request, 'dashboard.html', {
-        'auth0User': auth0user,
-        'userdata': json.dumps(userdata, indent=4)
-    })
+```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),
+        },
+    )
 ```
 
-Add the following snippet to `dashboard.html` to display the [user information](/user-profile/normalized/oidc).
+### 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:
 
-```html
-
-
        
-    
        
-    
-    
        Welcome {{ user.username }}
        
-    
        {{ userdata }}
        
-
        
-```
+```python
+# 📁 webappexample/urls.py -----
 
-## Logout
+from django.urls import path
 
-To log a user out, add a link to `/logout` in `dashboard.html`.
+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"),
+]
 
-```html
-
-
-
        
-    
        
-    
-    
        Welcome {{ user.username }}
        
-    
        {{ userdata }}
        
-    Logout
-
        
 ```
 
-## Add URL Mappings
+## Add templates
 
-In previous steps we added methods to the `views.py` file. We need to map those methods to URLs.
+Now we just need to create the simple template files used in the routes about (during `render()` calls).
 
-Django has a [URL dispatcher](https://docs.djangoproject.com/en/1.11/topics/http/urls/) that lets you map URL patterns to views.
+Create a new sub-directory within the `webappexample` folder named `templates`, and create a `index.html` file:
 
-Add mappings for the root folder, the dashboard folder, and the authentication applications in `urls.py`.
+```html
+# 📁 webappexample/templates/index.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+    
        Welcome {{session.userinfo.name}}!
        
+    
        Logout
        
+    
        {{pretty}}
        
+    {% else %}
+    
        Welcome Guest
        
+    
        Login
        
+    {% endif %}
+  
+
 
-```python
-# auth0login\urls.py
+```
 
-urlpatterns = [
-    url('^$', views.index),
-    url(r'^dashboard', views.dashboard),
-    url(r'^', include('django.contrib.auth.urls', namespace='auth')),
-    url(r'^', include('social_django.urls', namespace='social')),
-]
+## 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.
diff --git a/articles/quickstart/webapp/django/download.md b/articles/quickstart/webapp/django/download.md
new file mode 100644
index 0000000000..a098e882df
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure Python 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 image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/django/files/index.md b/articles/quickstart/webapp/django/files/index.md
new file mode 100644
index 0000000000..7daba88473
--- /dev/null
+++ b/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/articles/quickstart/webapp/django/files/settings.md b/articles/quickstart/webapp/django/files/settings.md
new file mode 100644
index 0000000000..a944c7f58d
--- /dev/null
+++ b/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/articles/quickstart/webapp/django/files/urls.md b/articles/quickstart/webapp/django/files/urls.md
new file mode 100644
index 0000000000..2f77e379a8
--- /dev/null
+++ b/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/articles/quickstart/webapp/django/files/views.md b/articles/quickstart/webapp/django/files/views.md
new file mode 100644
index 0000000000..19da7478fe
--- /dev/null
+++ b/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/articles/quickstart/webapp/django/files/webappexample/settings.md b/articles/quickstart/webapp/django/files/webappexample/settings.md
new file mode 100644
index 0000000000..28f748dd86
--- /dev/null
+++ b/articles/quickstart/webapp/django/files/webappexample/settings.md
@@ -0,0 +1,35 @@
+---
+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/articles/quickstart/webapp/django/files/webappexample/templates/index.md b/articles/quickstart/webapp/django/files/webappexample/templates/index.md
new file mode 100644
index 0000000000..a1c6426ea1
--- /dev/null
+++ b/articles/quickstart/webapp/django/files/webappexample/templates/index.md
@@ -0,0 +1,23 @@
+---
+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/articles/quickstart/webapp/django/files/webappexample/urls.md b/articles/quickstart/webapp/django/files/webappexample/urls.md
new file mode 100644
index 0000000000..6a3c8bda44
--- /dev/null
+++ b/articles/quickstart/webapp/django/files/webappexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/articles/quickstart/webapp/django/files/webappexample/views.md b/articles/quickstart/webapp/django/files/webappexample/views.md
new file mode 100644
index 0000000000..f141c8ea43
--- /dev/null
+++ b/articles/quickstart/webapp/django/files/webappexample/views.md
@@ -0,0 +1,59 @@
+---
+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/articles/quickstart/webapp/django/index.yml b/articles/quickstart/webapp/django/index.yml
index 72c4106537..a44e0e28d1 100644
--- a/articles/quickstart/webapp/django/index.yml
+++ b/articles/quickstart/webapp/django/index.yml
@@ -1,7 +1,15 @@
 title: Django
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/python.png
-tags:
+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
@@ -10,3 +18,29 @@ 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/articles/quickstart/webapp/django/interactive.md b/articles/quickstart/webapp/django/interactive.md
new file mode 100644
index 0000000000..e49db760a7
--- /dev/null
+++ b/articles/quickstart/webapp/django/interactive.md
@@ -0,0 +1,98 @@
+---
+title: Add Login to your Django Application
+description: This guide demonstrates how to integrate Auth0 with a Python Django application using the Authlib SDK.
+interactive:  true
+files:
+ - files/webappexample/templates/index
+ - files/webappexample/settings
+ - files/webappexample/urls
+ - files/webappexample/views
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# 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 application using the Authlib SDK.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to 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:
        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:
        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.
        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:
        django-admin startproject webappexample
        Change to the new project folder:
        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.
        
+
+## Setup your route handlers {{{ data-action="code" data-code="webappexample/views.py#20:52" }}}
+
+
+
        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:
        python3 manage.py migrate
+
+python3 manage.py runserver 3000
+
+
        
+
+
        Your application should now be ready to open from your browser at http://localhost:3000.
        Django - Step 10 - Run your application - Checkpoint 
        Visit 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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/express/01-login.md b/articles/quickstart/webapp/express/01-login.md
new file mode 100644
index 0000000000..eeadd156ab
--- /dev/null
+++ b/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 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` 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
+- `clientID` - The Client ID found in your Application 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.
+
+:::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`.
+
+## 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`.
+
+:::note
+For a deep dive into implementing user authentication in Express, visit the Complete Guide to Node.js User Authentication with Auth0. 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 in more advanced use cases:
+
+* Route Customization
+* Obtaining access tokens for external APIs
+* Require auth for specific routes
diff --git a/articles/quickstart/webapp/express/download.md b/articles/quickstart/webapp/express/download.md
new file mode 100644
index 0000000000..e9d2d24e91
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure Node.JS LTS 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 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/articles/quickstart/webapp/express/files/server.md b/articles/quickstart/webapp/express/files/server.md
new file mode 100644
index 0000000000..ed5b9ef117
--- /dev/null
+++ b/articles/quickstart/webapp/express/files/server.md
@@ -0,0 +1,39 @@
+---
+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/articles/quickstart/webapp/express/index.yml b/articles/quickstart/webapp/express/index.yml
new file mode 100644
index 0000000000..9c819b80d0
--- /dev/null
+++ b/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/articles/quickstart/webapp/express/interactive.md b/articles/quickstart/webapp/express/interactive.md
new file mode 100644
index 0000000000..5af2d2416d
--- /dev/null
+++ b/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,48 @@
+---
+title: Add Login to your Express Application
+description: 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
+locale: en-US
+---
+
+# 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
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000/.
        
+
+## Install the Express OpenID Connect SDK {{{ data-action="code" data-code="server.js#2:16" }}}
+
+
+
        Your application will need the 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:
        cd <your-project-directory>
+
+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.
        • clientID - The Client ID found in your Application settings.
        For additional configuration options visit the API documentation.
        You can generate a suitable string for LONG_RANDOM_STRING using openssl rand -hex 32 on the command line.
        Express - Step 2 - Install the Express OpenID Connect SDK - Checkpoint 
        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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
+
+## Display User Profile {{{ data-action="code" data-code="server.js#25:28" }}}
+
+
+
        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.
        Express - Step 3 - Display User Profile - Checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. You should check that you configured the logout URL correctly.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/golang/01-login.md b/articles/quickstart/webapp/golang/01-login.md
index 39f6214ef9..7be35ad94b 100644
--- a/articles/quickstart/webapp/golang/01-login.md
+++ b/articles/quickstart/webapp/golang/01-login.md
@@ -1,352 +1,500 @@
 ---
 title: Login
-description: This tutorial will demonstrates how to use the OAuth2 Go package to add authentication and authorization to your web app.
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-golang-web-app',
-  path: '01-Login',
-	requirements: [
-		'Go 1.5.3 and up'
-	]
-}) %>
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
 
-<%= include('../_includes/_getting_started', { library: 'Go', callback: 'http://localhost:3000' }) %>
+## Configure Go to Use Auth0
 
-## Add Dependencies
+### Download dependencies
 
-Install the following dependencies using `go get`.
+Start by adding a `go.mod` file to list all the dependencies to be used.
 
-${snippet(meta.snippets.dependencies)}
+```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 `mux` for routing but you can use whichever router you want.
+This example uses `gin` for routing, but you can use whichever router you want.
 :::
 
-## Add the Auth0 Callback Handler
 
-You'll need to create a callback handler that Auth0 will call once it redirects to your app. For that, you can do the following:
+### 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 and 
+oidc clients, and another one to verify an ID Token.
 
 ```go
-// routes/callback/callback.go
+// platform/authenticator/auth.go
 
-package callback
+package authenticator
 
 import (
 	"context"
-	_ "crypto/sha512"
-	"encoding/json"
-	"../../app"
-	"golang.org/x/oauth2"
-	"net/http"
+	"errors"
 	"os"
-)
 
-func CallbackHandler(w http.ResponseWriter, r *http.Request) {
+	"github.com/coreos/go-oidc/v3/oidc"
+	"golang.org/x/oauth2"
+)
 
-	domain := os.Getenv("${account.namespace}")
+// Authenticator is used to authenticate our users.
+type Authenticator struct {
+	*oidc.Provider
+	oauth2.Config
+}
 
-	conf := &oauth2.Config{
-		ClientID:     os.Getenv("${account.clientId}"),
-		ClientSecret: os.Getenv("YOUR_CLIENT_SECRET"),
-		RedirectURL:  os.Getenv("http://localhost:3000/callback"),
-		Scopes:       []string{"openid", "profile"},
-		Endpoint: oauth2.Endpoint{
-			AuthURL:  "https://" + domain + "/authorize",
-			TokenURL: "https://" + domain + "/oauth/token",
-		},
-	}
-	state := r.URL.Query().Get("state")
-	session, err := app.Store.Get(r, "state")
+// New instantiates the *Authenticator.
+func New() (*Authenticator, error) {
+	provider, err := oidc.NewProvider(
+		context.Background(),
+		"https://"+os.Getenv("AUTH0_DOMAIN")+"/",
+	)
 	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
+		return nil, err
 	}
 
-	if state != session.Values["state"] {
-		http.Error(w, "Invalid state parameter", http.StatusInternalServerError)
-		return
+	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"},
 	}
 
-	code := r.URL.Query().Get("code")
+	return &Authenticator{
+		Provider: provider,
+		Config:   conf,
+	}, nil
+}
 
-	token, err := conf.Exchange(context.TODO(), code)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
+// 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")
 	}
 
-	// Getting now the userInfo
-	client := conf.Client(context.TODO(), token)
-	resp, err := client.Get("https://" + domain + "/userinfo")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
+	oidcConfig := &oidc.Config{
+		ClientID: a.ClientID,
 	}
 
-	defer resp.Body.Close()
+	return a.Verifier(oidcConfig).Verify(ctx, rawIDToken)
+}
+```
 
-	var profile map[string]interface{}
-	if err = json.NewDecoder(resp.Body).Decode(&profile); err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
+### Setting up your application routes
 
-	session, err = app.Store.Get(r, "auth-session")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
+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. You will be passing an
+instance of `Authenticator` to the method, so it can be used within the `login` and `callback` handlers.
 
-	session.Values["id_token"] = token.Extra("id_token")
-	session.Values["access_token"] = token.AccessToken
-	session.Values["profile"] = profile
-	err = session.Save(r, w)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
+```go
+// platform/router/router.go
 
-	// Redirect to logged in page
-	http.Redirect(w, r, "/user", http.StatusSeeOther)
+package router
 
-}
-```
+import (
+	"encoding/gob"
+	"net/http"
 
-Remember to set this handler to the `/callback` path:
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-contrib/sessions/cookie"
+	"github.com/gin-gonic/gin"
 
-${snippet(meta.snippets.setup)}
+	"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)
 
-## Triggering the Login
+	return router
+}
+```
+
+::: note
+The router uses the github.com/gin-contrib/sessions middleware to manage 
+our cookie based sessions.
+:::
 
-Create a file called `login.go` in the `routes/login` folder, and add `LoginHandler` function to handle `/login` route.
+### Serving your application
 
-This function sets the configuration for [OAuth2 Go](https://godoc.org/golang.org/x/oauth2) to get the authorization url, and redirects the user to the [login page](/hosted-pages/login).
+Next, let's create our application's entry point `main.go` and wire everything up together:
 
 ```go
-// routes/login/login.go
+// main.go
 
-package login
+package main
 
 import (
-	"golang.org/x/oauth2"
+	"log"
 	"net/http"
-	"os"
-	"crypto/rand"
-	"encoding/base64"
-	"../../app"
-)
 
-func LoginHandler(w http.ResponseWriter, r *http.Request) {
+	"github.com/joho/godotenv"
 
-	domain := os.Getenv("${account.namespace}")
-	aud := os.Getenv("YOUR_API_AUDIENCE")
-
-	conf := &oauth2.Config{
-		ClientID:     os.Getenv("${account.clientId}"),
-		ClientSecret: os.Getenv("YOUR_CLIENT_SECRET"),
-		RedirectURL:  os.Getenv("http://localhost:3000/callback"),
-		Scopes:       []string{"openid", "profile"},
-		Endpoint: oauth2.Endpoint{
-			AuthURL:  "https://" + domain + "/authorize",
-			TokenURL: "https://" + domain + "/oauth/token",
-		},
-	}
+	"01-Login/platform/authenticator"
+	"01-Login/platform/router"
+)
 
-	if aud == "" {
-		aud = "https://" + domain + "/userinfo"
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Failed to load the env vars: %v", err)
 	}
 
-	// Generate random state
-	b := make([]byte, 32)
-	rand.Read(b)
-	state := base64.StdEncoding.EncodeToString(b)
-
-	session, err := app.Store.Get(r, "state")
+	auth, err := authenticator.New()
 	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-	session.Values["state"] = state
-	err = session.Save(r, w)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
+		log.Fatalf("Failed to initialize the authenticator: %v", err)
 	}
 
-	audience := oauth2.SetAuthURLParam("audience", aud)
-	url := conf.AuthCodeURL(state, audience)
+	rtr := router.New(auth)
 
-	http.Redirect(w, r, url, http.StatusTemporaryRedirect)
+	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)
+	}
 }
 ```
 
-In `server.go` file create the router, and add the function created above to handle `/login` route.
+## 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
-// server.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
+	}
 
-r := mux.NewRouter()
-r.HandleFunc("/login", login.LoginHandler)
+	state := base64.StdEncoding.EncodeToString(b)
+
+	return state, nil
+}
 ```
 
-Add a link to `/login` route in the `index.html` template.
+Add a link to `/login` route in the `home.html` template.
 
 ```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 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. 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/articles/quickstart/webapp/java-ee/_includes/_setup.md b/articles/quickstart/webapp/java-ee/_includes/_setup.md
new file mode 100644
index 0000000000..63bd3d8909
--- /dev/null
+++ b/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 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 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 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/articles/quickstart/webapp/java-ee/download.md b/articles/quickstart/webapp/java-ee/download.md
new file mode 100644
index 0000000000..cb0e843940
--- /dev/null
+++ b/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 to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure Java 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 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/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
new file mode 100644
index 0000000000..29a24545b4
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
@@ -0,0 +1,52 @@
+---
+name: src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java
+language: javascript
+---
+    
+```javascript
+// 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;
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
new file mode 100644
index 0000000000..ed6667e7e3
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
@@ -0,0 +1,23 @@
+---
+name: src/main/java/com/auth0/example/web/HomeServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
new file mode 100644
index 0000000000..c818e9a8b0
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
@@ -0,0 +1,38 @@
+---
+name: src/main/java/com/auth0/example/web/LoginServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
new file mode 100644
index 0000000000..929dd24742
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
@@ -0,0 +1,54 @@
+---
+name: src/main/java/com/auth0/example/web/LogoutServlet.java
+language: 
+---
+    
+```
+// 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://${account.namespace}/v2/logout?client_id=${account.clientId}&returnTo=http://localhost:3000/
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                config.getDomain(),
+                config.getClientId(),
+                returnUrl
+        );
+
+        return logoutUrl;
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md b/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
new file mode 100644
index 0000000000..58f32a0fdc
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
@@ -0,0 +1,30 @@
+---
+name: src/main/webapp/WEB-INF/web.xml
+language: powershell
+---
+    
+```powershell
+
+
+
+    auth0.domain
+    java.lang.String
+    ${account.namespace}
+
+
+    auth0.clientId
+    java.lang.String
+    ${account.clientId}
+
+
+    auth0.clientSecret
+    java.lang.String
+    ${account.clientSecret}
+
+
+    auth0.scope
+    java.lang.String
+    openid profile email
+
+
+```
diff --git a/articles/quickstart/webapp/java-ee/index.yml b/articles/quickstart/webapp/java-ee/index.yml
new file mode 100644
index 0000000000..01f40a2809
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/index.yml
@@ -0,0 +1,52 @@
+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
+hidden_articles:
+  - interactive
+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/articles/quickstart/webapp/java-ee/interactive.md b/articles/quickstart/webapp/java-ee/interactive.md
new file mode 100644
index 0000000000..edd4e1a132
--- /dev/null
+++ b/articles/quickstart/webapp/java-ee/interactive.md
@@ -0,0 +1,410 @@
+---
+title: Add Login to Your Java EE web application
+description: This tutorial demonstrates how to add user login to a Java EE web application.
+interactive:  true
+files:
+ - files/src/main/webapp/WEB-INF/web
+ - files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig
+ - files/src/main/java/com/auth0/example/web/LoginServlet
+ - files/src/main/java/com/auth0/example/web/HomeServlet
+ - files/src/main/java/com/auth0/example/web/LogoutServlet
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# Add Login to Your Java EE web application
+
+
+
        This tutorial demonstrates how to add user login to a Java EE web application. We recommend that you log in to follow this quickstart with examples configured for your account.
        System Requirements
        This tutorial and sample project have been tested with the following:
        • Java 11
        
+
+## 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 section in the Auth0 dashboard.
        You need the following information:
        • Domain
        • Client ID
        • Client Secret
        If you download the sample from the top of this page, these details are filled out for you.
        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. If this field is not set, users will be unable to log in to the application and will get an error.
        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 http://localhost:3000/callback.
        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. If this field is not set, users will be unable to log out from the application and will get an error.
        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 http://localhost:3000/.
        
+
+## Configure Java EE to use Auth0 {{{ data-action="code" data-code="src/main/webapp/WEB-INF/web.xml" }}}
+
+
+
        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 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:
        <!-- pom.xml -->
+
+<dependency>
+
+ <groupId>com.auth0</groupId>
+
+ <artifactId>mvc-auth-commons</artifactId>
+
+ <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax</groupId>
+
+ <artifactId>javaee-api</artifactId>
+
+ <version>8.0.1</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax.security.enterprise</groupId>
+
+ <artifactId>javax.security.enterprise-api</artifactId>
+
+ <version>1.0</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+
        
+
+
        If you are using Gradle, add them to your build.gradle:
        // 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
        The sample that accompanies this tutorial is written using JSP and tested with the WildFly 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. 
        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 of the library.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **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.
        
+
+## Configure Java EE Security {{{ data-action="code" data-code="src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java" }}}
+
+
+
        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 handling the authentication workflow for users returning from Auth0. (JavaDoc).
        • IdentityStore: Responsible for validating the user's credentials (JavaDoc).
        • CallerPrincipal: Represents the caller principal of the current HTTP request (JavaDoc).
        • Credential: Represents the credential the caller will use to authenticate (JavaDoc).
        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.
        Next, create a custom CallerPrincipal that represents the caller of the current request:
        // 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:
        // 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:
        // 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 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.
        To learn more about the available signing algorithms, refer to the documentation.
        The sample below shows how to configure the AuthenticationController for use with the RS256 signing algorithm:
        // 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
        // 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 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 {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LoginServlet.java" }}}
+
+
+
        To enable a user to log in, create a Servlet that will handle requests to the /login path.
        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 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:
        // 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 {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/HomeServlet.java" }}}
+
+
+
        You can use the Auth0JwtPrincipal to get profile information for the authenticated user. The HomeServlet.java code sample demonstrates how to use the claims on the ID token to set profile data as a request attribute.
        You can then use that profile information in your view to display information about the user:
        <!-- src/main/webapp/WEB-INF/jsp/fragments/navbar.jspf -->
+
+
+
+<c:choose>
+
+ <c:when test="{empty profile}">
+
+<li>
+
+ <form action="/login" method="GET">
+
+<input type="submit" value="Login"/>
+
+ </form>
+
+</li>
+
+ </c:when>
+
+ <c:otherwise>
+
+<li>
+
+ <a href="#">
+
+<!-- Profile image should be set to the profile picture from the id token -->
+
+<img src="{profile.get('picture').asString()}" alt="Profile picture"/>
+
+ </a>
+
+ <div>
+
+<!-- Show the user's full name from the id token here -->
+
+<div>"{profile.get('name').asString()}"</div>
+
+<a href="/profile">Profile</a>
+
+<a href="/logout">Log out</a>
+
+ </div>
+
+</li>
+
+ </c:otherwise>
+
+</c:choose>
+
+
        
+
+
        
+
+## Handle logout {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LogoutServlet.java" }}}
+
+
+
        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.
        
+
+## 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 documentation for more information.
        If you are using Linux or MacOS:
        ./mvnw clean wildfly:run
+
+
        
+
+
        Windows:
        mvnw.cmd clean wildfly:run
+
+
        
+
+
        Point your browser to http://localhost:3000.  Follow the Log In link to log in or sign up to your Auth0 tenant.
        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/articles/quickstart/webapp/java-spring-boot/01-login.md b/articles/quickstart/webapp/java-spring-boot/01-login.md
new file mode 100644
index 0000000000..2ac3387890
--- /dev/null
+++ b/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. If you are using Spring WebFlux, the steps to add authentication are similar, but some of the implementation details are different. Refer to the Spring Boot WebFlux Sample Code 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 in your application's dependencies.
+
+:::note
+This guide uses Thymeleaf and the Spring Security integration module 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.
+
+
+```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, 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 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 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. 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 document.
+:::
+
+## Add Logout to Your Application
+
+Now that users can log into your application, they need a way to log out. 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://${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 associated with logged-in users through the OidcUser class, which can be used with the AuthenticationPrincipal annotation.
+
+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 after you have logged in.
+:::
diff --git a/articles/quickstart/webapp/java-spring-boot/download.md b/articles/quickstart/webapp/java-spring-boot/download.md
new file mode 100644
index 0000000000..41d63b0ede
--- /dev/null
+++ b/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 to:
+```text
+http://localhost:3000/login/oauth2/code/auth0
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure Java 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 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/articles/quickstart/webapp/java-spring-boot/files/HomeController.md b/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
new file mode 100644
index 0000000000..4ca305ce5e
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
@@ -0,0 +1,29 @@
+---
+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";
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md b/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
new file mode 100644
index 0000000000..a08d869b03
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
@@ -0,0 +1,31 @@
+---
+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();
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md b/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md
new file mode 100644
index 0000000000..d36c761126
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.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);
+            }
+        };
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java-spring-boot/files/application.md b/articles/quickstart/webapp/java-spring-boot/files/application.md
new file mode 100644
index 0000000000..035001998b
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/files/application.md
@@ -0,0 +1,12 @@
+---
+name: application.yml
+language: javascript
+---
+    
+```javascript
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: ${account.clientSecret}
+```
diff --git a/articles/quickstart/webapp/java-spring-boot/files/home-controller.md b/articles/quickstart/webapp/java-spring-boot/files/home-controller.md
new file mode 100644
index 0000000000..ad510c0ccf
--- /dev/null
+++ b/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/articles/quickstart/webapp/java-spring-boot/files/index.md b/articles/quickstart/webapp/java-spring-boot/files/index.md
new file mode 100644
index 0000000000..9c8255bdc8
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/files/index.md
@@ -0,0 +1,24 @@
+---
+name: index.html
+language: html
+---
+    
+```html
+
+
+    
+        
        
+            Log In
+        
        
+        
        
+            
        You are logged in!
        
+            " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+            
        ">
        
+            
        ">
        
+            
        
+                
        
+    
+
+```
diff --git a/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md b/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md
new file mode 100644
index 0000000000..2b60bcd070
--- /dev/null
+++ b/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/articles/quickstart/webapp/java-spring-boot/files/security-config.md b/articles/quickstart/webapp/java-spring-boot/files/security-config.md
new file mode 100644
index 0000000000..6c68d3b916
--- /dev/null
+++ b/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/articles/quickstart/webapp/java-spring-boot/index.yml b/articles/quickstart/webapp/java-spring-boot/index.yml
new file mode 100644
index 0000000000..7674acadc2
--- /dev/null
+++ b/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/articles/quickstart/webapp/java-spring-boot/interactive.md b/articles/quickstart/webapp/java-spring-boot/interactive.md
new file mode 100644
index 0000000000..7f78b1680b
--- /dev/null
+++ b/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,198 @@
+---
+title: Add Login to your Spring Web Application
+description: This guide demonstrates how to integrate Auth0 with a Spring Boot application using the Auth0 Spring Boot SDK.
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/index
+ - files/HomeController
+ - files/SecurityConfigWithLogout
+github:
+  path: mvc-login
+locale: en-US
+---
+
+# Add Login to your Spring Web Application
+
+
+
        Using Spring WebFlux? 
        This tutorial uses Spring MVC. If you are using Spring WebFlux, the steps to add authentication are similar, but some implementation details are different. Refer to the Spring Boot WebFlux Sample Code to see how to integrate Auth0 with your Spring Boot WebFlux application.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to
        http://localhost:3000/login/oauth2/code/okta.
        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.
        If you are following along with our sample project, set this to 
        http://localhost:3000.
        
+
+## Configure Sprint Boot application
+
+
+
        Add Spring dependencies
        To integrate your Spring Boot application with Auth0, include the Okta Spring Boot Starter in your application's dependencies.
        This guide uses Thymeleaf and the Spring Security integration module 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.
        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:
        <parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.4</version>
+
+ <relativePath/>
+
+</parent>
+
+
+
+<dependencies>
+
+ <dependency>
+
+<groupId>com.okta</groupId>
+
+<artifactId>okta-spring-boot-starter</artifactId>
+
+<version>3.0.5</version>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-oauth2-client</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-thymeleaf</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.thymeleaf.extras</groupId>
+
+<artifactId>thymeleaf-extras-springsecurity6</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>nz.net.ultraq.thymeleaf</groupId>
+
+<artifactId>thymeleaf-layout-dialect</artifactId>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## Configure Spring Security {{{ data-action="code" data-code="application.yml" }}}
+
+
+
        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.
        #src/main/resources/application.yml
+
+
+
+okta:
+
+  oauth2:
+
+    issuer: https://${account.namespace}/
+
+    client-id: ${account.clientId}
+
+    client-secret: ${account.clientSecret}
+
+
+
+#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, and add the @Configuration annotation.
        You can configure the HttpSecurity instance to require authentication on all or certain paths. For example, to require authentication on all paths except the home page:
        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.
        spring boot step 6 checkpoint 
        When you click the login link, verify the 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.
        
+
+  
        
+
+  
        
+
+  
        Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with social identity providers. 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 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. 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://{yourDomain}/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
        spring boot step 7 checkpoint 
        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.
        
+
+  
        
+
+  
        
+
+  
        
diff --git a/articles/quickstart/webapp/java-spring-mvc/01-login.md b/articles/quickstart/webapp/java-spring-mvc/01-login.md
deleted file mode 100644
index 7d79a23f30..0000000000
--- a/articles/quickstart/webapp/java-spring-mvc/01-login.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication to your Java Spring web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above',
-    'Spring Boot 1.5.3 or above'
-  ]
-}) %>
-
-This integration guide will walk you through setting up and managing authentication and authorization in your Java Spring MVC apps using Auth0.
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/java-spring-mvc/_includes/_login.md b/articles/quickstart/webapp/java-spring-mvc/_includes/_login.md
deleted file mode 100644
index ed55ce88bd..0000000000
--- a/articles/quickstart/webapp/java-spring-mvc/_includes/_login.md
+++ /dev/null
@@ -1,159 +0,0 @@
-## Project Structure
-The Login project sample has the following structure:
-
-```text
-- src
--- main
----- java
------- com
--------- auth0
----------- example
------------- App.java
------------- AppConfig.java
------------- Auth0Filter.java
------------- AuthController.java
------------- CallbackController.java
------------- ErrorController.java
------------- HomeController.java
------------- LoginController.java
------------- LogoutController.java
----- resources
------- application.properties
------- auth0.properties
----- webapp
------- WEB-INF
--------- jsp
----------- home.jsp
-- build.gradle
-```
-
-The project contains a single JSP: the `home.jsp` which will display the tokens associated to the user after a successful login and provide the option to logout.
-
-The project contains a Filter: 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 `LoginController`. This Filter is set on the `AppConfig.java` class.
-
-The project contains also five Controllers:
-- `LoginController.java`: Invoked when the user attempts to login. The controller uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
-- `CallbackController.java`: The controller 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.
-- `HomeController.java`: The controller reads the previously saved tokens and shows them on the `home.jsp` resource.
-- `LogoutController.java`: Invoked when the user clicks the logout link. The controller invalidates the user session and redirects the user to the login page, handled by the `LoginController`.
-- `ErrorController.java`: The controller triggers upon any non-handled exception and redirects the user to the `/login` path.
-
-Lastly, the project defines a helper class: the `AuthController.java` which will be in charge of creating new instances of `AuthenticationController`. By defining it as a Spring Component, the framework will handle it's creation.
-
-
-## Authenticate the User
-
-Let's begin by making your Auth0 credentials available on the App. In the `AppConfig` class we tell Spring to map the properties defined in the `auth0.properties` file to the corresponding fields by using the `@Configuration` and `@Value` annotations. We also define the class as a `@Component` so we can later autowire it to make it available on other classes:
-
-```java
-@Component
-@Configuration
-public class AppConfig {
-    @Value(value = "<%= "${com.auth0.domain}" %>")
-    private String domain;
-
-    @Value(value = "<%= "${com.auth0.clientId}" %>")
-    private String clientId;
-
-    @Value(value = "<%= "${com.auth0.clientSecret}" %>")
-    private String clientSecret;
-}
-```
-
-Now create the `AuthenticationController` instance that will create the Authorize URLs and handle the request received in the callback. Any customization on the behavior of the component should be done here, such as requesting a different scope or using a different signature verification algorithm.
-
-```java
-// src/main/java/com/auth0/example/AppConfig.java
-
-@Component
-public class AuthController {
-    private final AuthenticationController controller;
-    private final String userInfoAudience;
-
-    @Autowired
-    public AuthController(AppConfig config) {
-        controller = AuthenticationController.newBuilder(config.getDomain(), config.getClientId(), config.getClientSecret())
-                .build();
-        userInfoAudience = String.format("https://%s/userinfo", config.getDomain());
-    }
-
-    public Tokens handle(HttpServletRequest request) throws IdentityVerificationException {
-        return controller.handle(request);
-    }
-
-    public String buildAuthorizeUrl(HttpServletRequest request, String redirectUri) {
-        return controller.buildAuthorizeUrl(request, redirectUri)
-                .withAudience(userInfoAudience)
-                .build();
-    }
-}
-```
-
-
-To authenticate the users we will redirect them to the **Auth0 Login Page** which uses the best version available of [Lock](/lock). This page is what we call the "Authorize URL". By using this library we can generate it with a simple method call. It will require a `HttpServletRequest` to store the call context in the session and the URI to redirect the authentication result to. This URI is normally the address where our app is running plus the path where the result will be parsed, which happens to be also the "Callback URL" whitelisted before. Finally, we will request the "User Info" *audience* in order to obtain an Open ID Connect compliant response. After we create the Authorize URL, we redirect the request there so the user can enter their credentials. The following code snippet is located on the `LoginController` class of our sample.
-
-```java
-@RequestMapping(value = "/login", method = RequestMethod.GET)
-protected String login(final HttpServletRequest req) {
-    String redirectUri = req.getScheme() + "://" + req.getServerName() + ":" + req.getServerPort() + "/callback";
-    String authorizeUrl = controller.buildAuthorizeUrl(req, redirectUri);
-    return "redirect:" + authorizeUrl;
-}
-```
-
-After the user logs in the result will be received in our `CallbackController`, either via a GET or a POST Http method. The request holds the call context that we've previously set by generating the Authorize URL with the controller. When we pass it to the controller, we get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, we need to save the credentials somewhere we can access them later. We will use again the `HttpSession` of the request. A helper class called `SessionUtils` is included in the library to set and read values from a request's session.
-
-```java
-@RequestMapping(value = "/callback", method = RequestMethod.GET)
-protected void getCallback(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
-  try {
-      Tokens tokens = controller.handle(req);
-      SessionUtils.set(req, "accessToken", tokens.getAccessToken());
-      SessionUtils.set(req, "idToken", tokens.getIdToken());
-      res.sendRedirect("/portal/home");
-  } catch (IdentityVerificationException e) {
-      res.sendRedirect("/login");
-  }
-}
-```
-
-::: note
-It it's 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 `HomeController` 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
-@RequestMapping(value = "/portal/home", method = RequestMethod.GET)
-protected String home(final Map model, final HttpServletRequest req) {
-    String accessToken = (String) SessionUtils.get(req, "accessToken");
-    String idToken = (String) SessionUtils.get(req, "idToken");
-    if (accessToken != null) {
-        model.put("userId", accessToken);
-    } else if (idToken != null) {
-        model.put("userId", idToken);
-    }
-    return "home";
-}
-```
-
-## 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 bootRun
-```
-
-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}/#/).
-
-![Login using Lock](/media/articles/java/login-with-lock.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/articles/quickstart/webapp/java-spring-mvc/_includes/_setup.md b/articles/quickstart/webapp/java-spring-mvc/_includes/_setup.md
deleted file mode 100644
index 78ff959723..0000000000
--- a/articles/quickstart/webapp/java-spring-mvc/_includes/_setup.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Configure Callback URLs
-
-A Callback URL is a URL that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and attaches some details to it including a token. Callback URLs can be manipulated on the fly which could be harmful. For security reasons, you will need to add your application's callback URL in the **Allowed Callback URLs** box in your app's [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). This will allow Auth0 to recognize the URLs as valid. The same principle applies to **Logout URLs**. They must be whitelisted in the Auth0 Dashboard.
-
-If you are following this guide directly, set the following for your Callback and Logout URLs:
-
-- Allowed Callback URLs: `http://localhost:3000/callback`
-- Allowed Logout URLs: `http://localhost:3000/logout`
-
-
-## Setup Dependencies
-
-You'll need to configure **Spring Boot** in your project first. You can generate the base project in [this](https://start.spring.io/) link, choosing `Web` in the dependencies and clicking the button "Generate Project". The downloaded project has the Spring Boot dependencies and plugin applied. 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.
-The next step is to add the **auth0-java-mvc-commons** library. This one 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. You can always check the latest version in the [library's GitHub](https://github.com/auth0/auth0-java-mvc-common).
-
-If you are using Gradle, add it to your `build.gradle`:
-
-```java
-compile 'com.auth0:mvc-auth-commons:1.+'
-```
-
-If you are using Maven, add it to your `pom.xml`:
-
-```xml
-
-  com.auth0
-  mvc-auth-commons
-  1.+
-
-```
-
-## Configure your Java Spring App
-
-Your Java Spring App needs some information in order to authenticate against your Auth0 account. The samples read this information from the properties file `src/main/resources/auth0.properties`, 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
-```
-
-The library we're using has this default behavior:
-- Request the scope `openid`, needed to call the `/userinfo` endpoint later to verify the User's identity.
-- Request the `code` Response Type and later perform a Code Exchange to obtain the tokens.
-- Use the `HS256` Algorithm along with the Client Secret to verify the tokens.
-
-But it also allows us to customize it's behavior:
-* To use the `RS256` Algorithm along with the Public Key obtained dynamically from the Auth0 hosted JWKs file, pass a `JwkProvider` instance to the `AuthenticationController` builder.
-* To use a different Response Type, set the desired value in the `AuthenticationController` builder. Any combination of `code token id_token` is allowed.
-* To request a different `scope`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
-* To specify the `audience`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
-
-
-::: panel Check populated attributes
-If you download the seed using our **Download Sample** button then the `domain`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered application. In any case, you should verify that the values are correct if you have multiple applications in your account and you might want to use another than the one we set the information for.
-:::
diff --git a/articles/quickstart/webapp/java-spring-mvc/dashboard-default.md b/articles/quickstart/webapp/java-spring-mvc/dashboard-default.md
deleted file mode 100644
index bfc4aef6a3..0000000000
--- a/articles/quickstart/webapp/java-spring-mvc/dashboard-default.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your Java Spring web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above',
-    'Spring Boot 1.5.3 or above'
-  ]
-}) %>
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/java-spring-mvc/index.yml b/articles/quickstart/webapp/java-spring-mvc/index.yml
deleted file mode 100644
index 6923b0ddcb..0000000000
--- a/articles/quickstart/webapp/java-spring-mvc/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: Java Spring MVC
-image: /media/platforms/spring.png
-logo_name: java
-author:
-  name: Luciano Balmaceda
-  email: luciano.balmaceda@auth0.com
-  community: false
-tags:
-  - quickstart
-alias:
-  - spring
-  - spring-security
-seo_alias: java spring
-default_article: dashboard-default
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/java-spring-security-mvc/01-login.md b/articles/quickstart/webapp/java-spring-security-mvc/01-login.md
deleted file mode 100644
index 477609e519..0000000000
--- a/articles/quickstart/webapp/java-spring-security-mvc/01-login.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication to your Java Spring Security web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above',
-    'Spring Boot 1.5.3 or above'
-  ]
-}) %>
-
-This integration guide will walk you through setting up and managing authentication and authorization in your Java Spring Security MVC apps using Auth0.
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/java-spring-security-mvc/_includes/_login.md b/articles/quickstart/webapp/java-spring-security-mvc/_includes/_login.md
deleted file mode 100644
index 3f5c7efb10..0000000000
--- a/articles/quickstart/webapp/java-spring-security-mvc/_includes/_login.md
+++ /dev/null
@@ -1,153 +0,0 @@
-## Project Structure
-The Login project sample has the following structure:
-
-```text
-- src
--- main
----- java
------- com
--------- auth0
----------- example
------------- mvc
--------------- CallbackController.java
--------------- ErrorController.java
--------------- HomeController.java
--------------- LoginController.java
--------------- LogoutController.java
------------- security
--------------- AppConfig.java
--------------- TokenAuthentication.java
------------- App.java
----- resources
------- application.properties
------- auth0.properties
----- webapp
------- WEB-INF
--------- jsp
----------- home.jsp
-- build.gradle
-```
-
-The project contains a single JSP: the `home.jsp` which will display the user information associated to the token after a successful login and provide the option to logout.
-
-The access control is handled by the Spring Security framework. A few rules in the `AppConfig.java` class will suffice to 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 by the `ErrorController` to the `LoginController`.
-
-The project contains also five Controllers:
-- `LoginController.java`: Invoked when the user attempts to login. The controller uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
-- `CallbackController.java`: The controller 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.
-- `HomeController.java`: The controller reads the previously saved tokens and shows them on the `home.jsp` resource.
-- `LogoutController.java`: Invoked when the user clicks the logout link. The controller invalidates the user session and redirects the user to the login page, handled by the `LoginController`.
-- `ErrorController.java`: The controller triggers upon any non-handled exception and redirects the user to the `/login` path.
-
-
-## Authenticate the User
-
-Let's begin by making your Auth0 credentials available on the App. In the `AppConfig` class we tell Spring to map the properties defined in the `auth0.properties` file to the corresponding fields by using the `@Configuration` and `@Value` annotations.
-
-```java
-
-@Configuration
-@EnableWebSecurity
-@EnableGlobalMethodSecurity(prePostEnabled = true)
-public class AppConfig extends WebSecurityConfigurerAdapter {
-
-    @Value(value = "<%= "${com.auth0.domain}" %>")
-    private String domain;
-    @Value(value = "<%= "${com.auth0.clientId}" %>")
-    private String clientId;
-    @Value(value = "<%= "${com.auth0.clientSecret}" %>")
-    private String clientSecret;
-
-    //...
-}
-```
-
-Next, define the rules that will prevent unauthenticated users to access our protected resources. You do that by allowing anyone to access the `/login` and `/callback` endpoints in order to be able to complete the login flow, and blocking them from accessing any other endpoint if they are not authenticated:
-
-```java
-@Override
-protected void configure(HttpSecurity http) throws Exception {
-    http.csrf().disable();
-    http
-            .authorizeRequests()
-            .antMatchers("/callback", "/login").permitAll()
-            .antMatchers("/**").authenticated()
-            .and()
-            .logout().permitAll();
-    http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.NEVER);
-}
-```
-
-Now create the `AuthenticationController` instance that will create the Authorize URLs and handle the request received in the callback. Do that by defining a method that returns the Bean in the same `AppConfig` class. Any customization on the behavior of the component should be done here, such as requesting a different response type or using a different signature verification algorithm.
-
-```java
-@Bean
-public AuthenticationController authenticationController() throws UnsupportedEncodingException {
-    return AuthenticationController.newBuilder(domain, clientId, clientSecret)
-            .build();
-}
-```
-
-To authenticate the users you will redirect them to the login page which uses [Lock](/libraries/lock/v10). This page is accessible from what we call the "Authorize URL". By using this library you can generate it with a simple method call. It will require a `HttpServletRequest` to store the call context in the session and the URI to redirect the authentication result to. This URI is normally the address where your app is running plus the path where the result will be parsed, which happens to be also the "Callback URL" whitelisted before. Finally, request the "User Info" *audience* in order to obtain an Open ID Connect compliant response. After you create the Authorize URL, you redirect the request there so the user can enter their credentials. The following code snippet is located on the `LoginController` class of our sample.
-
-```java
-@RequestMapping(value = "/login", method = RequestMethod.GET)
-protected String login(final HttpServletRequest req) {
-    String redirectUri = req.getScheme() + "://" + req.getServerName() + ":" + req.getServerPort() + "/callback";
-    String authorizeUrl = controller.buildAuthorizeUrl(req, redirectUri)
-        .withAudience(String.format("https://%s/userinfo", appConfig.getDomain()))
-        .build();
-    return "redirect:" + authorizeUrl;
-}
-```
-
-After the user logs in the result will be received in our `CallbackController`, either via a GET or a POST Http method. The request holds the call context that the library have previously set by generating the Authorize URL with the controller. When you pass it 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 create a new `TokenAuthentication` instance with the *id_token* and set it to the `SecurityContextHolder`. You can modify this class to accept *access_token* as well, but this is not covered in this tutorial. If an exception is raised instead, you need to clear any existing Authentication from the `SecurityContextHolder`.
-
-```java
-@RequestMapping(value = "/callback", method = RequestMethod.GET)
-protected void getCallback(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
-  try {
-      Tokens tokens = controller.handle(req);
-      TokenAuthentication tokenAuth = new TokenAuthentication(JWT.decode(tokens.getIdToken()));
-      SecurityContextHolder.getContext().setAuthentication(tokenAuth);
-      res.sendRedirect(redirectOnSuccess);
-  } catch (AuthenticationException | IdentityVerificationException e) {
-      e.printStackTrace();
-      SecurityContextHolder.clearContext();
-      res.sendRedirect(redirectOnFail);
-  }
-}
-```
-
-## Display the Home Page
-
-Now that the user is authenticated (the tokens exists), the framework will allow them to access our protected resources. In the `HomeController` you can get the existing Authentication object and even the Principal that represents it. Let's set that as the `userId` attribute so it can be used from the JSP code:
-
-```java
-@RequestMapping(value = "/portal/home", method = RequestMethod.GET)
-protected String home(final Map model, final Principal principal) {
-    if (principal == null) {
-        return "redirect:/logout";
-    }
-    model.put("userId", principal);
-    return "home";
-}
-```
-
-## 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 bootRun
-```
-
-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 framework to the login page. The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
-
-![Login using Lock](/media/articles/java/login-with-lock.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/articles/quickstart/webapp/java-spring-security-mvc/_includes/_setup.md b/articles/quickstart/webapp/java-spring-security-mvc/_includes/_setup.md
deleted file mode 100644
index 14dd610a3e..0000000000
--- a/articles/quickstart/webapp/java-spring-security-mvc/_includes/_setup.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Configure Callback URLs
-
-A Callback URL is a URL that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and attaches some details to it including a token. Callback URLs can be manipulated on the fly which could be harmful. For security reasons, you will need to add your application's callback URL in the **Allowed Callback URLs** box in your app's [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). This will allow Auth0 to recognize the URLs as valid. The same principle applies to **Logout URLs**. They must be whitelisted in the Auth0 Dashboard.
-
-If you are following this guide directly, set the following for your Callback and Logout URLs:
-
-- Allowed Callback URLs: `http://localhost:3000/callback`
-- Allowed Logout URLs: `http://localhost:3000/logout`
-
-
-## Setup Dependencies
-
-You'll need to configure **Spring Boot** in your project first. You can generate the base project in [this](https://start.spring.io/) link, choosing `Web` in the dependencies and clicking the button "Generate Project". The downloaded project has the Spring Boot dependencies and plugin applied. 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.
-The next step is to add the **auth0-java-mvc-commons** library. This one 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. You can always check the latest version in the [library's GitHub](https://github.com/auth0/auth0-java-mvc-common).
-
-If you are using Gradle, add it to your `build.gradle`:
-
-```java
-compile 'com.auth0:mvc-auth-commons:1.+'
-```
-
-If you are using Maven, add it to your `pom.xml`:
-
-```xml
-
-  com.auth0
-  mvc-auth-commons
-  1.+
-
-```
-
-## Configure your Java Spring Security App
-
-Your Java Spring Security App needs some information in order to authenticate against your Auth0 account. The samples read this information from the properties file `src/main/resources/auth0.properties`, 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'
-```
-
-The library we're using has this default behavior:
-- Request the scope `openid`, needed to call the `/userinfo` endpoint later to verify the User's identity.
-- Request the `code` Response Type and later perform a Code Exchange to obtain the tokens.
-- Use the `HS256` Algorithm along with the Client Secret to verify the tokens.
-
-But it also allows us to customize it's behavior:
-* To use the `RS256` Algorithm along with the Public Key obtained dynamically from the Auth0 hosted JWKs file, pass a `JwkProvider` instance to the `AuthenticationController` builder.
-* To use a different Response Type, set the desired value in the `AuthenticationController` builder. Any combination of `code token id_token` is allowed.
-* To request a different `scope`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
-* To specify the `audience`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
-
-
-::: panel Check populated attributes
-If you download the seed using our **Download Sample** button then the `domain`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered application. In any case, you should verify that the values are correct if you have multiple applications in your account and you might want to use another than the one we set the information for.
-:::
diff --git a/articles/quickstart/webapp/java-spring-security-mvc/dashboard-default.md b/articles/quickstart/webapp/java-spring-security-mvc/dashboard-default.md
deleted file mode 100644
index 98329f3011..0000000000
--- a/articles/quickstart/webapp/java-spring-security-mvc/dashboard-default.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your Java Spring Security web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above',
-    'Spring Boot 1.5.3 or above'
-  ]
-}) %>
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/java-spring-security-mvc/index.yml b/articles/quickstart/webapp/java-spring-security-mvc/index.yml
deleted file mode 100644
index 3fbe9d8749..0000000000
--- a/articles/quickstart/webapp/java-spring-security-mvc/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: Java Spring Security
-image: /media/platforms/spring.png
-logo_name: java
-author:
-  name: Luciano Balmaceda
-  email: luciano.balmaceda@auth0.com
-  community: false
-tags:
-  - quickstart
-alias:
-  - spring
-  - spring-security
-seo_alias: java spring
-default_article: dashboard-default
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/java/01-login.md b/articles/quickstart/webapp/java/01-login.md
index ddc90a85c4..e8a096df04 100644
--- a/articles/quickstart/webapp/java/01-login.md
+++ b/articles/quickstart/webapp/java/01-login.md
@@ -1,22 +1,20 @@
 ---
 title: Login
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication to your Java Servlet web app
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servlet-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above'
-  ]
-}) %>
-
-This integration guide will walk you through setting up and managing authentication and authorization in your Java apps using Auth0.
-
-<%= include('../../../_includes/_new_app') %>
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/login' }) %>
 
 <%= include('_includes/_setup') %>
 
diff --git a/articles/quickstart/webapp/java/_includes/_login.md b/articles/quickstart/webapp/java/_includes/_login.md
index db1c3b3051..754b9e4d74 100644
--- a/articles/quickstart/webapp/java/_includes/_login.md
+++ b/articles/quickstart/webapp/java/_includes/_login.md
@@ -1,4 +1,4 @@
-## Project Structure
+### Project Structure
 
 The Login project sample has the following structure:
 
@@ -23,53 +23,96 @@ The Login project sample has the following structure:
 - build.gradle
 ```
 
-The project contains a single JSP: the `home.jsp` which will display the tokens associated to the user after a successful login and provide the option to logout.
+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 login. The servlet uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
+- `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`
 
-Lastly, the project defines a helper class: the `AuthenticationControllerProvider.java` which will be in charge of creating new instances of `AuthenticationController`. Because this controller is very simple and doesn't keep any context it can be safely reused. You can also choose to create a new one every time it's needed.
+## 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 to learn about additional configuration options. If you are using HS256, there is no need to configure the `JwkProvider`. 
 
-## Authenticate the User
-
-Let's begin by creating the `AuthenticationController` instance. From any Servlet class we can obtain the ServletConfig instance and read the properties defined in the `web.xml` file. Let's read our application properties and create a new instance of this controller:
+:::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
-String domain = getServletConfig().getServletContext().getInitParameter("com.auth0.domain");
-String clientId = getServletConfig().getServletContext().getInitParameter("com.auth0.clientId");
-String clientSecret = getServletConfig().getServletContext().getInitParameter("com.auth0.clientSecret");
+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");
 
-AuthenticationController controller = AuthenticationController.newBuilder(domain, clientId, clientSecret)
-                .build();
+            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;
+    }
 ```
 
-To authenticate the users we will redirect them to the **Auth0 Login Page** which uses the best version available of [Lock](/lock). This page is what we call the "Authorize URL". By using this library we can generate it with a simple method call. It will require a `HttpServletRequest` to store the call context in the session and the URI to redirect the authentication result to. This URI is normally the address where our app is running plus the path where the result will be parsed, which happens to be also the "Callback URL" whitelisted before. Finally, we will request the "User Info" *audience* in order to obtain an Open ID Connect compliant response. After we create the Authorize URL, we redirect the request there so the user can enter their credentials. The following code snippet is located on the `LoginServlet` class of our sample.
+## Trigger Authentication
+
+To enable users to login, your application will redirect them to the 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() + ":" + req.getServerPort() + "/callback";
+    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, redirectUri)
-            .withAudience(String.format("https://%s/userinfo", domain))
+    String authorizeUrl = authenticationController.buildAuthorizeUrl(req, res, redirectUri)
             .build();
     res.sendRedirect(authorizeUrl);
 }
 ```
 
-After the user logs in the result will be received in our `CallbackServlet`, either via a GET or a POST Http method. The request holds the call context that we've previously set by generating the Authorize URL with the controller. When we pass it to the controller, we get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, we need to save the credentials somewhere we can access them later. We will use again the `HttpSession` of the request. A helper class called `SessionUtils` is included in the library to set and read values from a request's session.
+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);
+        // Parse the request
+        Tokens tokens = authenticationController.handle(req, res);
         SessionUtils.set(req, "accessToken", tokens.getAccessToken());
         SessionUtils.set(req, "idToken", tokens.getIdToken());
         res.sendRedirect(redirectOnSuccess);
@@ -81,15 +124,16 @@ public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOExce
 ```
 
 ::: note
-It it's 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.
+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");
@@ -102,6 +146,40 @@ protected void doGet(HttpServletRequest req, HttpServletResponse res) throws Ser
 }
 ```
 
+## 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:
@@ -110,11 +188,11 @@ To run the sample from a terminal, change the directory to the root folder of th
 ./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}/#/).
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource 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.
 
-![Login using Lock](/media/articles/java/login-with-lock.png)
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
 
-After a successful authentication you'll be able to see the home page contents.
+After a successful authentication, you'll be able to see the home page contents.
 
 ![Display Token](/media/articles/java/display-token.png)
 
diff --git a/articles/quickstart/webapp/java/_includes/_setup.md b/articles/quickstart/webapp/java/_includes/_setup.md
index 0be53c3e46..753e49ee3a 100644
--- a/articles/quickstart/webapp/java/_includes/_setup.md
+++ b/articles/quickstart/webapp/java/_includes/_setup.md
@@ -1,23 +1,17 @@
-## Configure Callback URLs
+## Integrate Auth0 in your Application
 
-A Callback URL is a URL that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and attaches some details to it including a token. Callback URLs can be manipulated on the fly which could be harmful. For security reasons, you will need to add your application's callback URL in the **Allowed Callback URLs** box in your app's [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). This will allow Auth0 to recognize the URLs as valid. The same principle applies to **Logout URLs**. They must be whitelisted in the Auth0 Dashboard.
-
-If you are following this guide directly, set the following for your Callback and Logout URLs:
-
-- Allowed Callback URLs: `http://localhost:3000/callback`
-- Allowed Logout URLs: `http://localhost:3000/logout`
-
-
-## Setup Dependencies
+### 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 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. You can always check the latest version in the [library's GitHub](https://github.com/auth0/auth0-java-mvc-common).
+- **auth0-java-mvc-commons**: is the Java library 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 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.+'
 ```
@@ -25,10 +19,12 @@ 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.+
+  [1.0, 2.0)
 
 
   javax.servlet
@@ -37,12 +33,13 @@ If you are using Maven, add them to your `pom.xml`:
 
 ```
 
-
-## Configure your Java App
+### 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}
@@ -59,18 +56,9 @@ Your Java App needs some information in order to authenticate against your Auth0
 
 ```
 
-The library we're using has this default behavior:
-- Request the scope `openid`, needed to call the `/userinfo` endpoint later to verify the User's identity.
-- Request the `code` Response Type and later perform a Code Exchange to obtain the tokens.
-- Use the `HS256` Algorithm along with the Client Secret to verify the tokens.
-
-But it also allows us to customize it's behavior:
-* To use the `RS256` Algorithm along with the Public Key obtained dynamically from the Auth0 hosted JWKs file, pass a `JwkProvider` instance to the `AuthenticationController` builder.
-* To use a different Response Type, set the desired value in the `AuthenticationController` builder. Any combination of `code token id_token` is allowed.
-* To request a different `scope`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
-* To specify the `audience`, set the desired value in the `AuthorizeUrl` received after calling `AuthenticationController#buildAuthorizeUrl()`.
+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.
 
 
 ::: panel Check populated attributes
-If you download the seed using our **Download Sample** button then the `domain`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered application. In any case, you should verify that the values are correct if you have multiple applications in your account and you might want to use another than the one we set the information for.
+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/articles/quickstart/webapp/java/dashboard-default.md b/articles/quickstart/webapp/java/dashboard-default.md
deleted file mode 100644
index 330f8c7413..0000000000
--- a/articles/quickstart/webapp/java/dashboard-default.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your Java Servlet web app
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servlet-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Gradle 3.3 or above'
-  ]
-}) %>
-
-<%= include('../../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/java/download.md b/articles/quickstart/webapp/java/download.md
new file mode 100644
index 0000000000..73515fc8af
--- /dev/null
+++ b/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 to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+```text
+http://localhost:3000/login
+```
+
+3) Make sure Java 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 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/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md b/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
new file mode 100644
index 0000000000..badefcb759
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
@@ -0,0 +1,34 @@
+---
+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;
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java/files/CallbackServlet.md b/articles/quickstart/webapp/java/files/CallbackServlet.md
new file mode 100644
index 0000000000..ff5d16fdd5
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/CallbackServlet.md
@@ -0,0 +1,45 @@
+---
+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);
+        }
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java/files/HomeServlet.md b/articles/quickstart/webapp/java/files/HomeServlet.md
new file mode 100644
index 0000000000..edec61b849
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/HomeServlet.md
@@ -0,0 +1,22 @@
+---
+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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java/files/LoginServlet.md b/articles/quickstart/webapp/java/files/LoginServlet.md
new file mode 100644
index 0000000000..e05ba29f75
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/LoginServlet.md
@@ -0,0 +1,32 @@
+---
+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);
+    }
+}
+```
diff --git a/articles/quickstart/webapp/java/files/LogoutServlet.md b/articles/quickstart/webapp/java/files/LogoutServlet.md
new file mode 100644
index 0000000000..95dd2ed96b
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/LogoutServlet.md
@@ -0,0 +1,39 @@
+---
+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);
+    }
+
+}
+```
diff --git a/articles/quickstart/webapp/java/files/authentication-controller-provider.md b/articles/quickstart/webapp/java/files/authentication-controller-provider.md
new file mode 100644
index 0000000000..c722f0beef
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/files/callback-servlet.md b/articles/quickstart/webapp/java/files/callback-servlet.md
new file mode 100644
index 0000000000..1c60791bd7
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/files/home-servlet.md b/articles/quickstart/webapp/java/files/home-servlet.md
new file mode 100644
index 0000000000..5013342a7b
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/files/login-servlet.md b/articles/quickstart/webapp/java/files/login-servlet.md
new file mode 100644
index 0000000000..34af59e76e
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/files/logout-servlet.md b/articles/quickstart/webapp/java/files/logout-servlet.md
new file mode 100644
index 0000000000..50c36f2249
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/files/web.md b/articles/quickstart/webapp/java/files/web.md
new file mode 100644
index 0000000000..1adea02008
--- /dev/null
+++ b/articles/quickstart/webapp/java/files/web.md
@@ -0,0 +1,21 @@
+---
+name: web.xml
+language: 
+---
+    
+```
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    ${account.clientSecret}
+
+```
diff --git a/articles/quickstart/webapp/java/index.yml b/articles/quickstart/webapp/java/index.yml
index 28866a8d9b..77afc30ff0 100644
--- a/articles/quickstart/webapp/java/index.yml
+++ b/articles/quickstart/webapp/java/index.yml
@@ -1,14 +1,47 @@
 title: Java
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/java.png
-tags:
+logo: java
+topics:
   - quickstart
+contentType: tutorial
+useCase: quickstart
 author:
-  name: Luciano Balmaceda
-  email: luciano.balmaceda@auth0.com
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
   community: false
 alias:
   - java
 seo_alias: java
-default_article: dashboard-default
+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/articles/quickstart/webapp/java/interactive.md b/articles/quickstart/webapp/java/interactive.md
new file mode 100644
index 0000000000..8ed2921eff
--- /dev/null
+++ b/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,143 @@
+---
+title: Add Login to Your Java Servlet Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Java Servlet application.
+interactive:  true
+files:
+ - files/web
+ - files/AuthenticationControllerProvider
+ - files/LoginServlet
+ - files/CallbackServlet
+ - files/HomeServlet
+ - files/LogoutServlet
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# 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.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000/.
        
+
+## 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 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 that identify the user.
        If you are using Gradle, add them to your build.gradle:
        // build.gradle
+
+
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+
+compile 'com.auth0:mvc-auth-commons:1.+'W
+
+
        
+
+
        If you are using Maven, add them to your pom.xml:
        <!-- pom.xml -->
+
+
+
+<dependency>
+
+  <groupId>com.auth0</groupId>
+
+  <artifactId>mvc-auth-commons</artifactId>
+
+  <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+  <groupId>javax.servlet</groupId>
+
+  <artifactId>javax.servlet-api</artifactId>
+
+  <version>3.1.0</version>
+
+</dependency>
+
+
        
+
+
        
+
+## Configure your Java application {{{ data-action="code" data-code="web.xml" }}}
+
+
+
        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.
        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:
        - 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.java: Responsible to create and manage a single instance of the AuthenticationController
        
+
+## Create the AuthenticationController {{{ data-action="code" data-code="AuthenticationControllerProvider.java#5:26" }}}
+
+
+
        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 to learn about additional configuration options. If you are using HS256, there is no need to configure the JwkProvider.
        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 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.
        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
+
+
+
        To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
        ./gradlew clean app
+
+
        
+
+
        After a few seconds, the application will be accessible on http://localhost:3000/. Try to access the protected resource 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.
        After a successful authentication, you'll be able to see the home page contents.
        Log out by clicking the logout button at the top right of the home page.
        
diff --git a/articles/quickstart/webapp/laravel/01-login.md b/articles/quickstart/webapp/laravel/01-login.md
index e7b1960fe8..13bcb2ef85 100644
--- a/articles/quickstart/webapp/laravel/01-login.md
+++ b/articles/quickstart/webapp/laravel/01-login.md
@@ -1,402 +1,217 @@
 ---
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 PHP Laravel SDK to add authentication and authorization to your web app.
-budicon: 448
+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
 ---
 
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-laravel-php-web-app',
-  path: '01-Login',
-  requirements: [
-    'Composer 1.5',
-    'PHP 7.0',
-    'Laravel 5.5'
-  ]
-}) %>
+
 
-## Install and Configure Laravel 5.5
+## Laravel Installation
 
-If you are installing Auth0 to an existing app, you can skip this section. Otherwise, walk through the Laravel guides below to get started with a sample project.
+**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:
 
-1. **[Installation](https://laravel.com/docs/5.5/installation)**
-    * Use any of the install methods listed to start a new project
-    * PHP can be served any way that works for your development process (we use Homebrew-installed Apache and PHP)
-    * Walk through the "Configuration" section completely
-2. **[Configuration](https://laravel.com/docs/5.5/configuration)**
-    * Create a .env file, used later for critical and sensitive Auth0 connection values
-    * Make sure `APP_DEBUG` is set to `true`
-    
-By the end of those 2 sections, you should have a Laravel application up and running locally or on a test server.
-
-## Install Auth0 Login and Dependencies
-
-${snippet(meta.snippets.dependencies)}
-
-::: note
-**[Composer](https://getcomposer.org/)** is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you. See Composer's [getting started](https://getcomposer.org/doc/00-intro.md) doc for information on how to use it.
-:::
-
-This will install:
-
-* The [Auth0 PHP SDK](https://github.com/auth0/auth0-PHP) in `vendor\auth0\auth0-php`
-* The [Auth0 Laravel plugin](https://github.com/auth0/laravel-auth0) in `vendor\auth0\login`
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+```
 
-## Enable Auth0 Login in Laravel
+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:
 
-First, we need to add the Auth0 Services to the list of Providers in `config/app.php`:
+```shell
+cd auth0-laravel-app
+```
 
-${snippet(meta.snippets.setup)}
+## SDK Installation
 
-If you want to use an `Auth0` facade, add an alias in the same file (not required, [more information on facades here](http://laravel.com/docs/5.5/facades)):
+Run the following command within your project directory to install the Auth0 Laravel SDK:
 
-```php
-// config/app.php
-
-'aliases' => array(
-    // ...
-    'Auth0' => Auth0\Login\Facade\Auth0::class
-);
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
 ```
 
-Finally, you will need to bind a class that provides the app's User model each time a user is logged in or a JWT is decoded. You can use the `Auth0UserRepository` provided by this package or build your own (see the "Custom User Handling" section below).
-
-Add the following to your `AppServiceProvider::register()` method:
+Then generate an SDK configuration file for your application:
 
-```php
-// app/Providers/AppServiceProvider.php
-
-// ...
-use Auth0\Login\Contract\Auth0UserRepository as Auth0Contract;
-use Auth0\Login\Repository\Auth0UserRepository as UserRepo;
-
-class AppServiceProvider extends ServiceProvider
-{
-    // ...
-    public function register()
-    {
-        $this->app->bind(
-            Auth0Contract::class,
-            UserRepo::class
-        );
-    }
-}
+```shell
+php artisan vendor:publish --tag auth0
 ```
 
-## Configure It
-
-To configure the plugin, you must publish the plugin configuration and complete the file `config/laravel-auth0.php` using  information from your Auth0 account and details of your implementation.
+## SDK Configuration
 
-Publish the default configuration file with the following command:
+Run the following command from your project directory to download the Auth0 CLI:
 
-```bash
-php artisan vendor:publish
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
 ```
 
-Select the option for `Auth0\Login\LoginServiceProvider` and look for `Publishing complete.` This creates the file `config/laravel-auth0.php` with the following settings:
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
 
-* `domain` - Your Auth0 tenant domain, found in your Application settings (required)
-* `client_id` - Your Auth0 Client ID, found in your Application settings (required)
-* `client_secret` - Your Auth0 Client Secret, found in your Application settings (required)
-* `redirect_uri` - The callback URI for your Laravel application to handle the login response from Auth0; by default this is `APP_URL/auth0/callback` (required)
-* `persist_user` - Should the user information persist in a PHP session? Default is `true`
-* `persist_access_token` - Should the Access Token persist in a PHP session? Default is `false`
-* `persist_id_token` - Should the ID Token persist in a PHP session? Default is `false`
-* `authorized_issuers` - An array of authorized token issuers, should include at least your tenant domain
-* `api_identifier` - The authorized token audience
-* `secret_base64_encoded` - Is the Client Secret Base64 encoded? Look below the Client Secret field in the Auth0 dashboard to see how to set this; default is `false`
-* `supported_algs` - JWT decoding algorithms supported by your application; default is `RS256`
-* `guzzle_options` - Specify additional [request options for Guzzle](http://docs.guzzlephp.org/en/stable/request-options.html)
+```shell
+./auth0 login
+```
 
-To keep sensitive data out of version control and allow for different testing and production instances, we recommend using the `.env` file Laravel uses to load other environment-specific variables:
+Next, create a new application with Auth0:
 
-```
-// .env
-// ...
-AUTH0_DOMAIN=${account.namespace}
-AUTH0_CLIENT_ID=${account.clientId}
-AUTH0_CLIENT_SECRET=YOUR_CLIENT_SECRET
+```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
 ```
 
-Call `env()` in `laravel-auth0.php` to get the correct setting:
+You should also create a new API:
 
-```php
-// config/laravel-auth0.php
-
-return array(
-    // ...
-    'domain'        => env( 'AUTH0_DOMAIN' ),
-    // ...
-    'client_id'     => env( 'AUTH0_CLIENT_ID' ),
-    // ...
-    'client_secret' => env( 'AUTH0_CLIENT_SECRET' ),
-    // ...
-);
+```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
 ```
 
-## Set Up Routes
-
-The plugin works with the [Laravel authentication system](https://laravel.com/docs/5.5/authentication) by creating a callback route to handle the authentication data from the Auth0 server.
+This produces two files in your project directory that configure the SDK.
 
-First, we'll add our route and controller to `routes/web.php`. The route used here must match the `redirect_uri` configuration option set previously:
+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:
 
-```php
-// routes/web.php
-// ...
-Route::get( '/auth0/callback', '\Auth0\Login\Auth0Controller@callback' )->name( 'auth0-callback' );
+```bash
+echo ".auth0.*.json" >> .gitignore
 ```
 
-If you load this callback URL now, you should be immediately redirected back to the homepage rather than getting a 404 error. This tells us that the route is setup and being handled. 
+## Login Routes
 
-Now we need to add this URL to the **Allowed Callback URLs** field in the Application settings screen for the Application used with this app. Add the complete URL, like `https://myapp.com/auth0/callback`.
+The SDK automatically registers all the necessary routes for your application's users to authenticate.
 
-Lastly, we need to set up how users log in and out of our app. This is handled by redirecting users to Auth0 for the former and clearing out session data for the latter. Let's start by creating a generic route handling controller. In the console:
+| Route       | Purpose                            |
+| ----------- | ---------------------------------- |
+| `/login`    | Initiates the authentication flow. |
+| `/logout`   | Logs the user out.                 |
+| `/callback` | Handles the callback from Auth0.   |
 
-```bash
-php artisan make:controller Auth/Auth0IndexController
-```
+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 SDKs README for advanced integrations.
 
-This creates a controller file to handle the routes used to log in and out. Let's create a function for each of these in the controller we just made:
+## Access Control {{{ data-action=code data-code="routes/web.php#6:12" }}}
 
-```php
-// app/Http/Controllers/Auth/Auth0IndexController.php
-// ...
-class Auth0IndexController extends Controller
-{
-    /**
-     * Redirect to the Auth0 hosted login page
-     * 
-     * @return mixed
-     */
-    public function login()
-    {
-        return \App::make('auth0')->login(null, null, ['scope' => 'openid email email_verified'], 'code');
-    }
-
-    /**
-     * Log out of Auth0
-     * 
-     * @return mixed
-     */
-    public function logout()
-    {
-        \Auth::logout();
-        return  \Redirect::intended('/');
-    }
-}
-```
+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.
 
-Now, add the routes tied to the correct handler method along with names we can use and `auth` middleware where needed:
+To require users to authenticate before accessing a route, you can use Laravel's `auth` middleware:
 
 ```php
-// routes/web.php
-// ...
-Route::get('/login', 'Auth\Auth0IndexController@login' )->name( 'login' );
-Route::get('/logout', 'Auth\Auth0IndexController@logout' )->name( 'logout' )->middleware('auth');
+Route::get('/private', function () {
+  return response('Welcome! You are logged in.');
+})->middleware('auth');
 ```
 
-## Defining a User and a User Provider
+You can also require authenticated users to have specific permissions by combining this with Laravel's `can` middleware:
 
-The [Laravel authentication system](https://laravel.com/docs/5.5/authentication) needs a *User Object* given by a *User Provider*. With these two abstractions, the user entity can have any structure you like and can be stored anywhere. You configure the *User Provider* indirectly, by selecting a user provider in `app/config/auth.php`. The default provider is Eloquent, which persists the User model in a database using the ORM.
+```php
+Route::get('/scope', function () {
+    return response('You have the `read:messages` permissions, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+```
 
-The plugin comes with an authentication driver called `auth0` which defines a user structure that wraps the [Normalized User Profile](/user-profile) defined by Auth0. This driver does not actually persist the User, it just stores it in session for future calls. This works fine for basic testing or if you don't really need to persist the user. For persistence in the database, see the "Custom User Handling" section below.
+## User Information {{{ data-action=code data-code="routes/web.php#14:24" }}}
 
-At any point you can call `Auth::check()` to see if there is a user logged in and `Auth::user()` to get the wrapper with the user information.
+Information about the authenticated user is available through Laravel's `Auth` Facade, or the `auth()` helper function.
 
-Configure the User driver in `config/auth.php` to use `auth0` like this:
+For example, to retrieve the user's identifier and email address:
 
 ```php
-// config/auth.php
-// ...
-'providers' => [
-    'users' => [
-        'driver' => 'auth0'
-    ],
-],
-```
-
-## Add Login and Logout Links
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
 
-To test all this out, let's add links to our site to access these routes. If you're using the default project, open up `resources/views/welcome.blade.php` and look for the `@if (Route::has('login'))` block. Change that block to the following:
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
 
-```blade
-@if (Route::has('login'))
-    
        
-        @auth
-            Logout
-        @else
-            Login/Signup
-        @endauth
-    
        
-@endif
+  return response("Hello {$name}! Your email address is {$email}.");
+});
 ```
 
-Load the homepage of your app and you should see a **Login** link at the top right. If you click on that, you should be redirected to an Auth0 login page for your application. If this does not happen then you should see one of two things:
+## User Management{{{ data-action=code data-code="routes/web.php#26:43" }}}
 
-1. A Laravel debug screen (is `APP_DEBUG` is set to `true`) which, along with the steps above, should help diagnose the issues
-1. An Auth0 error page with more information under the "Technical Details" heading (click **See details for this error**)
+You can update user information using the Auth0 Management API. All Management endpoints are accessible through the SDK's `management()` method.
 
-Once you're able to successfully log in, you will be redirected to your homepage with a **Logout** link at the top right. This tells us that the login process was successful and the Auth0 user provider is functioning properly. Click **Logout** and you should be back where you started. 
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the Auth0 Dashboards API page, 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.
 
-At this point you should have a fully-functioning authentication process using Auth0! 
+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.
 
-## Extra: Custom User Handling
+```php
+use Auth0\Laravel\Facade\Auth0;
 
-What if you need to customize how users are handled beyond what Auth0 provides? You may want to, for example, store the user profile in a database. These kind of customizations can be done by extending the `Auth0UserRepository` class with your own custom class.
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
 
-::: note
-The database information below is an example and is based on a new, default Laravel project. Your database connection information will be different and the table, column names may need to be adjusted, and migrations should be reviewed.
-:::
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
 
-Let's walk through how to add user database persistence using this a custom Repository class called `CustomUserRepository`. You'll need to have a database configured and a `users` table created. If you're starting with the default project, update your MySQL information in your `.env` file:
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
 
-```
-DB_CONNECTION=mysql
-DB_HOST=127.0.0.1
-DB_PORT=3306
-DB_DATABASE=laravel
-DB_USERNAME=db_user
-DB_PASSWORD=db_password
-```
+  $metadata = $endpoint->get(auth()->id());
+  $metadata = Auth0::json($metadata);
 
-In the `database/migrations` folder for the default Laravel project there will be two files, one for creating a users table and one for creating a password reset table. We can delete the password reset one since that's handled by Auth0 but we want to change the users one to remove unnecessary columns and add a new one. 
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
 
-Edit the migration file with a name similar to `create_users_table` and change the `CreateUsersTable::up()` method to remove the `password` field and add one for `sub` (the Auth0 user ID):
-
-```php
-// database/migrations/x_x_x_create_users_table.php
-// ...
-class CreateUsersTable extends Migration
-{
-    // ...
-    public function up()
-    {
-        Schema::create('users', function (Blueprint $table) {
-            $table->increments('id');
-            $table->string('name');
-            $table->string('sub')->unique();
-            $table->string('email')->unique();
-            $table->rememberToken();
-            $table->timestamps();
-        });
-    }
-    // ...
-}
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
 ```
 
-Save this file and run the artisan command to create this table:
+A quick reference guide of all the SDK's Management API methods is available here.
 
-```bash
-php artisan migrate
-``` 
+## Run the Application
 
-Next, make a `CustomUserRepository.php` class we can modify:
+You are now ready to start your Laravel application, so it can accept requests:
 
-```bash
-# From the Laravel root
-mkdir app/Repositories;
-touch app/Repositories/CustomUserRepository.php
+```shell
+php artisan serve
 ```
 
-We're going to implement a method called `upsertUser()` to retrieve or add users to the database. We'll also re-implement the `getUserByDecodedJWT()` and `getUserByUserInfo()` methods to use `upsertUser()` when getting users:
+### Checkpoint
 
-```php
-// app/Repositories/CustomUserRepository.php
-namespace App\Repositories;
-
-use App\User;
-
-use Auth0\Login\Auth0User;
-use Auth0\Login\Auth0JWTUser;
-use Auth0\Login\Repository\Auth0UserRepository;
-
-class CustomUserRepository extends Auth0UserRepository
-{
-
-    /**
-     * Get an existing user or create a new one
-     *
-     * @param array $profile - Auth0 profile
-     *
-     * @return User
-     */
-    protected function upsertUser( $profile ) {
-
-        // See if we have a user that matches the Auth0 user_id
-        $user = User::where( 'sub', $profile['sub'] )->first();
-
-        // In not, add them to the database
-        if ( ! $user ) {
-            $user = new User();
-
-            // All are required, no default set
-            $user->setAttribute( 'email', $profile['email'] );
-            $user->setAttribute( 'sub', $profile['sub'] );
-            $user->setAttribute( 'name', isset( $profile['name'] ) ? $profile['name'] : '' );
-
-            $user->save();
-        }
-        return $user;
-    }
-
-    /**
-     * Authenticate a user with a decoded ID Token
-     *
-     * @param object $jwt
-     *
-     * @return Auth0JWTUser
-     */
-    public function getUserByDecodedJWT( $jwt ) {
-        $user = $this->upsertUser( (array) $jwt );
-        return new Auth0JWTUser( $user->getAttributes() );
-    }
-
-    /**
-     * Get a User from the database using Auth0 profile information
-     *
-     * @param array $userinfo
-     *
-     * @return Auth0User
-     */
-    public function getUserByUserInfo( $userinfo ) {
-        $user = $this->upsertUser( $userinfo['profile'] );
-        return new Auth0User( $user->getAttributes(), $userinfo['accessToken'] );
-    }
-}
-```
-
-::: note
-If you get an error message stating "Can't initialize a new session while there is one active session already" while testing changes to the Repository file, clear all cookies for the testing site and try again. This can happen when a session is set but an error occurs after or the process does not complete.
-:::
+Open your web browser and try accessing the following routes:
 
-Finally, we'll change the binding in the `AppServiceProvider` to point to this new custom Repository class:
+- http://localhost:8000 to see the public route.
+- http://localhost:8000/private to be prompted to authenticate.
+- http://localhost:8000 to see the pubic route, now authenticated.
+- http://localhost:8000/scope to check if you have the `read:messages` permission.
+- http://localhost:8000/update to update the user's profile.
+- http://localhost:8000/logout to log out.
 
-```php
-// app/Providers/AppServiceProvider.php
-
-// ...
-use \Auth0\Login\Contract\Auth0UserRepository as Auth0Contract;
-use \App\Repositories\CustomUserRepository as UserRepo;
-
-class AppServiceProvider extends ServiceProvider
-{
-    // ...
-    public function register()
-    {
-        $this->app->bind(
-            Auth0Contract::class,
-            UserRepo::class
-        );
-    }
-}
-```
+If you have any issues, here are a couple of things to try:
 
-Logging in for the first time should create a new entry in the database with the Auth0 `sub` ID and email address used. Subsequent logins should simply access that same user and not create any new records. 
+- 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.
 
-## Extra: More About the QuickStart Project
+Encountering problems? Check the SDK's documentation or our documentation hub. You should also consider visiting the community where our team and other community members can help answer your questions.
 
-The Sample Project linked at the start of this guide implements everything here and more. 
+### Additional Reading
 
-* A simple Profile screen that displays user data from Auth0
-* Additional work with templates 
\ No newline at end of file
+- User Repositories and Models extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- Hooking Events covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- Management API support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/articles/quickstart/webapp/laravel/download.md b/articles/quickstart/webapp/laravel/download.md
new file mode 100644
index 0000000000..e149badf02
--- /dev/null
+++ b/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/articles/quickstart/webapp/laravel/files/routes/web.md b/articles/quickstart/webapp/laravel/files/routes/web.md
new file mode 100644
index 0000000000..3552be454c
--- /dev/null
+++ b/articles/quickstart/webapp/laravel/files/routes/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/articles/quickstart/webapp/laravel/files/web.md b/articles/quickstart/webapp/laravel/files/web.md
new file mode 100644
index 0000000000..77344cc11d
--- /dev/null
+++ b/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/articles/quickstart/webapp/laravel/index.yml b/articles/quickstart/webapp/laravel/index.yml
index a32e188f8a..3379252e0f 100644
--- a/articles/quickstart/webapp/laravel/index.yml
+++ b/articles/quickstart/webapp/laravel/index.yml
@@ -1,12 +1,36 @@
-title: PHP (Laravel)
+title: Laravel
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/php.png
-tags:
+logo: laravel
+alias:
+  - laravel
+languages:
+  - PHP
+framework:
+  - Laravel
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
   - quickstart
-snippets:
-  dependencies: server-platforms/laravel/dependencies
-  setup: server-platforms/laravel/setup
-  use: server-platforms/laravel/use
-seo_alias: laravel
-default_article: 01-login
+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/articles/quickstart/webapp/laravel/interactive.md b/articles/quickstart/webapp/laravel/interactive.md
new file mode 100644
index 0000000000..070da053e0
--- /dev/null
+++ b/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,253 @@
+---
+title: Add Login to Your Laravel Application
+description: This guide demonstrates how to integrate Auth0 with a new (or existing) Laravel 9 or 10 application.
+interactive:  true
+files:
+ - files/routes/web
+github:
+  path: sample
+locale: en-US
+---
+
+# Add Login to Your Laravel Application
+
+
+
        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.
        Test Change
        
+
+## 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:
        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:
        cd auth0-laravel-app
+
+
        
+
+
        
+
+## SDK Installation
+
+
+
        Run the following command within your project directory to install the Auth0 Laravel SDK:
        composer require auth0/login:^7.8 --update-with-all-dependencies
+
+
        
+
+
        Then generate an SDK configuration file for your application:
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## SDK Configuration
+
+
+
        Run the following command from your project directory to download the Auth0 CLI:
        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:
        ./auth0 login
+
+
        
+
+
        Next, create a new application with Auth0:
        ./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:
        ./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:
        echo ".auth0.*.json" >> .gitignore
+
+
        
+
+
        
+
+## Login Routes
+
+
+
        The SDK automatically registers all the necessary routes for your application's users to authenticate.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **Routes****Purpose**
        /loginInitiates the authentication flow.
        /logoutLogs the user out.
        /callbackHandles 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 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.
        Route::get('/private', function () {
+
+  return response('Welcome! You are logged in.');
+
+})->middleware('auth');
+
+
        
+
+
        You can also require authenticated users to have specific permissions by combining this with Laravel's can middleware.
        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:
        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. 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, 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.
        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.
        
+
+## Run the Application
+
+
+
        You are now ready to start your Laravel application, so it can accept requests:
        php artisan serve
        Laravel - Step 8 - Run the Application - Checkpoint 
        Open your web browser and try accessing the following routes:
        
+
+  
        
+
+  
        
+
+  
        Additional Reading
        • User Repositories and Models extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
        • Hooking Events covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
        • Management API support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
        
diff --git a/articles/quickstart/webapp/nancyfx/01-login.md b/articles/quickstart/webapp/nancyfx/01-login.md
deleted file mode 100644
index f33423b244..0000000000
--- a/articles/quickstart/webapp/nancyfx/01-login.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial will show you how to use the Auth0 NancyFX SDK to add authentication and authorization to your web app.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-nancyfx-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Microsoft Visual Studio 2015',
-    '.NET Framework 4.5.2'
-  ]
-}) %>
-
-## Install the Dependencies
-
-Install Auth0 NancyFX dependency with `NuGet`
-
-${snippet(meta.snippets.dependencies)}
-
-## Configure Auth0
-
-In your Nancy self-hosted application add the following to your BootStrapper:
-
-${snippet(meta.snippets.setup)}
-
-The `RedirectOnLoginFailed` specifies the view that should be shown to an authenticated user when they try to access a restricted view.
-
-The `CookieName` allows you to set the name of the cookie that will be used to save the User information.
-
-The `UserIdentifier` lets you set an identifier for the user. Currently, here are the fields that are available:
-
-  * `userid`
-  * `email`
-  * `nickname`
-  * `gravatarurl`
-
-::: note
-Auth0.Nancy.SelfHost enables `CookieBasedSessions` setting in the background. If you use this setting in your app as well, you should switch it off.
-:::
-
-## Add Auth0 Configuration
-
-You need to configure your Auth0 keys in the `app.config`
-
-```xml
-
-    
-    
-    
-    
-    
-
-```
-
-## Block all Unauthenticated Requests
-
-After you enabled the `Auth0Authentication` you are able to block all unauthenticated requests with the following code.
-
-```cs
-public class SecurePage : NancyModule
-{
-    public SecurePage()
-    {
-        this.RequiresAuthentication(); //<- This is a new implemetation of default extension
-        Get["/securepage"] = o => View["securepage"];
-    }
-}
-```
-
-## Add Auth0 Callback Handler
-
-We need to add the handler for the Auth0 callback so that we can authenticate the user and get their information. We also need to add an endpoint to let users log in and log out.
-
-```cs
-public class Authentication : NancyModule
-{
-    public Authentication()
-    {
-        Get["/login"] = o =>
-        {
-            if (this.SessionIsAuthenticated())
-                return Response.AsRedirect("securepage");
-
-            var apiClient = new AuthenticationApiClient(ConfigurationManager.AppSettings["auth0:domain"]);
-            var authorizationUri = apiClient.BuildAuthorizationUrl()
-                .WithClient(ConfigurationManager.AppSettings["auth0:ClientId"])
-                .WithRedirectUrl(ConfigurationManager.AppSettings["auth0:CallbackUrl"])
-                .WithResponseType(AuthorizationResponseType.Code)
-                .WithScope("openid profile")
-                .Build();
-
-            return Response.AsRedirect(authorizationUri.ToString());
-        };
-
-        Get["/login-callback"] = o => this
-            .AuthenticateThisSession()
-            .ThenRedirectTo("securepage");
-
-        Get["/logout"] = o => this
-            .RemoveAuthenticationFromThisSession()
-            .ThenRedirectTo("index");
-    }
-}
-```
diff --git a/articles/quickstart/webapp/nancyfx/index.yml b/articles/quickstart/webapp/nancyfx/index.yml
deleted file mode 100644
index a9d329b4c0..0000000000
--- a/articles/quickstart/webapp/nancyfx/index.yml
+++ /dev/null
@@ -1,13 +0,0 @@
-title: NancyFX
-community: true
-image: /media/platforms/nancyfx.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/nancyfx/dependencies
-  setup: server-platforms/nancyfx/setup
-  use: server-platforms/nancyfx/use
-seo_alias: nancyfx
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/nextjs/01-login.md b/articles/quickstart/webapp/nextjs/01-login.md
new file mode 100644
index 0000000000..3073c14074
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/01-login.md
@@ -0,0 +1,231 @@
+---
+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/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 on the backend and React Context with React Hooks on the frontend.
+
+### Configure the SDK
+
+In the root directory of your project, create the file `.env.local` with the following environment variables:
+
+```sh
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+APP_BASE_URL='http://localhost:3000'
+AUTH0_DOMAIN='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+# 'If your application is API authorized add the variables AUTH0_AUDIENCE and AUTH0_SCOPE'
+AUTH0_AUDIENCE='your_auth_api_identifier'
+AUTH0_SCOPE='openid profile email read:shows' 
+```
+
+- `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.
+- `APP_BASE_URL`: The base URL of your application
+- `AUTH0_DOMAIN`: The URL of your Auth0 tenant domain
+- `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 configure itself automatically.
+
+::: note
+Manually add the values for `AUTH0_AUDIENCE` and `AUTH_SCOPE` to the file `lib/auth0.js`.  These values are not configured automatically.
+If you are using a Custom Domain with Auth0, set `AUTH0_DOMAIN` to the value of your Custom Domain instead of the value reflected in the application "Settings" tab.
+:::
+
+### Create the Auth0 SDK Client
+
+Create a file at `lib/auth0.js` to add an instance of the Auth0 client. This instance provides methods for handling authentication, sesssions and user data. 
+
+```javascript
+// lib/auth0.js
+
+import { Auth0Client } from "@auth0/nextjs-auth0/server";
+
+// Initialize the Auth0 client 
+export const auth0 = new Auth0Client({
+  // Options are loaded from environment variables by default
+  // Ensure necessary environment variables are properly set
+  // domain: process.env.AUTH0_DOMAIN,
+  // clientId: process.env.AUTH0_CLIENT_ID,
+  // clientSecret: process.env.AUTH0_CLIENT_SECRET,
+  // appBaseUrl: process.env.APP_BASE_URL,
+  // secret: process.env.AUTH0_SECRET,
+
+  authorizationParameters: {
+    // In v4, the AUTH0_SCOPE and AUTH0_AUDIENCE environment variables for API authorized applications are no longer automatically picked up by the SDK.
+    // Instead, we need to provide the values explicitly.
+    scope: process.env.AUTH0_SCOPE,
+    audience: process.env.AUTH0_AUDIENCE,
+  }
+});
+```
+
+### Add the Authentication Middleware
+
+The Next.js Middleware allows you to run code before a request is completed.
+Create a `middleware.ts` file. This file is used to enforce authentication on specific routes.
+
+```javascript
+import type { NextRequest } from "next/server";
+import { auth0 } from "./lib/auth0";
+
+export async function middleware(request: NextRequest) {
+  return await auth0.middleware(request);
+}
+
+export const config = {
+  matcher: [
+    /*
+     * Match all request paths except for the ones starting with:
+     * - _next/static (static files)
+     * - _next/image (image optimization files)
+     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
+     */
+    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
+  ],
+};
+```
+
+The `middleware` function intercepts incoming requests and applies Auth0's authentication logic. The `matcher` configuration ensures that the middleware runs on all routes except for static files and metadata.
+
+#### Auto-configured routes
+
+Using the SDK's middleware auto-configures the following routes:
+
+- `/auth/login`: The route to perform login with Auth0
+- `/auth/logout`: The route to log the user out
+- `/auth/callback`: The route Auth0 will redirect the user to after a successful login
+- `/auth/profile`: The route to fetch the user profile
+- `/auth/access-token`: The route to verify the user's session and return an access token (which automatically refreshes if a refresh token is available)
+- `/auth/backchannel-logout`: The route to receive a `logout_token` when a configured Back-Channel Logout initiator occurs
+
+:::note
+The `/auth/access-token` route is enabled by default, but is only neccessary when the access token is needed on the client-side. If this isn't something you need, you can disable this endpoint by setting `enableAccessTokenEndpoint` to `false`. 
+:::
+
+## Add Login to Your Application
+
+Users can now log in to your application at `/auth/login` route provided by the SDK. Use an **anchor tag** to add a link to the login route to redirect your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 redirects your users back to your application.
+
+```html
+Login
+```
+
+:::note
+Next.js suggests using Link components instead of anchor tags, but since these are API routes and not pages, anchor tags are needed.
+:::
+
+:::panel Checkpoint
+Add the login link to your application. Select it and verify that your Next.js 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 back to your application.
+
+If you are following along with the sample app project from the top of this page, run the command:
+
+```sh
+npm i && npm run dev 
+```
+and visit http://localhost:3000 in your browser.
+:::
+
+![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. Add a link that points to the `/auth/logout` API route. To learn more, read Log Users out of Auth0 with OIDC Endpoint.
+
+```html
+Logout
+```
+
+:::panel Checkpoint
+Add the logout link to your application. When you select it, verify that your Next.js application redirects you to the address you specified as one of the "Allowed Logout URLs" in the application "Settings".
+:::
+
+## Show User Profile Information
+
+The Auth0 Next.js SDK helps you retrieve the profile information 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 as an example of how to use it:
+
+```jsx
+'use client';
+import { useUser } from "@auth0/nextjs-auth0"
+
+export default function Profile() {
+  const { user, isLoading } = useUser();
+  return (
+    <>
+      {isLoading && 
        Loading...
        }
+      {user && (
+        
        
+          Profile
+          
        {user.name}
        
+          
        {user.email}
        
+          
        {JSON.stringify(user, null, 2)}
        
+        
        
+      )}
+    
+  );
+}
+```
+
+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 as an example of how to use it:
+
+```jsx
+import { auth0 } from "@/lib/auth0";
+
+export default async function ProfileServer() {
+  const { user } = await auth0.getSession(); 
+  return ( user && ( 
         {user.name}/ 
        {user.name}
         
        {user.email}
         
         )  ); 
+}
+
+```
+
+:::panel Checkpoint
+Verify that you can display the `user.name` or any other `user` property within a component correctly after you have logged in.
+:::
+
+## What's next?
+
+We put together a few examples on how to use nextjs-auth0 for more advanced use cases.
diff --git a/articles/quickstart/webapp/nextjs/download.md b/articles/quickstart/webapp/nextjs/download.md
new file mode 100644
index 0000000000..b80e4d475b
--- /dev/null
+++ b/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 to
+```text
+http://localhost:3000/auth/callback
+```
+
+2) Set **Allowed Logout URLs** in the Application Settings to
+```text
+http://localhost:3000
+```
+
+3) Make sure Node.JS LTS 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 image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/nextjs/files/.env.md b/articles/quickstart/webapp/nextjs/files/.env.md
new file mode 100644
index 0000000000..e4de060766
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/.env.md
@@ -0,0 +1,12 @@
+---
+name: .env.local
+language: 
+---
+    
+```
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+APP_BASE_URL='http://localhost:3000'
+AUTH0_DOMAIN='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
diff --git a/articles/quickstart/webapp/nextjs/files/auth.md b/articles/quickstart/webapp/nextjs/files/auth.md
new file mode 100644
index 0000000000..4a7cc02805
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/auth0.md b/articles/quickstart/webapp/nextjs/files/auth0.md
new file mode 100644
index 0000000000..ef0bc05299
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/auth0.md
@@ -0,0 +1,12 @@
+---
+name: "src/lib/auth0.ts"
+language: javascript
+---
+
+
+
+```javascript
+import { Auth0Client } from "@auth0/nextjs-auth0/server";
+
+export const auth0 = new Auth0Client();
+```
diff --git a/articles/quickstart/webapp/nextjs/files/env.md b/articles/quickstart/webapp/nextjs/files/env.md
new file mode 100644
index 0000000000..c582873ef0
--- /dev/null
+++ b/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'
+APP_BASE_URL='http://localhost:3000'
+AUTH0_DOMAIN='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
diff --git a/articles/quickstart/webapp/nextjs/files/layout.md b/articles/quickstart/webapp/nextjs/files/layout.md
new file mode 100644
index 0000000000..8567031642
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/login.md b/articles/quickstart/webapp/nextjs/files/login.md
new file mode 100644
index 0000000000..e245a0cbbd
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/logout.md b/articles/quickstart/webapp/nextjs/files/logout.md
new file mode 100644
index 0000000000..60fa22031e
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/middleware.md b/articles/quickstart/webapp/nextjs/files/middleware.md
new file mode 100644
index 0000000000..143a21f55f
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/middleware.md
@@ -0,0 +1,27 @@
+---
+name: "src/middleware.ts"
+language: javascript
+---
+
+
+
+```javascript
+import type { NextRequest } from "next/server";
+import { auth0 } from "./lib/auth0";
+
+export async function middleware(request: NextRequest) {
+  return await auth0.middleware(request);
+}
+
+export const config = {
+  matcher: [
+    /*
+     * Match all request paths except for the ones starting with:
+     * - _next/static (static files)
+     * - _next/image (image optimization files)
+     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
+     */
+    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
+  ],
+};
+```
diff --git a/articles/quickstart/webapp/nextjs/files/page.md b/articles/quickstart/webapp/nextjs/files/page.md
new file mode 100644
index 0000000000..5bc12c8dfa
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/page.md
@@ -0,0 +1,42 @@
+---
+name: "src/app/page.tsx"
+language: javascript
+---
+
+
+
+```javascript
+import { auth0 } from "@/lib/auth0";
+import './globals.css';
+
+export default async function Home() {
+  // Fetch the user session
+  const session = await auth0.getSession();
+
+  // If no session, show sign-up and login buttons
+  if (!session) {
+    return (
+      
        
+        
+          
+        
+        
+          
+        
+      
        
+    );
+  }
+
+  // If session exists, show a welcome message and logout button
+  return (
+    
        
+      
        Welcome, {session.user.name}!
        
+      
        
+        
+          
+        
+      
        
+    
        
+  );
+}
+```
diff --git a/articles/quickstart/webapp/nextjs/files/profile-client.md b/articles/quickstart/webapp/nextjs/files/profile-client.md
new file mode 100644
index 0000000000..a4ae7102fe
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/profile-server.md b/articles/quickstart/webapp/nextjs/files/profile-server.md
new file mode 100644
index 0000000000..1f164c403a
--- /dev/null
+++ b/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/articles/quickstart/webapp/nextjs/files/src/app/page.md b/articles/quickstart/webapp/nextjs/files/src/app/page.md
new file mode 100644
index 0000000000..c623d584a1
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/src/app/page.md
@@ -0,0 +1,40 @@
+---
+name: src/app/page.tsx
+language: javascript
+---
+    
+```javascript
+import { auth0 } from "@/lib/auth0";
+import './globals.css';
+
+export default async function Home() {
+  // Fetch the user session
+  const session = await auth0.getSession();
+
+  // If no session, show sign-up and login buttons
+  if (!session) {
+    return (
+      
        
+        
+          
+        
+        
+          
+        
+      
        
+    );
+  }
+
+  // If session exists, show a welcome message and logout button
+  return (
+    
        
+      
        Welcome, {session.user.name}!
        
+      
        
+        
+          
+        
+      
        
+    
        
+  );
+}
+```
diff --git a/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md b/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
new file mode 100644
index 0000000000..d6a24d5995
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
@@ -0,0 +1,10 @@
+---
+name: src/lib/auth0.ts
+language: javascript
+---
+    
+```javascript
+import { Auth0Client } from "@auth0/nextjs-auth0/server";
+
+export const auth0 = new Auth0Client();
+```
diff --git a/articles/quickstart/webapp/nextjs/files/src/middleware.md b/articles/quickstart/webapp/nextjs/files/src/middleware.md
new file mode 100644
index 0000000000..cac77eaa10
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/files/src/middleware.md
@@ -0,0 +1,25 @@
+---
+name: src/middleware.ts
+language: javascript
+---
+    
+```javascript
+import type { NextRequest } from "next/server";
+import { auth0 } from "./lib/auth0";
+
+export async function middleware(request: NextRequest) {
+  return await auth0.middleware(request);
+}
+
+export const config = {
+  matcher: [
+    /*
+     * Match all request paths except for the ones starting with:
+     * - _next/static (static files)
+     * - _next/image (image optimization files)
+     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
+     */
+    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
+  ],
+};
+```
diff --git a/articles/quickstart/webapp/nextjs/index.yml b/articles/quickstart/webapp/nextjs/index.yml
new file mode 100644
index 0000000000..2fc7d9d1fc
--- /dev/null
+++ b/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 15.2.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/articles/quickstart/webapp/nextjs/interactive.md b/articles/quickstart/webapp/nextjs/interactive.md
new file mode 100644
index 0000000000..12be362c62
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,59 @@
+---
+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 v4 SDK (Beta).
+interactive:  true
+files:
+ - files/.env
+ - files/src/lib/auth0
+ - files/src/middleware
+ - files/src/app/page
+github:
+  path: Sample-01
+locale: en-US
+---
+
+# 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 v4 SDK. We recommend that you log in to follow this quickstart with examples configured for your account.
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:3000/auth/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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Install the Auth0 Next.js v4 SDK
+
+
+
        Run the following command within your project directory to install the Auth0 Next.js SDK:
        npm i @auth0/nextjs-auth0
        The SDK exposes methods and variables that help you integrate Auth0 with your Next.js application using Route Handlers on the backend and React Context with React Hooks 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:
        • 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.
        • APP_BASE_URL: The base URL of your application.
        • AUTH0_DOMAIN: The URL of your Auth0 tenant domain. If you are using a Custom Domain with Auth0, 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.
        
+
+## Create the Auth0 SDK Client {{{ data-action="code" data-code="src/lib/auth0.ts" }}}
+
+
+
        Create a file at src/lib/auth0.ts. This file provides methods for handling authentication, sessions and user data.
        Then, import the Auth0Client class from the SDK to create an instance and export it as auth0. This instance is used in your app to interact with Auth0.
        
+
+## Add the Authentication Middleware {{{ data-action="code" data-code="src/middleware.ts" }}}
+
+
+
        The Next.js Middleware allows you to run code before a request is completed.
        Create a file at src/middleware.ts. This file is used to enforce authentication on specific routes.
        The middleware function intercepts incoming requests and applies Auth0's authentication logic. The matcher configuration ensures that the middleware runs on all routes except for static files and metadata.
        
+
+## Add the Landing Page Content {{{ data-action="code" data-code="src/app/page.tsx" }}}
+
+
+
        The Landing page src/app/page.tsx is where users interact with your app. It displays different content based on whether the users is logged in or not.
        Edit the file src/app/page.tsx to add the auth0.getSession() method to determine if the user is logged in by retrieving the user session.
        If there is no user session, the method returns null and the app displays the Sign up or Log in buttons. If a user sessions exists, the app displays a welcome message with the user's name and a Log out button.
        The Logout functionality is already included in the file src/app/page.tsx. When the user selects the Log out button, they are redirected to the Auth0 logout endpoint, which clears their session and redirects back to your app.
        
+
+## Run Your Application
+
+
+
        Run this command to start your Next.js development server:
        npm run dev
        Visit the url http://localhost:3000 in your browser.
        You will see:
        • A Sign up and Log in button if the user is not authenticated.
        • A welcome message and a Log out button if the user is authenticated.
        Checkpoint 
        Run Your application.
        • Verify that your Next.js 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 back to your application.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/nginx-plus/01-login.md b/articles/quickstart/webapp/nginx-plus/01-login.md
new file mode 100644
index 0000000000..7d8be88335
--- /dev/null
+++ b/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** 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 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. 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/articles/quickstart/webapp/nginx-plus/files/frontend.md b/articles/quickstart/webapp/nginx-plus/files/frontend.md
new file mode 100644
index 0000000000..20c215f56b
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/files/frontend.md
@@ -0,0 +1,34 @@
+---
+name: frontend.conf
+language: 
+---
+    
+```
+# auth_jwt_claim_set $claim_name https://namespace/key;
+
+server {
+    include conf.d/openid_connect.server_conf; # Authorization code flow and Relying Party processing
+    error_log /var/log/nginx/error.log debug;  # Reduce severity level as required
+
+    listen 8010; # Use SSL/TLS in production
+
+    location / {
+        # This site is protected with OpenID Connect
+        auth_jwt "" token=$session_jwt;
+        error_page 401 = @do_oidc_flow;
+
+        #auth_jwt_key_file $oidc_jwt_keyfile; # Enable when using filename
+        auth_jwt_key_request /_jwks_uri; # Enable when using URL
+
+        # Successfully authenticated users are proxied to the backend,
+        # with 'sub' claim passed as HTTP header
+        proxy_set_header username $jwt_claim_sub;
+        proxy_set_header x-email $jwt_claim_email;
+        #proxy_set_header x-custom $claim_name;             # namespaced claim
+
+        proxy_pass http://my_backend; # The backend site/app
+
+        access_log /var/log/nginx/access.log main_jwt;
+    }
+}
+```
diff --git a/articles/quickstart/webapp/nginx-plus/files/nginx.md b/articles/quickstart/webapp/nginx-plus/files/nginx.md
new file mode 100644
index 0000000000..e3f7cac534
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/files/nginx.md
@@ -0,0 +1,10 @@
+---
+name: nginx.conf
+language: 
+---
+    
+```
+...
+load_module modules/ngx_http_js_module.so;
+...
+```
diff --git a/articles/quickstart/webapp/nginx-plus/files/openid_connect.md b/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
new file mode 100644
index 0000000000..3e1a926164
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
@@ -0,0 +1,22 @@
+---
+name: openid_connect.server_conf
+language: 
+---
+    
+```
+location = /_jwks_uri {
+    internal;
+    ...
+    proxy_set_header    Content-Length "";           
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+
+location = /_token {
+    internal;
+    ...
+    proxy_set_header    Content-Type "application/x-www-form-urlencoded";
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+```
diff --git a/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md b/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
new file mode 100644
index 0000000000..429c0e2605
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
@@ -0,0 +1,10 @@
+---
+name: openid_connection_configuration.conf
+language: 
+---
+    
+```
+map $host $oidc_logout_redirect {
+    default "https://${account.namespace}/v2/logout";
+}
+```
diff --git a/articles/quickstart/webapp/nginx-plus/index.yml b/articles/quickstart/webapp/nginx-plus/index.yml
new file mode 100644
index 0000000000..d93f2ed067
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/index.yml
@@ -0,0 +1,24 @@
+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
+hidden_articles:
+  - interactive
+contentType: tutorial
+useCase: quickstart
diff --git a/articles/quickstart/webapp/nginx-plus/interactive.md b/articles/quickstart/webapp/nginx-plus/interactive.md
new file mode 100644
index 0000000000..21f5b36f6e
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,73 @@
+---
+title: NGINX Plus
+description: This tutorial demonstrates how to use the nginx-openid-connect module to add authentication and authorization to your NGINX server.
+interactive:  true
+files:
+ - files/nginx
+ - files/openid_connection_configuration
+ - files/openid_connect
+ - files/frontend
+locale: en-US
+---
+
+# NGINX Plus
+
+
+
        This tutorial demonstrates how to use the nginx-openid-connect module to add authentication and authorization to your NGINX server. We recommend that you log in to follow this quickstart with examples configured for your account.
        System requirements
        This tutorial and seed project have been tested with the following:
        • NGINX Plus R24
        
+
+## Install and enable nginx-plus-module-njs module {{{ data-action="code" data-code="nginx.conf" }}}
+
+
+
        First, you need to install the nginx-plus-module-njs module for NGINX Plus.
        Follow the dynamic module installation guide to install packages in your host OS.
        For Linux distributions that use yum package manager, you can install the module like so:
        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:
        load_module modules/ngx_http_js_module.so;
+
+
        
+
+## Checkout nginx-openid-connect template repository
+
+
+
        Clone the nginx-openid-connect repository. This repository comes with a template configuration.
        git clone https://github.com/nginxinc/nginx-openid-connect
        
+
+## Configure NGINX with your Auth0 application details {{{ data-action="code" data-code="openid_connection_configuration.conf" }}}
+
+
+
        Run the configure.sh script inside the nginx-openid-connect folder to populate the template configuration for your Auth0 application:
        ./configure.sh --auth_jwt_key request \
+
+  --client_id ${account.clientId} \
+
+  --pkce_enable \
+
+  https://${account.namespace}/.well-known/openid-configuration
+
+
        
+
+
        Next, add your tenant’s logout URL to your openid_connect_configuration.conf file.
        
+
+## Configure Accept-Encoding header for token and JWKS endpoints {{{ data-action="code" data-code="openid_connect.server_conf" }}}
+
+
+
        Add the Accept-Encoding header and set the value to gzip in your openid_connect.server_conf file.
        
+
+## Copy OpenID Connect configuration files
+
+
+
        Copy your four configuration files to the conf.d folder.
        sudo cp openid_connect.js \ 
+
+   frontend.conf \
+
+   openid_connect_configuration.conf \
+
+   openid_connect.server_conf /etc/nginx/conf.d
+
+
        
+
+
        
+
+## Configure Auth0 application settings
+
+
+
        In the Auth0 Dashboard:
        1. Go to Applications > Applications, and then select your application from the list.
        2. Switch to the Settings view.
        3. In the Application URIs section, add https://${account.namespace}/_codexch to Allowed Callback URLs.
        4. Switch to the Credentials view.
        In the Application Authentication section, set Authentication Method to None.
        
+
+## Pass headers to upstream application {{{ data-action="code" data-code="frontend.conf" }}}
+
+
+
        Add additional headers from the ID token (JWT) to the upstream target in your /etc/nginx/conf.d/frontend.conf file.
        
diff --git a/articles/quickstart/webapp/nodejs/01-login.md b/articles/quickstart/webapp/nodejs/01-login.md
deleted file mode 100644
index d3924573c2..0000000000
--- a/articles/quickstart/webapp/nodejs/01-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to add authentication to a Node.js and Express web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '01-Login',
-  requirements: [
-    'NodeJS 4.3 or higher',
-    'Express 4.16'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Node.js', callback: 'http://localhost:3000/callback' }) %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/quickstart/webapp/nodejs/02-user-profile.md b/articles/quickstart/webapp/nodejs/02-user-profile.md
deleted file mode 100644
index a5a72ba952..0000000000
--- a/articles/quickstart/webapp/nodejs/02-user-profile.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch and update user profile information
-budicon: 292
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '02-User-Profile',
-  requirements: [
-    'NodeJS 4.3 or higher',
-    'Express 4.16'
-  ]
-}) %>
-
-## User Profile
-
-After the user has authenticated, every express request has a `user` object with the entire user profile. 
-By default, it is a minimal profile. Add the `profile` scope to the authentication scopes to get additional profile information. 
-
-Add the `openid profile` value to the `scope` parameter in the `/login` route. 
-
-```js
-// routes/index.js
-
-router.get(
-  '/login',
-  passport.authenticate('auth0', {
-    clientID: env.AUTH0_CLIENT_ID,
-    domain: env.AUTH0_DOMAIN,
-    redirectUri: env.AUTH0_CALLBACK_URL,
-    audience: 'https://' + env.AUTH0_DOMAIN + '/userinfo',
-    responseType: 'code',
-    scope: 'openid profile'
-  }),
-  function(req, res) {
-    res.redirect('/');
-  }
-);
-
-```
-
-## Show the User Profile
-
-Modify the `/user` endpoint to display the user object. Update the `views/user.pug` template.
-
-```pug
-// views/user.pug
-
-extends layout
-
-block content
-  img(src=user.picture)
-  h2 Welcome #{user.nickname}!
-  br
-  h2 User Profile
-  pre #{userProfile}
-  br
-  a(href='/logout') Logout
-```
-
-To have full access to the user profile on  `userProfile`, stringify the `user` object. Modify the `/` endpoint in `routes/user.js` to include `userProfile`.
-
-```js
-// routes/user.js
-
-// Get the user profile
-router.get('/', ensureLoggedIn, function(req, res, next) {
-  res.render('user', {
-    user: req.user,
-    userProfile: JSON.stringify(req.user, null, '  ')
-  });
-});
-
-```
-
-You can now present a basic user profile.
diff --git a/articles/quickstart/webapp/nodejs/_includes/_login.md b/articles/quickstart/webapp/nodejs/_includes/_login.md
deleted file mode 100644
index 2d8f80ee3c..0000000000
--- a/articles/quickstart/webapp/nodejs/_includes/_login.md
+++ /dev/null
@@ -1,123 +0,0 @@
-## Install the Middleware Dependencies
-
-Install the necessary middleware.
-
-```bash
-# installation with npm
-npm install passport passport-auth0 connect-ensure-login --save
-
-# installation with yarn
-yarn add passport passport-auth0 connect-ensure-login
-```
-
-## Configure the Middleware
-
-Create a new instance of the `Auth0Strategy` strategy. 
-Enter your Auth0 application details as configuration values. Tell `passport` to use this strategy. 
-
-```js
-// app.js
-
-const passport = require('passport');
-const Auth0Strategy = require('passport-auth0');
-
-// Configure Passport to use Auth0
-const strategy = new Auth0Strategy(
-  {
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    clientSecret: 'YOUR_CLIENT_SECRET',
-    callbackURL: 'http://localhost:3000/callback'
-  },
-  (accessToken, refreshToken, extraParams, profile, done) => {
-    return done(null, profile);
-  }
-);
-
-passport.use(strategy);
-
-// This can be used to keep a smaller payload
-passport.serializeUser(function(user, done) {
-  done(null, user);
-});
-
-passport.deserializeUser(function(user, done) {
-  done(null, user);
-});
-
-// ...
-app.use(passport.initialize());
-app.use(passport.session());
-
-```
-
-## Trigger Authentication
-
-[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.
-
-::: note
-You can also embed the login dialog directly in your application using the [Lock widget](/lock). If you use this method, some features, such as single sign-on, will not be accessible. 
-To learn how to embed the Lock widget in your application, follow the [Embedded Login sample](https://github.com/auth0-samples/auth0-nodejs-webapp-sample/tree/embedded-login/01-Embedded-Login).
-:::
-
-Add a route called `/login`. Use the `env` object to set the following properties for your application: 
-* Client ID
-* Domain
-* Callback URL
-
-The route creates an instance of the `auth0.WebAuth` object. Then, the route calls the `authorize` method and redirects the user to the login page.
-
-```js
-// routes/index.js
-
-const express = require('express');
-const passport = require('passport');
-const router = express.Router();
-
-const env = {
-  AUTH0_CLIENT_ID: '${account.clientId}',
-  AUTH0_DOMAIN: '${account.namespace}',
-  AUTH0_CALLBACK_URL: 'http://localhost:3000/callback'
-};
-
-/* GET home page. */
-router.get('/', function(req, res, next) {
-  res.render('index');
-});
-
-// Perform the login
-router.get(
-  '/login',
-  passport.authenticate('auth0', {
-    clientID: env.AUTH0_CLIENT_ID,
-    domain: env.AUTH0_DOMAIN,
-    redirectUri: env.AUTH0_CALLBACK_URL,
-    audience: 'https://' + env.AUTH0_DOMAIN + '/userinfo',
-    responseType: 'code',
-    scope: 'openid'
-  }),
-  function(req, res) {
-    res.redirect('/');
-  }
-);
-
-// Perform session logout and redirect to homepage
-router.get('/logout', (req, res) => {
-  req.logout();
-  res.redirect('/');
-});
-
-// Perform the final stage of authentication and redirect to '/user'
-router.get(
-  '/callback',
-  passport.authenticate('auth0', {
-    failureRedirect: '/'
-  }),
-  function(req, res) {
-    res.redirect(req.session.returnTo || '/user');
-  }
-);
-
-```
-
-![hosted login](/media/articles/web/hosted-login.png)
diff --git a/articles/quickstart/webapp/nodejs/index.yml b/articles/quickstart/webapp/nodejs/index.yml
deleted file mode 100644
index 8f3e5abacd..0000000000
--- a/articles/quickstart/webapp/nodejs/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: Node.js
-image: /media/platforms/node.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/nodejs/dependencies
-  setup: server-platforms/nodejs/setup
-  use: server-platforms/nodejs/use
-alias:
-  - node
-  - express
-  - node-connect
-  - passport
-seo_alias: nodejs
-default_article: 01-login
-articles:
-  - 01-login
-  - 02-user-profile
diff --git a/articles/quickstart/webapp/php/01-login.md b/articles/quickstart/webapp/php/01-login.md
index 5a840100b9..a9fcff579a 100644
--- a/articles/quickstart/webapp/php/01-login.md
+++ b/articles/quickstart/webapp/php/01-login.md
@@ -1,138 +1,216 @@
 ---
 title: Login
 default: true
-description: This tutorial demonstrates how to use the Auth0 PHP SDK to add authentication and authorization to your web app
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-php-web-app',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Apache 2.4.4',
-    'PHP 5.6.14 and up',
-    'Auth0-PHP 5.0 and up'
-  ]
-}) %>
+<%= include('../_includes/_getting_started', { library: 'PHP', callback: 'http://127.0.0.1:3000/' }) %>
 
-<%= include('../_includes/_getting_started', { library: 'PHP', callback: 'http://localhost:3000/' }) %>
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://127.0.0.1:3000' }) %>
 
-## Add the Dependencies
+## Integrate your PHP application
 
-${snippet(meta.snippets.dependencies)}
+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 for a more robust example.
 
-::: note
-This sample uses [Composer](https://getcomposer.org/doc/00-intro.md), a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs. Then, it installs them in your project.
-:::
+### Installing HTTP Client and Messaging Factories
 
-## Configure Auth0 PHP SDK
+The Auth0 PHP SDK supports many PHP-FIG standards offering interoperability options with your architecture. Two of particular importance are PSR-17 and 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.
 
-Configure the Auth0 PHP SDK for each page that will use it.
+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. 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
-// index.php
-
-use Auth0\SDK\Auth0;
-
-$auth0 = new Auth0([
-  'domain' => '${account.namespace}',
-  'client_id' => '${account.clientId}',
-  'client_secret' => 'YOUR_CLIENT_SECRET',
-  'redirect_uri' => '${account.callback}',
-  'audience' => 'https://${account.namespace}/userinfo',
-  'scope' => 'openid profile',
-  'persist_id_token' => true,
-  'persist_access_token' => true,
-  'persist_refresh_token' => true,
+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']
 ]);
 ```
 
-## Add the Auth0 Callback Handler
+### Setting up your application routes
 
-Call `$auth0->getUser()` to retrieve user information. If you call it from the page that handles the callback, it will use the code provided by Auth0 to get the information after the successful login.
+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.
 
-```php
-// index.php
-
-...
-$userInfo = $auth0->getUser();
-
-if (!$userInfo) {
-    // We have no user info
-    // redirect to Login
-} else {
-    // User is authenticated
-    // Say hello to $userInfo['name']
-    // print logout button
-}
+From our project directory, let's run the following shell command to install the routing library:
+
+```sh
+composer require steampixel/simple-php-router
 ```
 
-The user's information is stored in the session. Each time you call `getUser()`, it retrieves the information from the session.
+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:
 
-## Trigger Login with the Auth0 PHP SDK
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
 
-```html
-
+// 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');
 ```
 
-```php
-// login.php
+Now we can move on to adding our application's route handling logic, and the SDK integrations:
 
-login();
+## 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.
        ';
+});
 ```
 
-::: note
-The `redirect_uri` specified in the `Auth0` constructor must match the URL specified in the [ Add the Auth0 Callback Handler](#add-the-auth0-callback-handler) step.
-:::
+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->usernickname`, or their email address from `$session->useremail`. The structure is a normalized user profile, which you can learn more about here.
 
-## Access User Information
+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:
 
-You can access user information with the `getUser` method from Auth0.
+```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';
+```
 
-```php
-getUser();
-?>
-
-  
-    
        
-  
-
+## 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;
+});
 ```
 
-To learn about all the available properties from the user's profile, read the [user profile](/user-profile) documentation. 
+## Handling authentication callback
 
-::: note
-Some of the user profile properties depend on the social provider you use.
-:::
+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.
 
-### Optional: Configure session data
+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:
 
-By default, the SDK stores user information in the PHP session and discards the access and ID Tokens. 
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
 
-To keep the tokens, to the SDK configuration, pass the following:
-* `'persist_access_token' => true`
-* `'persist_id_token' => true`
+Route::add('/callback', function() use ($auth0) {
+    // Have the SDK complete the authentication flow:
+    $auth0->exchange(ROUTE_URL_CALLBACK);
 
-To disable the session, pass `'store' => false` to the SDK configuration.
+    // Finally, redirect our end user back to the / index route, to display their user profile:
+    header("Location: " . ROUTE_URL_INDEX);
+    exit;
+});
+```
 
-Instead of using the PHP session to store information, you can use Laravel, Zend, Symfony or similar techniques. To do that, create a class that implements the get, set and delete methods and pass it to the SDK.
+## Logging out
 
-```php
-// index.php
-
-$laravelStore = new MyLaravelStore();
-$auth0 = new Auth0(array(
-    // ...
-    'store' => $laravelStore,
-    // ...
-));
+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 (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/articles/quickstart/webapp/php/download.md b/articles/quickstart/webapp/php/download.md
new file mode 100644
index 0000000000..c4da3162ad
--- /dev/null
+++ b/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 to:
+
+```text
+http://127.0.0.1:3000/callback
+```
+
+2. Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://127.0.0.1:3000/logout
+```
+
+3. Make sure PHP and Composer are installed and execute the following commands in the sample's directory:
+
+```bash
+composer run app
+```
+
+You can also run it from Docker with the following commands:
+
+```bash
+composer run docker
+```
diff --git a/articles/quickstart/webapp/php/files/callback.md b/articles/quickstart/webapp/php/files/callback.md
new file mode 100644
index 0000000000..d6d8f81048
--- /dev/null
+++ b/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/articles/quickstart/webapp/php/files/index.md b/articles/quickstart/webapp/php/files/index.md
new file mode 100644
index 0000000000..da33ff8012
--- /dev/null
+++ b/articles/quickstart/webapp/php/files/index.md
@@ -0,0 +1,27 @@
+---
+name: index.php
+language: php
+---
+    
+```php
+login()));
+```
diff --git a/articles/quickstart/webapp/php/files/logout.md b/articles/quickstart/webapp/php/files/logout.md
new file mode 100644
index 0000000000..cd4e6a9608
--- /dev/null
+++ b/articles/quickstart/webapp/php/files/logout.md
@@ -0,0 +1,18 @@
+---
+name: logout.php
+language: php
+---
+    
+```php
+logout()));
+```
diff --git a/articles/quickstart/webapp/php/files/profile.md b/articles/quickstart/webapp/php/files/profile.md
new file mode 100644
index 0000000000..fc2fbda6e1
--- /dev/null
+++ b/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/articles/quickstart/webapp/php/files/router.md b/articles/quickstart/webapp/php/files/router.md
new file mode 100644
index 0000000000..35740dafe5
--- /dev/null
+++ b/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/articles/quickstart/webapp/php/index.yml b/articles/quickstart/webapp/php/index.yml
index d3477da97b..2613a515a4 100644
--- a/articles/quickstart/webapp/php/index.yml
+++ b/articles/quickstart/webapp/php/index.yml
@@ -1,12 +1,53 @@
 title: PHP
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/php.png
-tags:
+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:
-  dependencies: server-platforms/php/dependencies
-  setup: server-platforms/php/setup
-  use: server-platforms/php/use
-seo_alias: php
+  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/articles/quickstart/webapp/php/interactive.md b/articles/quickstart/webapp/php/interactive.md
new file mode 100644
index 0000000000..b24126c7d2
--- /dev/null
+++ b/articles/quickstart/webapp/php/interactive.md
@@ -0,0 +1,88 @@
+---
+title: Add Login to Your PHP Application
+description: This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any 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
+locale: en-US
+---
+
+# 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
+
+
+
        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.
        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.
        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.
        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 (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps.
        The Auth0 PHP SDK requires PSR-17 and 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:
        cd <your-project-directory>
+
+composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        Now install the Auth0 PHP SDK by running the following command in your terminal:
        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, 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.
        PHP Step 2 Checkpoint 
        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.
        
+
+  
        
+
+  
        
+
+  
        
+
+## 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.
        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.
        Php step 4 checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        • You configured the correct redirectUri.
        Still having issues? Check out our documentation or visit our community page 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 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.
        PHP Section 5 Checkpoint 
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        • You configured the correct Logout URL.
        Still having issues? Check out our documentation or visit our community page 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 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.
        Php section 6 Checkpoint 
        Verify that:
        • You can display the nickname or any other user property correctly after you have logged in.
        
+
+  
        
+
+  
        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 or visit our community page to get more help.
        
+
+  
        
diff --git a/articles/quickstart/webapp/python/01-login.md b/articles/quickstart/webapp/python/01-login.md
index 53d5465803..63d9cca243 100644
--- a/articles/quickstart/webapp/python/01-login.md
+++ b/articles/quickstart/webapp/python/01-login.md
@@ -1,208 +1,219 @@
 ---
 title: Login
 default: true
-description: This tutorial demonstrates how to add authentication and authorization to a Python Web Application built with the Flask framework.
+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' }) %>
 
-You can get started by either downloading the complete sample or following the tutorial steps to integrate Auth0 with an existing application.
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-python-web-app',
-  path: '01-Login',
-   requirements: [
-    'Python 2.7, 3.0 and up',
-    'Flask 0.10.1 and up',
-    'Python-dotenv 0.6.5 and up',
-    'Requests 2.3.0 and up',
-    'Authlib 0.6',
-    'Six 1.10.0 and up'
-  ]
-}) %>
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
 
-<%= include('../_includes/_getting_started', { library: 'Python', callback: 'http://localhost:3000/callback' }) %>
+## Install dependencies
+
+For the purposes of this example, we'll be using the Authlib OAuth library and Flask.
 
-## Add the Dependencies
+Begin by creating a `requirements.txt` file in your project directory:
 
-This example uses [Flask](http://flask.pocoo.org) and the [Authlib](https://github.com/lepture/authlib) OAuth library.
+```python
+# 📁 requirements.txt -----
+
+flask>=2.0.3
+python-dotenv>=0.19.2
+authlib>=1.0
+requests>=2.27.1
+```
 
-Add the following dependencies to your `requirements.txt` and run `pip install -r requirements.txt`.
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
 
-```js
-// /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=
 
-flask
-python-dotenv
-requests
-authlib
-six
 ```
 
-## Initialize Authlib
+- 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.
 
-Create a file named `server.py`, and instantiate an application with your client keys, scopes, and OAuth endpoints.
+Begin by importing all the libraries your application will be making use of:
 
 ```python
-# /server.py
-    
-from functools import wraps
+# 📁 server.py -----
+
 import json
 from os import environ as env
-from werkzeug.exceptions import HTTPException
-
-from dotenv import load_dotenv, find_dotenv
-from flask import Flask
-from flask import jsonify
-from flask import redirect
-from flask import render_template
-from flask import session
-from flask import url_for
-from authlib.flask.client import OAuth
-from six.moves.urllib.parse import urlencode
-import requests
-    
-app = Flask(__name__)
+from urllib.parse import quote_plus, urlencode
 
-oauth = OAuth(app)
-
-auth0 = oauth.register(
-    'auth0',
-    client_id='${account.clientId}',
-    client_secret='YOUR_CLIENT_SECRET',
-    api_base_url='https://${account.namespace}',
-    access_token_url='https://${account.namespace}/oauth/token',
-    authorize_url='https://${account.namespace}/authorize',
-    client_kwargs={
-        'scope': 'openid profile',
-    },
-)
+from authlib.integrations.flask_client import OAuth
+from dotenv import find_dotenv, load_dotenv
+from flask import Flask, redirect, render_template, session, url_for
 ```
 
-## Add the Auth0 Callback Handler
+Next, your application will need to load the configuration `.env` file you made in the previous step:
 
-This handler exchanges the `code` that Auth0 sends to the callback URL for an `access_token` and an `id_token`.
+```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)
+```
 
-The `access_token` will be used to call the `/userinfo` endpoint to get the user profile. After the user information is obtained, store then in the flask `session`.
+Now you can configure Flask for your application's needs:
 
 ```python
-# /server.py
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-# Here we're using the /callback route.
-@app.route('/callback')
-def callback_handling():
-    # Handles response from token endpoint
-    resp = auth0.authorize_access_token()
+app = Flask(__name__)
+app.secret_key = env.get("APP_SECRET_KEY")
+```
 
-    url = 'https://${account.namespace}/userinfo'
-    headers = {'authorization': 'Bearer ' + resp['access_token']}
-    resp = requests.get(url, headers=headers)
-    userinfo = resp.json()
+Finally, you can now configure Authlib to handle your application's authentication with Auth0:
 
-    # Store the tue user information in flask session.
-    session['jwt_payload'] = userinfo
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-    session['profile'] = {
-        'user_id': userinfo['sub'],
-        'name': userinfo['name'],
-        'picture': userinfo['picture']
-    }
+oauth = OAuth(app)
 
-    return redirect('/dashboard')
+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'
+)
 ```
 
-## Trigger Authentication
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from their documentation.
+
+## Setup your routes
 
-Add a `/login` route that uses the `Authlib` client instance to redirect the user to the [login page](/hosted-pages/login).
+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
-# /server.py
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-@app.route('/login')
+@app.route("/login")
 def login():
-    return auth0.authorize_redirect(redirect_uri='YOUR_CALLBACK_URL', audience='https://${account.namespace}/userinfo')
+    return oauth.auth0.authorize_redirect(
+        redirect_uri=url_for("callback", _external=True)
+    )
 ```
 
-Create a `home.html` file in a `/template` folder. Add a link to the `/login` route.
+### 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.
 
-```html
-
-```
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-## Logout
+@app.route("/callback", methods=["GET", "POST"])
+def callback():
+    token = oauth.auth0.authorize_access_token()
+    session["user"] = token
+    return redirect("/")
+```
 
-To log the user out, you have to clear the data from the session, and redirect the user to the Auth0 logout endpoint. You can find more information about this in [our logout documentation](/logout).
+### 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
-# /server.py
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-@app.route('/logout')
+@app.route("/logout")
 def logout():
-    # Clear session stored data
     session.clear()
-    # Redirect user to logout endpoint
-    params = {'returnTo': url_for('home', _external=True), 'client_id': '${account.clientId}'}
-    return redirect(auth0.base_url + '/v2/logout?' + urlencode(params))
+    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,
+        )
+    )
 ```
 
-::: note
-Please take into consideration that the return to URL needs to be in the list of Allowed Logout URLs in the settings section of the application as explained in [our documentation](/logout#redirect-users-after-logout)
-:::
+### 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.
 
-## Check if the user is authenticated
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
 
-Add the following decorator to your `Flask` app. Use it to decorate methods that require authentication.
+@app.route("/")
+def home():
+    return render_template("home.html", session=session.get('user'), pretty=json.dumps(session.get('user'), indent=4))
+```
 
-::: note
-You should import `wraps` first, adding the following line to your `server.py` file: `from functools import wraps`.
-:::
+### Server instantiation
+Finally, you'll need to add some small boilerplate code for Flask to actually run your app and listen for connections.
 
 ```python
-# /server.py
-
-def requires_auth(f):
-  @wraps(f)
-  def decorated(*args, **kwargs):
-    if 'profile' not in session:
-      # Redirect to Login page here
-      return redirect('/')
-    return f(*args, **kwargs)
-    
-  return decorated
+# 👆 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))
 ```
 
-## Showing the User Profile
+## Add templates
 
-Add a `/dashboard` route to `server.py` that will render the user information stored in the Flask session.
+Now we just need to create the simple template files used in the routes about (during `render_template()` calls).
 
-Decorate it with `@requires_auth`. It will only be accessible if the user has been authenticated.
+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:
 
-```python
-# /server.py
-
-@app.route('/dashboard')
-@requires_auth
-def dashboard():
-    return render_template('dashboard.html',
-                           userinfo=session['profile'],
-                           userinfo_pretty=json.dumps(session['jwt_payload'], indent=4))
+```html
+# 📁 templates/home.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+        
        Welcome {{session.userinfo.name}}!
        
+        
        Logout
        
+        
        {{pretty}}
        
+    {% else %}
+        
        Welcome Guest
        
+        
        Login
        
+    {% endif %}
+  
+
 ```
 
-Add a `dashboard.html` file in a `/template` folder to display the user information.
+## Run your application
 
-Add a link to allow users to Log Out.
+You're ready to run your application! From your project directory, open a shell and use:
 
-```html
-
        
-    
        
-    
-    
        Welcome {{userinfo['name']}}
        
-    
        {{userinfo_pretty}}
        
-    Logout
-
        
+```sh
+python3 server.py
 ```
+
+Your application should now be ready to open from your browser at http://localhost:3000.
diff --git a/articles/quickstart/webapp/python/download.md b/articles/quickstart/webapp/python/download.md
new file mode 100644
index 0000000000..31aac47d7a
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+```text
+http://localhost:3000
+```
+
+3) Make sure Python 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 image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/python/files/home.md b/articles/quickstart/webapp/python/files/home.md
new file mode 100644
index 0000000000..8a0f7e8dc5
--- /dev/null
+++ b/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/articles/quickstart/webapp/python/files/server.md b/articles/quickstart/webapp/python/files/server.md
new file mode 100644
index 0000000000..194c279e61
--- /dev/null
+++ b/articles/quickstart/webapp/python/files/server.md
@@ -0,0 +1,67 @@
+---
+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/articles/quickstart/webapp/python/files/templates/home.md b/articles/quickstart/webapp/python/files/templates/home.md
new file mode 100644
index 0000000000..d543f58b29
--- /dev/null
+++ b/articles/quickstart/webapp/python/files/templates/home.md
@@ -0,0 +1,23 @@
+---
+name: templates/home.html
+language: markup
+---
+    
+```markup
+
+
+  
+  Auth0 Example
+
+
+  {% if session %}
+      
        Welcome {{session.userinfo.name}}!
        
+      
        Logout
        
+      
        {{pretty}}
        
+  {% else %}
+    
        Welcome Guest
        
+    
        Login
        
+  {% endif %}
+
+
+```
diff --git a/articles/quickstart/webapp/python/index.yml b/articles/quickstart/webapp/python/index.yml
index a6392a6958..b94c1a9d6d 100644
--- a/articles/quickstart/webapp/python/index.yml
+++ b/articles/quickstart/webapp/python/index.yml
@@ -1,7 +1,15 @@
 title: Python
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/python.png
-tags:
+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
@@ -10,3 +18,33 @@ 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/articles/quickstart/webapp/python/interactive.md b/articles/quickstart/webapp/python/interactive.md
new file mode 100644
index 0000000000..f4718d9568
--- /dev/null
+++ b/articles/quickstart/webapp/python/interactive.md
@@ -0,0 +1,93 @@
+---
+title: Add Login to Your Python Flask Application
+description: This guide demonstrates how to integrate Auth0 with a Python Flask application using the Authlib SDK.
+interactive:  true
+files:
+ - files/server
+ - files/templates/home
+github:
+  path: 01-Login
+locale: en-US
+---
+
+# 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 application using the Authlib SDK.
        
+
+## Configure Auth0
+
+
+
        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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Install dependencies
+
+
+
        Create a requirements.txt file in your project directory:
        # 📁 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:
        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.
        # 📁 .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="templates/home.html" }}}
+
+
+
        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.
        
+
+## Setup your routes {{{ data-action="code" data-code="server.py" }}}
+
+
+
        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
+
+
+
        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:
        python3 server.py
+
+
        
+
+
        Python Step 7 Checkpoint 
        Visit 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.
        
+
+  
        
+
+  
        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 or visit our community page to get more help
        
+
+  
        
diff --git a/articles/quickstart/webapp/rails/01-login.md b/articles/quickstart/webapp/rails/01-login.md
index f072450586..b7bc1e8981 100644
--- a/articles/quickstart/webapp/rails/01-login.md
+++ b/articles/quickstart/webapp/rails/01-login.md
@@ -1,147 +1,165 @@
 ---
 title: Login
-description: Ruby on Rails Login with Auth0
+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/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '01-Login',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
+<%= include('../_includes/_getting_started', { library: 'Rails', callback: 'http://localhost:3000/auth/auth0/callback' }) %>
 
-The first step in adding authentication to your Ruby on Rails 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](/hosted-pages/login).
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
 
-## Create an Application
+## Install the Auth0 SDK
 
-Create a new application in your [Auth0 dashboard](${manage_url}) and retrieve the __Domain__, __Client ID__ and __Client Secret__ for the app. The downloadable samples throughout the quickstart steps will be configured with the credentials for your default application.
+### Install Dependencies
 
-![App Dashboard](/media/articles/server-platforms/rails/app_dashboard.png)
+This tutorial uses `omniauth-auth0`, a custom OmniAuth strategy, to handle the authentication flow.  Add the following dependencies to your `Gemfile`:
 
-<%= include('../../../_includes/_callback_url') %>
-
-${include('../_callbackRegularWebApp')}
-
-In this case, the callbackURL should look something like:
-
-```bash
-https://example.com/auth/oauth2/callback
+```ruby
+gem 'omniauth-auth0', '~> 3.0'
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
 ```
 
-## Install the Dependencies
-
-To follow along with this guide, add the following dependencies to your `Gemfile` and run `bundle install`.
-
-::: note
-If you are using Windows, uncomment the `tzinfo-data` gem in the Gemfile.
-:::
-
-${snippet(meta.snippets.dependencies)}
-
-## Initialize Omniauth Auth0
+Once your gems are added, install the gems with `bundle install`:
 
-Create a file named `auth0.rb` under `config/initializers` and configure the **OmniAuth** middleware in it.
+### Initialize Auth0 Configuration
 
-${snippet(meta.snippets.setup)}
+Create an Auth0 config file `./config/auth0.yml`
 
-::: note
-This tutorial uses omniauth-auth0, a custom [OmniAuth strategy](https://github.com/intridea/omniauth#omniauth-standardized-multi-provider-authentication).
-:::
-
-## Add the Auth0 Callback Handler
+```yaml
+# ./config/auth0.yml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: 
+```
 
-Use the following command to create the controller that will handle the Auth0 callback:
+Create the following initializer file `./config/initializers/auth0.rb` and configure the **OmniAuth** middleware.
 
-```bash
-rails generate controller auth0 callback failure --skip-template-engine --skip-assets
+```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
 ```
 
-In the newly created controller, add a callback success and failure handler.
+### 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
+# ./app/controllers/auth0_controller.rb
 class Auth0Controller < ApplicationController
   def callback
-    # This stores all the user information that came from Auth0
-    # and the IdP
-    session[:userinfo] = request.env['omniauth.auth']
+    # 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
-    # show a failure page or redirect to an error page
+    # 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
 ```
 
-Replace the generated routes on `routes.rb` with the following:
+Add the following routes to your `./config/routes.rb` file:
 
 ```ruby
-get "/auth/oauth2/callback" => "auth0#callback"
-get "/auth/failure" => "auth0#failure"
+# ./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
 ```
 
-## Trigger Login with Omniauth
-
-Create a file called `session_helper.rb`:
+## Add Login to Your Application
+A user can now log into your application by visiting the `/auth/auth0` endpoint.
 
-```ruby
-# app/helpers/session_helper.rb
-
-module SessionHelper
-  def get_state
-    state = SecureRandom.hex(24)
-    session['omniauth.state'] = state
+::: warning
+To prevent forged authentication requests, use the `link_to` or `button_to` helper methods with the `:post` method
+:::
 
-    state
-  end
-end
+```erb
+  
+  ${"<%= button_to 'Login', '/auth/auth0', method: :post, data: \{ turbo: false \} %>"}
 ```
 
-Use the following command to create the controller that will handle user login:
+## Add Logout to Your Application
+Now that you can log in to your Rails application, you need a way to log out. Revisit the Auth0Controller you created earlier, and finish up the logout method added there.
 
-```bash
-rails generate controller home
-```
+You will need to clear out your session and then redirect the user to the Auth0 logout endpoint.
 
-In the controller `home_controller.rb` add the `show` action.
+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.  Add the following code to `./app/controllers/auth0_controller.rb`:
 
 ```ruby
-# app/controllers/home_controller.rb
+# ./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
 
-class HomeController < ApplicationController
-  def show
+  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
 ```
 
-Create a file called `show.html.erb` to add the template for `show` action. Add a link to `/auth/auth0` to trigger user login.
+::: note
+The final destination URL (the `returnTo` value) needs to be in the list of `Allowed Logout URLs` . See the logout documentation for more.
+:::
 
-```html
-
+The user will now be able to logout of your application by visiting the `/auth/logout` endpoint.
 
-
        
-  
        
-  
        RoR Auth0 Sample
        
-  
        Step 1 - Login.
        
-  Login
-
        
+```erb
+  
+  ${"<%= button_to 'Logout', 'auth/logout', method: :get, data: \{ turbo: false \} %>"}
 ```
 
-## Check the User's Authentication Status
-
-You can use a controller `concern` to control access to routes that require the user to be authenticated.
+## 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
-
+# ./app/controllers/concerns/secured.rb
 module Secured
   extend ActiveSupport::Concern
 
@@ -155,100 +173,25 @@ module Secured
 end
 ```
 
-Use the following command to create the controller for the dashboard view:
-
-```bash
-rails generate controller dashboard show --skip-template-engine --skip-assets
-```
-
-Include the `concern` in the newly-created controller to prevent unauthenticated users from accessing its routes:
+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
-
+# ./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
 ```
 
-## Display Error Descriptions
-
-Configure the application to display errors by adding the following to `config/environments/production.rb`:
-
-```ruby
-OmniAuth.config.on_failure = Proc.new { |env|
-  message_key = env['omniauth.error.type']
-  error_description = Rack::Utils.escape(env['omniauth.error'].error_reason)
-  new_path = "#{env['SCRIPT_NAME']}#{OmniAuth.config.path_prefix}/failure?message=#{message_key}&error_description=#{error_description}"
-  Rack::Response.new(['302 Moved'], 302, 'Location' => new_path).finish
-}
-```
-
-## Troubleshooting
-
-### 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 and 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` and add the following:
-
-```ruby
-Rails.application.config.session_store :cache_store
-```
-
-Go to `/config/environments/development.rb` and add the following:
-
-```ruby
-config.cachestore = :memorystore
-```
-
-It is recommended that a memory store such as MemCached 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 -o lib/ca-bundle.crt http://curl.haxx.se/ca/ca-bundle.crt
-```
-
-Add this initializer to `config/initializers/fix_ssl.rb`:
-
-```ruby
-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:
-
+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])%>"}
        
+
        
 ```
-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/articles/quickstart/webapp/rails/02-session-handling.md b/articles/quickstart/webapp/rails/02-session-handling.md
deleted file mode 100644
index 00c283439c..0000000000
--- a/articles/quickstart/webapp/rails/02-session-handling.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Session Handling
-description: Learn how to store user data in your session and clean it up upon logout.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '02-Session-Handling',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## Store Session Data on Login
-
-Upon successful authentication, **OmniAuth** sets the authentication hash of a request to `/auth/oauth2/callback`. To handle this request, add a new route in your routes file.
-
-```ruby
-get "/auth/oauth2/callback" => "auth0#callback"
-```
-
-Store the user information in the session in `auth0_controller/callback`.
-
-```ruby
-# app/controllers/auth0_controller.rb
-
-def callback
-  # This stores all the user information that came from Auth0
-  # and the IdP
-  session[:userinfo] = request.env['omniauth.auth']
-
-  # Redirect to the URL you want after successful auth
-  redirect_to '/dashboard'
-end
-```
-
-## Logout Action
-
-Use the following command to create the controller that will handle user logout:
-
-```bash
-rails generate controller logout
-```
-
-To clear out all the objects stored within the session, call the `reset_session` method within the `logout_controller/logout` method. [Learn more about `reset_session` here](http://api.rubyonrails.org/classes/ActionController/Base.html#M000668).
-
-```ruby
-# app/controllers/logout_controller.rb
-
-class LogoutController < ApplicationController
-  include LogoutHelper
-  def logout
-    reset_session
-    redirect_to logout_url.to_s
-  end
-end
-```
-
-In `logout_helper.rb` file add the methods to generate the logout URL.
-
-```ruby
-# app/helpers/logout_helper.rb
-
-module LogoutHelper
-  def logout_url
-    domain = Rails.application.secrets.auth0_domain
-    client_id = Rails.application.secrets.auth0_client_id
-    request_params = {
-      returnTo: root_url,
-      client_id: client_id
-    }
-
-    URI::HTTPS.build(host: domain, path: '/v2/logout', query: to_query(request_params))
-  end
-
-  private
-
-  def to_query(hash)
-    hash.map { |k, v| "#{k}=#{URI.escape(v)}" unless v.nil? }.reject(&:nil?).join('&')
-  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#redirecting-users-after-logout) for more.
-:::
diff --git a/articles/quickstart/webapp/rails/02-troubleshooting.md b/articles/quickstart/webapp/rails/02-troubleshooting.md
new file mode 100644
index 0000000000..37a2eddf67
--- /dev/null
+++ b/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. 
+
+## 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/articles/quickstart/webapp/rails/03-user-profile.md b/articles/quickstart/webapp/rails/03-user-profile.md
deleted file mode 100644
index e5b552de54..0000000000
--- a/articles/quickstart/webapp/rails/03-user-profile.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: User Profile
-description: Access the user profile information using OmniAuth-Auth0 strategy.
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '03-User-Profile',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## The OmniAuth Auth Hash
-
-After receiving a successful callback at `/auth/oauth2/callback`, the **OmniAuth** strategy provides available user profile information via the `request.env['omniauth.auth']` hash.
-
-::: note
-The full contents of the authentication hash retrieved by the Auth0 strategy are detailed [here](https://github.com/auth0/omniauth-auth0#auth-hash).
-:::
-
-## Retrieve the Auth Hash
-
-In the [login](/quickstart/webapp/rails/01-login) step, you configured the application for **OmniAuth** to start the **OmniAuth-Auth0** strategy and for **OmniAuth** to take over and complete the authentication process. You also set a route that matches the callback URL in the application routes.
-
-```ruby
-get "/auth/oauth2/callback" => "auth0#callback"
-```
-
-The `callback` action in the `auth0` controller retrieves the auth hash and stores it in the application's session hash. It then redirects to the dashboard controller `show` action, which renders the dashboard view.
-
-```ruby
-# app/controllers/auth0_controller
-
-def callback
-  session[:userinfo] = request.env['omniauth.auth']
-
-  redirect_to '/dashboard'
-end
-```
-
-## Display the User Profile Data
-
-The auth hash built by the **OmniAuth** Auth0 strategy has the user profile data under the `info` key. Each element is named according to [the normalized user profile definition](/user-profile/normalized).
-
-The auth hash also contains the full user profile under the `raw` key. The difference is that the normalized user profile data is pre-processed and guaranteed to be present, while the full user profile data may vary depending on several factors, including which social identity provider is used to log the user in.
-
-Add a template which displays the user's profile data.
-
-```html
-
-
        
-  
        
-  
        Welcome, ${ '<%= @user[:info][:name] %>' }
        
-
        
-
        
-  
        
-    
        Normalized User Profile
        
-    
        
-      
        ${ '<%= JSON.pretty_generate(@user[:info]) %>' }
        
-    
        
-  
        
-  
        
-    
        Full User Profile
        
-    
        
-      
        ${ '<%= JSON.pretty_generate(@user[:extra][:raw_info]) %>' }
        
-    
        
-  
        
-
        
-```
-
-Additionally, declare and assign the contents to the `user` variable in the dashboard controller:
-
-```ruby
-# app/controller/dashboard_controller
-
-class DashboardController < ApplicationController
-  include Secured
-  def show
-    @user = session[:userinfo]
-  end
-end
-```
diff --git a/articles/quickstart/webapp/rails/download.md b/articles/quickstart/webapp/rails/download.md
new file mode 100644
index 0000000000..2a4cda9a35
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/auth/auth0/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+ ```text
+http://localhost:3000
+```
+
+3) Make sure Rails 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 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/articles/quickstart/webapp/rails/files/auth0.md b/articles/quickstart/webapp/rails/files/auth0.md
new file mode 100644
index 0000000000..1f2fac9081
--- /dev/null
+++ b/articles/quickstart/webapp/rails/files/auth0.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
+```
diff --git a/articles/quickstart/webapp/rails/files/auth0_controller.md b/articles/quickstart/webapp/rails/files/auth0_controller.md
new file mode 100644
index 0000000000..af8dc0c527
--- /dev/null
+++ b/articles/quickstart/webapp/rails/files/auth0_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/articles/quickstart/webapp/rails/files/concern.md b/articles/quickstart/webapp/rails/files/concern.md
new file mode 100644
index 0000000000..a3782a7023
--- /dev/null
+++ b/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/articles/quickstart/webapp/rails/files/config.md b/articles/quickstart/webapp/rails/files/config.md
new file mode 100644
index 0000000000..b838b819bf
--- /dev/null
+++ b/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/articles/quickstart/webapp/rails/files/config/auth0.md b/articles/quickstart/webapp/rails/files/config/auth0.md
new file mode 100644
index 0000000000..35907e29d2
--- /dev/null
+++ b/articles/quickstart/webapp/rails/files/config/auth0.md
@@ -0,0 +1,11 @@
+---
+name: config/auth0.yml
+language: yaml
+---
+    
+```yaml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: ${account.clientSecret}
+```
diff --git a/articles/quickstart/webapp/rails/files/controller.md b/articles/quickstart/webapp/rails/files/controller.md
new file mode 100644
index 0000000000..610d4a7ab0
--- /dev/null
+++ b/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/articles/quickstart/webapp/rails/files/initializer.md b/articles/quickstart/webapp/rails/files/initializer.md
new file mode 100644
index 0000000000..a1695fdefc
--- /dev/null
+++ b/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/articles/quickstart/webapp/rails/files/routes.md b/articles/quickstart/webapp/rails/files/routes.md
new file mode 100644
index 0000000000..f4b9d7219d
--- /dev/null
+++ b/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
+```
diff --git a/articles/quickstart/webapp/rails/files/secured.md b/articles/quickstart/webapp/rails/files/secured.md
new file mode 100644
index 0000000000..a1f58412c4
--- /dev/null
+++ b/articles/quickstart/webapp/rails/files/secured.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
+```
diff --git a/articles/quickstart/webapp/rails/index.yml b/articles/quickstart/webapp/rails/index.yml
index 3e8bd47292..35e85c2158 100644
--- a/articles/quickstart/webapp/rails/index.yml
+++ b/articles/quickstart/webapp/rails/index.yml
@@ -1,21 +1,53 @@
 title: Ruby On Rails
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
 image: /media/platforms/rails.png
-tags:
+logo: rails
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
   - quickstart
   - ruby
   - rails
   - ruby on rails
-snippets:
-  dependencies: server-platforms/rails/dependencies
-  setup: server-platforms/rails/setup
-  use: server-platforms/rails/use
+contentType: tutorial
+useCase: quickstart
 alias:
   - ruby-rails
   - sinatra
   - omniauth
 seo_alias: rails
 default_article: 01-login
+hidden_articles:
+  - interactive
 articles:
   - 01-login
-  - 02-session-handling
-  - 03-user-profile
+  - 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/articles/quickstart/webapp/rails/interactive.md b/articles/quickstart/webapp/rails/interactive.md
new file mode 100644
index 0000000000..9e73fd88ea
--- /dev/null
+++ b/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,132 @@
+---
+title: Add Login to Your Ruby on Rails Application
+description: This tutorial demonstrates how to add user login to a Ruby on Rails application.
+interactive:  true
+files:
+ - files/config/auth0
+ - files/auth0
+ - files/auth0_controller
+ - files/routes
+ - files/secured
+github:
+  path: sample
+locale: en-US
+---
+
+# Add Login to Your Ruby on Rails Application
+
+
+
        
+
+## Configure Auth0
+
+
+
        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.
        If you are following along with our sample project, set this to http://localhost:3000/auth/auth0/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.
        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.
        If you are following along with our sample project, set this to http://localhost:3000.
        
+
+## Add dependencies
+
+
+
        Use omniauth-auth0, a custom OmniAuth strategy, to handle the authentication flow.
        Add the following dependencies to your Gemfile:
        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="config/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 the OmniAuth middleware {{{ data-action="code" data-code="auth0.rb" }}}
+
+
+
        Create the following initializer file ./config/initializers/auth0.rb and configure 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.
        
+
+## 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.
        Ruby on Rails Quickstart - Step 6 Checkpoint 
        Run your application to verify it continues to work as intended and you aren't receive any errors relating to Auth0.
        
+
+  
        
+
+  
        Sorry about that. Please double-check that the previous steps completed without error.
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
+
+## Add login to your application
+
+
+
        A user can now log into your application by visiting the /auth/auth0 endpoint.
        To prevent forged authentication requests, use the link_to or button_to helper methods with the :post method.
        <!-- Place a login button anywhere on your application -->
+
+\${ "<\%= button_to 'Login', '/auth/auth0', method: :post %>" }
+
+
        
+
+
        Ruby on Rails Quickstart - Step 7 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 for any other errors or messages that may have prevented login from working
        Still having issues? Check out our documentation or visit our community page 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. Log out a user by redirecting to the auth/logout action, which redirects them to the Auth0 logout endpoint.
        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.
        <!-- Place a logout button anywhere on your application -->
+
+\${"<%= button_to 'Logout', 'auth/logout', method: :get %>"}
+
+
        
+
+
        Ruby on Rails Quickstart - Step 8 Checkpoint 
        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.
        
+
+  
        
+
+  
        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 for any other errors or messages that may have prevented login from working
        Still having issues? Check out our documentation or visit our community page to get more help.
        
+
+  
        
+
+## Show user profile information {{{ data-action="code" data-code="routes.rb" }}}
+
+
+
        To display the user's profile, your application should provide a protected route. You can use a Concern 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:
        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:
        <div>
+
+  <p>Normalized User Profile:\${"<%= JSON.pretty_generate(@user[:info])%>"}</p>
+
+  <p>Full User Profile:\${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}</p>
+
+</div>
+
+
        
+
+
        Ruby on Rails Quickstart - Step 9 Checkpoint 
        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/articles/quickstart/webapp/scala/01-login.md b/articles/quickstart/webapp/scala/01-login.md
deleted file mode 100644
index ac3cca8e68..0000000000
--- a/articles/quickstart/webapp/scala/01-login.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Play 2 Scala SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-scala-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Scala 2.11.7',
-    'Typesafe Activator 1.3.7',
-    'Play framework 2.4.6'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Node.js', callback: 'http://localhost:3000/callback' }) %>
-
-## Add the Auth0 Callback Handler
-
-Add the handler for the Auth0 callback so you can authenticate the user and retrieve their information:
-
-```scala
-// app/controllers/Callback.scala
-
-package controllers
-
-import scala.concurrent.ExecutionContext.Implicits.global
-import scala.concurrent.Future
-
-import javax.inject.Inject
-import play.api.cache._
-import play.api.http.HeaderNames
-import play.api.http.MimeTypes
-import play.api.libs.json.JsValue
-import play.api.libs.json.Json
-import play.api.libs.json.Json.toJsFieldJsValueWrapper
-import play.api.libs.ws._
-import play.api.mvc.Action
-import play.api.mvc.Controller
-import helpers.Auth0Config
-
-class Callback @Inject() (cache: CacheApi, ws: WSClient) extends Controller {
-  
-  def callback(codeOpt: Option[String] = None, stateOpt: Option[String] = None) = Action.async {
-    if (stateOpt == cache.get("state")) {
-      (for {
-        code <- codeOpt
-      } yield {
-        getToken(code).flatMap { case (idToken, accessToken) =>
-          getUser(accessToken).map { user =>
-            cache.set(idToken + "profile", user)
-            Redirect(routes.User.index())
-              .withSession(
-                "idToken" -> idToken,
-                "accessToken" -> accessToken
-              )
-          }
-
-        }.recover {
-          case ex: IllegalStateException => Unauthorized(ex.getMessage)
-        }
-      }).getOrElse(Future.successful(BadRequest("No parameters supplied")))
-    } else {
-      Future.successful(BadRequest("Invalid state parameter"))
-    }
-  }
-
-  def getToken(code: String): Future[(String, String)] = {
-    val config = Auth0Config.get()
-    var audience = config.audience
-    if (config.audience == ""){
-      audience = String.format("https://%s/userinfo",config.domain)
-    }
-    val tokenResponse = ws.url(String.format("https://%s/oauth/token", config.domain)).
-      withHeaders(HeaderNames.ACCEPT -> MimeTypes.JSON).
-      post(
-        Json.obj(
-          "client_id" -> config.clientId,
-          "client_secret" -> config.secret,
-          "redirect_uri" -> config.callbackURL,
-          "code" -> code,
-          "grant_type"-> "authorization_code",
-          "audience" -> audience
-        )
-      )
-      
-    tokenResponse.flatMap { response =>
-      (for {
-        idToken <- (response.json \ "id_token").asOpt[String]
-        accessToken <- (response.json \ "access_token").asOpt[String]
-      } yield {
-        Future.successful((idToken, accessToken)) 
-      }).getOrElse(Future.failed[(String, String)](new IllegalStateException("Tokens not sent")))
-    }
-    
-  }
-  
-  def getUser(accessToken: String): Future[JsValue] = {
-    val config = Auth0Config.get()
-    val userResponse = ws.url(String.format("https://%s/userinfo", config.domain))
-      .withQueryString("access_token" -> accessToken)
-      .get()
-
-    userResponse.flatMap(response => Future.successful(response.json))
-  }
-}
-```
-
-## Trigger Authentication
-
-In the `Application` controller add `login` action to log the user in.
-
-```scala
-// app/controllers/Application.scala
-
-package controllers
-
-import javax.inject.Inject
-import play.api.cache._
-import play.api.mvc.Action
-import play.api.mvc.Controller
-import helpers.Auth0Config
-import java.security.SecureRandom
-import java.math.BigInteger
-
-class Application @Inject() (cache: CacheApi) extends Controller {
-
-  def index = Action {
-    Ok(views.html.index())
-  }
-
-  def login = Action {
-    val config = Auth0Config.get()
-    // Generate random state parameter
-    object RandomUtil {
-      private val random = new SecureRandom()
-
-      def alphanumeric(nrChars: Int = 24): String = {
-        new BigInteger(nrChars * 5, random).toString(32)
-      }
-    }
-    val state = RandomUtil.alphanumeric()
-    var audience = config.audience
-    cache.set("state", state)
-    if (config.audience == ""){
-      audience = String.format("https://%s/userinfo",config.domain)
-    }
-
-    val query = String.format(
-      "authorize?client_id=%s&redirect_uri=%s&response_type=code&scope=openid profile&audience=%s&state=%s",
-      config.clientId,
-      config.callbackURL,
-      audience,
-      state
-    )
-    Redirect(String.format("https://%s/%s",config.domain,query))
-  }
-}
-```
-
-In the `index` view add a link to `login` route.
-
-```html
-
-
-
-```
-
-## Access User Information
-
-You can access the user information from the `cache`.
-
-```scala
-// app/controllers/User.scala
-
-package controllers
-
-import javax.inject.Inject
-import play.api.mvc._
-import play.api.mvc.{Action, Controller}
-import play.api.libs.json._
-import play.api.cache._
-
-
-class User @Inject() (cache: CacheApi) extends Controller {
-  def AuthenticatedAction(f: Request[AnyContent] => Result): Action[AnyContent] = {
-    Action { request =>
-      (request.session.get("idToken").flatMap { idToken =>
-        cache.get[JsValue](idToken + "profile")
-      } map { profile =>
-        f(request)
-      }).orElse {
-        Some(Redirect(routes.Application.index()))
-      }.get
-    }
-  }
-  
-  def index = AuthenticatedAction { request =>
-    val idToken = request.session.get("idToken").get
-    val profile = cache.get[JsValue](idToken + "profile").get
-    Ok(views.html.user(profile))
-  }
-}
-```
-
-Display the user information in the `user` view.
-
-```scala
-// app/views/user.scala.html
-
-@(profile: JsValue)
-
-@main("Auth0 Play2 Scala Sample","home") {
-  
-  
        Welcome @((profile \ "name").as[String])
        
-}
-```
-
-## Logout
-
-To log the user out, you have to clear the data from the session, and redirect the user to the Auth0 logout endpoint. You can find more information about this in [our documentation logout documentation](/logout).
-
-Add the `logout` action in the `Application` controller.
-
-```scala
-// app/controllers/Application.scala
-
-class Application @Inject() (cache: CacheApi) extends Controller {
-  
-  //...
-  
-  def logout = Action {
-    val config = Auth0Config.get()
-    Redirect(String.format(
-      "https://%s/v2/logout?client_id=%s&returnTo=http://localhost:9000",
-      config.domain,
-      config.clientId)
-    ).withNewSession
-  }
-}
-```
-
-::: note
-Please take into consideration that the return to URL needs to be in the list of Allowed Logout URLs in the settings section of the application as explained in [our documentation](/logout#redirect-users-after-logout)
-:::
-
-In the `user` view add a link to `logout` route.
-
-```html
-
-
-Logout
-```
-
-## Optional Steps
-
-You can add the following `Action` to check if the user is authenticated. If not, redirect them to the login page:
-
-```scala
-// app/controllers/User.scala
-
-def AuthenticatedAction(f: Request[AnyContent] => Result): Action[AnyContent] = {
-  Action { request =>
-    (request.session.get("idToken").flatMap { idToken =>
-      cache.getAs[JsValue](idToken + "profile")
-    } map { profile =>
-      f(request)
-    }).orElse {
-      Some(Redirect(routes.Application.index()))
-    }.get
-  }
-}
-
-def index = AuthenticatedAction { request =>
-  val idToken = request.session.get("idToken").get
-  val profile = cache.getAs[JsValue](idToken + "profile").get
-  Ok(views.html.user(profile))
-}
-```
diff --git a/articles/quickstart/webapp/scala/index.yml b/articles/quickstart/webapp/scala/index.yml
deleted file mode 100644
index 52ee57e3be..0000000000
--- a/articles/quickstart/webapp/scala/index.yml
+++ /dev/null
@@ -1,13 +0,0 @@
-title: Play 2 Scala
-community: true
-image: /media/platforms/play.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/scala/dependencies
-  setup: server-platforms/scala/setup
-  use: server-platforms/scala/use
-seo_alias: scala
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/servicestack/01-login.md b/articles/quickstart/webapp/servicestack/01-login.md
deleted file mode 100644
index 7bd218cf35..0000000000
--- a/articles/quickstart/webapp/servicestack/01-login.md
+++ /dev/null
@@ -1,203 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 ServiceStack SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servicestack-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Microsoft Visual Studio 2015',
-    '.NET Framework 4.5.2'
-  ]
-}) %>
-
-At the end of this tutorial, you will have a working website that calls a ServiceStack API with authenticated users.
-
-## Before Starting
-
-We assume you are familiar with [ServiceStack](http://www.servicestack.net/)
-
-## Create a Simple MVC4 Website and Install ServiceStack Through NuGet
-
-For this example, we will use the standard template that ships with Visual Studio. Select __"FILE > New project > ASP.NET Web Application > MVC"__ .
-
-Once the default template unfolds, use NuGet to install the **ServiceStack.Host.Mvc** nuget, running the command:
-
-${snippet(meta.snippets.dependencies)}
-
-![](/media/articles/server-platforms/servicestack/install-servicestack-nuget.png)
-
-Change `HomeController` to return the `default.htm` page. Under the __Controllers__ folder add:
-
-```cs
-public class HomeController : Controller
-{
-    public ActionResult Index()
-    {
-        return Redirect("default.htm");
-    }
-}
-```
-
-## Install Auth0 OAuthProvider
-
-We provide a [Nuget package](http://nuget.org/packages/Auth0-ServiceStack-OAuthProvider/) to simplify integration of Auth0 with ServiceStack based applications.
-
-Run this command on the __Package Manager Console__:
-
-```text
-Install-Package Auth0-ServiceStack-OAuthProvider
-```
-
-This command will add two classes to your project under the __App_Start__ folder: `Auth0Provider` and `Auth0UserSession`.
-
-`Auth0Provider` extends ServiceStack's `OAuthProvider` and handles the authentication transaction for you.
-
-## Enable Authentication and Plugin Auth0's Provider
-
-Open the `AppHost.cs` file (also under the __App_Start__ folder) generated by the ServiceStack NuGet. Uncomment the following call under the `Configure` method:
-
-```text
-ConfigureAuth(container);
-```
-
-And then uncomment (if it is commented out) and edit the `ConfigureAuth` method to look like this:
-
-${snippet(meta.snippets.setup)}
-
-::: note
-In this sample we are not interested in user registration. So we are leaving that section out.
-:::
-
-## Configuring Callback URLs
-
-
        
-
        After authenticating the user on Auth0, we will do a POST to a URL on your website. For security purposes, you have to register this URL on the Application Settings section on Auth0 Admin app (make sure to change the port).
        
-
-
        http://localhost:PORT/api/auth/auth0/
        
-
        
-
-## Enter Configuration Settings
-
-Open your `web.config` file and change the three Auth0's parameters under ``:
-
-```text
-
-
-
-```
-
-## Add Backend Code to Test the App
-
-Open the `WebServiceExamples.cs` file.
-
-### 6.1. Add the `Authenticate` Attribute to the `Hello` DTO:
-
-```cs
-[Authenticate]
-public class Hello
-{
-  public string Name { get; set; }
-}
-```
-
-### 6.2. Add an `IAuthSession` Property to the `HelloResponse` DTO:
-
-```cs
-public class HelloResponse
-{
-  public IAuthSession UserInfo { get; set; }
-  public string Result { get; set; }
-  public ResponseStatus ResponseStatus { get; set; } //Where Exceptions get auto-serialized
-}
-```
-
-### 6.3. Modify the `HelloService` to Return the Current User's `UserInfo` Object
-
-```cs
-public class HelloService : Service
-{
-  public object Any(Hello request)
-  {
-    IAuthSession session = this.GetSession();
-    var sb = new StringBuilder();
-    sb.AppendLine("Id: " + session.Id);
-    sb.AppendLine("DisplayName: " + session.DisplayName);
-
-    return new HelloResponse { Result = "Hello, " + request.Name, UserInfo = session };
-  }
-}
-```
-
-::: note
-Notice we are not doing anything useful with these properties. You can place a breakpoint here and explore the session object.
-:::
-
-## Call the Auth0 Authorization endpoint
-
-You will need to redirect the user to the Auth0 Authorization endpoint in order to log in to the application. We will use the [Auth0.NET SDK](https://github.com/auth0/auth0.net) to construct the redirect URL. First, install the `Auth0.AuthenticationApi` NuGet package:
-
-```text
-Install-Package Auth0.AuthenticationApi
-```
-
-Then, add an `AccountController` class to your MVC application with a `Login` action. This action will construct the authorization URL, and then redirect the user to that URL.
-
-```cs
-public class AccountController : Controller
-{
-    public ActionResult Login()
-    {
-        string clientId = WebConfigurationManager.AppSettings["oauth.auth0.AppId"];
-        string domain = WebConfigurationManager.AppSettings["oauth.auth0.OAuthServerUrl"].Substring(8);
-
-        var redirectUri = new UriBuilder(this.Request.Url.Scheme, this.Request.Url.Host, this.Request.Url.IsDefaultPort ? -1 : this.Request.Url.Port, "api/auth/auth0");
-
-        var client = new AuthenticationApiClient(new Uri($"https://{domain}"));
-        var authorizeUrlBuilder = client.BuildAuthorizationUrl()
-            .WithClient(clientId)
-            .WithRedirectUrl(redirectUri.ToString())
-            .WithResponseType(AuthorizationResponseType.Code)
-            .WithScope("openid profile")
-            .WithAudience($"https://{domain}/userinfo");
-
-
-        return Redirect(authorizeUrlBuilder.Build().ToString());
-    }
-}
-```
-
-## Add UI Code to Log In and display user info
-
-Open `default.htm` and add a login button which will redirect the user to the `/Account/Login` route:
-
-```html
-
        
-    Log In
-
        
-```
-
-Also add the following statement in the `jQuery.ready` body which will call the `/api/hello` endpoint which will return the logged in user's information:
-
-```js
-// get user info from hello endpoint
-$.getJSON('/api/hello', function (data) {
-    $('#userInfo').text(JSON.stringify(data.userInfo, 1, 2));
-});
-```
-
-Add a section to display the `UserInfo`:
-
-```html
-
        User Info:
-     
        Not logged in
        
-
        
-```
-
-## Run the app
-
-You can now run the application, and click on the **Log In** button. After successful authentication, the user profile will be displayed on the page.
diff --git a/articles/quickstart/webapp/servicestack/index.yml b/articles/quickstart/webapp/servicestack/index.yml
deleted file mode 100644
index a385ce7ba2..0000000000
--- a/articles/quickstart/webapp/servicestack/index.yml
+++ /dev/null
@@ -1,13 +0,0 @@
-title: ServiceStack
-community: true
-image: /media/platforms/service-stack.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/servicestack/dependencies
-  setup: server-platforms/servicestack/setup
-  use: server-platforms/servicestack/use
-seo_alias: servicestack
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/quickstart/webapp/symfony/01-login.md b/articles/quickstart/webapp/symfony/01-login.md
deleted file mode 100644
index 93fd23eee8..0000000000
--- a/articles/quickstart/webapp/symfony/01-login.md
+++ /dev/null
@@ -1,212 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Symfony SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../../_includes/_package', {
-  org: 'auth0-community',
-  repo: 'auth0-symfony-php-web-app',
-  path: '00-Starter-Seed',
-  requirements: [
-    'PHP 5.6, 7.0',
-    'Symfony 3.3'
-  ]
-}) %>
-
-<%= include('../_includes/_getting_started', { library: 'Symfony', callback: 'http://localhost:3000/callback' }) %>
-
-
-## Using HWIOAuthBundle for Authentication
-
-If you have used [Symfony](http://symfony.com) before, you are probably already familiar with the [HWIOAuth Bundle](https://github.com/hwi/HWIOAuthBundle). We'll be using it to integrate the Symfony WebApp with [Auth0](https://auth0.com/) and achieve Single Sign On with a few simple steps.
-
-Add HWIOAuthBundle to `composer.json`.
-
-${snippet(meta.snippets.dependencies)}
-
-and run `composer update`.
-
-::: note
-This sample is using [`curl-client`](https://github.com/php-http/curl-client) as PHP HTTP client implementation for [`httplug-bundle`](https://github.com/php-http/HttplugBundle), you can use the PHP HTTP [client implementation](http://docs.php-http.org/en/latest/clients.html) you want.
-:::
-
-## Enable the Bundle
-
-${snippet(meta.snippets.setup)}
-
-## Configure the Routes
-
-Add the following routes at the beginning of `app/config/routing.yml`
-
-```yml
-hwi_oauth_redirect:
-    resource: "@HWIOAuthBundle/Resources/config/routing/redirect.xml"
-    prefix:   /connect
-
-hwi_oauth_login:
-    resource: "@HWIOAuthBundle/Resources/config/routing/login.xml"
-    prefix:   /login
-
-auth0_login:
-    path:    /auth0/callback
-
-auth0_logout:
-    path: /auth0/logout
-```
-
-## Create an Auth0 Resource Owner
-
-You need to create an Auth0 resource owner to enable HWIOAuthBundle to connect to Auth0.
-
-Add this to your `src/AppBundle/Auth0ResourceOwner.php`
-
-```php
- 'user_id',
-        'nickname' => 'nickname',
-        'realname' => 'name',
-        'email' => 'email',
-        'profilepicture' => 'picture',
-    );
-
-    /**
-     * {@inheritdoc}
-     */
-    public function getAuthorizationUrl($redirectUri, array $extraParameters = array())
-    {
-        return parent::getAuthorizationUrl($redirectUri, array_merge(array(
-            'audience' => $this->options['audience'],
-        ), $extraParameters));
-    }
-
-    /**
-     * {@inheritdoc}
-     */
-    protected function configureOptions(OptionsResolver $resolver)
-    {
-        parent::configureOptions($resolver);
-
-        $dotenv = new Dotenv();
-
-        if (!getenv('AUTH0_DOMAIN')) {
-            $dotenv->load(__DIR__ . '/../../.env');
-        }
-
-        $resolver->setDefaults(array(
-            'authorization_url' => '{base_url}/authorize',
-            'access_token_url' => '{base_url}/oauth/token',
-            'infos_url' => '{base_url}/userinfo',
-            'audience' => 'https://'.getenv('AUTH0_DOMAIN').'/userinfo',
-        ));
-
-        $resolver->setRequired(array(
-            'base_url',
-        ));
-
-        $normalizer = function (Options $options, $value) {
-            return str_replace('{base_url}', $options['base_url'], $value);
-        };
-
-        $resolver->setNormalizer('authorization_url', $normalizer);
-        $resolver->setNormalizer('access_token_url', $normalizer);
-        $resolver->setNormalizer('infos_url', $normalizer);
-    }
-}
-```
-
-## Configure the Resource Owner
-
-Add this to your `app/config/config.yml`
-
-```yml
-hwi_oauth:
-    firewall_names: [secured_area]
-    resource_owners:
-        auth0:
-            type:                oauth2
-            class:               'AppBundle\Auth0ResourceOwner'
-            base_url:            https://${account.namespace}
-            client_id:           ${account.clientId}
-            client_secret:       YOUR_CLIENT_SECRET
-            redirect_uri:        http://yourUrl/auth0/callback
-            scope: "openid profile"
-```
-
-## User Provider
-
-You can create a user provider that implements `OAuthAwareUserProviderInterface` and set it up in the next step, or you
-can use one of the predefined services that `HWIOAuthBundle` provides.
-
-## Configure the OAuth Firewall
-
-This is where you set the filters to select which pages require authentication or authorization. You can read more on how to configure this at the Symfony [security](http://symfony.com/doc/current/book/security.html) docs.
-
-This is a basic example that allows anonymous users and then restricts access to the `/secured` route. It doesn't store the users in a DB.
-
-This file is `app/config/security.yml`:
-
-```yml
-security:
-    providers:
-        hwi:
-            id: hwi_oauth.user.provider
-
-    firewalls:
-        secured_area:
-            anonymous: ~
-            oauth:
-                resource_owners:
-                    auth0: "/auth0/callback"
-                login_path:        /login
-                use_forward:       false
-                failure_path:      /login
-
-                oauth_user_provider:
-                    service: hwi_oauth.user.provider
-            logout:
-                path:   /auth0/logout
-                target: /
-
-    access_control:
-        - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
-        - { path: ^/secured, roles: ROLE_OAUTH_USER }
-```
-
-Notice that we need to identify the user provided selected in the step before both in the providers and in the firewall.
-
-## Triggering Login and accessing user information
-
-Set the following in `app/resources/views/index.html.twig`
-
-```html
-{% if app.user %}
-    Welcome, {{ app.user.username }}!
        
-    {{ dump(app.user) }}
-    Protected route
-    
-        
-    
-{% else %}
-    
        Symfony Auth0 Quickstart
        
-    
-{% endif %}
-```
-
diff --git a/articles/quickstart/webapp/symfony/index.yml b/articles/quickstart/webapp/symfony/index.yml
deleted file mode 100644
index 2b968e3e6c..0000000000
--- a/articles/quickstart/webapp/symfony/index.yml
+++ /dev/null
@@ -1,13 +0,0 @@
-title: PHP (Symfony)
-community: true
-image: /media/platforms/php.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/symfony/dependencies
-  setup: server-platforms/symfony/setup
-  use: server-platforms/symfony/use
-seo_alias: symfony
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/rules/_includes/_context-prop-authentication.md b/articles/rules/_includes/_context-prop-authentication.md
new file mode 100644
index 0000000000..3019eaff7f
--- /dev/null
+++ b/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/articles/rules/_includes/_context-prop-authorization.md b/articles/rules/_includes/_context-prop-authorization.md
new file mode 100644
index 0000000000..5625777e2f
--- /dev/null
+++ b/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/articles/rules/_includes/_context-prop-protocol.md b/articles/rules/_includes/_context-prop-protocol.md
new file mode 100644
index 0000000000..7a76ff8125
--- /dev/null
+++ b/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/articles/rules/current/_context-request.md b/articles/rules/_includes/_context-prop-request.md
similarity index 100%
rename from articles/rules/current/_context-request.md
rename to articles/rules/_includes/_context-prop-request.md
diff --git a/articles/rules/_includes/_context-prop-sso.md b/articles/rules/_includes/_context-prop-sso.md
new file mode 100644
index 0000000000..834c9ce793
--- /dev/null
+++ b/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/articles/rules/_includes/_supported-modules.md b/articles/rules/_includes/_supported-modules.md
new file mode 100644
index 0000000000..0ae32fe785
--- /dev/null
+++ b/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/articles/rules/_includes/_user-prop-identities.md b/articles/rules/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..4647b53706
--- /dev/null
+++ b/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/articles/rules/current/_context-protocol.md b/articles/rules/current/_context-protocol.md
deleted file mode 100644
index 5b5bd5b0ef..0000000000
--- a/articles/rules/current/_context-protocol.md
+++ /dev/null
@@ -1,12 +0,0 @@
-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-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/articles/rules/current/_context-sso.md b/articles/rules/current/_context-sso.md
deleted file mode 100644
index 0172721d81..0000000000
--- a/articles/rules/current/_context-sso.md
+++ /dev/null
@@ -1,4 +0,0 @@
-This object will contain information about the 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.
-- `with_dbconn`: an SSO login for a user that logged in through a database connection.
-- `current_clients`: client IDs using SSO.
diff --git a/articles/rules/current/context.md b/articles/rules/current/context.md
deleted file mode 100644
index 4bfc3fc940..0000000000
--- a/articles/rules/current/context.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Context Argument Properties in Rules
-description: Lists the properties that are available for the context argument when creating rules.
----
-# Context Argument Properties in Rules
-
-When creating [Rules](/rules), one of the input arguments is `context`. 
-
-This is an object containing contextual information of the current authentication transaction, such as user's IP address, application, location, and so forth.
-
-This article lists all properties that the `context` object includes. For examples on how to use them see [Rules Examples](/rules#examples).
-
-## List of properties
-
-The following properties are available for the `context` object.
-
-| Name | Description |
-|-|-|
-| `clientID` | The client id of the application the user is logging in to. |
-| `clientName` | The name of the application (as defined on the dashboard). |
-| `clientMetadata` | An object for holding other application properties. Its keys and values are strings. |
-| `connection` | The name of the connection used to authenticate the user (such as: `twitter` or `some-google-apps-domain`) |
-| `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. |
-| `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). |
-| `protocol` | <%= include('./_context-protocol.md') %> |
-| `stats` | An object containing specific user stats, like `stats.loginsCount`. Note that any of the counter variables returned as part of the `stats` object does not increase during [silent authentication](/api-auth/tutorials/silent-authentication) (as when `prompt=none`). |
-| `sso` | <%= include('./_context-sso.md') %> |
-| `accessToken` | Used to add custom namespaced claims to the [Access Token](/tokens/access-token). |
-| `idToken` | Used to add custom namespaced claims to the [ID Token](/tokens/id-token). |
-| `sessionID` | Unique id for the authentication session. Value is kept only if `prompt=none`. |
-| `request` | <%= include('./_context-request.md') %> |
-
-## Sample contents
-
-```js
-{
-  clientID: 'q2hn...pXmTUA',
-  clientName: 'Default App',
-  clientMetadata: {},
-  connection: 'Username-Password-Authentication',
-  connectionStrategy: 'auth0',
-  samlConfiguration: {},
-  protocol: 'oidc-basic-profile',
-  stats: { loginsCount: 111 },
-  sso: { with_auth0: false, with_dbconn: false, current_clients: [] },
-  accessToken: {},
-  idToken: {},
-  sessionID: 'jYA5wG...BNT5Bak',
-  request:
-  {
-    userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36',
-    ip: '188.6.125.49',
-    hostname: 'mydomain.auth0.com',
-    query: 
-    {
-      scope: 'openid',
-      response_type: 'code',
-      connection: 'Username-Password-Authentication',
-      sso: 'true',
-      protocol: 'oauth2',
-      audience: 'my-api',
-      state: 'nB7rfBCL41nppFxqLQ-3cO75XO1QRFyD',
-      client_id: 'q2hn...pXmTUA',
-      redirect_uri: 'http://localhost/callback',
-      device: 'Browser'
-    },
-    body: {},
-    geoip:
-    {
-      country_code: 'GR',
-      country_code3: 'GRC',
-      country_name: 'Greece',
-      city_name: 'Athens',
-      latitude: 136.9733,
-      longitude: 125.7233,
-      time_zone: 'Europe/Athens',
-      continent_code: 'EU'
-    }
-  }
-}
-```
diff --git a/articles/rules/current/csharp.md b/articles/rules/current/csharp.md
deleted file mode 100644
index afaa8e3601..0000000000
--- a/articles/rules/current/csharp.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Using C# in Rules
-description: Learn how to use C# in Rules with Edge.js
-toc: true
----
-# Using C# in Rules
-
-Even though you typically write Rules in JavaScript, there is support for using C# by making use of [Edge.js](http://tjanczuk.github.io/edge/#/). In order to use C# in your Rule you will first need to `require` Edge:
-
-```js
-var edge = require('edge');
-```
-
-You can then declare an Edge function, and embed the C# code inside the function body using a JavaScript multi-line comment block:
-
-```js
-var helloWorld = edge.func(function () {/*
-  async (input) => { 
-      return ".NET Welcomes " + input.ToString(); 
-  }
-*/});
-```
-
-Please note from the code above that you need to declare the C# function as an `async` Lambda taking a single input parameter:
-
-```cs
-async (input) => { 
-    return ".NET Welcomes " + input.ToString(); 
-}
-```
-
-Finally, you can call the `helloWorld` function from somewhere else inside your Rule. Here is the full sample code for the Rule making use of C#:
-
-```js
-function (user, context, callback) {
-  var edge = require('edge');
-  
-  var helloWorld = edge.func(function () {/*
-    async (input) => { 
-        return ".NET Welcomes " + input.ToString(); 
-    }
-  */});
-  
-  helloWorld('JavaScript', function (error, result) {
-    callback(error, user, context);
-  });
-}
-```
-
-You can take this one step further by adding the result of the C# function as a [namespaced Claim](/api-auth/tutorials/adoption/scope-custom-claims):
-
-```js
-function (user, context, callback) {
-  var edge = require('edge');
-  
-  var helloWorld = edge.func(function () {/*
-    async (input) => { 
-        return ".NET Welcomes " + input.ToString(); 
-    }
-  */});
-  
-  helloWorld('JavaScript', function (error, result) {
-    context.accessToken['https://company.com/hello'] = result;
-    callback(error, user, context);
-  });
-}
-```
-
-You can also pass the `user` or `context` parameters which was passed into the Rule to the C# function. In this case you will need to declare the `input` parameter of the Lambda function as `dynamic` so you can access the attributes from the JavaScript object inside the C# function. You will also need to pass the `user` or `context` object to the `helloWorld` function.
-
-In the updated sample below you can see that the C# function replaces the `@` and `.` characters in the user's email address with the `_` character:
-
-```js
-function (user, context, callback) {
-  var edge = require('edge');
-  
-  var helloWorld = edge.func(function () {/*
-    async (dynamic input) => { 
-        return input.email.Replace('@', '_').Replace('.', '_'); 
-    }
-  */});
-  
-  helloWorld(user, function (error, result) {
-    context.accessToken['https://company.com/email'] = result;
-    callback(error, user, context);
-  });
-}
-```
-
-::: note
-For details on the properties of the `context` argument refer to [Context Argument Properties in Rules](/rules/context).
-:::
diff --git a/articles/rules/current/index.md b/articles/rules/current/index.md
deleted file mode 100644
index 455e063168..0000000000
--- a/articles/rules/current/index.md
+++ /dev/null
@@ -1,362 +0,0 @@
----
-description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
-toc: true
----
-# Rules
-
-**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.
-
-![Rule 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 tokens ([id_token](/tokens/id-token) and/or [access_token](/tokens/access-token)) pass through the Rules pipeline, and are sent to the app.
-
-## What can I use rules for?
-
-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).
-* Modify tokens: Change the returned __scopes__ of the `access_token` and/or add claims to it, and to the `id_token`.
-
-## 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 Structure](/user-profile/user-profile-structure).
-
-* `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/context).
-
-* `callback`: a function to send back 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.
-
-## 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. 
-
-Select an empty rule to start from scratch, or use one of the templates. Name your rule, keeping in mind that it can only contain alphanumeric characters, spaces and '-', and cannot start, nor end, with '-' or spaces.
-
-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: 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. An exception to that 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/id-token).
-
-::: 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 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);
-}
-```
-
-### API Authorization: Modify Scope
-
-This will override the returned scopes of the `access_token`. The rule will run after user authentication and before authorization.
-
-```js
-function(user, context, callback) {
-
-  // change scope
-  context.accessToken.scope = ['array', 'of', 'strings'];
-
-  callback(null, user, context);
-}
-```
-
-The user will be granted three scopes: `array`, `of`, and `strings`.
-
-### API Authorization: Add Claims to Access Tokens
-
-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`.
-
-### Using the Configuration Object
-
-The global `configuration` object is available in your rules if you wish to save some commonly used items, such as credentials, URLs, and so on, that might be subject to change or that you wish to keep out of your Rule code.
-
-The following example is a Rule template for sending a Slack message when a new user has signed up via Auth0:
-
-```js
-function(user, context, callback) {
-  // short-circuit if the user signed up already
-  if (context.stats.loginsCount > 1) return callback(null, user, context);
-
-  // get your slack's hook url from: https://slack.com/services/10525858050
-  var SLACK_HOOK = configuration.SLACK_HOOK;
-
-  var slack = require('slack-notify')(SLACK_HOOK);
-  var message = 'New User: ' + (user.name || user.email) + ' (' + user.email + ')';
-  var 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);
-}
-```
-
-This Rule will require that you have a `configuration` value set for the key `SLACK_HOOK`. At the [Rules](${manage_url}/#/rules/) page in the Dashboard you can scroll down beneath your list of Rules to the configuration area and enter `SLACK_HOOK` as the key and your Slack URL to post a message to the appropriate channel as the value, then hit "Create". Now your URL will be available to all rules via `configuration.SLACK_HOOK`. Bear in mind that `configuration` is global to all rules on the account.
-
-![Rules Configuration](/media/articles/rules/rules-configuration.png)
-
-::: note
-Note that you need to have created at least one rule in order for the configuration area to show up, otherwise the Rules demo shows instead.
-:::
-
-## 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}"
-  }
-}
-```
-
-::: note
-You can use the [auth0-custom-db-testharness library](https://www.npmjs.com/package/auth0-custom-db-testharness) to deploy, execute, and test the output of Custom DB Scripts using a Webtask sandbox environment.
-:::
-
-## 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 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)
-
-    Please note that this feature functions outside the context of a specific client. That is, it uses a default **All Applications** client application. Because you are unable to configure parameters for this default application, y ou may run into issues if your rule depends on data that would otherwise be provided when called from an actual application.
-
-1. **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. For more info see [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs).
-1. **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.
-
-  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 based on [webtask.io](https://webtask.io) 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://tehsis.github.io/webtaskio-canirequire) and [Additional Modules Available in Rules](/appliance/modules).
-
-## Keep reading
-
-::: next-steps
-* [Redirecting users from rules](/rules/current/redirect)
-* [User Metadata in rules](/rules/current/metadata-in-rules)
-* [Use the Management API in rules](/rules/current/management-api)
-* [Using C# in Rules](/rules/current/csharp)
-* [Properties of the Context Argument](/rules/current/context)
-:::
diff --git a/articles/rules/current/management-api.md b/articles/rules/current/management-api.md
deleted file mode 100644
index 323cdad234..0000000000
--- a/articles/rules/current/management-api.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-description: How to use the Management API in rules.
-toc: true
----
-# Use the Management API in rules
-
-You have limited access to the [Management API](/api/management/v2) inside Rules. In particular, the version of the Node.js client library available from rules only allow you to update the user's `app_metadata` and `user_metadata` as descibed in [User Metadata in Rules](/rules/current/metadata-in-rules).
-
-## Accessing a Newer Version of the Node.js Client Library
-
-You can load a newer version of the Auth0 Node.js client library by requiring the specific version on the library. The sample code below loads version `2.6.0` of the library, then query the list of users and log the users to the console (to be inspected with the [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs)):
-
-```js
-function (user, context, callback) {
-  var ManagementClient = require('auth0@2.6.0').ManagementClient;
-  var management = new ManagementClient({
-    token: auth0.accessToken,
-    domain: auth0.domain
-  });
-
-  management.getUsers(function (err, users) {
-    console.log(users);
-    callback(null, user, context);
-  });
-}
-```
-
-::: 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 Client Credentials Grant](/api/management/v2/tokens#automate-the-process).
-:::
\ No newline at end of file
diff --git a/articles/rules/current/metadata-in-rules.md b/articles/rules/current/metadata-in-rules.md
deleted file mode 100644
index 5732e561c3..0000000000
--- a/articles/rules/current/metadata-in-rules.md
+++ /dev/null
@@ -1,443 +0,0 @@
----
-toc: true
-description: How to use metadata in rules.
----
-# User Metadata in Rules
-
-This article explains how to [read](#reading-metadata), [update](#updating-metadata) and [delete](#deleting-metadata) [metadata](/metadata) using [Rules](/rules).
-
-Each sample rule in this article assumes that 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"
-    }
-  }
-}
-```
-
-## Reading Metadata
-
-To read the available metadata, you will need to access the correct user property.
-
-### Reading `app_metadata`
-
-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
-  }
-  ...
-}
-```
-
-### Reading `user_metadata`
-
-Similarly, you can use the color preference:
-
-```js
-function(user, context, callback){
-  user.user_metadata = user.user_metadata || {};
-  if (user.user_metadata.preferences.color === 'black'){
-    // code to be executed
-  }
-  ...
-}
-```
-
-### Reading `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
-  }
-  ...
-}
-```
-
-#### Reading via the API
-
-`client_metadata` is included amongst in the response to the `GET /api/v2/clients` and `GET /api/v2/client/{id}` endpoints
-
-#### Creating applications with `client_metadata` properties
-
-A `client_metadata` object can be included when creating a new application via the `POST /api/v2/` applications endpoint.
-
-#### Creating `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)
-
-## Updating Metadata
-
-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.
-
-### Updating `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"
-    }
-  }
-}
-```
-
-### Updating `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
-    }
-  }
-}
-```
-
-### Updating `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){
-  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
-    }
-  }
-}
-```
-
-### Updating `client_metadata`
-
-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"
-  }
-  ...
-}
-```
-
-#### Updating `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)
-
-## Deleting Metadata
-
-### Deleting `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.
-
-### Deleting `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": { }
-  }
-}
-```
-
-### Deleting `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.
-
-#### Deleting`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/articles/rules/current/redirect.md b/articles/rules/current/redirect.md
deleted file mode 100644
index 05046698ff..0000000000
--- a/articles/rules/current/redirect.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-description: How to implement a user redirect using rules, and actions after redirecting.
----
-# Redirect Users from Rules
-
-[Rules](/rules) allow you to define arbitrary code which can be used to fulfill custom authentication and authorization requirements, log events, retrieve information from external services, and much more.
-
-Rules can also be used to programatically redirect users before an authentication transaction is complete, allowing the implementation of custom authentication flows which require input on behalf of the user, such as:
-
-* Requiring users to provide additional verification when logging in from unknown locations.
-* Implementing custom verification mechanisms (such as proprietary multifactor authentication providers).
-* Forcing users to change passwords.
-
-::: panel-warning Redirect Rules
-Redirect rules won't work for the [Resource Owner endpoint](/api/authentication/reference#resource-owner), the [Password exchange](/api-auth/grant/password) or the [Refresh Token exchange](/tokens/refresh-token#rules). You can detect these 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'`
-:::
-
-## How to implement a redirect
-
-To redirect a user from a rule, 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, the user will be redirected to the specified URL.
-
-Auth0 will also pass a state value in that URL, for example `https://example.com/foo?state=abc123`.
-
-::: note
-State is an opaque value, used to prevent [CSRF attacks](/security/common-threats#cross-site-request-forgery-xsrf-or-csrf-). In this case, Auth0 passes this param to the redirect URL.
-:::
-
-Your redirect URL will need to extract the `state` parameter and send it back to Auth0 in order to resume the authentication transaction.
-
-## What to do afterwards
-
-An authentication transaction that has been interrupted, by setting `context.redirect`, can be resumed by redirecting the user to the following URL:
-
-```text
-https://${account.namespace}/continue?state=THE_ORIGINAL_STATE
-```
-
-By `THE_ORIGINAL_STATE` we mean 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` (`abc123` being the `THE_ORIGINAL_STATE`). In this case in order to resume the authentication transaction you should redirect to `https://${account.namespace}/continue?state=abc123`.
-
-How you extract the `state` parameter depends entirely on the server you redirect to. If you're using [Node.js and Express, you could use `req.query.state` to extract this parameter](https://expressjs.com/en/api.html#req.query).
-
-When a user has been redirected to the `/continue` endpoint, **all rules will be run again.**
-
-::: warning
-Make sure to send back the original state to the `/continue` endpoint, otherwise Auth0 will lose the context of the login transaction and the user will not be able to login due to to an `invalid_request` error.
-:::
-
-To distinguish between user-initiated logins and resumed login flows, the `context.protocol` property can be checked:
-
-```js
-function (user, context, callback) {
-    if (context.protocol === "redirect-callback") {
-        // User was redirected to the /continue endpoint
-    } else {
-        // User is logging in directly
-    }
-}
-```
-
-## How to securely process results
-
-Suppose you would like to force users to change their passwords under specific conditions. You can write a rule that would have 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. The application redirects back to `/continue`, with a JWT in the query string. This token must be issued for the same user that is attempting to log in, and must contain a `passwordChanged: true` claim.
-
-```js
-function(user, context, callback) {
-  // Prerequisites:
-  // 1. Implement a `mustChangePassword` function
-  // 2. Set configuration variables for the following:
-  // * CLIENT_ID
-  // * CLIENT_SECRET
-  // * ISSUER
-  if (context.protocol !== "redirect-callback") {
-    if (mustChangePassword(user)) {
-      // User has initiated a login and is forced to change their password
-      // Send user's information in a JWT to avoid tampering
-      function createToken(clientId, clientSecret, issuer, user) {
-        var options = {
-          expiresInMinutes: 5,
-          audience: clientId,
-          issuer: issuer
-        };
-        return jwt.sign(user, clientSecret, options);
-      }
-      var token = createToken(
-        configuration.CLIENT_ID,
-        configuration.CLIENT_SECRET,
-        configuration.ISSUER, {
-          sub: user.user_id,
-          email: user.email
-        }
-      );
-      context.redirect = {
-        url: "https://example.com/change-pw?token=" + token
-      };
-      return callback(null, user, context);
-    }
-  } else {
-    // User has been redirected to /continue?token=..., password change must be validated
-    // The generated token must include a `passwordChanged` claim to confirm the password change
-    function verifyToken(clientId, clientSecret, issuer, token, cb) {
-      jwt.verify(
-        token,
-        clientSecret, {
-          audience: clientId,
-          issuer: issuer
-        },
-        cb
-      );
-    }
-    function postVerify(err, decoded) {
-      if (err) {
-        return callback(new UnauthorizedError("Password change failed"));
-      } else if (decoded.sub !== user.user_id) {
-        return callback(new UnauthorizedError("Token does not match the current user"));
-      } else if (!decoded.passwordChanged) {
-        return callback(new UnauthorizedError("Password change was not confirmed"));
-      } else {
-        // User's password has been changed successfully
-        return callback(null, user, context);
-      }
-    }
-    verifyToken(
-      configuration.CLIENT_ID,
-      configuration.CLIENT_SECRET,
-      configuration.ISSUER,
-      context.request.query.token,
-      postVerify
-    );
-  }
-}
-```
-
-## Caveats
-
-You can redirect a user **once** per authentication flow. For example, if you have one rule that redirects a user, you cannot invoke a second rule to redirect the user at a later time.
-
-Redirect rules won't work for the [Resource Owner endpoint](/api/authentication/reference#resource-owner) authentication endpoint. This is because the endpoint returns a JSON result. Redirect rules work _only_ with browser based protocols.
-
-Also, if you are using any social network as a connection, make sure you register your own account (vs. using Auth0's Dev Keys). This is because redirect rules are resumed on the endpoint: `https://${account.namespace}/continue`. When using Auth0's Dev Keys, the session is established on a special endpoint that is generic and tenant agnostic, and calling `/continue` will not find your previous session, resulting in an error.
-
-You can [read more about issues that may arise from using Auth0's Dev Keys here.](/connections/social/devkeys)
diff --git a/articles/rules/guides/automatically-generate-leads-shopify.md b/articles/rules/guides/automatically-generate-leads-shopify.md
new file mode 100644
index 0000000000..f01f3cdeb8
--- /dev/null
+++ b/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/articles/rules/guides/cache-resources.md b/articles/rules/guides/cache-resources.md
new file mode 100644
index 0000000000..38f2e6fb5e
--- /dev/null
+++ b/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/articles/rules/guides/configuration.md b/articles/rules/guides/configuration.md
new file mode 100644
index 0000000000..bad1fd86d4
--- /dev/null
+++ b/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/articles/rules/guides/debug.md b/articles/rules/guides/debug.md
new file mode 100644
index 0000000000..b269e370a5
--- /dev/null
+++ b/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/articles/rules/guides/integrate-efm-solutions.md b/articles/rules/guides/integrate-efm-solutions.md
new file mode 100644
index 0000000000..4c6d8539fd
--- /dev/null
+++ b/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/articles/rules/guides/integrate-erfm-solutions.md b/articles/rules/guides/integrate-erfm-solutions.md
new file mode 100644
index 0000000000..29597e769b
--- /dev/null
+++ b/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/articles/rules/guides/integrate-hubspot.md b/articles/rules/guides/integrate-hubspot.md
new file mode 100644
index 0000000000..f80a3ea207
--- /dev/null
+++ b/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/articles/rules/guides/integrate-maxmind.md b/articles/rules/guides/integrate-maxmind.md
new file mode 100644
index 0000000000..4078db7c80
--- /dev/null
+++ b/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/articles/rules/guides/integrate-mixpanel.md b/articles/rules/guides/integrate-mixpanel.md
new file mode 100644
index 0000000000..64681528b6
--- /dev/null
+++ b/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/articles/rules/guides/integrate-salesforce.md b/articles/rules/guides/integrate-salesforce.md
new file mode 100644
index 0000000000..0199086e95
--- /dev/null
+++ b/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/articles/rules/guides/integrate-user-id-verification.md b/articles/rules/guides/integrate-user-id-verification.md
new file mode 100644
index 0000000000..fbfe64ed0b
--- /dev/null
+++ b/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/articles/rules/guides/management-api.md b/articles/rules/guides/management-api.md
new file mode 100644
index 0000000000..bc49ddd310
--- /dev/null
+++ b/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/articles/rules/guides/metadata.md b/articles/rules/guides/metadata.md
new file mode 100644
index 0000000000..3a8247c063
--- /dev/null
+++ b/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/articles/rules/guides/redirect.md b/articles/rules/guides/redirect.md
new file mode 100644
index 0000000000..160a5dcf45
--- /dev/null
+++ b/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/articles/rules/index.md b/articles/rules/index.md
new file mode 100644
index 0000000000..87116867e7
--- /dev/null
+++ b/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/articles/rules/index.yml b/articles/rules/index.yml
deleted file mode 100644
index fca269dea0..0000000000
--- a/articles/rules/index.yml
+++ /dev/null
@@ -1,9 +0,0 @@
-versioning:
-  baseUrl: rules
-  current: current
-  versions:
-    - legacy
-    - current
-  defaultArticles:
-    legacy: index
-    current: index
diff --git a/articles/rules/legacy/index.md b/articles/rules/legacy/index.md
deleted file mode 100644
index 5d2f9b6eed..0000000000
--- a/articles/rules/legacy/index.md
+++ /dev/null
@@ -1,282 +0,0 @@
----
-description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
-toc: true
----
-
-# Rules
-
-::: 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 Structure](/user-profile/user-profile-structure).
-
-* `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/context).
-
-::: 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 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}"
-  }
-}
-```
-
-::: note
-You can use the [auth0-rules-testharness library](https://www.npmjs.com/package/auth0-rules-testharness) to deploy, execute, and test the output of Rules using a Webtask sandbox environment.
-:::
-
-## 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 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.
-
-  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 based on [webtask.io](https://webtask.io) 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://tehsis.github.io/webtaskio-canirequire).
-
-## Read more
-
-* [Redirecting users from within rules](/rules/redirect)
diff --git a/articles/rules/references/context-object.md b/articles/rules/references/context-object.md
new file mode 100644
index 0000000000..929edfcfb3
--- /dev/null
+++ b/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/articles/rules/references/legacy.md b/articles/rules/references/legacy.md
new file mode 100644
index 0000000000..99cf62c5fb
--- /dev/null
+++ b/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/articles/rules/references/modules.md b/articles/rules/references/modules.md
new file mode 100644
index 0000000000..aee9a8c3b9
--- /dev/null
+++ b/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/articles/rules/references/samples.md b/articles/rules/references/samples.md
new file mode 100644
index 0000000000..e24de4191a
--- /dev/null
+++ b/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/articles/rules/references/use-cases.md b/articles/rules/references/use-cases.md
new file mode 100644
index 0000000000..0db47d8b72
--- /dev/null
+++ b/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/articles/rules/references/user-object.md b/articles/rules/references/user-object.md
new file mode 100644
index 0000000000..9ceda737ca
--- /dev/null
+++ b/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/articles/scopes/current/api-scopes.md b/articles/scopes/current/api-scopes.md
new file mode 100644
index 0000000000..dae3ed63a1
--- /dev/null
+++ b/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/articles/scopes/current/guides/customize-consent-prompt.md b/articles/scopes/current/guides/customize-consent-prompt.md
new file mode 100644
index 0000000000..437fdd21df
--- /dev/null
+++ b/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/articles/scopes/current/index.md b/articles/scopes/current/index.md
index f24a70a49a..e510f4a386 100644
--- a/articles/scopes/current/index.md
+++ b/articles/scopes/current/index.md
@@ -1,193 +1,62 @@
 ---
+url: /scopes/current
+section: articles
+classes: topic-page
 title: Scopes
-description: Overview of scopes.
-toc: true
+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
 
-The OAuth2 protocol is a delegated authorization mechanism, where an application requests access to resources controlled by the user (the resource owner) and hosted by an API (the resource server), and the authorization server issues the application a more restricted set of credentials than those of the user.
-
-The `scope` parameter allows the application to express the desired scope of the access request. In turn, the `scope` parameter can be used by the authorization server in the response to indicate which scopes were actually granted (if they are different than the ones requested).
-
-You can use scopes to:
+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.
 
-- Let an application authenticate users and get additional information about them, such as their email or picture. For details, refer to [OpenID Connect Scopes](#openid-connect-scopes).
+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.
 
-- Implement granular access control to your API. In this case, you need to define custom scopes for your API and add these newly-created scopes to your `scope` request parameter: `scope=read:contacts`. For details, refer to [API Scopes](#api-scopes).
+## Ways to use scopes
 
-## OpenID Connect 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).
 
-OpenID Connect (OIDC) is an authentication protocol that sits on top of OAuth2, and allows the application to verify the identity of the users and obtain basic profile information about them in a interoperable way. This information can be returned in the `id_token` and/or in the response from [the /userinfo endpoint](/api/authentication#get-user-info) (depending on the type of request).
+Generally, you use scopes in three ways:
 
-The basic (and required) scope for OpenID Connect is the `openid` scope. This scope represents the intent of the application to use the OIDC protocol to verify the identity of the user.
+* 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 OpenID Connect (OIDC), we have the notion of __claims__. There are two types of claims:
+* 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).
 
-* [Standard](#standard-claims) (which means that they meet OIDC specification)
-* [Custom](#custom-claims)
+* 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)
 
-### Standard Claims
+## Best practices
 
-OpenID Connect specifies a set of [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). These claims are user attributes and are intended to provide the application with user details such as email, name and picture.
+Understand your use case and choose the most restrictive scopes possible. 
 
-The basic claim returned for the `openid` scope is the `sub` claim, which uniquely identifies the user (`iss`, `aud`, `exp`, `iat` and `at_hash` claims will also be present in the `id_token`). Applications can ask for additional scopes, separated by spaces, to request more information about the user. The following additional scopes apply:
+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. 
 
-- `profile`: will request the claims representing basic profile information. These are `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `picture` and `updated_at`.
-- `email`: will request the `email` and `email_verified` claims.
+Similarly, when creating custom scopes for an API, consider what levels of granular access applications may need and design accordingly.
 
-### Example: Ask for Standard Claims
+## Requested scopes versus granted scopes
 
-In this example, we will use the [OAuth 2.0 Implicit Grant](/api-auth/grant/implicit) to authenticate a user and retrieve an `id_token` that contains the user's name, nickname, profile picture, and email information.
+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. 
 
-To initiate the authentication flow, send the user to the authorization URL and request an `id_token`:
-
-```text
-https://${account.namespace}/authorize?
-  scope=openid%20profile%20email&
-  response_type=id_token&
-  client_id=${account.clientId}&
-  redirect_uri=${account.callback}&
-  nonce=YOUR_CRYPTOGRAPHIC_NONCE
-  state=YOUR_OPAQUE_VALUE
-```
+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
-For details on the params and how to implement this flow refer to [How to implement the Implicit Grant](/api-auth/tutorials/implicit-grant).
-:::
-
-Notice that we included three values at the `scope` param: `openid`, `profile` (to get `name`, `nickname` and `picture`) and email (to get the `email` claim).
-
-After Auth0 has redirected back to the app, you can extract the `id_token` from the hash fragment of the URL.
-
-When decoded, the `id_token` contains 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 these values and use them to personalize the UI.
-
-## Custom Claims
-
-When adding custom claims to ID or Access Tokens, they must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims). This is to avoid any possible collision with standard OIDC claims.
-
-### Example: Add Custom Claims
-
-Suppose that:
-
-* The identity provider returns a `favorite_color` claim as part of the user's profile 
-* We've used the Auth0 Management API to set application-specific information for this user
-* We've saved the `preferred_contact` information as part of the `user_metadata`
-
-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"
-  }
-}
-```
-
-In order to add these claims to the `id_token`, we need to create a [rule](/rules) to: 
-
-* Customize the token 
-* Add these claims using namespaced format in the rule
-
-Sample Rule:
-
-```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);
-}
-```
-
-Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. 
-
-::: warning 
-`auth0.com`, `webtask.io` and `webtask.run` are Auth0 domains and therefore cannot be used as a namespace identifier. 
+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.
 :::
 
-The namespace URL does not have to point to an actual resource, since it’s only used as an identifier and will not be called by Auth0. This follows the [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 required by the the specification, Auth0 will always enforce namespacing, which means that any non-namespaced claims will be silently excluded from tokens.
-
-::: note
-Adding custom claims to the Access Token is very similar to the process of adding custom claims to the ID Token. However, you would use `context.accessToken` instead of `context.idToken`.
-:::
-
-Custom claims added to ID Tokens using this method allows you to obtain them when calling the `/userinfo` endpoint. However, note that rules run during the user authentication process only, not when `/userinfo` is called.
-
-## API Scopes
-
-Scopes allow you to define the API data accessible to your applications. When you [create an API in Auth0](/apis), you'll need to define one scope for each API represented and action. For example, if you want to `read` and `delete` contact information, you would create two scopes: `read:contacts` and `delete:contacts`.
-
-Once you create an API and define the scopes, the applications can request these defined permissions when they initiate an authorization flow and include them in the Access Token as part of the scope request parameter.
-
-If you wanted to expand [our example](#example-asking-for-standard-claims) to include also the `read:contacts` permission, then you would using something like the following sample URL to initiate the authentication flow using the Implicit grant:
-
-```text
-https://${account.namespace}/authorize?
-  audience=YOUR_API_AUDIENCE&
-  scope=openid%20profile%20email%20read:contacts&
-  response_type=id_token%20token&
-  client_id=${account.clientId}&
-  redirect_uri=${account.callback}&
-  nonce=YOUR_CRYPTOGRAPHIC_NONCE
-  state=YOUR_OPAQUE_VALUE
-```
-
-Note the differences between the two examples. In the latest, we want to get an `access_token`, that will allow us to access the API, with the rights to do specific actions. To do so, we changed two parameters and added a new one:
-
-- `audience`: New parameter added for this example. Its value is the unique identifier of the API we want to get access to.
-
-- `scope`: We appended the value `read:contacts`. This denotes the rights that we want to be granted at the API (in this case, read contact information).
-
-- `response_type`: We appended the value `token`. This tells the Authorization Server (Auth0 in our case) to issue an `access_token` as well, not only an `id_token`. The `access_token` will be sent to the API as credentials.
-
-### Define Scopes Using the Dashboard
-
-::: warning
-By default, any user of any application can ask for any scope defined here. You can implement access policies to limit this behaviour via [Rules](/rules).
-:::
-
-You can define API scopes using the [Dashboard](${manage_url}/#/apis). Select the API you want to edit, and open up its **Scopes** tab.
-
-Provide the following parameters:
-
-| Parameter | Description |
-| - | - |
-| Name | The name of your scope |
-| Description | A friendly description for your scope |
-
-Click **Add** when you've provided the requested values.
-
-![API Scopes](/media/articles/scopes/api-scopes.png)
-
-### Limiting API Scopes being Issued
-
-An application can request any scope and the user will be prompted to approve those scopes during the authorization flow. This may not be a desirable situation, as you may want to limit the scopes based on, for example, the permissions (or role) of a user.
-
-You can make use of the [Authorization Extension](/extensions/authorization-extension) in conjunction with a custom [Rule](/rules) to ensure that scopes are granted based on the permissions of a user.
+## Keep reading
 
-This approach is discussed in more depth in some of our [Architecture Scenarios](/architecture-scenarios). Specifically, you can review the entire [Configure the Authorization Extension](/architecture-scenarios/application/spa-api/part-2#configure-the-authorization-extension) section of our SPA+API Architecture Scenario which demonstrates how to configure the Authorization Extension, and also create a custom Rule which will ensure scopes are granted based on the permissions of a user. 
+- [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/articles/scopes/current/oidc-scopes.md b/articles/scopes/current/oidc-scopes.md
new file mode 100644
index 0000000000..58c9fbe902
--- /dev/null
+++ b/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/articles/scopes/current/sample-use-cases.md b/articles/scopes/current/sample-use-cases.md
new file mode 100644
index 0000000000..fe4ea0d57c
--- /dev/null
+++ b/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/articles/scopes/legacy/index.md b/articles/scopes/legacy/index.md
index d2f9b951d0..7fceba1b84 100644
--- a/articles/scopes/legacy/index.md
+++ b/articles/scopes/legacy/index.md
@@ -1,14 +1,22 @@
 ---
 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).
+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.
+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)
 
@@ -56,7 +64,7 @@ The attributes included in the issued token can be controlled with the `scope` p
 
 * `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.
+* `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).
@@ -66,6 +74,6 @@ The `scope` parameter can be used in the same way when calling the [Resource Own
 
 ::: 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)
+* [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/articles/security/blacklisting-attributes.md b/articles/security/blacklisting-attributes.md
index 6d4ba1d9c4..32b85c318a 100644
--- a/articles/security/blacklisting-attributes.md
+++ b/articles/security/blacklisting-attributes.md
@@ -2,6 +2,15 @@
 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
 
@@ -13,18 +22,18 @@ To blacklist attributes make a `PATCH` call to the [Update Connection](/api/mana
 
 ### Step 1. Get a token
 
-First, you need a valid Access Token in order to access that endpoint. The token must include the `update:connections` scope. 
+First, you need a valid Access Token to access that endpoint. The token must include the `update:connections` scope. 
 
-You can either get one manually from the Dashboard, or automate the process (for example, by building a simple command line tool that generates tokens). For detailed steps on how to do either, refer to  [The Auth0 Management APIv2 Token](/api/management/v2/tokens).
+For detailed steps on how to get one, see [Access Tokens for the Management API](/api/management/v2/tokens).
 
 ### Step 2. Call the API
 
-One you have the token (and the list of attributes to be blacklisted), you are ready to 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`.
 
 
-```har
+```js
 {
   "method": "PATCH",
   "url": "https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID",
@@ -32,11 +41,12 @@ Here is a sample HTTP request that blacklists two attributes: `ethnicity` and `g
   "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\"]}\", \"enabled_clients\": [\"\"]}"
+    "text": "{\"options\": {\"non_persistent_attrs\": [\"ethnicity\", \"gender\"]}}"
   },
   "headersSize" : -1,
   "bodySize" : -1,
@@ -52,14 +62,16 @@ Where:
 
 ## Limitations
 
-- Only root fields (such as `user.name` or `user.email`) can be blacklisted
+- 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 multifactor authentication
+  - 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
-- For SAMLP connections, if you enable Debug mode, your logs will contain information on the blacklisted attributes
+  - 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/articles/security/bulletins/2019-01-10_rules.md b/articles/security/bulletins/2019-01-10_rules.md
new file mode 100644
index 0000000000..27fa3bdea6
--- /dev/null
+++ b/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/articles/security/bulletins/2019-09-05_scopes.md b/articles/security/bulletins/2019-09-05_scopes.md
new file mode 100644
index 0000000000..93bd59afda
--- /dev/null
+++ b/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/articles/security/bulletins/2020-03-31_wpauth0.md b/articles/security/bulletins/2020-03-31_wpauth0.md
new file mode 100644
index 0000000000..a5a6f4d6bc
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2017-16897.md b/articles/security/bulletins/cve-2017-16897.md
index 3809bb29b9..2dd3913dfc 100644
--- a/articles/security/bulletins/cve-2017-16897.md
+++ b/articles/security/bulletins/cve-2017-16897.md
@@ -2,6 +2,17 @@
 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
 
@@ -16,7 +27,7 @@ toc: true
 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/).
+**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.
diff --git a/articles/security/bulletins/cve-2017-17068.md b/articles/security/bulletins/cve-2017-17068.md
index 9aa18f6329..9721c1184b 100644
--- a/articles/security/bulletins/cve-2017-17068.md
+++ b/articles/security/bulletins/cve-2017-17068.md
@@ -2,6 +2,16 @@
 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
 
diff --git a/articles/security/bulletins/cve-2018-11537.md b/articles/security/bulletins/cve-2018-11537.md
new file mode 100644
index 0000000000..8fb96b3033
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2018-15121.md b/articles/security/bulletins/cve-2018-15121.md
new file mode 100644
index 0000000000..df5674586f
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2018-6873.md b/articles/security/bulletins/cve-2018-6873.md
index 8f1ac32838..546d8d75b7 100644
--- a/articles/security/bulletins/cve-2018-6873.md
+++ b/articles/security/bulletins/cve-2018-6873.md
@@ -1,6 +1,15 @@
 ---
 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
 
@@ -14,7 +23,7 @@ description: Details about a security vulnerability identified in the Auth0 auth
 
 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. 
+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.
 
diff --git a/articles/security/bulletins/cve-2018-6874.md b/articles/security/bulletins/cve-2018-6874.md
index 084c78e0d3..c90b549af7 100644
--- a/articles/security/bulletins/cve-2018-6874.md
+++ b/articles/security/bulletins/cve-2018-6874.md
@@ -1,6 +1,15 @@
 ---
 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
 
@@ -12,21 +21,21 @@ description: Details about a security vulnerability identified in the Auth0 auth
 
 ## 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.
+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.
+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](/libraries/lock/v11/migration-guide#disabling-legacy-lock-api) in the Auth0 management dashboard is visible and flagged on.
+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.
+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-of-cross-origin-authentication)). Applications are also encouraged to [migrate to Universal Login](/guides/login/migration-embedded-universal).
+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.
 
diff --git a/articles/security/bulletins/cve-2018-7307.md b/articles/security/bulletins/cve-2018-7307.md
index 0704013d75..7887c5fd03 100644
--- a/articles/security/bulletins/cve-2018-7307.md
+++ b/articles/security/bulletins/cve-2018-7307.md
@@ -1,6 +1,15 @@
 ---
 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
 
diff --git a/articles/security/bulletins/cve-2019-13483.md b/articles/security/bulletins/cve-2019-13483.md
new file mode 100644
index 0000000000..c8cedc4767
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2019-16929.md b/articles/security/bulletins/cve-2019-16929.md
new file mode 100644
index 0000000000..5922b85b6c
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2019-20173.md b/articles/security/bulletins/cve-2019-20173.md
new file mode 100644
index 0000000000..884f10df9d
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2019-20174.md b/articles/security/bulletins/cve-2019-20174.md
new file mode 100644
index 0000000000..0c6c6a2cf0
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2019-7644.md b/articles/security/bulletins/cve-2019-7644.md
new file mode 100644
index 0000000000..19a9e1eb95
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2020-15084.md b/articles/security/bulletins/cve-2020-15084.md
new file mode 100644
index 0000000000..895eff253d
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2020-15119.md b/articles/security/bulletins/cve-2020-15119.md
new file mode 100644
index 0000000000..d86ffb1b10
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2020-15125.md b/articles/security/bulletins/cve-2020-15125.md
new file mode 100644
index 0000000000..075fe0240e
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2020-5263.md b/articles/security/bulletins/cve-2020-5263.md
new file mode 100644
index 0000000000..a7a282b891
--- /dev/null
+++ b/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/articles/security/bulletins/index.md b/articles/security/bulletins/index.md
index f42d3b8a67..63ad7bf6e1 100644
--- a/articles/security/bulletins/index.md
+++ b/articles/security/bulletins/index.md
@@ -2,6 +2,14 @@
 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
 ---
 
        
   
        
@@ -19,6 +27,20 @@ Each bulletin contains a description of the vulnerability, how to identify if yo
 
 | **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) |
diff --git a/articles/security/common-threats.md b/articles/security/common-threats.md
index 1c6aa5fb90..2da556c201 100644
--- a/articles/security/common-threats.md
+++ b/articles/security/common-threats.md
@@ -1,10 +1,23 @@
 ---
-description: This page describes different types of cyber attacks and what steps can be taken to prevent them.
+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
+## 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.
 
@@ -18,25 +31,33 @@ To help defend against this type of attack it is important to use strong encrypt
 
 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
 
-Another type of attacks is a replay attacks, also sometimes called a playback attack. With this type of network attack an attacker spies on a data exchange such as a login authentication, then the attacker takes this information to the receiver. This does not necessarily happen in real-time. With a replay attack the attacker gives the proof of identity by impersonating a user with stolen credentials.
+Replay attacks allow attackers to:
 
-### Preventing Replay Attacks
+* Gain access to a network and information which would not have been easily accessible 
+* Complete a duplicate transaction
 
-Replay attacks are usually avoided by using session tokens. But if these credentials are stolen from local storage (such as from an XSS attack), there are alternatives that you could use to avoid someone having infinite tokens:
+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. 
 
-1. Set expirations for tokens
-2. Provide a way to blacklist tokens that have been used (perhaps even a user)
+A replay attack is also known as a playback attack.
 
-The [JWT](/jwt) spec provides the `jti` field as a way to prevent replay attacks. Though Auth0 tokens don't currently don't return a jti, you can blacklist a jti to prevent a token being used more than X times. In this way you are kind of implementing a nonce (think of the token's signature as the nonce). If a token gets stolen, it should be blacklisted (or the nth token that has been issued after it) and wait for it to expire. Once it expires the attacker will no longer be able to impersonate the user.
+### Preventing Replay attacks
 
-Replay attacks can also be avoided by using one-time passwords. With Auth0 you can use [Passwordless Authentication](/passwordless) and only use one-time passwords instead of traditional passwords. Auth0 also provides [Multifactor Authentication](multifactor-authentication) which uses one-time passwords as a 2nd factor authentication which can be sent via push notifications, texts and more.
+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:
 
-## Cross-site Request Forgery (XSRF or CSRF)
+* 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
 
-This is a type of attack which occurs when a malicious program causes a user's web browser to perform an unwanted action on a trusted site that the user is currently authenticated. This type of attack specifically target 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.
+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.
 
-### Preventing Cross-site Request Forgery (XSRF or CSRF)
+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.
 
-One way to verify the requests that are being sent is to utilize the state parameter to authenticate the response. [Click here to learn more about using the state parameter.](/protocols/oauth-state)
+## 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/articles/security/index.md b/articles/security/index.md
index f6e1fb119d..829e78deb8 100644
--- a/articles/security/index.md
+++ b/articles/security/index.md
@@ -3,6 +3,14 @@ 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
 ---
 
 
        
@@ -22,8 +30,8 @@ description: Read about various security-related topics and keep up-to-date with
 ## Handling tokens
 
 <%= include('../_includes/_topic-links', { links: [
-  'security/store-tokens',
-  'tokens'
+  'tokens',
+  'tokens/concepts/token-storage'
 ] }) %>
 
 ## Preventing security attacks
diff --git a/articles/security/store-tokens.md b/articles/security/store-tokens.md
deleted file mode 100644
index 07c5890f51..0000000000
--- a/articles/security/store-tokens.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-description: Explains how to securely store tokens used in token-based authentication. 
----
-# Where to Store Tokens
-
- This document explains how to securely store tokens used in token-based authentication. The following assumes a basic knowledge of JSON Web Tokens (JWTs). To learn more about JWTs see:
-
- * [Auth0 Tokens](/tokens)
- * [JSON Web Tokens (JWT) in Auth0](/jwt)
-
-## Where to Store Your JWTs
-
-::: warning
-You __must__ [verify a JWT's signature](/tokens/id-token#verify-the-signature) before storing and using it.
-:::
-
-With token-based authentication, you are given the choice of where to store the JWT. We strongly recommend that you store your tokens in local storage/session storage or a cookie.
-
-### Web Storage (local storage/session storage)
-
-Commonly, the JWT is placed in the browsers local storage and this works well for most use cases. 
-
-When logging in a user with a username and password, the response body contains the `access_token` JWT. Then you need to handle this response in the client side code. This token can then be stored in localStorage or sessionStorage.
-
-[Click here for an example using sessionStorage](https://github.com/auth0-blog/angular-token-auth/blob/master/auth.client.js#L31)
-
-Both `localStorage` and `sessionStorage` both extend `Storage`. The only difference between them is the persistance of the data:
-
-`localStorage` - data persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
-
-`sessionStorage` - Changes made are saved and available for the current page, as well as future visits to the site on the same window. Once the window is closed, the storage is deleted.
-
-#### Web Storage Disadvantages
-
-* Unlike cookies, local storage is sandboxed to a specific domain and its data cannot be accessed by any other domain including sub-domains.
-* Web Storage is accessible through JavaScript on the same domain so any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks.
-* The developer must ensure that the JWT is always sent over HTTPS and never HTTP.
-
-### Using Cookies
-
-You can also use cookies to store the JWT. The exact way to set a cookie depends on the client side language you are using.
-
-There are different options to control the lifetime of a cookie:
-
-* Cookies can be destroyed after the browser is closed (session cookies).
-* Implement a server side check (typically done for you by the web framework in use), and you could implement expiration or sliding window expiration.
-* Cookies can be persistent (not destroyed after the browser is closed) with an expiration.
-* Cookies can be read by both the JavaScript and the server side code or only server side if the `httpOnly` flag is set.
-
-## Understanding Sessions and Cookies
-
-:::warning
-Please be sure to refer to the [Lock API documentation](/libraries/lock/v10/api) for the most up-to-date code snippets.
-:::
-
-<%= include('../_includes/_video', { id: 'paxlbixuya' }) %>
-
-This video will show you how to handle session data when building a web app. It will help you understand how your application uses cookies and sessions to manage the state of an authenticated user. This video example uses Node.js with Passport, but the techniques apply to any traditional server-based web application.
-
-#### Cookie Disadvantages
-
-*  The max size of a cookie is only 4kb so that may be problematic if you have many claims attached to the token.
-* Cookies can be vulnerable cross-site request forgery (CSRF or XSRF) attacks. This type of attack occurs when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site where the user is currently authenticated. This is an exploit of how the browser handles cookies. Using a web app framework’s CSRF protection makes cookies a secure option for storing a JWT. CSRF can also be partially prevented by checking the HTTP `Referer` and `Origin` header.
-*  Can be difficult to implement if the application requires cross-domain access. Cookies have additional properties (Domain/Path) that can be modified to allow you to specify where the cookie is allowed to be sent. 
-
-## How to implement
-
-Many of our Quickstarts demonstrate how to store tokens, and the exact implementation will be different based on the technology being used. Please refer to the Quickstarts at the top of our [Documentation Home Page](/), select the appropriate Quickstart based on your application type, and follow the code samples provided.
-
-## Keep reading
-
-::: next-steps
-* [Understanding Sessions & Cookies Video](/videos/session-and-cookies)
-* [Auth0 Blog: 10 Things You Should Know about Tokens](https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/)
-* [Auth0 Blog: Cookies vs Tokens: The Definitive Guide](https://auth0.com/blog/cookies-vs-tokens-definitive-guide/)
-:::
diff --git a/articles/services/_includes/_further-help.md b/articles/services/_includes/_further-help.md
new file mode 100644
index 0000000000..5aba279e75
--- /dev/null
+++ b/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/articles/services/architectural-design.md b/articles/services/architectural-design.md
index 5da814849e..8f842b97e7 100644
--- a/articles/services/architectural-design.md
+++ b/articles/services/architectural-design.md
@@ -1,5 +1,13 @@
 ---
 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
diff --git a/articles/services/auth0-advanced.md b/articles/services/auth0-advanced.md
deleted file mode 100644
index 33ca28c412..0000000000
--- a/articles/services/auth0-advanced.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-description: A training for advanced development on the Auth0 platform.
----
-
-# Training: Auth0 Advanced Topics
-
-A training for advanced development on the Auth0 platform. Target audience is developers and solution architects.
-
-
-## Duration
-
-Two (2) training sessions with an Auth0 Solutions Architect.
-
-
-## Level
-
-**Level 300-400**: deep dive into Auth0 platform capabilities. Course focuses on advanced topics, extensibility, performance optimizations and advanced integrations.
-
-## Topics covered
-
-Deep dive on architecture, extensibility points, proven practices for high performance, scalability, and high availability.
-
-<%= include('../_includes/_contact-sales') %>
diff --git a/articles/services/auth0-introduction.md b/articles/services/auth0-introduction.md
deleted file mode 100644
index ed992c0384..0000000000
--- a/articles/services/auth0-introduction.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-description: Training covering fundamentals of the Auth0 service.
----
-
-# Training: Auth0 Introduction
-
-This training course explains the fundamentals of Auth0 services. The intended audience is developers, solutions architects, security and infrastructure engineers.
-
-## Duration
-
-2 training sessions with an Auth0 Solutions Architect.
-
-## Level
-
-This course is **Level 200** and assumes basic or little knowledge of Auth0.
-
-## Topics covered
-
-* Auth0 Architecture
-* Deployment Models
-* Architecture Scenarios
-* Features
-* Platform extensibility points
-* Proven practices around identity providers, AD/LDAP Connector, API Authentication and Authorization, Anomaly Detection, SSO, Multifactor Authentication.
-
-<%= include('../_includes/_contact-sales') %>
diff --git a/articles/services/code-review.md b/articles/services/code-review.md
index 889c5d5477..03287053c2 100644
--- a/articles/services/code-review.md
+++ b/articles/services/code-review.md
@@ -1,5 +1,12 @@
 ---
 description: Project to help customers analyze common design patterns.
+topics:
+  - professional services
+  - code-review
+contentType:
+  - reference
+useCase:
+  - development
 ---
 
 # Advisory Sessions: Code Review
diff --git a/articles/services/custom-implementation.md b/articles/services/custom-implementation.md
new file mode 100644
index 0000000000..3046dec8f1
--- /dev/null
+++ b/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/articles/services/discover-and-design.md b/articles/services/discover-and-design.md
new file mode 100644
index 0000000000..8d1b6fcba7
--- /dev/null
+++ b/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/articles/services/implement.md b/articles/services/implement.md
new file mode 100644
index 0000000000..515db956b8
--- /dev/null
+++ b/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/articles/services/index.md b/articles/services/index.md
index 41206b1c76..4fbecde974 100644
--- a/articles/services/index.md
+++ b/articles/services/index.md
@@ -3,43 +3,70 @@ 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 on the Auth0 Platform. These offerings help customers deploy, implement and maintain solutions based on proven practices, avoiding common pitfalls and reducing risk.
+    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.
   
        
 
        
 
-## Assess & Plan
+## How Professional Services can help with your project
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/architectural-design',
-  'services/performance-scalability',
-  'services/scenario-guidance',
-  'services/code-review'
-] }) %>
+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. 
 
-## Maintain & Improve
+### Get to production faster
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/pair-programming',
-  'services/private-saas-configuration',
-  'services/code-review'
-] }) %>
+
          
 
-## Educate
+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: 
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/auth0-introduction',
-  'services/auth0-advanced',
-  'services/private-saas-management'
-] }) %>
+* **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.
 
-## Jumpstart
+* **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.
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/jumpstart'
-] }) %>
+* **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/articles/services/jumpstart.md b/articles/services/jumpstart.md
deleted file mode 100644
index 86338ccc3c..0000000000
--- a/articles/services/jumpstart.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-description: Focused project to help customers get started with Auth0 during their first year.
----
-
-# Jumpstart
-
-The Jumpstart consists of **4 phases** covering:
-
-* [Scenario Guidance](#scenario-guidance)
-* [Programming Advisory](#programming-advisory)
-* [Architectural Review](#architectural-review)
-* [Recommendations Review](#recommendations-review)
-
-## Scenario Guidance
-
-This activity is designed to help Auth0 understand your specific scenario requirements. Example scenarios include, but aren't limited to:
-
-* Single sign-on across different web applications
-* Mobile authentication
-* User-database migration
-* API authorization
-* Step-up authentication
-
-Please note that this activity is *not* intended to review your full business or solution architecture, nor will we review more than one scenario. Instead, we will focus on how you can integrate your solution with Auth0.
-
-::: note
-If you need a holistic review of your solution, please consider the [Architecture Design](/services/architectural-design) session offerings.
-:::
-
-The Scenario Guidance phase includes one working session, where we will jointly draft a high-level solution to address the requirements of your scenario. We will provide a recommendations memo afterwards for your reference.
-
-Diagrams or information you deem relevant should be provided prior to our session so that we can optimize the time available.
-
-## Programming Advisory
-
-The Programming Advisory phase includes a working sessions where an Auth0 Solutions Architect works with and provides guidance to your development team on topics like:
-
-* Auth0 tenant configuration
-* Auth0 extensibility endpoints
-* Your application integration with Auth0
-
-The goal of the Programming Advisory working session is to make sure you are getting the most out of Auth0's capabilities. The work done during this working session will focus on the scenario covered during the [Scenario Guidance](#scenario-guidance) session.
-
-We recommend completing the Programming Advisory sessions no more than **30 days** after you complete the Scenario Guidance session.
-
-## Architectural Review
-
-The Architectural Review phase includes one session designed to help you understand what needs to be completed prior to Productive go-live, as well as what needs to be done afterwards regarding your Auth0 integration and usage. Topics covered include:
-
-* The production checklist
-* Auth0 features 
-* Development lifecycle best practices
-* Engaging with the Auth0 Support Team
-
-We recommend completing Architectural Review session no more than **30 days** after you complete the [Programming Advisory](#programming-advisory) session.
- 
-## Recommendations Review
-
-The Recommendations Review session is focused on examining the findings and recommendations of the Jumpstart and formulating a plan for the next stages of your Auth0 implementation and rollout. Topic covered include:
-
-* Recommendations and action items from working sessions
-* Training and enablement needs
-* Future project milestones and deliverables
-* Project planning and guidance
-* Recommended resources and services
-
-The Jumpstart Closeout session will be completed no more than **15 days** after completion of the [Architectural Review](#architectural-review) session.
-
-<%= include('../_includes/_contact-sales') %>
diff --git a/articles/services/maintain-and-improve.md b/articles/services/maintain-and-improve.md
new file mode 100644
index 0000000000..6a65da44bb
--- /dev/null
+++ b/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/articles/services/packages.md b/articles/services/packages.md
new file mode 100644
index 0000000000..79947158d6
--- /dev/null
+++ b/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/articles/services/pair-programming.md b/articles/services/pair-programming.md
index d21e2fa722..a2aff15193 100644
--- a/articles/services/pair-programming.md
+++ b/articles/services/pair-programming.md
@@ -1,5 +1,12 @@
 ---
 description: Project to co-develop integration points with Auth0.
+topics:
+  - professional services
+  - pair-programming
+contentType:
+  - reference
+useCase:
+  - development
 ---
 
 # Advisory Sessions: Pair Programming
diff --git a/articles/services/performance-scalability.md b/articles/services/performance-scalability.md
index bcb02c9719..47ec47f31b 100644
--- a/articles/services/performance-scalability.md
+++ b/articles/services/performance-scalability.md
@@ -1,5 +1,13 @@
 ---
 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
diff --git a/articles/services/private-cloud-configuration.md b/articles/services/private-cloud-configuration.md
new file mode 100644
index 0000000000..023a05dd68
--- /dev/null
+++ b/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/articles/services/private-cloud-management.md b/articles/services/private-cloud-management.md
new file mode 100644
index 0000000000..9670cf91b2
--- /dev/null
+++ b/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/articles/services/private-saas-configuration.md b/articles/services/private-saas-configuration.md
deleted file mode 100644
index ad88337653..0000000000
--- a/articles/services/private-saas-configuration.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-description: A project to assist with design and deployment of a Private SaaS Auth0 environment.
----
-
-# Advisory Hours: Private SaaS reconfiguration
-
-A project to assist with the design, and deployment of a Private SaaS 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 SaaS 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/articles/services/private-saas-management.md b/articles/services/private-saas-management.md
deleted file mode 100644
index 9def269132..0000000000
--- a/articles/services/private-saas-management.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: A workshop designed to provide IT organizations with core Auth0 Private SaaS management concepts.
----
-
-# Training: Private SaaS Management Workshop
-
-A workshop designed to provide IT organizations with core concepts on availability, reliability, on-going operations and security in their Private SaaS 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/articles/services/scenario-guidance.md b/articles/services/scenario-guidance.md
index 61c366d784..fc211feb9e 100644
--- a/articles/services/scenario-guidance.md
+++ b/articles/services/scenario-guidance.md
@@ -1,5 +1,14 @@
 ---
 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
diff --git a/articles/services/solution-design.md b/articles/services/solution-design.md
new file mode 100644
index 0000000000..c693dd13f1
--- /dev/null
+++ b/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/articles/sessions/concepts/cookie-attributes.md b/articles/sessions/concepts/cookie-attributes.md
new file mode 100644
index 0000000000..72a9db75de
--- /dev/null
+++ b/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/articles/sessions/concepts/cookies.md b/articles/sessions/concepts/cookies.md
new file mode 100644
index 0000000000..cf6ce50b56
--- /dev/null
+++ b/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/articles/sessions/concepts/session-layers.md b/articles/sessions/concepts/session-layers.md
new file mode 100644
index 0000000000..d013992e1a
--- /dev/null
+++ b/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/articles/sessions/concepts/session-lifetime.md b/articles/sessions/concepts/session-lifetime.md
new file mode 100644
index 0000000000..2ae61eecaa
--- /dev/null
+++ b/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/articles/sessions/index.md b/articles/sessions/index.md
new file mode 100644
index 0000000000..d653876353
--- /dev/null
+++ b/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/articles/sessions/references/example-short-lived-session-mgmt.md b/articles/sessions/references/example-short-lived-session-mgmt.md
new file mode 100644
index 0000000000..4ad8a94cf1
--- /dev/null
+++ b/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/articles/sessions/references/sample-use-cases-sessions.md b/articles/sessions/references/sample-use-cases-sessions.md
new file mode 100644
index 0000000000..d6757b2d36
--- /dev/null
+++ b/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/articles/sso/current/inbound.md b/articles/sso/current/inbound.md
new file mode 100644
index 0000000000..3533e94697
--- /dev/null
+++ b/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/articles/sso/current/index.md b/articles/sso/current/index.md
index cffdd1abae..5ca58fe4e8 100644
--- a/articles/sso/current/index.md
+++ b/articles/sso/current/index.md
@@ -1,28 +1,115 @@
 ---
-title: Single Sign On (SSO) with Auth0
-description: Single Sign On (SSO) with Auth0
-classes: topic-page
+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 (SSO) with Auth0
-
-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.
-
-::: note
-[Universal login](/hosted-pages/login) is the easiest and most secure way to implement SSO with Auth0. If for some reason you cannot use universal login with your application, check out the [Lock](/libraries/lock) page or the [Auth0.js](/libraries/auth0js) page for more information on embedded authentication.
-:::
-
-
+
+# 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/articles/sso/current/index_old.md b/articles/sso/current/index_old.md
new file mode 100644
index 0000000000..065b76fe02
--- /dev/null
+++ b/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/articles/sso/current/introduction.md b/articles/sso/current/introduction.md
deleted file mode 100644
index a5618dabb9..0000000000
--- a/articles/sso/current/introduction.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-description: A brief introduction to Single Sign On (SSO) and an overview of how SSO works with Auth0.
-toc: true
----
-
-# Introduction to Single Sign On with Auth0
-
-## What is 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 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 logs in to one of Google's products are automatically logged in to their other products as well.
-
-Single Sign On 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.
-1. The user receives a Google Accounts-generated cookie.
-1. The user navigates to another Google product.
-1. The user is redirected again to Google Accounts.
-1. Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
-
-## What is Single Log Out?
-
-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.
-
-## 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 an example of how the SSO flow looks when using Auth0 and the [Lock](/libraries/lock) widget and a user visits your application for the first time:
-
-1. Your application will redirect the user to the login page where they can log in.
-1. Auth0 will check to see whether there is an existing SSO cookie.
-1. Because this is the first time the user visits this login 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, etc. (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)
-
-1. Once the user has logged in, Auth0 will set an SSO cookie
-1. 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 login page where they can sign in.
-1. Auth0 will check to see whether there is an existing SSO cookie.
-1. 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 who 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)
-
-1. Auth0 will update the SSO cookie if required
-1. 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 [Setup Single Sign On with Auth0](/sso/current/setup) tutorial.
-
-## SSO with Native Platforms
-
-Currently, SSO is only possible with native platforms (such as iOS or Android) if the application uses the universal login for authentication. The [Swift](/quickstart/native/ios-swift/00-login) and [Android](/quickstart/native/android/00-login) quickstarts provide some examples of usage of universal login for authentication from their respective platforms.
diff --git a/articles/sso/current/outbound.md b/articles/sso/current/outbound.md
new file mode 100644
index 0000000000..e2b83c2d38
--- /dev/null
+++ b/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/articles/sso/current/relevant-api-endpoints.md b/articles/sso/current/relevant-api-endpoints.md
new file mode 100644
index 0000000000..fb6e10f24f
--- /dev/null
+++ b/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/articles/sso/current/setup.md b/articles/sso/current/setup.md
deleted file mode 100644
index 604a94c803..0000000000
--- a/articles/sso/current/setup.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-description: Tutorial on implementing Single Sign On (SSO) with Auth0.
-toc: true
----
-
-# Set Up Single Sign On with Auth0
-
-This tutorial covers implementing Single Sign On (SSO) with Auth0.
-
-::: note
-For information on SSO Integrations, check out the [Single Sign On Integrations](/integrations/sso) page.
-:::
-
-## 1. Configure the Connection
-
-Before enabling SSO on a [Application](/applications), create and configure a Connection for each [Identity Provider](/identityproviders) you want to use.
-
-For Social Identity Providers ensure the Connection is not using [developer keys](/connections/social/devkeys).
-
-## 2. Enable SSO for the Application
-
-Navigate to the Applications section of the [Dashboard](${manage_url}/#/applications). Click on **Settings** (represented by the gear icon) for the Application to enable SSO on.
-
-![](/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)
-
-::: note
-You can also set the Application's SSO flag using the [Auth0 Management API](/api/management/v2#!/Clients/patch_clients_by_id).
-:::
-
-## 3. Configure SSO Session Length
-
-When the SSO flag is set for an Application, Auth0 maintains an SSO session for any user authenticating via that Application. The **SSO Cookie Timeout** setting determines how long an SSO session is valid. By default, an SSO session expires in 10080 minutes (or 7 days).
-
-To configure the **SSO Cookie Timeout** setting, navigate to [Dashboard > Tenant Settings > Advanced](${manage_url}/#/tenant/advanced).
-
-![](/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png)
-
-SSO session cookies expire after **3 days** of inactivity. For example, if no application (in the same browser) on a user's machine performs a login using the SSO session then the cookie expires after 3 days, even though a server side session might persist. Performing a new standard login would reset the SSO session.
-
-The session inactivity duration (3 days) and is not configurable on the Public Cloud. PSaaS Appliance users, however, can control this account-level setting.
-
-## 4. Check the User's SSO Status from the Application
-
-Whenever you need to determine the user's SSO status, you'll need to check the following:
-
-* The Auth0 `accessToken`, which is used to access the desired resource
-* The `expirationDate` on the `accessToken`, which is calculated using the `expires_in` response parameter after successful authentication on the part of the user
-
-If you don't have a valid `accessToken`, the user is **not** logged in. However, they may be logged in via SSO to another associated application. You can determine if this is the case or not by calling the `checkSession` method of the auth0.js SDK, which will attempt to silently authenticate the user within an iframe. Whether the authentication is successful or not indicates whether the user has an active SSO cookie.
-
-For more detailed information on how to implement this, please refer to [Client-Side SSO (Single Page Apps)](/sso/current/single-page-apps-sso).
-
-::: note
-The [Auth0 OIDC SSO Sample](https://github.com/auth0-samples/oidc-sso-sample) repo is an example of how to implement OIDC-compliant SSO.
-:::
diff --git a/articles/sso/current/single-page-apps.md b/articles/sso/current/single-page-apps.md
deleted file mode 100644
index c2c127ba2d..0000000000
--- a/articles/sso/current/single-page-apps.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-description: Tutorial on implementing client-side SSO on single page applications.
-toc: true
----
-
-# Client-Side SSO on Single Page Applications
-
-Single Page Applications (SPA) are user-friendly apps that load a single HTML page. This page then dynamically updates as the users interacts with the app. If your SPA is associated with other apps or sites that asks for authentication, you can implement OIDC-compliant Single Sign On to minimize the number of times the user has to provide their credentials. This ensures both the security of the process and ease of use from the perspective of the user.
-
-## What SSO Looks Like
-
-Suppose you have two applications:
-
-* App 1: `app1.com` (single page app)
-* App 2: `app2.com` (regular web app)
-
-If you've implemented SSO and the user logs in either of the two applications, the user should automatically be logged in to the other application.
-
-This article shows you how to implement OIDC-compliant Single Sign On via [Silent Authentication](/api-auth/tutorials/silent-authentication) for your Single Page Applications using [this sample](https://github.com/auth0-samples/oidc-sso-sample).
-
-## Configure the Sample Application
-
-::: warning
-This document assumes that you're using port `3000` when running the sample. If you are using a different port, you'll need to adjust for this as you work through the sample (specifically the `auth0-variables.js`, `callback.html`, and `index.js` files) and configure your Auth0 Application.
-:::
-
-If you don't already have an Auth0 Application (of type **Single Page Web Applications**) with the **OIDC Conformant** flag enabled, you'll need to create one.
-
-1. Go to the [Auth0 Dashboard](${manage_url}) and click on [Applications](${manage_url}/#/applications) in the left-hand navigation bar. Click **Create Application**.
-2. 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**. When done, click on **Create** to proceed.
-3. Navigate to the [Auth0 Application Settings](${manage_url}/#/applications/${account.clientId}/settings) page. Add `http://localhost:3000` and `http://localhost:3000/callback.html` to the Allowed Callback URLs field of your [Auth0 Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
-4. Scroll to the bottom of the [Settings](${manage_url}/#/applications/${account.clientId}/settings) page, where you'll find the **Advanced Settings** section. Under the **OAuth** tab, enable the **OIDC Conformant** Flag under the **OAuth** area of **Advanced Settings**.
-
-Now that you've configured your Auth0 Application, you can continue configuring your sample.
-
-1. Update the `auth0-variables.js` file included in the sample repository with your Auth0 Domain and the ID of the Auth0 Application you're using. These values can be found in your [Auth0 Application's Settings page](${manage_url}/#/applications/${account.clientId}/settings).
-2. Once you've made the configuration changes detailed in steps 2 and 3, start up a web server in the root of the repository at port `3000` .
-3. Browse to `http://localhost:3000` to view the client side of the sample.
-
-  ![Home page before logging in](/media/articles/sso/v2/spa/before-login.png)
-
-Please feel free to [download the sample](https://github.com/auth0-samples/oidc-sso-sample) and work through the examples on your local environment as you read this doc.
-
-## Silent Authentication
-
-Because applications cannot query Auth0 directly to determine if users are logged in via SSO, the apps must redirect users to Auth0 for SSO authentication. However, because users find redirection disruptive, you should avoid doing so. One way of doing this is via [Silent Authentication](/api-auth/tutorials/silent-authentication), which allows you to implement an authentication flow where Auth0 replies only with redirects and never presents a login page to your users.
-
-### Configure Silent Authentication
-
-To bypass displaying the Lock screen when logging in a user, you must:
-
-* Enable the **Use Auth0 instead of the IdP to do Single Sign On** flag in the [Auth0 Application's settings page](${manage_url}/#/applications/${account.clientId}/settings);
-* Have a SSO cookie for the tenant's domain (in other words, the user has previously signed in and their saved cookie is still valid);
-* Pass the name of the user's Connection to Auth0 for authentication. You can do this by:
-  * Including it as a parameter when calling the `signin` function of the [auth0.js library](/libraries/auth0js);
-  * Passing the `connection` query string parameter when calling the [Authentication API's `/authorize` endpoint](/api/authentication#implicit-grant).
-
-### Silent Authentication using the API
-
-To initiate a silent authentication request, include the `prompt` parameter in your [authorization URL](/api/authentication#implicit-grant) and set it to `none` when redirecting users to the [Authentication API's `/authorize` endpoint](/api/authentication#implicit-grant).
-
-```text
-https://${account.namespace}/authorize?
-    scope=YOUR_SCOPE&
-    response_type=YOUR_RESPONSE_TYPE&
-    client_id=4rO4qfTUOr1QafUxUGtGRYPqZfPVpuFa&
-    redirect_uri=https://YOUR_APP/callback&
-    nonce=YOUR_CRYPTOGRAPHIC_NONCE&
-    state=YOUR_OPAQUE_VALUE&
-    connection=CONNECTION_NAME&
-    prompt=none
-```
-
-:::note
-For details on the request parameters, refer to [How to implement the Implicit Grant](/api-auth/tutorials/implicit-grant#1-get-the-user-s-authorization).
-:::
-
-For requests received with the parameter `prompt=none`, Auth0 redirects to the `redirect_uri` specified. There are two possible outcomes:
-
-* If the user is already logged in via SSO, Auth0 sends a successful authentication response;
-* If the user is not logged in via SSO (and therefore Auth0 cannot silently authenticate the user), Auth0 sends an error response.
-
-Regardless of which outcome occurs, the sample app's [`postMessage()` function](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) sends Auth0's response from the iframe back to the main page, allowing it to act based on the response.
-
-### Silent Authentication using Auth0.js
-
-Users of the `Auth0.js` library have access to [the `checkSession()` method](/libraries/auth0js#using-checksession-to-acquire-new-tokens), which attempts to get a new token from Auth0 by using silent authentication or invokes callback with an error if the user does not have an active SSO session at your Auth0 domain.
-
-This method can be used to detect a locally unauthenticated user's SSO session status, or to renew an authenticated user's Access Token. The actual redirect to `/authorize` happens inside an iframe, so it will not reload your application or redirect away from it.
-
-```js
-auth0.checkSession({
-  audience: 'https://mystore.com/api/v2',
-  scope: 'read:order write:order'
-  }, function (err, authResult) {
-    // Renewed tokens or error
-});
-```
-
-## Run the Sample Application
-
-When you run the sample app for the first time, you will not have a valid Access Token. As such, the SSO login process errors when attempting silent authentication.
-
-![Prompt to begin silent authentication](/media/articles/sso/v2/spa/begin-silent-auth.png)
-
-You will then see the Lock screen, which allows you to provide the required credentials.
-
-![Lock screen](/media/articles/sso/v2/spa/lock.png)
-
-Once you've provided correct credentials, the app will indicate if you've successfully acquired a token.
-
-![Home page after logging in](/media/articles/sso/v2/spa/logged-in.png)
-
-If silent authentication succeeds, however, the app stores the token and its expiration date in your local storage.
-
-## Successful Authentication Response
-
-If the user is logged in via SSO already, Auth0 responds as if the user had manually authenticated using the SSO login page. You can extract the `access_token` from the hash fragment of the returned 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
-  // ...
-});
-```
-
-The response for a call made without the `prompt=none` parameter is indistinguishable from the response for a call made with the parameter.
-
-You can test this using the sample app. If you're already logged in, you can request an updated token by clicking the **Click here to renew it** link.
-
-At this point, the app silently authenticates you, gets the new token, and updates the page to reflect your new token expiration datetime. Notice that you did not see the Lock screen asking for your credentials.
-
-## Further Actions
-
-If your authentication flow triggers an error (indicating unsuccessful authentication) at any point, you'll need to [handle the error(s)](/api-auth/tutorials/silent-authentication#refresh-expired-tokens) before moving on.
-
-If your Access Tokens expire, you can use [Silent Authentication](/api-auth/tutorials/silent-authentication#refresh-expired-tokens) to get a new one.
-
-## Single Logout
-
-If the user logs out of `app1.com`, then you'll want the user's tokens cleaned up on `app2.com` and `app3.com`.
-
-To implement [Single Log Out](/logout), you need to check periodically to see if Auth0 has expired the SSO session. If so, remove the token from the application's local storage to ensure that the local session clears.
-
-```js
-// check every 15 minutes if the SSO session is still active
-
-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.checkSession(function (err, data) {
-    if (err) { 
-      // 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';
-    }
-  });
-}, 900000)
-```
diff --git a/articles/sso/current/sso-auth0.md b/articles/sso/current/sso-auth0.md
new file mode 100644
index 0000000000..fa8aef4898
--- /dev/null
+++ b/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/articles/sso/legacy/index.md b/articles/sso/legacy/index.md
index fc21aadb9d..8283021d59 100644
--- a/articles/sso/legacy/index.md
+++ b/articles/sso/legacy/index.md
@@ -1,18 +1,24 @@
 ---
 toc: true
-description: Introduction to Single Sign On (SSO) with Auth0.
+description: Introduction to Single Sign-on (SSO) with Auth0.
+topics:
+  - sso
+contentType:
+  - index
+useCase:
+  - integrate-saas-sso
 ---
-# What is Single Sign On?
+# 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).
+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.
 
-Single Sign On 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:
+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.
@@ -33,7 +39,7 @@ Let's look at how the SSO flow looks when using Auth0 and a user visits your app
     ![](/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.
+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:
 
@@ -44,7 +50,7 @@ Now let's look at flow when the user returns to your website for a subsequent vi
     ![](/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.
+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.
 
@@ -54,11 +60,11 @@ If an SSO cookie is present you can also sign the user in silently, that is, wit
 Prior to enabling SSO for a given Application, you must first [configure the Identity Provider(s)](/identityproviders) you want to use.
 :::
 
-To enable 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.
+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**.
+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)
 
@@ -70,24 +76,24 @@ The result of this function will indicate whether an SSO cookie is present, and
 
 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)
+* [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.
+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 Log Out?
+## 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 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
 
@@ -95,7 +101,7 @@ See the [Logout URL docs](/logout) for information on terminating the first two
 
 ## Using Social Identity Providers
 
-Single Sign On works with Social Identity Providers given the following conditions:
+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
+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/articles/sso/legacy/regular-web-apps-sso.md b/articles/sso/legacy/regular-web-apps-sso.md
index b8884ac304..3f8fc043fc 100644
--- a/articles/sso/legacy/regular-web-apps-sso.md
+++ b/articles/sso/legacy/regular-web-apps-sso.md
@@ -1,22 +1,30 @@
 ---
 toc: true
-description: Server-side SSO with regular web applications.
+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 SSO (Regular Web Apps)
+# 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. An 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.
+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 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.
@@ -25,7 +33,7 @@ In this document we will be looking specifically how to achieve this in a Regula
 
 ## 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:
+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
diff --git a/articles/sso/legacy/single-page-apps.md b/articles/sso/legacy/single-page-apps.md
index 3a1c1d004f..e726c4d78a 100644
--- a/articles/sso/legacy/single-page-apps.md
+++ b/articles/sso/legacy/single-page-apps.md
@@ -1,8 +1,16 @@
 ---
-description: Client-side SSO with single page applications.
+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 SSO (Single Page Apps)
+# 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).
@@ -10,21 +18,21 @@ This document covers an outdated version of the Auth0 authentication pipeline. W
 
 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. An 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.
+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 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. 
+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
+In this document we will be looking specifically how to achieve this in a Single-Page (JavaScript) Application
 
 ## Obtaining the SSO cookie information  
 
@@ -56,7 +64,7 @@ This function will return an `ssoData` object which will indicate whether an act
 
 ## 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. 
+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
@@ -75,7 +83,7 @@ auth0.getSSOData(function (err, ssoData) {
 
 ## 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. 
+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)
 
@@ -98,7 +106,7 @@ The full code sample for both the SPA applications as well as the normal web app
     callbackOnLocationHash: true
   });
 
-  // Handle authenticated event to store id_token in localStorage
+  // Handle authenticated event to store ID Token in localStorage
   lock.on("authenticated", function (authResult) {
     isAuthCallback = true;
 
@@ -158,7 +166,7 @@ The full code sample for both the SPA applications as well as the normal web app
 
 ## 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 Log Out](/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.
 
diff --git a/articles/support/_delete-tenant.md b/articles/support/_delete-tenant.md
index a4352edc6b..339c60adc2 100644
--- a/articles/support/_delete-tenant.md
+++ b/articles/support/_delete-tenant.md
@@ -1,21 +1,21 @@
-## Delete your Auth0 Tenant
+## 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
-This action cannot be undone.
+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 bring up the associated dropdown box.
-
-![](/media/articles/subscriptions/dashboard.png)
-
+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 is open, click on the **Advanced** tab.
+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**.
 
-![](/media/articles/subscriptions/advanced.png)
+### For enterprise customers
 
-5. Scroll down to the **Danger Zone** at the bottom of the page, and click **Delete**.
+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.
 
-![](/media/articles/subscriptions/danger-zone.png)
+### For paid subscription customers
 
-This process deletes only one tenant. If you have other tenants that need to be removed, you will need to manually delete them as well.
+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/articles/support/_reset-tenant.md b/articles/support/_reset-tenant.md
new file mode 100644
index 0000000000..f055220c71
--- /dev/null
+++ b/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/articles/support/cancel-paid-subscriptions.md b/articles/support/cancel-paid-subscriptions.md
index 2736008d61..df35bb82d8 100644
--- a/articles/support/cancel-paid-subscriptions.md
+++ b/articles/support/cancel-paid-subscriptions.md
@@ -1,19 +1,28 @@
 ---
 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
+# Cancel Your Auth0 Subscription
 
-If you wish to cancel your Auth0 subscription, you have two options:
+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.
+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 a Paid Subscription to a Free Subscription
+## 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 bring up the associated dropdown box.
+2. Click on your tenant name in the top right corner to display the  dropdown box.
 
 ![](/media/articles/subscriptions/dashboard.png)
 
diff --git a/articles/support/delete-reset-tenant.md b/articles/support/delete-reset-tenant.md
index a590762ede..5b89c4de31 100644
--- a/articles/support/delete-reset-tenant.md
+++ b/articles/support/delete-reset-tenant.md
@@ -1,13 +1,35 @@
 ---
-description: How to manage your tenant
+description: How to delete or reset your tenant
+topics:
+    - support
+    - delete-tenant
+    - reset-tenant
+    - tenants
+contentType:
+  - how-to
+useCase:
+  - support
 ---
 
-# Delete/Reset Your Tenant
+# Delete or Reset Tenants
 
-Using the [Reset Tenant Extension](https://github.com/auth0-extensions/auth0-reset-tenant), you can programmatically make changes to your Auth0 tenant. Not only is this useful for creating new environments for development or test purposes, you can use the extension to "clean" your tenant and remove unwanted items.
+::: 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.
+:::
 
-## Delete vs. Reset
+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.
 
-In some cases, users have opted to delete their tenant to begin with a clean slate. Unfortunately, doing so means that you don't keep your tenant name. Because tenant names have to be unique, they can only used once. As such, we recommend using the Reset Tenant Extension to remove the unwanted items and return your tenant to its initial state, since this means that you do *not* have to start over with a new 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/articles/support/how-auth0-versions-software.md b/articles/support/how-auth0-versions-software.md
index 20afa715b9..0d3109b493 100644
--- a/articles/support/how-auth0-versions-software.md
+++ b/articles/support/how-auth0-versions-software.md
@@ -1,6 +1,14 @@
 ---
 title: How Auth0 versioning works
-description: This page explains how Auth0 versioning works.
+description: Understand how Auth0 versioning works.
+topics:
+    - support
+    - auth0-versioning
+    - versioning
+contentType:
+  - reference
+useCase:
+  - support
 ---
 # Versioning
 
@@ -9,7 +17,7 @@ We believe versioning is a crucial part of our offering. By providing a consiste
 ## Semantic versioning
 
 ::: note
-This scheme is used in [Auth0 Lock](https://github.com/auth0/lock), [Auth0 AD Connector](https://github.com/auth0/ad-ldap-connector), [Auth0.js](https://github.com/auth0/auth0.js) and SDKs.
+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. 
@@ -20,9 +28,9 @@ This scheme is used in [Auth0 Lock](https://github.com/auth0/lock), [Auth0 AD Co
 
 More information about this versioning scheme can be found at [semver](http://semver.org)
 
-### Production Usage
+### 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, Auth0 Lock can be found at the following URLs:
+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
 
@@ -35,8 +43,6 @@ Auth0 provides links to our [Content Delivery Network (CDN)](https://en.wikipedi
 
 ```
 
-If you link to the major release (the first script) and we release 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. 
-
 **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
diff --git a/articles/support/index.md b/articles/support/index.md
index 9892b029df..d579b97fee 100644
--- a/articles/support/index.md
+++ b/articles/support/index.md
@@ -2,6 +2,12 @@
 url: /support
 toc: true
 description: Explains the different types of support options provided by Auth0.
+topics:
+    - support
+contentType:
+  - index
+useCase:
+  - support
 ---
 # Support Options
 
@@ -14,7 +20,7 @@ Auth0 offers the following support plans:
 
-      
+      
@@ -25,16 +31,22 @@ Auth0 offers the following support plans:
       
+    
+      
+      
+    
-      
+      
        
   
     
        No PlanCommunity Support
       Customers with Auth0's free subscription plan can seek support through the Auth0 Community.
     
        
     
        Enterprise Support
       For 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.For customers with an Enterprise subscription plan that have added the Preferred Support option. This offering is no longer for sale.
     
        
           
 
        
 
-### No Support
+### 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.
 
-Customers with Auth0's free 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})).
@@ -51,11 +63,9 @@ Customers with a paid Auth0 subscription plan receive Standard Support, which of
 
 The Auth0 Support Center offers ticketed support, where support specialists are available to provide assistance.
 
-### Enterprise Support (with or without Preferred Support)
+### Enterprise Support (with or without Premier Support)
 
-Customers with an Enterprise subscription plan receive extended support hours for outages, quicker response times, and Auth0 Sprint onboarding assistance.
-
-Please contact the [Auth0 Sales Team](https://auth0.com/?contact=true) if you have specific support requirements or are interested in the Enterprise Support Plan (with or without the Preferred Support option).
+Customers with an Enterprise Subscription Plan receive extended support hours for outages, quicker response times, and access to the Customer Success Team.
 
 ## Support Channels
 
@@ -63,7 +73,7 @@ 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 existing through questions and post a new question if theirs hasn't been answered. There are no guaranteed response times for questions posted.
+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
 
@@ -77,7 +87,7 @@ Critical Production issues should always be reported via the [Support Center](ht
 
 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}).
 
-You can add support-only users via the Support Center. Click on your name in the top right, and click **Support Center Users**.
+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)
 
@@ -99,22 +109,28 @@ Using this page, you can:
 
 ## Program Features
 
-The Support Program applies to **production instances** of the Auth0 Platform only. If you require support for non-production instances, then you may request [Demand Services](#demand-services) from Auth0.
+Your Sales Order will indicate whether you are subscribed to the **Standard** Support Program, **Enterprise** Support Program, or **Premier** Support Program.
 
-Your Sales Order will indicate whether you are subscribed to the **Standard** Support Program or the **Enterprise** Support Program. The features of each program are as follows:
+The following features are provided with **every** support plan:
 
-| Support Feature | Standard | Enterprise/Preferred |
-| - | - | - |
-| Answer questions concerning usage issues related to Auth0 Platform specific features, options and configurations | Yes | Yes |
-| Provide initial and high-level suggestions regarding the appropriate usage, features, or solution configurations for the particular type of reporting, analysis, or functionality | Yes | Yes |
-| Isolate, document, and find alternative solutions for reported Defects | Yes | Yes |
-| 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 | Yes | Yes |
-| Address your concerns with online or printed documentation, providing additional examples or explanation for concepts requiring clarification | Yes | Yes |
-| Access to online release notes for Updates | Yes | Yes |
-| Access to Auth0’s online library of Support webinars and knowledgebase | Yes | Yes |
-| Access to Auth0’s Customer Community forums to collaborate with fellow Auth0 customers | Yes | Yes |
-| Enhanced Response Times | No | Yes |
-| Enhanced Hours of Support | No | Yes |
+- 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
 
@@ -151,12 +167,12 @@ Auth0 will assign all Defects one of four response priorities, dependent upon th
 
 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 Reponse Time | Enterprise Target Response Time | Preferred 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 | 
        • 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) | 
        • 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) | 
        • 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) | 
        • Answer to question is provided.
          •  
        • Enhancement request logged.
         |
+| 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
 
@@ -164,9 +180,9 @@ 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 |
-| - | - |
-| 6AM to 6PM (your local time) Monday to Friday | 24 hours a day, Monday to Friday (your local time) |
+| 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
 
@@ -176,10 +192,6 @@ We provide all technical support in English, but we will make an effort to accom
 
 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.
 
-## Demand Services
-
-You may from time to time request assistance from Auth0 for services that are outside the scope of the Support Program.  Auth0 will make resources available for mutually agreeable time periods to provide such assistance.  Auth0 will invoice you, and you will pay for these services (“Demand Services”) at Auth0’s then applicable rates, or such other rates as may be agreed in writing between Auth0 and you, plus any applicable expenses.
-
 ## 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).
diff --git a/articles/support/matrix.md b/articles/support/matrix.md
index 133a987c81..1d8783c5bc 100644
--- a/articles/support/matrix.md
+++ b/articles/support/matrix.md
@@ -3,6 +3,13 @@ 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
 
@@ -55,7 +62,7 @@ Throughout this article, we will use the following terms to indicate the varying
 
 ## Browsers
 
-This section covers the browsers that Auth0 will support when using the Auth0 Dashboard or Lock Library, or executing authentication transactions.
+This section covers the browsers that Auth0 will support when using the Auth0 Dashboard or Lock Library, or executing authentication transactions.
 
 ### Auth0 Dashboard
 
@@ -75,10 +82,6 @@ This section covers the browsers that Auth0 will support when using the Auth0 Da
       Apple Safari (Latest version)
       
        Sustained
        
     
-    
-      Microsoft Internet Explorer 11
-      
        Sustained
        
-    
     
       Microsoft Edge (Latest version)
       
        Sustained
        
@@ -152,7 +155,7 @@ At this time, Auth0 only supports use of the Dashboard with desktop browsers.
 
 ## Operating Systems
 
-This section covers the operating systems (OS) that Auth0 will support when using the Auth0 Dashboard, Lock Library or executing authentication transactions.
+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.
@@ -210,8 +213,6 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
 
 ## SDKs and Libraries
 
-<%= include('../_includes/_lock_auth0js_deprecations_notice') %>
-
 ### Auth0 Lock Widgets
 
 <%= include('../_includes/_libraries_support_lock') %>
@@ -254,7 +255,7 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
   
   
     
-      Wordpress
+      WordPress
       
        Supported
        
     
     
@@ -287,23 +288,18 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
        Supported
        
     
     
-      Electron
-      
-      
        Supported
        
-    
-    
-      Ionic
-      
-      
        Supported
        
+      Cordova
+      
+      
        Supported
        
     
-    
-      Ionic 2
-      
-      
        Supported
        
+        
+      Device Authorization Flow
+      
+      
        Supported
        
     
     
-      iOS - Objective-C
-      
+      Ionic 4
+      
       
        Supported
        
     
     
@@ -312,59 +308,29 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
        Supported
        
     
     
-      React Native - Android
-      
-      
        Supported
        
-    
-    
-      React Native - iOS
-      
+      React Native
+      
       
        Supported
        
     
-    
-      Chrome Extension
-      
-      
        Community
        
-    
-    
-      Cordova
-      
-      
        Community
        
-    
-    
-      Phonegap
-      
-      
        Community
        
-    
     
       Windows Universal App C#
-      
-      
        Community
        
+      
+      
        Supported
        
     
-    
-      Windows Universal App JavaScript
-      
-      
        Community
        
-    
-    
-      Windows Phone
-      
-      
        Community
        
-    
-    
+        
       WPF/Winforms
-      
-      
        Community
        
+      
+      
        Supported
        
     
     
       Xamarin
-      
-      
        Community
        
+      
+      
        Supported
        
     
   
 
 
-### Single Page Applications
+### Single-Page Applications
 
 
@@ -376,12 +342,7 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
   
-      
-      
-      
-    
-    
-      
+      
@@ -390,41 +351,16 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
        
   
   
     
        AngularJS
        Supported
        Angular (2+)Angular
       
       
        Supported
        		
     
        
       
        Supported
        		
     
        jQuery
        Supported
        
     
        
       React
       
       
        Supported
        		
     
        Socket.io
        Supported
        
     
        
       Vue.js
       
       
        Supported
        		
     
        Aurelia
        Community
        Cycle.js
        Community
        Ember
        Community
        
           
 
        
 
@@ -445,12 +381,12 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
        Supported
        
     
     
-      ASP.NET (System.Web)
-      
+      ASP.NET Core v2.1
+      
       
        Supported
        
     
-    
-      ASP.NET Core
+        
+      ASP.NET Core v3.1
       
       
        Supported
        
     
@@ -465,13 +401,8 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
        Supported
        
     
     
-      Java Spring MVC
-      
-      
        Supported
        
-    
-    
-      Java Spring Security
-      
+      Java Spring Boot
+      
       
        Supported
        
     
     
@@ -489,16 +420,6 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
       
        Supported
        
     
-    
-      PHP (Symfony)
-      
-      
        Community
        
-    
-    
-      Play 2 Scala
-      
-      
        Community
        
-    
     
       Python
       
@@ -509,21 +430,6 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
       
        Supported
        
     
-    
-      Apache
-      
-      
        Community
        
-    
-    
-      NancyFX
-      
-      
        Community
        
-    
-    
-      ServiceStack
-      
-      
        Community
        
-    
   
 
 
@@ -553,11 +459,6 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
       
        Supported
        
     
-    
-      Hapi.js
-      
-      
        Community
        
-    
     
       Java Spring Security
       
@@ -574,40 +475,20 @@ Auth0 support is limited to the most recent version of the OS listed (unless oth
       
        Supported
        
     
     
-      Laravel
+      Laravel
       
       
        Supported
        
     
-    
-      Symfony
-      
-      
        Community
        
-    
     
       Python
       
       
        Supported
        
     
-    
-      Ruby
-      
-      
        Community
        
-    
     
       Ruby on Rails
       
       
        Supported
        
     
-    
-      Falcor
-      
-      
        Community
        
-    
-    
-      Relay
-      
-      
        Community
        
-    
   
 
 
diff --git a/articles/support/removing-auth0-exporting-data.md b/articles/support/removing-auth0-exporting-data.md
index edc384f0c4..c9cc3013e5 100644
--- a/articles/support/removing-auth0-exporting-data.md
+++ b/articles/support/removing-auth0-exporting-data.md
@@ -1,24 +1,32 @@
 ---
 description: How to export data out of Auth0.
+topics:
+    - support
+    - data
+    - data-export
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
 ---
 
-# Moving out of Auth0
+# 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 are the password hashes of your [Auth0-hosted database users](/connections/database) and private keys, for security reasons.
-You can still request this information by opening a [support ticket](${env.DOMAIN_URL_SUPPORT}). Please note that in order to make this request you must be signed in to the Developer plan for one month.
+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.
 
-## Keeping user credentials on your infrastructure
+## 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).
 
-## I don't want to use proprietary Auth0 components
+## If you don't want to use proprietary Auth0 components
 
-Auth0 mainly uses [OpenID Connect as its authentication protocol](/protocols), so you should be able to implement an integration to your application using standard libraries.
-The same applies when [integrating Auth0 through SAML](/saml-configuration).
+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/).
+All of Auth0's SDKs, libraries, and samples [are published on GitHub as free software](https://github.com/auth0/).
 
 ## Social identity providers
 
@@ -26,9 +34,9 @@ If you choose not to use Auth0 but keep using the same OAuth client IDs and secr
 
 ## Custom code
 
-All of Auth0's custom code features (rules, custom database scripts, custom OAuth connections, and so on) run on [Webtask](https://webtask.io/), which is a Node.js sandbox service.
-In the vast majority of cases, Webtask code is also valid Node.js code or can be adapted with minimal effort.
-All libraries available on Webtask are also available on npm for use with standard Node.js 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
 
diff --git a/articles/support/reset-account-password.md b/articles/support/reset-account-password.md
index 11b0638691..05c72bd204 100644
--- a/articles/support/reset-account-password.md
+++ b/articles/support/reset-account-password.md
@@ -1,28 +1,32 @@
 ---
-description: How to reset your Auth0 account password
+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 Your Auth0 Account Password
+# Reset Auth0 Account Password
 
-You can reset the password associated with your Auth0 account at any time by invoking the password reset flow.
+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. If you are already logged in to your Auth0 account, click on your username in the top right corner. Select **Logout**.
+1. On the Auth0 account login screen, click **Don't remember your password?**
 
-    ![Management Dashboard Logout](/media/articles/tutorials/reset-password/logout.png)
+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.
 
-2. When you see the log in screen, click **Don't remember 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."
 
-    ![Management Dashboard Logout](/media/articles/tutorials/reset-password/login-screen.png)
+## Special password reset circumstances
 
-3. Provide your email address and click the **right arrow** to submit. You will receive an email that provides further instructions on resetting your password.
+- 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).
 
-    ![Management Dashboard Logout](/media/articles/tutorials/reset-password/provide-email.png)
+## Keep reading
 
-4. If your request was successfully received, you'll be directed back to the log in screen with a message that says, "We've just sent you an email to reset your password."
-
-    ![Management Dashboard Logout](/media/articles/tutorials/reset-password/message-sent.png)
-
-::: note
-If you have enabled multifactor authentication and you need your account reset, please [contact Support](${env.DOMAIN_URL_SUPPORT}).
-:::
+* [Customize Hosted Password Reset Page](/universal-login/password-reset)
diff --git a/articles/support/sla.md b/articles/support/sla.md
deleted file mode 100644
index c9fb5c1b1a..0000000000
--- a/articles/support/sla.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-description: Details on SLA for enabled subscribers.
----
-
-# SLA
-
-Auth0 guarantees a monthly uptime percentage of **99.9%**. 
-
-::: note
-At additional cost, Auth0 offers a __99.95%__ uptime service level agreement guarantee to subscribers enabling it in their subscription.
-:::
-
-The specifics of the Auth0 SLA are below:
-
-## Definitions
-* "Downtime" is period of at least 1 minute in which there is more than a five percent authentication error rate, as measured by a 3rd party service monitoring service such as Pingdom. Downtime is measured based on the backend server side error rate.
-* "Monthly Uptime Percentage" means total number of minutes in a calendar month minus the number of minutes of Downtime suffered in a calendar month (other than Permitted Downtime), divided by the total number of minutes in a calendar month.
-* “Permitted Downtime” has the meaning set forth in Section III on this Schedule.
-* “Non-Permitted Downtime” means any downtime that is not Permitted Downtime.
-* “SLC” means service level credits (calculated as set forth below) that Auth0 will credit at the end of the Service term, at no charge to Subscriber.
-
-## Subscription Services Availability
-
-During the Term of the Agreement, the Subscription Services will be operational and available to Subscriber at least 99.9% of the time in minutes in any calendar month (referred to as “Availability”).
-
-If Auth0 fails to meet its Availability service level due to circumstances not listed within one of the exception in Section III below, and if Subscriber meets its obligations under the Agreement, Subscriber shall be eligible to receive service level credits (“SLCs”) as set forth in Section IV below.
-
-Auth0 will publish a monthly report describing Service availability on [uptime.auth0.com](http://uptime.auth0.com/749624).
-
-## Exceptions
-
-Subscriber shall receive no SLCs in connection with any unavailability of the Subscription Services caused by any one or more of the following (referred to as “Permitted Downtime”):
-
-* Circumstances beyond Auth0’s reasonable control, including the Force Majeure Events;
-* Defects in software or hardware owned or controlled by Subscriber causing downtime.
-
-## Service Level Credits
-
-Auth0 shall apply the following Service Level Credits
-
-| Monthly Uptime Percentage | Days of Service added to the end of the Service term, at no charge to Customer |
-| :---: | :---: |
-| < 99.9% - >= 99.0% | 3 |
-| < 99.0%  - >= 95.0% | 7 |
-| < 95.0% | 15 |
-
-Availability is calculated as follows:
-
-![](/media/articles/sla/availability.svg)
-
-If you require a different SLA or a dedicated instance of Auth0 in your own IT environment [contact sales](https://auth0.com/?contact=true).
diff --git a/articles/support/sld.md b/articles/support/sld.md
new file mode 100644
index 0000000000..ac13357746
--- /dev/null
+++ b/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/articles/support/subscription.md b/articles/support/subscription.md
index 9885213018..bda497694e 100644
--- a/articles/support/subscription.md
+++ b/articles/support/subscription.md
@@ -1,6 +1,14 @@
 ---
 title: Change or Upgrade Your Auth0 Subscription
-decription: How to upgrade or change 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
 
@@ -24,7 +32,7 @@ You can use the [Management Dashboard](${manage_url}) to upgrade your subscripti
 * 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/?contact=true).
+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.
@@ -37,7 +45,7 @@ To select a new plan, click **Checkout** in the associated box to upgrade. If yo
 
 Click **Subscribe Now** to confirm your information and activate your new subscription.
 
-## Downgrade a paid subscription to a free subscription
+## Downgrade to a free subscription
 
 On the **Subscription** tab, scroll down to the box associated with the **Free** plan and click **Checkout**.
 
diff --git a/articles/support/testing.md b/articles/support/testing.md
index 5dad0a7ff7..cf2c67b86a 100644
--- a/articles/support/testing.md
+++ b/articles/support/testing.md
@@ -1,6 +1,15 @@
 ---
 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
@@ -32,7 +41,7 @@ There are a number of third-party testing tools that you can use for performance
 
 * [Apache JMeter](http://jmeter.apache.org/)
 * [Artillery](https://artillery.io/)
-* [Micro Focusa LoadRunner](https://www.radview.com/)
+* [Micro Focus LoadRunner](https://www.radview.com/)
 * [Loader](https://loader.io/)
 * [RadView Webload](https://www.radview.com/)
 * [SmartBear LoadUI](https://smartbear.com/)
@@ -43,12 +52,4 @@ These tools should provide activity logs that help you identify anything that is
 
 ### 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.
-
-## Testing Rules and Custom Database Connections
-
-If you would like to automate the testing of [Rules](/rules) or [Custom Database Connections](/connections/database/custom-db), there are a couple of NPM packages that can assist you with this.
-
-The [auth0-rules-testharness](https://www.npmjs.com/package/auth0-rules-testharness) package provides an easy way to deploy, execute, and test the output of Auth0 Rules using a real webtask sandbox environment.
-
-The [auth0-custom-db-testharness](https://www.npmjs.com/package/auth0-custom-db-testharness) package provides an easy way to deploy, execute, and test the output of Auth0 Custom DB Scripts using a real webtask sandbox environment.
+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/articles/support/tickets.md b/articles/support/tickets.md
index 6e31e60586..f2a7253f40 100644
--- a/articles/support/tickets.md
+++ b/articles/support/tickets.md
@@ -1,35 +1,49 @@
 ---
-decription: How to open and manage tickets with Support Center.
+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 PSaaS Appliance 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 Customer Success Manager or Sales Executive to associate your cloud-based account to your existing PSaaS Appliance subscription.
+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 **Contact Support** button. If you don't see this button, then you do not have access to support (only paying and trial customers have). In this case you can use our [Community](https://community.auth0.com/) instead (click **Ask our Community**).
+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 the **Affected Account** from the dropdown menu.
-1.  Under **What can we help you with?** select the type of issue that best fits your case.
+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)
-    * **Auth0 Service Issue** - Choose this if something isn’t working correctly or you need help using a feature or getting something working.
-        * With Service Issues, you will be asked to select a severity:
-            *  **Low: Product Question** - You have questions about how things work, whether we support something
+    * **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
-        *  You will then be asked to choose an option under "What is the service issue related to?"
-            *  _You may be prompted for additional information depending on your selection._
-    * **Billing, Payments, or Account Issues** - You are experiencing issues such as incorrect billing, charges to the incorrect account, and so on
-    * **Auth0 Service Feedback** - You would like to suggested product improvements or enhancement requests
-    * **Vulnerability Reports or Legal Issues** - You would like to report security vulnerabilities or legal questions
-    * **Other** - You have a question that does not fall under any of the above categories
+        *  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 (if applicable):
+    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?
diff --git a/articles/support/troubleshooting-with-har-files.md b/articles/support/troubleshooting-with-har-files.md
deleted file mode 100644
index 7699e1c8b9..0000000000
--- a/articles/support/troubleshooting-with-har-files.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-description: How to troubleshoot with HAR files and steps to generate a HAR file.
----
-
-# Troubleshooting with HAR files
-
-Sometimes during development the authentication flow doesn't work as expected.
-
-The fastest way to identify the underlying issue is to export a `HAR` file from Google Chrome Dev Tools. An **HTTP Archive (HAR) format** file, is a JSON formatted log file of all web browser interactions with web servers.
-
-## Generating a HAR file:
-
-1. Close all __incognito__ windows from Google Chrome.
-1. Open a __new incognito__ tab on Google Chrome.
-1. Open __Google Chrome Developers Tools__ on the new Incognito Window and click the Network Tab. Make sure you check the __Preserve Log__ options to record all interactions.
-1. Proceed with the navigation that presents issues.
-1. When complete, go back to the __Network__ tab, right click and then select **Save as HAR with Content**: ![Google Dev Tools](/media/articles/tutorials/save-as-har-with-content.png)
-1. Before sending the HAR file to us, make sure to obfuscate any sensitive information using a text editor (such as remove passwords, client secrets, and so on).
-1. Send the file to support by opening a [support ticket](${env.DOMAIN_URL_SUPPORT})
diff --git a/articles/tokens/_includes/_rtr_enabled.md b/articles/tokens/_includes/_rtr_enabled.md
new file mode 100644
index 0000000000..3b92633b1c
--- /dev/null
+++ b/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/articles/tokens/_includes/_validate-id-token.md b/articles/tokens/_includes/_validate-id-token.md
new file mode 100644
index 0000000000..92aa63be6b
--- /dev/null
+++ b/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/articles/tokens/access-token.md b/articles/tokens/access-token.md
deleted file mode 100644
index 0dd2113eeb..0000000000
--- a/articles/tokens/access-token.md
+++ /dev/null
@@ -1,212 +0,0 @@
----
-title: Access Token
-description: Learn what Access Tokens are and how you can use them with Auth0.
-toc: true
----
-# Access Token
-
-## Overview
-
-The Access Token is a credential that can be used by an application to access an API. 
-
-It can be any type of token (such as an opaque string or a JWT) and is meant for an API. Its purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the **scope** that has been granted). 
-
-The Access Token should be used as a **Bearer** credential and transmitted in an HTTP **Authorization** header to the API. 
-
-## Access Token format
-
-Auth0 currently generates Access Tokens in two formats: as opaque strings or as [JSON Web Tokens (JWTs)](/jwt).
-
-This depends on the value that the **audience** parameter has in the [authorization request](/api/authentication#authorize-client).
-
-::: panel What is the audience?
-The **audience** is a parameter set during [authorization](/api/authentication#authorize-client), and it contains the unique identifier of the target API. This is how you tell Auth0 for which API to issue an Access Token (in other words, which is the intended *audience* of this token). If you do not want to access a custom API, then by setting the audience to `${account.namespace}/userinfo`, you can use the opaque Access Token to [retrieve the user's profile](/api/authentication#get-user-info).
-:::
-
-* If the **audience** is set to `${account.namespace}/userinfo`, then the Access Token will be an opaque string.
-* If the **audience** is set to the unique identifier of a custom API, then the Access Token will be a [JSON Web Token (JWT)](/jwt).
-
-When the **audience** is set to a custom API and the **scope** parameter includes the `openid` value, then the generated Access Token will be a JWT valid for both [retrieving the user's profile](/api/authentication#get-user-info) and for accessing the custom API. The **audience** parameter of this JWT will include two values: `${account.namespace}/userinfo` and your custom API's unique identifier.
-
-:::panel Use RS256 for multiple audiences
-If you set a custom API audience and also use `scope=openid` in your request, then your custom API must use **RS256** (read [how to change an API's settings](/apis#api-settings)). For security reasons, tokens signed with HS256 can hold only one audience. This also applies if you have set a **Default Audience** at your [API Authorization settings](${manage_url}/#/tenant).
-:::
-
-::: warning
-Remember always that the application should not depend on the Access Token to be any specific format, but instead treat the Access Token as opaque. It is meant **only** for the API.
-:::
-
-## How to get an Access Token
-
-Access Tokens are issued via Auth0's OAuth 2.0 endpoints: [/authorize](/api/authentication#authorize-client) and [/oauth/token](/api/authentication#get-token). You can use any OAuth 2.0-compatible library to obtain Access Tokens. If you do not already have a preferred OAuth 2.0 library, Auth0 provides libraries for many languages and frameworks that work seamlessly with our endpoints.
-
-### Using the Authentication API
-
-* To retrieve an Access Token when using a:
-  * **Server-side web app**, please see the docs for the [Authorization Code Grant](/api-auth/grant/authorization-code)
-  * **Mobile app**, please see the docs for the [Authorization Code using Proof Key for Code Exchange (PKCE) Grant](/api-auth/grant/authorization-code-pkce)
-  * **Client-side app**, please see the docs for the [Implicit Grant](/api-auth/grant/implicit)
-  * **Command line interface**, please see the docs for the [Client Credentials Grant](/api-auth/grant/client-credentials)
-  * **Trusted application**, please see the docs for the [Resource Owner Password Grant](/api-auth/grant/password)
-* For a list of widgets and SDKs that can help you implement Auth0, see our [Libraries](/libraries).
-* Calls to the Lock widget will return an Access Token as shown in the [Lock documentation](/libraries/lock).
-* If you need only a client-side library for authorization and authentication, use [auth0.js](/libraries/auth0js).
-
-## How to use an Access Token
-
-Access Tokens are typically obtained in order to access user-owned resources. For example, a Calendar application needs access to a Calendar API in the cloud in order to read the user's scheduled events and create new events.
-
-Such access is requested by the application and granted by the user, using the [Authorize endpoint](/api/authentication#authorize-client).
-
-```text
-https://${account.namespace}/authorize?
-  audience=api.calendar&
-  scope=read write&
-  response_type=token&
-  client_id={account.clientId}&
-  redirect_uri=${account.callback}&
-  nonce={CRYPTOGRAPHIC_NONCE}
-  state={OPAQUE_VALUE}
-```
-
-In this case the user will be prompted to permit read and write access (`scope=read write`). If allowed, an Access Token will be issued to the application, which the application can then use when making requests to the Calendar API. If consent has already been granted by the user, no consent dialog will be displayed and the Access Token will be issued without additional prompts.
-
-Also, the consent dialog might be displayed again if the access level changes. For example, if the user has granted read access but the functionality changes so write access is required as well, the user will have to use the consent dialog to grant the additional access.
-
-In some cases, consent can also be pre-configured administratively. This typically occurs when the user is an employee, and there are a set of company-specific applications that are always allowed access to employee data.
-
-### Server-to-server interactions
-
-Access Tokens can also be issued directly to applications. Such scenarios involve server-to-server interactions. In this case the user does not need to authenticate.
-
-For example, a reverse geocoding API that accepts latitude/longitude coordinates and returns a readable place name does not access user-owned data. In such cases, a backend server needs to call the geocoding API in order to perform the translation.
-
-Server-to-server Access Tokens can be obtained using the [Client Credentials flow](/api-auth/grant/client-credentials). In order to get a token using this flow, the application has to provide its credentials (`client_id`, `client_secret`).
-
-```har
-{
-  "method": "POST",
-  "url": "https://${account.namespace}/oauth/token",
-  "headers": [
-    { "name": "Content-Type", "value": "application/json" }
-  ],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"audience\": \"https://api.example.com/geocoding/v1/\"}"
-  }
-}
-```
-
-The result will be an Access Token that can be used to make requests to the geocoding API.
-
-```text
-HTTP/1.1 200 OK
-Content-Type: application/json
-{
-  "access_token": "eyJz93a...k4laUWw",
-  "token_type":"Bearer",
-  "expires_in":86400
-}
-```
-
-In order to obtain this Access Token, the application must first have permission to access the geocoding API. This is typically done by requesting access from the administrator of the geocoding API.
-
-For details on how to set up a Client Credentials Grant in Auth0, refer to [Setting up a Client Credentials Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard).
-
-## Add custom claims
-
-You can add custom claims to your Access Token (or [ID Token](/tokens/id-token)) using [Rules](/rules).
-
-The claim name must conform to a namespaced format, which basically means adding any non-Auth0 HTTP or HTTPS URL as a prefix. The Auth0 namespaces you cannot use are `auth0.com`, `webtask.io` and `webtask.run`. The format you should follow is this:  `http://my-namespace/claim-name`.
-
-For more information on the namespaced format of custom claims, refer to [User Profile Claims and Scope](/api-auth/tutorials/adoption/scope-custom-claims).
-
-For an example of how to add a custom claim, refer to [Add Custom Claims](/scopes/current#example-add-custom-claims).
-
-## Lifetime
-
-The token lifetime can be controlled on a per-API basis. The validity period can be increased or decreased based on the security requirements of each API.
-
-To configure the amount of time a token lives, use the **Token Expiration (Seconds)** field for your API at the [Dashboard](${manage_url}/#/apis) APIs section. The default value is `24` hours (`86400` seconds).
-
-![Token Expiration - API](/media/articles/tokens/tokens-expiration-api.png)
-
-Once expired, an Access Token can no longer be used to access an API. To regain access, a new Access Token needs to be obtained. This can be done by repeating the OAuth flow used to obtain the initial Access Token.
-
-In some situations, it is desirable to have permanent, ongoing access to an API without having to repeat an OAuth flow. This is often referred to as `offline_access`, and is possible with the use of a [Refresh Token](/tokens/refresh-token).
-
-A Refresh Token is issued from the OAuth 2.0 endpoints along with the Access Token. When the Access Token expires, the Refresh Token can be used to obtain a fresh Access Token with the same permissions, without further involvement from a user. 
-
-Note that offline access is enabled as a policy of the API to which the Access Token grants access. This is a setting that can be altered in the [Dashboard](${manage_url}/#/apis) under the APIs section.
-
-![Offline Access - API](/media/articles/tokens/tokens-offlineaccess-api.png)
-
-If the API does not permit offline access, a Refresh Token will not be issued. In such circumstances, the OAuth flow must be repeated in order to obtain a new Access Token.
-
-::: note
-For more information on Refresh Tokens and how to use them, refer to: [Refresh Token](/tokens/refresh-token).
-:::
-
-## Revoke Access Token
-
-Revoking Access Tokens is not supported at the moment. The best way to control this is to set the validity period of the token according to the security requirements of the API. For example, an Access Token that accesses a banking API should probably expire much more quickly than one that accesses a ToDo API.
-
-## Using Access Tokens with custom APIs
-
-### JSON Web Tokens
-
-Auth0 creates Access Tokens in JWT format for custom APIs. JWTs contain three parts: a header, a set of claims, and a signature:
-
-* The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
-* The set of claims contains verifiable security statements such as the identity of the user and the permissions they are allowed.
-* The signature is used to validate that the token is trustworthy and has not been tampered with.
-
-### Authorize Access Tokens
-
-Once an application has obtained an Access Token, it will include that token as a credential when making API requests.
-
-```text
-GET /calandar/v1/events
-Host​: api.example.com
-
-Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuYXV0aDAuY29tLyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1YiI6InVzcl8xMjMiLCJpYXQiOjE0NTg3ODU3OTYsImV4cCI6MTQ1ODg3MjE5Nn0.CA7eaHjIHz5NxeIJoFK9krqaeZrPLwmMmgI_XiQiIkQ
-```
-
-The token in this example decodes to the following claims:
-
-```json
-{
-  "alg": "RS256",
-  "typ": "JWT"
-}
-.
-{
-  "iss": "https://example.auth0.com/",
-  "aud": "https://api.example.com/calandar/v1/",
-  "sub": "usr_123",
-  "scope": "read write",
-  "iat": 1458785796,
-  "exp": 1458872196
-}
-```
-
-Before permitting access to the API using this token, the API must verify the token using the following steps:
-
-1. Check that the JWT is well formed.
-1. Check the signature.
-1. Validate the standard claims (specifically the `exp`, `iss` and `aud` claims)
-1. Check the Application permissions (scopes)
-
-::: note
-For a more detailed description of the process of verifying Access Tokens, please refer to [Verify Access Tokens](/api-auth/tutorials/verify-access-token).
-:::
-
-If any of these checks fail, the token is invalid and the request should be rejected.
-
-Once these checks have been performed successfully, the API can be assured that:
-
-* The token was issued by Auth0.
-* The token was issued to an application being operated by the user with an identifier of `usr_123`.
-* The user granted the application access to read from and write to his or her calendar.
-
-The API can now process the request, allowing the application to read from and write to user `usr_123`'s calendar.
diff --git a/articles/tokens/concepts/access-tokens.md b/articles/tokens/concepts/access-tokens.md
new file mode 100644
index 0000000000..9b5a68de41
--- /dev/null
+++ b/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/articles/tokens/concepts/delegation-tokens.md b/articles/tokens/concepts/delegation-tokens.md
new file mode 100644
index 0000000000..19057c78fb
--- /dev/null
+++ b/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/articles/tokens/concepts/id-tokens.md b/articles/tokens/concepts/id-tokens.md
new file mode 100644
index 0000000000..3dce442869
--- /dev/null
+++ b/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/articles/tokens/concepts/idp-access-tokens.md b/articles/tokens/concepts/idp-access-tokens.md
new file mode 100644
index 0000000000..8e8effd1f9
--- /dev/null
+++ b/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/articles/tokens/concepts/jwks.md b/articles/tokens/concepts/jwks.md
new file mode 100644
index 0000000000..38ef6ab6f1
--- /dev/null
+++ b/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/articles/tokens/concepts/jwt-claims.md b/articles/tokens/concepts/jwt-claims.md
new file mode 100644
index 0000000000..867a5efe32
--- /dev/null
+++ b/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/articles/tokens/concepts/jwts.md b/articles/tokens/concepts/jwts.md
new file mode 100644
index 0000000000..8a8c3aeb7a
--- /dev/null
+++ b/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/articles/tokens/concepts/refresh-token-rotation.md b/articles/tokens/concepts/refresh-token-rotation.md
new file mode 100644
index 0000000000..4f48c8014b
--- /dev/null
+++ b/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/articles/tokens/concepts/refresh-tokens.md b/articles/tokens/concepts/refresh-tokens.md
new file mode 100644
index 0000000000..8879806c8c
--- /dev/null
+++ b/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/articles/tokens/concepts/signing-algorithms.md b/articles/tokens/concepts/signing-algorithms.md
new file mode 100644
index 0000000000..5a47dcd750
--- /dev/null
+++ b/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/articles/tokens/concepts/token-storage.md b/articles/tokens/concepts/token-storage.md
new file mode 100644
index 0000000000..c880df666c
--- /dev/null
+++ b/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/articles/tokens/delegation.md b/articles/tokens/delegation.md
deleted file mode 100644
index 5a5cce6472..0000000000
--- a/articles/tokens/delegation.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-description: This page explains an overview about Auth0 delegation tokens.
----
-
-# Delegation Tokens
-
-::: warning
-With [the latest Auth0 authentication pipeline](/api-auth/intro), delegation tokens should not be used to exchange an ID Token issued to one application for a new one issued to a different application, or to get a new ID Token. See the [migration notice](/migrations#api-authorization-with-third-party-vendor-apis) for more information.
-:::
-
-A delegation token should 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` 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 will vary depending on the by provider. For example, if issued for Azure Blob Storage, it will be a SAS (Shared Access Signature). If it is for the Firebase Addon, it will be a JWT.
-
-## How to get a delegation token
-
-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 Addon configured in Auth0. The Addons for which this can be done are those that are not SAML or WS-Fed Addons and the Addon must be configured in Auth0 with secrets obtained from the Addon service, such as Firebase. Instructions for setting up the secrets are available from the Addon configuration page for each Addon. The secrets are used to sign the delegation token so that the Addon API can validate and trust the token.
-
-The delegation endpoint allows the setting of several parameters which will 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 addon 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 Addon. The documentation available from the provider of any Addon API should be consulted for further information.
-
-## Using Delegation Tokens with Public Applications
-
-There is an important caveat to note when using the delegation endpoint with [Public Applications](/applications/application-types#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/articles/tokens/guides/configure-refresh-token-rotation.md b/articles/tokens/guides/configure-refresh-token-rotation.md
new file mode 100644
index 0000000000..835ee5a4bb
--- /dev/null
+++ b/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/articles/tokens/guides/create-namespaced-custom-claims.md b/articles/tokens/guides/create-namespaced-custom-claims.md
new file mode 100644
index 0000000000..fa954ad2aa
--- /dev/null
+++ b/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/articles/tokens/guides/disable-refresh-token-rotation.md b/articles/tokens/guides/disable-refresh-token-rotation.md
new file mode 100644
index 0000000000..44e2c223ad
--- /dev/null
+++ b/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/articles/tokens/guides/get-access-tokens.md b/articles/tokens/guides/get-access-tokens.md
new file mode 100644
index 0000000000..fc658579f4
--- /dev/null
+++ b/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/articles/tokens/guides/get-id-tokens.md b/articles/tokens/guides/get-id-tokens.md
new file mode 100644
index 0000000000..edaec2e697
--- /dev/null
+++ b/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/articles/tokens/guides/get-refresh-tokens.md b/articles/tokens/guides/get-refresh-tokens.md
new file mode 100644
index 0000000000..a302814794
--- /dev/null
+++ b/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/articles/tokens/guides/locate-jwks.md b/articles/tokens/guides/locate-jwks.md
new file mode 100644
index 0000000000..9f990231aa
--- /dev/null
+++ b/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/articles/tokens/guides/manage-signing-keys.md b/articles/tokens/guides/manage-signing-keys.md
new file mode 100644
index 0000000000..a15dd9ebb5
--- /dev/null
+++ b/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/articles/tokens/guides/revoke-refresh-tokens.md b/articles/tokens/guides/revoke-refresh-tokens.md
new file mode 100644
index 0000000000..479b53b56b
--- /dev/null
+++ b/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/articles/tokens/guides/revoke-tokens.md b/articles/tokens/guides/revoke-tokens.md
new file mode 100644
index 0000000000..b6d495869f
--- /dev/null
+++ b/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/articles/tokens/guides/use-access-tokens.md b/articles/tokens/guides/use-access-tokens.md
new file mode 100644
index 0000000000..decece8005
--- /dev/null
+++ b/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/articles/tokens/guides/use-refresh-token-rotation.md b/articles/tokens/guides/use-refresh-token-rotation.md
new file mode 100644
index 0000000000..2a954f8834
--- /dev/null
+++ b/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/articles/tokens/guides/use-refresh-tokens.md b/articles/tokens/guides/use-refresh-tokens.md
new file mode 100644
index 0000000000..7a43aacab0
--- /dev/null
+++ b/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/articles/tokens/guides/validate-access-tokens.md b/articles/tokens/guides/validate-access-tokens.md
new file mode 100644
index 0000000000..baf23003a7
--- /dev/null
+++ b/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/articles/tokens/guides/validate-id-tokens.md b/articles/tokens/guides/validate-id-tokens.md
new file mode 100644
index 0000000000..0d743a1c98
--- /dev/null
+++ b/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/articles/tokens/guides/validate-jwts.md b/articles/tokens/guides/validate-jwts.md
new file mode 100644
index 0000000000..2099af5dce
--- /dev/null
+++ b/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/articles/tokens/id-token.md b/articles/tokens/id-token.md
deleted file mode 100644
index 35acf51522..0000000000
--- a/articles/tokens/id-token.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-description: How to obtain, use and renew an id_token.
-toc: true
----
-# ID Token
-
-## Overview
-
-The ID Token is a [JSON Web Token (JWT)](/jwt) that contains user profile information (like the user's name, email, and so forth), 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](#validate-an-id-token).
-
-You can get an ID Token for a user after they successfully authenticate.
-
-::: warning
-Υou __must__ [verify the ID Token's signature](#verify-the-signature) before storing and using it.
-:::
-
-You will need to decode this token to read the claims (or attributes) of the user. The JWT website provides a [list of libraries you can use to decode](https://jwt.io/#libraries-io) the ID Token.
-
-The ID Token is consumed by the application and the claims included, are typically used for UI display. It was added to the OIDC specification as an optimization so the application can know the identity of the user, without having to make an additional network requests.
-
-::: note
-If you need a refresher on OIDC refer to [OpenID Connect](/protocols/oidc).
-:::
-
-The ID Token conforms to an industry standard (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) and contains three parts: a header, a body and a signature.
-
-- The header contains the type of token and the hash algorithm used on the contents of the token.
-
-- The body, also called the payload, contains identity claims about a user.  There are some claims with registered names, for things like the issuer of the token, the subject of the token (who the claims are about), and the time of issuance.  Any number of additional claims with other names can be added. For the cases where the ID Token is returned in URLs, care must be taken to keep the JWT within the browser size limitations for URLs.
-
-- The signature is used by the recipient to verify that the sender of the JWT is who it says and to ensure that the message wasn't changed along the way.
-
-## Get an ID Token
-
-The ID Token can be returned when calling any of the Auth0 functions which invoke authentication. This includes calls to the Lock widget, to the auth0.js library, the [Authentication API](/api/authentication), or the libraries for other languages. You can view the implementation details for retrieving the ID Token at the [Lock web library](/libraries/lock) and [Auth0.js library](/libraries/auth0js) documents.
-
-## Validate an ID Token
-
-In order to validate an ID Token, an application needs to verify the signature of the token, as well as validate the standard claims of the token. Each of these steps are discussed in more detail below.
-
-::: note
-Most JWT libraries will take care of the token validation for you automatically, so be sure to reference the [Libraries for Token Signing/Verification section of JWT.io](https://jwt.io/#libraries-io) to find a JWT library for your platform and programming language.
-:::
-
-### Verify the signature
-
-The signature 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.
-
-Remember that the ID Token is always a JWT, and the signature is created using its header and payload, a secret and the hashing algorithm being used (as specified in the header: `HMAC`, `SHA256` or `RSA`). The way to verify it, depends on the hashing algorithm:
-
-- For `HS256`, the API's __Signing Secret__ is used. You can find this information at your [API's Settings](${manage_url}/#/apis). Note that the field is only displayed for APIs that use `HS256`.
-- For `RS256`, the tenant's [JSON Web Key Set (JWKS)](/jwks) is used. Your tenant's JWKS is `https://${account.namespace}/.well-known/jwks.json`.
-
-The most secure practice, and our recommendation, is to use `RS256`.
-
-To check or update the algorithm your Application uses go to [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) > Show Advanced Settings > OAuth > JsonWebToken Signature Algorithm. 
-
-### Validate the Claims
-
-Once the application verifies the token's signature, the next step is to validate the standard claims of the token's payload. The following validations need to be made:
-
-- **Token expiration**: The current date/time _must_ be before the expiration date/time listed in the `exp` claim (which is a Unix timestamp).
-
-- **Token issuer**: The `iss` claim denotes the issuer of the JWT. The value **must** match the the URL of your Auth0 tenant. For JWTs issued by Auth0, `iss` holds your Auth0 domain with a `https://` prefix and a `/` suffix: `https://${account.namespace}/`.
-
-- **Token audience**: The `aud` claim identifies the recipients that the JWT is intended for. The value _must_ match the Client ID of your Auth0 Application.
-
-## Control the contents of an ID Token
-
-In order to retrieve an ID Token the `responseType` should include the `id_token`, both for client-side and server-side authentication flows.
-
-The attributes included in the issued ID Token are controlled by the use of a [parameter called `scope`](/scopes).
-- If `scope` is set to `openid`, then the ID Token will contain only the `iss`, `sub`, `aud`, `exp` and `iat` claims.
-- If `scope` is set to `openid email`, then the ID Token will contain additionally the `email` and `email_verified` claims.
-- If `scope` is set to `openid profile`, then the ID Token will contain all 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`.
-
-If you are using Lock, the `options` object used in Lock’s instantiation can specify optional [authentication parameters](/libraries/lock/v11/configuration#auth-object-) as follows:
-
-```js
-var options = {
-  auth: {
-    responseType: 'id_token',
-    params: {scope: 'openid email'}
-  }
-};
-
-var lock = new Auth0Lock(
-  '${account.clientId}',
-  '${account.namespace}',
-  options
-);
-
-lock.show();
-```
-
-The ID Token will contain only the claims specified as the value of the `scope` parameter.
-
-### Add Custom Claims
-
-You can add custom claims to your ID Token (or [Access Token](/tokens/access-token)) using [Rules](/rules).
-
-The claim name must conform to a namespaced format, which basically means addind any non-Auth0 HTTP or HTTPS URL as a prefix. The Auth0 namespaces you cannot use are `auth0.com`, `webtask.io` and `webtask.run`. The format you should follow is this:  `http://my-namespace/claim-name`.
-
-For more information on the namespaced format of custom claims, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
-
-For an example of how to add a custom claim, refer to [Add Custom Claims](/scopes/current#example-add-custom-claims).
-
-### ID Token Payload
-
-::: note
-The [JWT.io website](https://jwt.io) has a debugger that allows you to debug any JSON Web Token. This is useful if you want to quickly decode a JWT to see the information it contains.
-:::
-
-The payload's claims can include some or all of the following:
-
-| 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. An Auth0 ID Token will always include the **registered claims** and the `sub` claim, but the others depends on the `scope`.
-
-## Token Lifetime
-
-The purpose of the ID Token is to cache user information for better performance and experience, and by default, the token is valid for 36000 seconds, or 10 hours. You may change this setting as you see fit; if there are security concerns, you may certainly shorten the time period before the token expires, but 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 that requires an API call.
-
-The expiration time can be changed in the [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings) screen using the `JWT Expiration (seconds)` field.
-
-There are cases where you might want to renew your ID Token. In order to do so, you can either perform another authorization flow with Auth0 (using the `/authorize` endpoint) or use a [Refresh Token](/tokens/refresh-token).
-
-When performing the initial authorization flow, you can ask for a `refresh_token`, by adding `offline_access` at the `scope` parameter, for example `scope=openid offline_access`. The `refresh_token` is stored in session, alongside with the ID Token. 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`.
-
-This method is not an option for Single Page Apps (SPAs), since for security reasons you cannot get a `refresh_token` from the [Implicit Grant](/api-auth/grant/implicit) (the OAuth flow typically used from Client-side Web Apps). In that case you would have to use [silent authentication](/api-auth/tutorials/silent-authentication).
-
-If you are using [auth0.js](/libraries/auth0js) on an SPA, then you can fetch a new token using the `checkSession()` method.
-
-```js
-auth0.checkSession({
-  audience: 'https://mystore.com/api/v2',
-  scope: 'read:order write:order'
-  }, function (err, authResult) {
-    // Renewed tokens or error
-});
-```
-
-## Revoke access
-
-Once issued, tokens can not be revoked in the same fashion as cookies with session id’s for server-side sessions.  As a result, tokens should be issued for relatively short periods, and then [renewed](#lifetime) periodically if the user remains active.
-
-## Keep Reading
-
-::: next-steps
-* [Overview of JSON Web Tokens](/jwt)
-* [IETF RFC for JWT](https://tools.ietf.org/html/rfc7519)
-* [Debugger for viewing JSON Web Tokens](http://jwt.io/)
-:::
diff --git a/articles/tokens/idp.md b/articles/tokens/idp.md
deleted file mode 100644
index dee5840765..0000000000
--- a/articles/tokens/idp.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Identity Provider Access Tokens
-description: How to obtain Identity Provider Access Tokens
----
-# Identity Provider Access Tokens
-
-Third-party [Access Tokens](/tokens/access-token) are issued by [Identity Providers (IdP)](/identityproviders) when a user authenticates with that provider. These Access Tokens can be used 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.
-
-## Get an Identity Provider Access Token
-
-IdP Access Tokens can be obtained after the user has authenticated 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 will need a [Management API Access Token](/api/management/v2/tokens) that will include the `read:user_idp_tokens` [scope](/scopes). The `access_token` for the IdP will be available in the `identities` array, under the element for the particular connection.
-
-For a step-by-step guide on obtaining IdP Access Tokens, see [Call an Identity Provider API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api).
-
-## Control the contents of IdP Access Tokens
-
-The contents of third-party Access Tokens will vary by the issuing IdP.
-
-## Validity period
-
-Since these tokens are created and managed by a third-party (such as Facebook, GitHub, and so on) **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 the token
-
-There is no standard way to renew IdP Access Tokens through Auth0. If available, the mechanism for renewing IdP Access Tokens will vary for each provider.
-
-For certain Identity Providers, Auth0 will store a [Refresh Token](/tokens/refresh-token) which you can use to obtain a new Access Token for the IdP. Currently this is supported for the following Identity Providers:
-
-* BitBucket
-* Google OAuth 2.0 (you need to pass the parameter `access_type=offline` when calling the Auth0 `/authorize` endpoint)
-* Any other OAuth 2.0 IdP
-* SharePoint
-* Azure AD
-
-IdP Refresh Tokens can be obtained the same way as Access Tokens, using [the /api/v2/user/{user-id} endpoint](/api/management/v2#!/Users/get_users_by_id). The `refresh_token` will be available in the `identities` array, under the element for the particular connection.
-
-## Terminate the token
-
-The ability to terminate IdP Access Tokens is up to each provider.
-
-## Validate the token
-
-In general, IdP Access Tokens are passed to the issuing provider, and the issuing provider is responsible for validation of the token.
-
-## Keep reading
-
-:::next-steps
-* [Calling an external IDP API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api)
-* [Adding Scopes for external IDP](/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp)
-:::
diff --git a/articles/tokens/index.html b/articles/tokens/index.html
deleted file mode 100644
index 0297f807c8..0000000000
--- a/articles/tokens/index.html
+++ /dev/null
@@ -1,138 +0,0 @@
----
-url: /tokens
-section: articles
-classes: topic-page
-title: Tokens
-description: Learn about the numerous types of tokens referenced in Auth0 documentation, what each is used for and how to use it.
----
-
-
        
-  
        
-  
        Tokens used by Auth0
        
-  
        
-    Learn about the types of tokens referenced in Auth0 documentation, what each is used for and how to use it.
-  
        
-
        
-
-
        
-  Auth0 uses two types of tokens:
        
-  
          
-    
        • 
-      JSON Web Tokens (JWT): Tokens that conform to the JSON Web Token standard and contain information about an identity 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.
-    
          • 
-    
        • 
-      Opaque tokens: 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.
-    
          • 
-  
        
-
-
        There are five primary tokens used in Auth0's token based authentication scenarios and referenced in Auth0 documentation.
-
        
-
-
diff --git a/articles/tokens/index.md b/articles/tokens/index.md
new file mode 100644
index 0000000000..b8eefdde25
--- /dev/null
+++ b/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/articles/tokens/jwks.md b/articles/tokens/jwks.md
deleted file mode 100644
index 9f08ff2fbe..0000000000
--- a/articles/tokens/jwks.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-url: /jwks
-title: JSON Web Key Set (JWKS)
-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).
-toc: true
----
-# JSON Web Key Set (JWKS)
-
-When creating applications and resources servers (APIs) in Auth0, two algorithms are supported for signing [JSON Web Tokens (JWTs)](/jwt): **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 [JWK](https://tools.ietf.org/html/rfc7517) specification 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 directly from the specification:
-
-> **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.
-
-At the most basic level, the JWKS is a set of keys containing the public keys that should be used to verify any JWT issued by the authorization server. 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. 
-
-This is an example of the JWKS used by a demo tenant.
-
-```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"
-  }
-]}
-```
-
-::: note
-Currently Auth0 only supports a single JWK for signing, 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 signing certificates.
-:::
-
-The example JWKS above contains a single key. Each property in the key is defined by the JWK specification [RFC 7517 Section 4](https://tools.ietf.org/html/rfc7517#section-4). We will use these properties to determine which key was used to sign the JWT. Here is a quick breakdown of what each property represents:
-
-* **alg**: is the algorithm for the key
-* **kty**: is the key type
-* **use**: is how the key was meant to be used. For the example above sig represents signature.
-* **x5c**: is the x509 certificate chain
-* **e**: is the exponent for a standard pem
-* **n**: is the modulus for a standard pem
-* **kid**: is the unique identifier for the key
-* **x5t**: is the thumbprint of the x.509 cert (SHA-1 thumbprint)
-
-## Verifying a JWT using the JWKS endpoint
-
-We discussed verifying a JWT in detail in [Verify Access Tokens](/api-auth/tutorials/verify-access-token), so will not go into much detail in this document. One of the steps when verifying a JWT is to [verify the signature](/api-auth/tutorials/verify-access-token#verify-the-signature). 
-
-When verifying a JWT using a JWKS, here are the high level steps you will need to follow:
-
-* Retrieve the JWKS and filter for potential signing keys.
-* Extract the JWT from the request's authorization header.
-* Decode the JWT and grab the `kid` property from the header.
-* Find the signing key in the filtered JWKS with a matching `kid` property.
-* Using the `x5c` property build a certificate which will be used to verify the JWT signature.
-
-## Using the JWKS in your application to verify a JWT
-
-Due to the fact that there are such a wide range of technologies being used by our customers, going into detail of the actual implementation of verifying a JWT using a JWKS is beyond the scope of this document.
-
-However, here are some resources which will assist you:
-
-1. When building an API, our [Backend / API Quickstarts](/quickstart/backend) show how to implement signature verification for many different platforms. This is typically done by some form of middleware which is available on the particular platform.
-1. To manually verify a token's signature, you can use one of the libraries listed in the Libraries for Token Signing/Verification section of [JWT.io](https://jwt.io/). Refer to the documentation of the relevant library for the exact implementation details.
-1. Our blog post [Navigating RS256 and JWKS](https://auth0.com/blog/navigating-rs256-and-jwks/) shows a sample implementation using Node.js.
diff --git a/articles/tokens/jwt.md b/articles/tokens/jwt.md
deleted file mode 100644
index 66e46d37ac..0000000000
--- a/articles/tokens/jwt.md
+++ /dev/null
@@ -1,189 +0,0 @@
----
-url: /jwt
-title: JSON Web Tokens (JWT) in Auth0
-description: JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This article introduces you to all of the concepts needed to fully understand JWTs.
-toc: true
----
-
-# JSON Web Tokens (JWT) in Auth0
-
-::: note
-For more information on all the types of tokens used by Auth0, see [Tokens](/tokens).
-:::
-
-<%= include('../_includes/_video', { id: 'dxfz716cw9' }) %>
-
-## What is JSON Web Token?
-
-JSON Web Token (JWT) 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. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the **HMAC** algorithm) or a public/private key pair using **RSA**.
-
-Let's explain some concepts of this definition further.
-
-- **Compact**: Because of its smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.
-
-- **Self-contained**: The payload contains all the required information about the user, avoiding the need to query the database more than once.
-
-## What a JSON Web Token is used for?
-
-Here are some scenarios where JSON Web Tokens are useful:
-
-- **Authentication**: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
-
-- **Information Exchange**: JSON Web Tokens are a good way of securely transmitting information between parties, because as they can be signed, for example using public/private key pairs, you can be sure that the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
-
-## What is the JSON Web Token structure?
-
-JSON Web Tokens consist of three parts separated by dots (`.`), which are:
-
-- Header
-- Payload
-- Signature
-
-Therefore, a JWT typically looks like the following.
-
-`xxxxx.yyyyy.zzzzz`
-
-Let's break down the different parts:
-
-### Header
-
-The header *typically* consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.
-
-For example:
-
-```
-{
-  "alg": "HS256",
-  "typ": "JWT"
-}
-```
-
-Then, this JSON is **Base64Url** encoded to form the first part of the JWT.
-
-### Payload
-
-The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata.
-
-When working with [JWT claims](https://tools.ietf.org/html/rfc7519#section-4), there are some rules you should be aware of when it comes to naming (especially if you are using self-defined custom claims).
-
-The JWT specification defines seven claims that can be included in a token. These are **registered claim names**, and they are:
-
-* iss
-* sub
-* aud
-* exp
-* nbf
-* iat
-* jti
-
-For your specific use case, you might then use what are called **public claim names**. Examples of these include:
-
-* auth_time
-* acr
-* nonce
-
-Finally, there are **private claim names**, which you can use to convey identity-related information, such as name or department.
-
-Because public and private claims are not registered, take care to avoid name collisions. If a collision does occur, it can be difficult to tease apart two claims of the same name, but with differing information.
-
-An example of payload could be:
-
-```
-{
-  "sub": "1234567890",
-  "name": "John Doe",
-  "admin": true
-}
-```
-
-The payload is then **Base64Url** encoded to form the second part of the JSON Web Token.
-
-### Signature
-
-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.
-
-For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
-
-```
-HMACSHA256(
-  base64UrlEncode(header) + "." +
-  base64UrlEncode(payload),
-  secret)
-```
-
-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.
-
-### Putting all together
-
-The output is three Base64 strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML.
-
-The following shows a JWT that has the previous header and payload encoded, and it is signed with a secret.
-![Encoded JWT](/media/articles/jwt/encoded-jwt3.png)
-
-If you want to play with JWT and put these concepts into practice, you can use [jwt.io Debugger](http://jwt.io) to decode, verify, and generate JWTs.
-
-![JWT.IO Debugger](/media/articles/jwt/legacy-app-auth-5.png)
-
-## How do JSON Web Tokens work?
-
-In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned and must be saved locally (typically in local storage, but cookies can be also used), instead of the traditional approach of creating a session in the server and returning a cookie.
-
-::: warning
-You __must__ [verify a JWT's signature](/tokens/id-token#verify-the-signature) before storing and using it.
-:::
-
-Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the **Authorization** header using the **Bearer** schema. The content of the header should look like the following:
-
-```text
-Authorization: Bearer 
-```
-
-This is a stateless authentication mechanism as the user state is never saved in server memory.
-The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources. As JWTs are self-contained, all the necessary information is there, reducing the need to query the database multiple times.
-
-This allows you to fully rely on data APIs that are stateless and even make requests to downstream services. It doesn't matter which domains are serving your APIs, so Cross-Origin Resource Sharing (CORS) won't be an issue as it doesn't use cookies.
-
-The following diagram shows this process:
-
-![How a JSON Web Token works](/media/articles/jwt/jwt-diagram.png)
-
-## How to implement JWT
-
-The safest way to implement JWT-based authentication, is to use one of the existing open source libraries. In [JWT.io](https://jwt.io/#libraries-io) you can find several, for .NET, Python, Java, Ruby, Objective-C, Swift, PHP, and more.
-
-To verify JWT (or manually create one), you can use the [JWT.io Debugger](https://jwt.io/#debugger-io).
-
-## JWT vs SWT vs SAML
-
-Let's talk about the benefits of **JSON Web Tokens (JWT)** when compared to **Simple Web Tokens (SWT)** and **Security Assertion Markup Language Tokens (SAML)**.
-
-As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.
-
-Security-wise, SWT can only be symmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML tokens can use a public/private key pair in the form of a X.509 certificate for signing. Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.
-
-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.
-
-Regarding usage, JWT is used at Internet scale. This highlights the ease of client-side processing of the JSON Web token on multiple platforms, especially mobile.
-
-![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_
-
-## Best Practices
-
-* **Keep it secret. Keep it safe.** The signing key should be treated like any other credentials and revealed only to services that absolutely need it.
-
-* **Do not add sensitive data to the payload.** Tokens are signed to protect against manipulation and are easily decoded. Add the bare minimum number of claims to the payload for best performance and security.
-
-* **Give tokens an expiration.** Technically, once a token is signed – it is valid forever – unless the signing key is changed or expiration explicitly set. This could pose potential issues so have a strategy for expiring and/or revoking tokens.
-
-* **Embrace HTTPS.** Do not send tokens over non-HTTPS connections as those requests can be intercepted and tokens compromised.
-
-* **Consider all of your authorization use cases.** Adding a secondary token verification system that ensure tokens were generated from your server, for example, may not be common practice, but may be necessary to meet your requirements.
-
-## Read More
-
-::: next-steps
-* [JWT Handbook](https://auth0.com/e-books/jwt-handbook)
-* [10 Things You Should Know About Tokens](https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/)
-* [Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/)
-:::
diff --git a/articles/tokens/references/id-token-structure.md b/articles/tokens/references/id-token-structure.md
new file mode 100644
index 0000000000..c8808ea8ad
--- /dev/null
+++ b/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/articles/tokens/references/jwks-properties.md b/articles/tokens/references/jwks-properties.md
new file mode 100644
index 0000000000..ea229c7aff
--- /dev/null
+++ b/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/articles/tokens/references/jwt-structure.md b/articles/tokens/references/jwt-structure.md
new file mode 100644
index 0000000000..a1d3af35dd
--- /dev/null
+++ b/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/articles/tokens/refresh-token/current/index.md b/articles/tokens/refresh-token/current/index.md
deleted file mode 100644
index 99ee9e9238..0000000000
--- a/articles/tokens/refresh-token/current/index.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-description: What is a Refresh Token and how you can use it.
-toc: true
----
-# Refresh Token
-
-A **Refresh Token** is a special kind of token that contains the information required to obtain a new [Access Token](/tokens/access-token) or [ID Token](/tokens/id-token).
-
-Usually, a user will need a new Access Token only after the previous one expires, or when gaining access to a new resource for the first time.
-
-Refresh Tokens are subject to strict storage requirements to ensure that they are not leaked. Also, [Refresh Tokens can be revoked](#revoke-a-refresh-token) by the Authorization Server.
-
-::: panel-warning OIDC-conformant applications
-The behaviour in this document is applicable to [OIDC-conformant applications](/api-auth/tutorials/adoption/oidc-conformant). An application can be configured as OIDC-conformant in two ways:
-
-1. By enabling the **OIDC Conformant** flag for an Application
-2. By passing an `audience` to the `/authorize` endpoint
-
-For more information on our authentication pipeline, refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
-:::
-
-## Overview
-
-The response of an [authentication request](/api-auth) can result in an Access Token and/or an ID Token being issued by Auth0. The  Access Token is used to make authenticated calls to a secured API, while the ID Token contains user profile attributes represented in the form of _claims_. Both JWTs have an expiration date indicated by the `exp` claim (among other security measures, like signing).
-
-A Refresh Token allows the application to request Auth0 to issue a new Access Token or ID Token directly, without having to re-authenticate the user. This will work as long as the Refresh Token has not been revoked.
-
-## Restrictions
-
-You can only get a Refresh Token if you are implementing: [Authorization Code Grant](/api-auth/grant/authorization-code), [Authorization Code Grant (PKCE)](/api-auth/grant/authorization-code-pkce) or [Resource Owner Password Grant](/api-auth/grant/password).
-
-A Single Page Application (normally implementing [Implicit Grant](/api-auth/grant/implicit)) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
-
-If you are implementing an SPA using [Implicit Grant](/api-auth/grant/implicit) and you need to renew a token, the only secure option is to use [Silent Authentication](/api-auth/tutorials/silent-authentication).
-
-Another safeguard is that the API should allow offline access. This is configured via the **Allow Offline Access** switch on the [API Settings](${manage_url}/#/apis). If the switch is disabled, Auth0 will not return a Refresh Token for this API, even if you included the `offline_access` scope.
-
-## Get a Refresh Token
-
-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 [Authorization Code Grant](/api-auth/grant/authorization-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}
-```
-
-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/json" }
-  ],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"grant_type\":\"authorization_code\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"code\": \"YOUR_AUTHORIZATION_CODE\",\"redirect_uri\": \"${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 needed for [confidential applications](/applications/application-types#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 Authorization Code Grant refer to [Execute an Authorization Code Grant Flow](/api-auth/tutorials/authorization-code-grant). For other grants refer to [API Authorization](/api-auth).
-
-::: note
-If the response did not include a Refresh Token, check that you comply with the [Restrictions](#restrictions) listed in this document.
-:::
-
-## Use a Refresh Token
-
-To refresh your token, using the `refresh_token` you already got during authorization, 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",
-    "httpVersion": "HTTP/1.1",
-    "cookies": [],
-    "headers": [
-      { "name": "Content-Type", "value": "application/json" }
-    ],
-    "queryString" : [],
-    "postData" : {
-      "mimeType": "application/json",
-      "text" : "{ \"grant_type\": \"refresh_token\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"refresh_token\": \"YOUR_REFRESH_TOKEN\" }"
-    },
-    "headersSize" : 150,
-    "bodySize" : 0,
-    "comment" : ""
-}
-```
-
-Where:
-- `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/application-types#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 amount of requests to this endpoint that can be executed using the same token from the same IP.
-:::
-
-## Revoke a Refresh Token
-
-Since Refresh Tokens never expire it is important to be able to revoke them in case they get compromised.
-
-Auth0 handles token revocation as though the token has been potentially exposed to malicious adversaries.
-Hence 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 either by posting a request to [the Authentication API /oauth/revoke endpoint](/api/authentication#revoke-refresh-token) or using the [dashboard](${manage_url}).
-
-### Use the API
-
-To revoke a Refresh Token you can send a `POST` request to `https://${account.namespace}/oauth/revoke`.
-
-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. Note that 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/application-types#confidential-applications). |
-| `token` 
        Required | The Refresh Token you want to revoke. |
-
-The application should match the one the Refresh Token was issued for.
-
-::: panel Revoke a token without the Client Secret
-For applications that cannot keep the Client Secret safe (for example, native apps), the [Revoke endpoint](/api/authentication#revoke-refresh-token) supports access without the Client Secret but 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 Dashboard
-
-When you revoke a Refresh Token using the dashboard, you have to revoke the user's authorized access to the application that issued the token. This renders the Refresh Token useless.
-
-To do so, 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 revokes also 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)
-
-## Rules
-
-Rules will run for the [Refresh Token Exchange](#use-a-refresh-token). To execute special logic, you can look at the `context.protocol` property in your rule. If the value is `oauth2-refresh-token`, then this is the indication that the rule is running during the [Refresh Token Exchange](#use-a-refresh-token).
-
-::: warning
-If you try to do a redirect with context.redirect, the authentication flow will return an error.
-:::
-
-## SDK Support
-
-### Web Apps
-
-All our main SDKs support Refresh Tokens out of the box. Some are [Node.js](/quickstart/webapp/nodejs), [ASP.NET Core](/quickstart/webapp/aspnet-core), [PHP](/quickstart/webapp/php), [Java](/dev-centers/java), and many more. For a complete listing refer to our [Quickstarts page](/quickstart/webapp).
-
-### Single Page Apps
-
-For web apps that execute on the browser, the way to refresh a token is using [Silent Authentication](/api-auth/tutorials/silent-authentication). [Auth0.js](/libraries/auth0js), our client-side library, provides methods for this out of the box.
-
-- The `authorize` method, redirects the user to the `/authorize` endpoint, in order to login and provide consent.
-- The `parseHash` method, parses a URL hash fragment to extract the result of an Auth0 authentication response.
-- The `checkSession` method, attempts to get a new token from Auth0, using [silent authentication](/api-auth/tutorials/silent-authentication). For more details refer to [Using checkSession to Acquire New Tokens](/libraries/auth0js#using-checksession-to-acquire-new-tokens).
-
-More information on the library:
-- [Auth0.js Reference](/libraries/auth0js)
-- [Auth0.js GitHub repo](https://github.com/auth0/auth0.js#api)
-
-### Mobile / Native Apps
-
-For more information on using Refresh Tokens with our mobile SDKs refer to:
-
-* [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)
-
-## Keep reading
-
-::: next-steps
-* [Refresh Tokens: When to use them and how they interact with JWTs](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/)
-* [Using a Refresh Token with an Access Token](/tokens/access-token#lifetime)
-:::
diff --git a/articles/tokens/refresh-token/index.yml b/articles/tokens/refresh-token/index.yml
deleted file mode 100644
index cbb865ba92..0000000000
--- a/articles/tokens/refresh-token/index.yml
+++ /dev/null
@@ -1,9 +0,0 @@
-versioning:
-  baseUrl: tokens/refresh-token
-  current: current
-  versions:
-    - legacy
-    - current
-  defaultArticles:
-    legacy: index
-    current: index
diff --git a/articles/tokens/refresh-token/legacy/index.md b/articles/tokens/refresh-token/legacy/index.md
deleted file mode 100644
index a4989b8252..0000000000
--- a/articles/tokens/refresh-token/legacy/index.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-description: A Refresh Token allows an application to request Auth0 to issue a new id_token directly, without needing to re-authenticate the user.
----
-
-# Refresh Token
-
-::: version-warning
-This document covers an outdated version of the Auth0 authentication pipeline and the way Refresh Tokens are used. We recommend you use the latest version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
-:::
-
-A **Refresh Token** is a special kind of token that is used to authenticate a user without them needing to re-authenticate. This is primarily useful for mobile applications that are installed on a device.
-
-Usually, a user will need a new Access Token only after the previous one expires, or when gaining access to a new resource for the first time.
-
-If you are new to Refresh Tokens, you can learn more about them in this blog post: [Refresh Tokens: When to Use Them and How They Interact with JWTs](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/).
-
-Refresh Tokens can be [obtained](#obtain-a-refresh-token) or [revoked](#revoke-a-refresh-token-using-the-management-api) programmatically through the Auth0 API. They can also be viewed and revoked [from the dashboard](#revoke-a-refresh-token-in-the-dashboard).
-
-Refresh Tokens are subject to strict storage requirements to ensure that they are not leaked.
-
-## Obtain a Refresh Token
-
-To obtain a Refresh Token, the `offline_access` scope (see: [Scopes](/scopes)) and an arbitrary `device` name must be included when initiating an authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint.
-
-For example:
-
-```text
-GET https://${account.namespace}/authorize/?
-    response_type=token
-    &client_id=${account.clientId}
-    &redirect_uri=YOUR_CALLBACK_URL
-    &state=VALUE_THAT_SURVIVES_REDIRECTS
-    &scope=openid%20offline_access
-    &device=my-device
-```
-
-::: note
-The `device` parameter can be any value, such as a unique mobile device identifier.
-:::
-
-When the authentication flow completes, Auth0 will redirect the user to the `callback_URL` as usual.
-The complete URL will be as follows:
-
-```text
-GET https://YOUR_CALLBACK_URL#
-    access_token=2nF...WpA
-    &id_token=eyJhb...
-    &state=VALUE_THAT_SURVIVES_REDIRECTS
-    &refresh_token=Cqp...Mwe
-```
-
-The Refresh Token is returned as part of the URL, in the form of an opaque string.
-
-::: panel-warning Security Warning
-Refresh Tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever.
-:::
-
-::: note
-In this case, the token was returned to the application directly in the URL because the Implicit Flow (`response_type=token`) was used.
-:::
-
-## Use a Refresh Token
-
-To obtain a new `id_token`, call the [delegation](/api/authentication/reference#delegation) endpoint in the Authentication API:
-
-```text
-POST https://${account.namespace}/delegation
-Content-Type: 'application/json'
-{
-  "client_id":       "${account.clientId}",
-  "grant_type":      "urn:ietf:params:oauth:grant-type:jwt-bearer",
-  "refresh_token":   "your_refresh_token",
-  "api_type":        "app"
-}
-```
-
-A response from this request could be as follows:
-
-```json
-{
-  "token_type": "Bearer",
-  "expires_in": 36000,
-  "id_token": "eyJ..."
-}
-```
-
-The `expires_in` parameter indicates the lifetime of the new JWT in seconds. It can be calculated by the difference between the `exp` and `iat` claims of the JWT.
-
-::: panel Rate limits
-Obtaining new tokens using the `refresh_token` should occur only if the `id_token` has expired. There are rate limits in Auth0 that will throttle the amount of requests to this endpoint that can be executed using the same token from the same IP.
-:::
-
-
-## Revoke a Refresh Token
-
-Since Refresh Tokens never expire, it is important to be able to revoke them.
-
-### Revoke a Refresh Token using 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` with an Access Token containing `read:device_credentials` scope. To narrow the results, you can also specify the `client_id` and `user_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 a **204**: The credential no longer exists.
-
-### Revoke a Refresh Token in the Dashboard
-
-To see if a user has existing devices with associated Refresh Tokens, go to the [Users section](${manage_url}/#/users) of the dashboard. Click the name of the user to view their **Details** page.
-
-Select the **Devices** tab. This page lists all device names and the number of Refresh Tokens associated with each. To revoke a Refresh Token, click the **X** to the right of the device name.
-
-![Revoke a Refresh Token in the Dashboard](/media/articles/tokens/legacy/dashboard-revoke-refresh-token.png)
-
-Click **UNLINK** to confirm.
diff --git a/articles/topics/_topic.md b/articles/topics/_topic.md
deleted file mode 100644
index 9f959044d3..0000000000
--- a/articles/topics/_topic.md
+++ /dev/null
@@ -1,9 +0,0 @@
-
        
-<% _.forEach(meta.articles, function(path) {
-  var article = cache.get('articles/' + path); %>
-  
        
-    
        ${article.title}
        
-    
        ${article.description}
        
-  
        
-<% }); %>
-
        
diff --git a/articles/topics/extensibility.md b/articles/topics/extensibility.md
deleted file mode 100644
index 85e729b250..0000000000
--- a/articles/topics/extensibility.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-description: Auth0 features that provide extensibility to your authentication and authorization flows.
----
-
-# Extensibility
-
-## Rules
-
-[Rules](/rules) are functions written in JavaScript that are executed in Auth0 as part of the transaction every time a user authenticates to your application. Rules allow you to easily customize and extend Auth0's capabilities. Rules can be chained together for modular coding and can be turned on and off individually.
-
-## Hooks
-
-[Hooks](/hooks) allow you to customize the behavior of Auth0 using Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). Hooks allow you modularity when configuring your Auth0 implementation, and extend the functionality of base Auth0 features.
-
-## Extensions
-
-[Auth0 Extensions](/extensions) enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product.
diff --git a/articles/topics/guides.md b/articles/topics/guides.md
deleted file mode 100644
index 96e4532ea2..0000000000
--- a/articles/topics/guides.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-classes: topic-page
-title: Guides
-description: Helpful docs for implementing Auth0
----
-
-
        
-  
        
-  
        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.
-  
        
-
        
-
-
          
-  
        • 
-    Architecture Scenarios
-    
          
-      Describes several architecture scenarios and how you can implement them using Auth0.
-    
          
-  
          • 
-  
        • 
-    Tokens
-    
          
-      Tokens are commonly used in Auth0, so learn what they are and how they're used
-    
          
-  
          • 
-  
        • 
-    User Management
-    
          
-      Learn how to manage your users in Auth0, as well as what can be stored in the user profile
-    
          
-  
          • 
-  
        • 
-    Multifactor Authentication
-    
          
-      Learn what multifactor authentication is and how to implement it to ensure a more secure sign on process for your users.
-    
          
-  
          • 
-  
        • 
-    Email
-    
          
-      How to handle emails, such as those for verification, confirming emails, and changing passwords, in Auth0.
-    
          
-  
          • 
-
        
diff --git a/articles/topics/guides/index.md b/articles/topics/guides/index.md
new file mode 100644
index 0000000000..ee6731da0f
--- /dev/null
+++ b/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/articles/topics/identity-glossary.md b/articles/topics/identity-glossary.md
deleted file mode 100644
index d355125296..0000000000
--- a/articles/topics/identity-glossary.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Identity Glossary
-articles:
-  - protocols
-  - tokens
-  - tokens/jwt
----
-
-::: note
-For addition definitions of Auth0-related terms, please see the [Auth0 Identity Glossary](https://auth0.com/identity-glossary).
-:::
-
-# Identity Glossary
-
-<%= include('./_topic') %>
diff --git a/articles/troubleshoot/_includes/_log_events_link.md b/articles/troubleshoot/_includes/_log_events_link.md
new file mode 100644
index 0000000000..36c5fa4a28
--- /dev/null
+++ b/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/articles/troubleshoot/concepts/auth-issues.md b/articles/troubleshoot/concepts/auth-issues.md
new file mode 100644
index 0000000000..a9e9c62cf8
--- /dev/null
+++ b/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/articles/troubleshoot/concepts/basics.md b/articles/troubleshoot/concepts/basics.md
new file mode 100644
index 0000000000..8d268cbffe
--- /dev/null
+++ b/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/articles/troubleshoot/concepts/integration-extensibility-issues.md b/articles/troubleshoot/concepts/integration-extensibility-issues.md
new file mode 100644
index 0000000000..64a8588f0d
--- /dev/null
+++ b/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/articles/troubleshoot/guides/check-api-calls.md b/articles/troubleshoot/guides/check-api-calls.md
new file mode 100644
index 0000000000..d1c28f4542
--- /dev/null
+++ b/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/articles/troubleshoot/guides/check-deprecation-errors.md b/articles/troubleshoot/guides/check-deprecation-errors.md
new file mode 100644
index 0000000000..e8e70e3298
--- /dev/null
+++ b/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/articles/troubleshoot/guides/check-error-messages.md b/articles/troubleshoot/guides/check-error-messages.md
new file mode 100644
index 0000000000..7fde71b5d5
--- /dev/null
+++ b/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/articles/troubleshoot/guides/check-login-logout-issues.md b/articles/troubleshoot/guides/check-login-logout-issues.md
new file mode 100644
index 0000000000..067b5c888b
--- /dev/null
+++ b/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/articles/troubleshoot/guides/check-user-profiles.md b/articles/troubleshoot/guides/check-user-profiles.md
new file mode 100644
index 0000000000..7b551af860
--- /dev/null
+++ b/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/articles/troubleshoot/guides/generate-har-files.md b/articles/troubleshoot/guides/generate-har-files.md
new file mode 100644
index 0000000000..b073f99123
--- /dev/null
+++ b/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/articles/troubleshoot/guides/verify-connections.md b/articles/troubleshoot/guides/verify-connections.md
new file mode 100644
index 0000000000..8c001cfeda
--- /dev/null
+++ b/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/articles/troubleshoot/guides/verify-domain.md b/articles/troubleshoot/guides/verify-domain.md
new file mode 100644
index 0000000000..76ea9bba52
--- /dev/null
+++ b/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/articles/troubleshoot/guides/verify-platform.md b/articles/troubleshoot/guides/verify-platform.md
new file mode 100644
index 0000000000..a131ec5578
--- /dev/null
+++ b/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/articles/troubleshoot/guides/verify-rules.md b/articles/troubleshoot/guides/verify-rules.md
new file mode 100644
index 0000000000..acaf441314
--- /dev/null
+++ b/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/articles/troubleshoot/index.md b/articles/troubleshoot/index.md
new file mode 100644
index 0000000000..eaa75352cd
--- /dev/null
+++ b/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/articles/troubleshoot/references/invalid-token.md b/articles/troubleshoot/references/invalid-token.md
new file mode 100644
index 0000000000..d858c6bfec
--- /dev/null
+++ b/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/articles/troubleshoot/references/mgmtv2-errors.md b/articles/troubleshoot/references/mgmtv2-errors.md
new file mode 100644
index 0000000000..3c98b12c0b
--- /dev/null
+++ b/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/articles/troubleshoot/references/oauth-errors.md b/articles/troubleshoot/references/oauth-errors.md
new file mode 100644
index 0000000000..4c0642b44d
--- /dev/null
+++ b/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/articles/troubleshoot/references/saml-errors.md b/articles/troubleshoot/references/saml-errors.md
new file mode 100644
index 0000000000..64b586983c
--- /dev/null
+++ b/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/articles/troubleshoot/references/self_change_password.md b/articles/troubleshoot/references/self_change_password.md
new file mode 100644
index 0000000000..739ba41d28
--- /dev/null
+++ b/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/articles/troubleshoot/references/wsfed-errors.md b/articles/troubleshoot/references/wsfed-errors.md
new file mode 100644
index 0000000000..d5da13e030
--- /dev/null
+++ b/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/articles/universal-login/_implement_universal_login.md b/articles/universal-login/_implement_universal_login.md
new file mode 100644
index 0000000000..bb54d23afc
--- /dev/null
+++ b/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/articles/universal-login/classic.md b/articles/universal-login/classic.md
new file mode 100644
index 0000000000..25d02460bc
--- /dev/null
+++ b/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/articles/universal-login/custom-error-pages.md b/articles/universal-login/custom-error-pages.md
new file mode 100644
index 0000000000..2ff0888a57
--- /dev/null
+++ b/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/articles/universal-login/customization-classic.md b/articles/universal-login/customization-classic.md
new file mode 100644
index 0000000000..6f26ed7249
--- /dev/null
+++ b/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/articles/universal-login/customization-new.md b/articles/universal-login/customization-new.md
new file mode 100644
index 0000000000..256be1d688
--- /dev/null
+++ b/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/articles/universal-login/default-login-url.md b/articles/universal-login/default-login-url.md
new file mode 100644
index 0000000000..f63742f5c8
--- /dev/null
+++ b/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/articles/universal-login/error-pages.md b/articles/universal-login/error-pages.md
new file mode 100644
index 0000000000..d7ea9a8325
--- /dev/null
+++ b/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/articles/universal-login/i18n.md b/articles/universal-login/i18n.md
new file mode 100644
index 0000000000..2500143f81
--- /dev/null
+++ b/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/articles/universal-login/index.md b/articles/universal-login/index.md
new file mode 100644
index 0000000000..1753159969
--- /dev/null
+++ b/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/articles/universal-login/multifactor-authentication.md b/articles/universal-login/multifactor-authentication.md
new file mode 100644
index 0000000000..f8df08134a
--- /dev/null
+++ b/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/articles/universal-login/new-experience-limitations.md b/articles/universal-login/new-experience-limitations.md
new file mode 100644
index 0000000000..1d8ef31edf
--- /dev/null
+++ b/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/articles/universal-login/new.md b/articles/universal-login/new.md
new file mode 100644
index 0000000000..a49d7e6c84
--- /dev/null
+++ b/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/articles/universal-login/page-templates.md b/articles/universal-login/page-templates.md
new file mode 100644
index 0000000000..f04413f65a
--- /dev/null
+++ b/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/articles/universal-login/password-reset.md b/articles/universal-login/password-reset.md
new file mode 100644
index 0000000000..965874977c
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/_prompt_definition.md b/articles/universal-login/text-customization-prompts/_prompt_definition.md
new file mode 100644
index 0000000000..6deafd6d70
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/_prompts.md b/articles/universal-login/text-customization-prompts/_prompts.md
new file mode 100644
index 0000000000..2cb6ef964e
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/common.md b/articles/universal-login/text-customization-prompts/common.md
new file mode 100755
index 0000000000..986a88477d
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/consent.md b/articles/universal-login/text-customization-prompts/consent.md
new file mode 100644
index 0000000000..dd8686c924
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/device-flow.md b/articles/universal-login/text-customization-prompts/device-flow.md
new file mode 100644
index 0000000000..47c986c704
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/email-otp-challenge.md b/articles/universal-login/text-customization-prompts/email-otp-challenge.md
new file mode 100644
index 0000000000..eed23ea0a6
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/email-verification.md b/articles/universal-login/text-customization-prompts/email-verification.md
new file mode 100644
index 0000000000..5be91db924
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/invitation.md b/articles/universal-login/text-customization-prompts/invitation.md
new file mode 100644
index 0000000000..c7f8e2c459
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/login-email-verification.md b/articles/universal-login/text-customization-prompts/login-email-verification.md
new file mode 100644
index 0000000000..9df537aa48
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/login-id.md b/articles/universal-login/text-customization-prompts/login-id.md
new file mode 100644
index 0000000000..3b6adb518f
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/login-password.md b/articles/universal-login/text-customization-prompts/login-password.md
new file mode 100644
index 0000000000..0f0f999b43
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/login.md b/articles/universal-login/text-customization-prompts/login.md
new file mode 100644
index 0000000000..24366e6e9c
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/logout.md b/articles/universal-login/text-customization-prompts/logout.md
new file mode 100644
index 0000000000..462232eba0
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-email.md b/articles/universal-login/text-customization-prompts/mfa-email.md
new file mode 100644
index 0000000000..99b440c987
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-otp.md b/articles/universal-login/text-customization-prompts/mfa-otp.md
new file mode 100644
index 0000000000..737b738045
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-phone.md b/articles/universal-login/text-customization-prompts/mfa-phone.md
new file mode 100644
index 0000000000..43373360ab
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-push.md b/articles/universal-login/text-customization-prompts/mfa-push.md
new file mode 100644
index 0000000000..ae05b309d5
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-recovery-code.md b/articles/universal-login/text-customization-prompts/mfa-recovery-code.md
new file mode 100644
index 0000000000..48cd305483
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-sms.md b/articles/universal-login/text-customization-prompts/mfa-sms.md
new file mode 100644
index 0000000000..a5aa3222dd
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-voice.md b/articles/universal-login/text-customization-prompts/mfa-voice.md
new file mode 100644
index 0000000000..4917d756dc
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa-webauthn.md b/articles/universal-login/text-customization-prompts/mfa-webauthn.md
new file mode 100644
index 0000000000..d1a5be36e1
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/mfa.md b/articles/universal-login/text-customization-prompts/mfa.md
new file mode 100644
index 0000000000..283fa545a0
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/organizations.md b/articles/universal-login/text-customization-prompts/organizations.md
new file mode 100644
index 0000000000..0cf5837020
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/reset-password.md b/articles/universal-login/text-customization-prompts/reset-password.md
new file mode 100644
index 0000000000..dcb8debd5c
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/signup-id.md b/articles/universal-login/text-customization-prompts/signup-id.md
new file mode 100644
index 0000000000..e7d89bd0c8
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/signup-password.md b/articles/universal-login/text-customization-prompts/signup-password.md
new file mode 100644
index 0000000000..50e26d2102
--- /dev/null
+++ b/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/articles/universal-login/text-customization-prompts/signup.md b/articles/universal-login/text-customization-prompts/signup.md
new file mode 100644
index 0000000000..137e38141f
--- /dev/null
+++ b/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/articles/universal-login/text-customization.md b/articles/universal-login/text-customization.md
new file mode 100644
index 0000000000..eddd3e613f
--- /dev/null
+++ b/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/articles/universal-login/version-control.md b/articles/universal-login/version-control.md
new file mode 100644
index 0000000000..571f0310dc
--- /dev/null
+++ b/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/articles/user-profile/customdb.md b/articles/user-profile/customdb.md
deleted file mode 100644
index dd7ed686d9..0000000000
--- a/articles/user-profile/customdb.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Update Users Using Your Database
-description: How to update user profiles when using your own database as an identity provider.
-toc: true
----
-
-# Update Users Using Your Database
-
-You can update user profiles when using [your own database as an identity provider](/connections/database/custom-db) by:
-
-* Using the [Management API](/api/management/v2#!/Users/patch_users_by_id).
-* Updating the user in your database.
-* [Enabling user migration](/users/migrations/automatic) 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.
-
-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. And 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 `email` and `email_verified` via the Management API. However, normal rules for updating other user fields will still apply as described in the [Normalized User Profile](/user-profile/normalized) (for example, you will still not be able to update fields such as `nickname`, `picture` and so on).
-
-## User profile cache
-
-Auth0 [caches the user profile](/user-profile/user-profile-details#caching-of-the-user-profile-in-auth0) 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](/user-profile/normalized) fields are based on the values returned from the Login Script of your custom database connection.
diff --git a/articles/user-profile/index.md b/articles/user-profile/index.md
deleted file mode 100644
index 00a168c14c..0000000000
--- a/articles/user-profile/index.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-description: Explains the basics of a User profile, how to create a user and view users and their profile details.
-toc: true
----
-# User Profile
-
-The Auth0 **User Profile** is the set of attributes that contains specific information about a user. User Profile information may include the user's name, email address, contact information, and so on.
-
-User Profile attributes can come from many places. Attributes may be returned by the authenticating service (such as Facebook), as well as via custom databases and web services. Auth0 refers to all attribute sources as **Connections** because Auth0 connects to them to authenticate the user.
-
-## Manage users using the Dashboard
-
-Use the [Dashboard > Users](${manage_url}/#/users) 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.
-:::
-
-![User Profile Dashboard](/media/articles/user-profile/user1.png)
-
-### Create a user
-
-To create a new user and their corresponding User Profile, click the [Users](${manage_url}/#/users) page in the Dashboard. Click the **+Create User** button at the top right of the *Users* page. You will be prompted to enter the following information:
-
-* **Email**: the user's email address. The maximum length is 64 chars for the user/local part and 256 chars for the domain part.
-* **Password**: the user's password. There is no limit for max password length. For more information refer to [Password Strength in Auth0 Database Connections](/connections/database/password-strength).
-* **Repeat Password**: retype the user's password to ensure that you entered the password correctly.
-* **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.
-
-Fill in the required information and click **Save** to create the new user. For more information refer to: [Creating Users via the Management Dashboard](/tutorials/creating-users-in-the-management-portal).
-
-::: note
-The User Details page will show `pending` when a user is first created until they have logged in for the first time.
-:::
-
-### 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
-
-The Details tab contains three sections that provide a high-level overview of the information in the user's profile:
-
-1. **User Identity** provides at-a-glance details about the user, including their email address, associated Connections, and access rights.
-2. **Metadata** displays the `app_metadata` and `user_metadata` information. You can edit these values.
-3. **Identity Provider Attributes** displays the information retrieved from the authentication provider. Note that identity provider attributes are read-only.
-
-#### User Details: Devices
-
-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
-
-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
-
-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
-
-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.
-
-### Impersonate a user
-
-<%= include('../_includes/_deprecate-impersonation.md') %>
-
-If you need to log in to your app as a user, see everything exactly as the user sees it, and do everything exactly as the user does it, you can do this using the Dashboard.
-
-Navigate to the [Users](${manage_url}/#/users) page in the Dashboard. Select the user you want to impersonate from the list. When the User Details page opens, click the "Sign in as User" button. Select the app you want to log into from 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 will display the URL to use to impersonate the user. You can 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 Impersonation API
-You can also use the [Impersonation API](/api/authentication/reference#impersonation) to impersonate a user. The API generates a link that you can use once to log in as a specific user. To distinguish between real logins and impersonation logins, the profile of the impersonated user will contain additional `impersonated` and `impersonator` properties.
-:::
-
-Please see [User Impersonation](/user-profile/user-impersonation) for more information about impersonating a user.
-
-### Block and unblock a user
-
-To disable a user's access to your apps, you can block the user in the Dashboard.
-
-To block a user, navigate to the [Users](${manage_url}/#/users) page in the Dashboard. Click the name of the user you want to block. When the User Details page opens, click the "Actions" button. 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 see the error message `user is blocked`.
-
-To unblock a user, navigate to the [Users](${manage_url}/#/users) page in the Dashboard. Click the name of the user you want to unblock. When the User Details page opens, click the **Actions** button. Select **Unblock User** from the dropdown menu.
-
-![Unblock a User](/media/articles/user-profile/user4.png)
-
-### Delete a user
-
-To permanently delete a user, navigate to the [Users](${manage_url}/#/users) page in the Dashboard. Click the name of the user you want to delete. When the User Details page opens, click the **Actions** button. 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. Click the **Yes, Delete It** button to confirm. This will permanently delete the user.
-
-## Manage users using the Management API
-
-Alternatively, you can retrieve, create, update or delete users using our [Management API](/api/management/v2#!/Users/get_users).
-
-First, you have to generate an `access_token` to call the Management API. For information on how to do that refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens).
-
-Instead of making the HTTP calls directly, and depending on the platform you use, you can use one of our SDKs. For a list of available SDKs, refer to [the SDKs section of our Support Matrix](/support/matrix#sdks).
-
-## User access to applications
-
-Inside a single Auth0 tenant the users are shared between applications. The idea here is that the all the applications in a single tenant will usually belong to the same app.
-
-For total separation you can create a new tenant. To do this 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.
-
-If you need to restrict some users to certain applications you can use 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/master/rules/simple-user-whitelist-for-app.md).
-
-You can also restrict users from applications by configuring a new connection and only giving access to a specific application. To enable application access for a connection go to the the **Settings** section for a connection and click on the **Applications** tab, here you can enable/disable any application.
-
-## Keep reading
-
-::: next-steps
-* [User Profile Attributes](/user-profile/user-profile-structure)
-* [Auth0 Normalized User Profile](/user-profile/normalized)
-* [User Metadata](/metadata)
-* [User Profile: In-Depth Details](/user-profile/user-profile-details)
-* [Update Users using a Custom Database](/user-profile/customdb)
-:::
diff --git a/articles/user-profile/normalized/auth0/index.md b/articles/user-profile/normalized/auth0/index.md
deleted file mode 100644
index e5950eb18e..0000000000
--- a/articles/user-profile/normalized/auth0/index.md
+++ /dev/null
@@ -1,201 +0,0 @@
----
-description: Auth0 normalizes common user properties in the User Profile.
-toc: true
----
-
-# Auth0 Normalized User Profile
-
-::: version-warning
-This version described a user's profile as normalized by Auth0. Use the dropdown for the user profile structure that conforms with the OIDC specification and includes only the standard claims.
-:::
-
-This article describes the claims included in the normalized user profile, as created by Auth0. This is a protocol-agnostic representation of the user that provides a standard way of storing user-related claims, regardless of the identity provider(s) involved. 
-
-Since every identity provider provides a different set of information about a user, Auth0 normalizes common profile properties in the User Profile. For example, `family_name` in the User Profile contains details that may have been returned as `surname` or `last_name`.
-
-::: note
-The Auth0 claims included in the normalized 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 the response from the [/userinfo](/api/authentication#user-profile) endpoint (both of which follow the requirements detailed in the OIDC specification). 
-:::
-
-## 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.
-* **`picture`**: the URL of the [user's picture](/user-profile/user-picture). 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.
-
-A user's `name`, `nickname`, and `picture` attributes are not directly editable, however you can update the fields in the `user_metadata` to update them for your front-end as desired. [Click here for more details for changing a user's picture](/user-profile/user-picture#change-a-user-s-picture); the `name`, `nickname` fields can be updated in the same way.
-
-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` but these fields are not available to be edited with the [update a user endpoint](/api/management/v2#!/Users/patch_users_by_id).
-:::
-
-::: 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](#uniquely-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.
-
-::: note
-For more information, see: [Link Accounts](/link-accounts).
-:::
-
-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.
-:::
-
-## 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.
-
-## Uniquely identify users
-
-There are two recommended options to uniquely identify your users:
-
-1. By the `user_id` property. This is guaranteed to be unique per user (such as `{identity provider id}|{unique id in the provider}`, or `facebook|1234567890`).
-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. E.g:
-
-```javascript
-function login (email, password, callback) {
-  var user = getUserFromDB(email);
-  var profile = {
-    user_id: 'MyConnection1|' + user.id,
-    email: user.email,
-    [...]
-  };
-  callback(null, profile);
-}
-```
-
-## Sample User Profiles
-
-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"
-}
-```
-
-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"
-}
-```
-
-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"
-}
-```
-
-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"
-}
-```
-
-## How to retrieve the user profile
-
-There are more than one endpoints you can use to retrieve users. You can search by Id, email, or other criteria, depending on your scenario. For more information on these endpoints and sample requests, refer to [User Search](/users/search).
diff --git a/articles/user-profile/normalized/index.yml b/articles/user-profile/normalized/index.yml
deleted file mode 100644
index 2623879dac..0000000000
--- a/articles/user-profile/normalized/index.yml
+++ /dev/null
@@ -1,9 +0,0 @@
-versioning:
-  baseUrl: user-profile/normalized
-  current: auth0
-  versions:
-    - auth0
-    - oidc
-  defaultArticles:
-    auth0: index
-    oidc: index
\ No newline at end of file
diff --git a/articles/user-profile/normalized/oidc/index.md b/articles/user-profile/normalized/oidc/index.md
deleted file mode 100644
index 839d3995e0..0000000000
--- a/articles/user-profile/normalized/oidc/index.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-description: Claims for a user profile returned via an OIDC-Compliant authorization flow
----
-# User Profiles Returned from OIDC-Compliant Pipelines
-
-::: version-warning
-This article describes the user profile that includes only the [OpenID Connect 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](/user-profile/normalized).
-
-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": "",
-   "updated_at": "",
-  }
-```
-
-## How to Retrieve the User Profile
-
-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 1.x](/quickstart/spa/angularjs/02-user-profile) and [Angular 2](/quickstart/spa/angular2/03-user-profile)
-- [jQuery](/quickstart/spa/jquery/02-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` | location where the user is located |
-| `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 |
diff --git a/articles/user-profile/progressive-profiling.md b/articles/user-profile/progressive-profiling.md
deleted file mode 100644
index d62d26f30a..0000000000
--- a/articles/user-profile/progressive-profiling.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-description: This page details how Auth0 can help you implement progressive profiling in your website or application.
----
-# Progressive Profiling
-
-Rather than asking your users to fill out extensive registration forms, you can implement **progressive profiling**, a technique to collect user information as users interact with your system, on your website or application.
-
-For example, you might collect just the user's name, email, and password on initial signup. At a later point in time, you might ask for the name of their company and their title.
-
-::: note
-Golden Rule: Never ask what you already know. If a user signs-up using a social network, you might already have demographic information on that user.
-:::
-
-## Progressive Profiling and Auth0
-
-One of the places you can get information for your progressive profile is Auth0. Every user that authenticates through Auth0 gets a User Profile, and the profile's contents can come from three different sources:
-
-* Properties supplied by the identity provider properties (such as any user property coming from LinkedIn, Facebook, or any [connection](/identityproviders)).
-* Attributes that are dynamically created in [Auth0 Rules](/rules) or 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 two sources are generally not directly relevant to **progressive profiling** (though they do supply information you won't need to ask the user for).
-
-::: note
-Users logging in with social networks will typically **consent** to disclose their information.
-:::
-
-Using the Auth0 [Users API](/api/v2#!/Users/patch_users_by_id), you can augment the profile of any authenticated user with any information. Auth0 metadata objects can contain any serializable data structure.
-
-The choice of what to collect, when to collect it, and how to collect it, are up to you. Each application will implement progressive profiling differently. Your application might already do so, in fact.
-
-::: note
-Auth0 provides two [metadata](/metadata) attributes: **user metadata** and **app metadata**. You can update the contents of your metadata fields with the [Management APIv2](/api/management/v2).
-:::
-
-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.
diff --git a/articles/user-profile/user-data-storage.md b/articles/user-profile/user-data-storage.md
deleted file mode 100644
index 9432048f1d..0000000000
--- a/articles/user-profile/user-data-storage.md
+++ /dev/null
@@ -1,300 +0,0 @@
----
-title: User Data Storage Guidance
-description: Demonstrates the best practices in using Auth0 storage mechanisms through the scenario of a native Swift app with a Node API backend
-toc: true
----
-
-# User Data Storage Guidance
-
-Auth0 provides multiple places to store data used to authenticate an Application's users. This document covers best practices on how to store your data securely and efficiently. It uses a sample Application (a mobile music application) that reflects the end-to-end user experience of using Auth0 with an external database to illustrate specific topics.
-
-The sample Application is a basic iOS app utilizing 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).
-
-## Where should I store my authentication data?
-
-To store user data points beyond the basic information Auth0 uses for authentication, you can use:
-
-1. The Auth0 data store;
-2. A [custom database](/connections/database/mysql).
-
-However, if you use these additional data points for authentication purposes, we recommend using the Auth0 data store, as this allows you to manage your user data through the [Auth0 Management Dashboard](${manage_url}).
-
-## How should I use the Auth0 data store?
-
-Any data you store in Auth0 that's *not* already a part of the user profile should go into one of the two provided [metadata](/metadata) :
-
-* `app_metadata`
-* `user_metadata`
-
-These fields contain JSON snippets and can be used during the Auth0 authentication process.
-
-### App metadata
-
-You can store data points that are read-only to the user in `app_metadata`. Three common types of data for 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.
-
-For a list of fields that *cannot* be stored within `app_metadata`, please see the [metadata overview page](/metadata#metadata-restrictions).
-
-#### Example: App metadata for a mobile music application
-
-The following data points from our mobile music application appropriate to store in `app_metadata`:
-
-* A user's subscription plan;
-* A user's right (or lack thereof) to edit featured playlists.
-
-These two should be stored in `app_metadata` instead of `user_metadata` because they should not be directly changeable by the user.
-
-The following section details [rules](/rules) we use to implement permissions on whether a user can edit featured playlists or not.
-
-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) {
-  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);
-    }
-
-  });
-
-}
-```
-
-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)
-
-### User metadata
-
-The following data points from our mobile music application are appropriate to store in `user_metadata`:
-
-* Application preferences;
-* Avatar customization;
-* 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`.
-
-#### Example: User metadata for a mobile music application
-
-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/tokens).
-
-## Why shouldn't I put all my Application's data in the Auth0 data store?
-
-Because the Auth0 data store is customized for authentication data, storing anything beyond the default user information should be done only in limited cases. Here's why:
-
-* **Scalability**: The Auth0 data store is limited in scalability, and your Application's data may exceed the appropriate limits. By using an external database, you keep your Auth0 data store simple, while the more efficient external database contains the extra data;
-* **Performance**: Your authentication data is likely accessed at lower frequencies than your other data. The Auth0 data store isn't optimized for high frequency use, so you should store data that needs to be retrieved more often elsewhere;
-* **Flexibility**: Because the Auth0 data store was built to accomodate only user profiles and their associated metadata, you are limited in terms of the actions you can perform on the database. By using separate databases for your other data, you can manage your data as appropriate.
-
-### Example
-
-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 our Application.
-
-The user's unique identifier is their [user_id](/user-profile/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.](/jwt)
-:::
-
-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
-});
-
-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);
-    });
-  });
-
-};
-```
-
-## Summary
-
-When determining where you should store specific pieces of data about your user, here are the general rules of thumb:
-
-| Type of Data | Storage Location |
-| --- | --- |
-| Data that should be **read-only** to the user | `app_metadata` |
-| Data that should be **editable** by the user | `user_metadata` |
-| Data unrelated to user authentication | External database |
diff --git a/articles/user-profile/user-impersonation.md b/articles/user-profile/user-impersonation.md
deleted file mode 100644
index 9baab45533..0000000000
--- a/articles/user-profile/user-impersonation.md
+++ /dev/null
@@ -1,264 +0,0 @@
----
-description: This page explains how to impersonate a user, a feature often used for testing and troubleshooting purposes.
-toc: true
----
-# User impersonation
-
-<%= include('../_includes/_deprecate-impersonation.md') %>
-
-In this article, we will cover:
-
-* Why you might use impersonation
-* How you can use impersonation
-* What the risks of using impersonation are
-* Go through a sample implementation
-
-## Why impersonation
-
-Often administrators need to impersonate other users for testing or troubleshooting purposes. Using impersonation, administrators 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.
-:::
-
-## Limitations
-
-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/access-token) returned to applications when using this flow is only valid for requests to [the /userinfo endpoint](/api/authentication#get-user-info). 
-
-## Enable 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.
-
-## Use the dashboard
-
-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.
-
-![Click Sign in as User](/media/articles/user-profile/user2.png)
-
-::: panel I can't see this button
-In order to see this button the following conditions should apply:
-- Impersonation should be enabled for your tenant (see panel at the top of this page)
-- The Applications registered in the tenant must have at least one __callback URL__ listed
-- The Applications must have the connections turned on that the users who are to be impersonated belong to
-:::
-
-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).
-
-![Links for User Impersonation](/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/id-token) 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](#impersonate-a-user-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`. Learn more about [using the state parameter here](/protocols/oauth2/oauth-state).
-
-## Use the impersonation API
-
-You can also use the [Impersonation API](/api/authentication/reference#impersonation). The API generates a link that can be used once to log in as a specific user. To distinguish between real logins and impersonation logins, the profile of the impersonated user will contain additional `impersonated` and `impersonator` properties. For more details on how to use the API read on.
-
-## Sample implementation
-
-Let's 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. Find the user ID
-
-You can 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 refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens) documentation.
-
-The Management APIv2 Token will be valid for 24 hours, so you should ask for a token everytime you make a request to the API, or vigorously handle `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)
-
-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 should include the following:
-
-- `protocol`: the protocol to use against the identity provider. It could be `oauth2` again or something else. (for example, Office 365 uses WS-Federation, Google Apps 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"
-  }
-  ```
-
-The `state` is an optional parameter, but we strongly recommend you [use it as it mitigates CSRF attacks](/protocols/oauth2/oauth-state).
-
-The `callback_url` must match what is defined in your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
-
-There are various possible values for `scope`:
-
-- `scope: 'openid'`: _(default)_ It will return, not only an opaque Access Token, but also an [ID Token](/tokens/id-token) which is a JSON Web Token ([JWT](/jwt)). The JWT will only contain the user id (`sub` claim).
-- `scope: 'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the [ID Token](/tokens/id-token) (for example, `scope: 'openid name email picture'`).
-
-You can get more information about this in the [Scopes documentation](/scopes).
-
-::: note
-Impersonation cannot be used to return [JWT Access Tokens](/tokens/access-token) 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\": \"\"}}"
-  }
-}
-```
-
-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
-
-Upon successful authentication, a URL will be returned as response that will 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 Applications. In case yours is a Single Page Application (SPA) you would have to use `"response_type":"token"` when invoking the [Impersonation API](/api/authentication/reference#impersonation). Once you do this Auth0 will redirect to your SPA _Callback URL_ with Access Token and ID Token in the `#` params. You can read more on the OAuth2 Implicit flow [here](/protocols/oauth2/oauth-implicit-protocol).
-:::
-
-### 3. Exchange Code with Token
-
-Now you should exchange the Authorization Code you received for a token. Note that this should already be implemented if you have a regular webapp and are using 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/json" }
-  ],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"client_id\": \"${account.clientId}\",\"client_secret\": \"YOUR_CLIENT_SECRET\",\"code\": \"AUTHORIZATION_CODE\",\"grant_type\": \"authorization_code\",\"redirect_uri\": \"${account.callback}\"}"
-  }
-}
-```
-
-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
-}
-```
-
-Congratulations, you are done!
-
-## Keep reading
-
-::: next-steps
-- [Troubleshooting? This is what you shouldn’t do](https://auth0.com/blog/2015/12/14/how-not-to-troubleshoot-bugs-by-impersonating-users/)
-- [Identity Protocols supported by Auth0](/protocols)
-:::
diff --git a/articles/user-profile/user-picture.md b/articles/user-profile/user-picture.md
deleted file mode 100644
index c954bc4299..0000000000
--- a/articles/user-profile/user-picture.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-description: How to use the user_metadata to change a user's picture field and how to change the default picture for all users.
----
-
-# User Picture
-
-Auth0 [normalizes](/user-profile/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)
-
-## Change a User's Picture
-
-The `user.picture` attribute is not directly editable. As an alternative, you can use the [User Metadata](/metadata) to store a picture attribute which you can then use in your application as desired. The `user_metadata` field can be updated by [calling the Management API v2 endpoint](/api/management/v2#!/Users/patch_users_by_id) with the `id` of the specified user.
-
-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": ""
-}
-```
-
-If you want to ensure that the picture from the `user_metadata` is returned in the `id_token`, you will need to create a [Rule](/rules) which will 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
-
-If you want 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
-
-::: next-steps
-- [Structure of the User Profile](/user-profile/user-profile-structure)
-- [User Profile: In-Depth Details](/user-profile/user-profile-details)
-- [Auth0 Blog: Update of the user's details section](https://auth0.com/blog/update-of-the-user-details-section/)
-:::
diff --git a/articles/user-profile/user-profile-details.md b/articles/user-profile/user-profile-details.md
deleted file mode 100644
index e445cc4059..0000000000
--- a/articles/user-profile/user-profile-details.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-description: This page details Auth0 User Profiles, such as sources of profile data, normalized user profiles, caching, profile structure and custom profiles.
-toc: true
----
-
-# User Profile: In-Depth Details
-
-The Auth0 **User Profile** is a set of attributes about a user, such as first name, last name, email address, and nickname. The attributes may also include information from social providers, such as a person's contacts or their profile picture, or in the case of Enterprise users, company identifiers such as an employee number or the name of the department to which an employee belongs.
-
-## Sources of User Profile Data
-
-User Profile attributes may come from multiple sources. A core set of attributes will come from the service, such as Facebook or LinkedIn, that authenticates a user. Alternatively, 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.
-
-Other types of authentication services include custom databases, web services, and the database that is included as part of the Auth0 service. These authentication services are also called providers, authentication providers or identity providers (often referred to as IDPs). Within Auth0, they are called **Connections**, because Auth0 connects to them to authenticate a user.
-
-## Normalized User Profile
-
-Auth0 supports [a wide variety of Connections](/identityproviders). 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](/user-profile/normalized). Auth0 will return a basic set of information using specific attribute names so programs can rely on using those exact 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](/user-profile/normalized).
-
-## Caching of the User Profile in Auth0
-
-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.
-
-The User Profile is cached for several reasons. First, caching allows you the option of implementing [Single Sign-On](/sso) at the Auth0 layer to avoid going to the Connection for every request. Additionally, this provides resilience if a Connection is temporarily unavailable.
-
-You may delete a user's cached profile via the Auth0 Dashboard or the Management API.
-
-## Structure of User Profile Data
-
-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.
-
-"Details" consists of core User Profile object with basic information such as name, email, and the timestamp of the latest login. The core User Profile object may contain additional attributes from its source Connection, in addition to the normalized Auth0 User Profile attributes.
-
-The User Profile object then has two **metadata** sub-objects, one called `user_metadata` and the other `app_metadata`. The metadata objects can be used to store additional User Profile information. The `user_metadata` object should be used to store user attributes, such as user preferences, that don't impact what a user can access. The `app_metadata` object should be used for user attributes, such as a support plan, security roles, or access control groups, which can impact how an application functions and/or what the user can access. [Learn more](/api/management/v2/changes#8) about when to use `app_metadata` vs `user_metadata`.
-
-::: panel Metadata Data Limits
-Both `app_metadata` and `user_metadata` are limited to a size of 16mb each. However, we recommend against using these properties like a database. They should be used for identity related information. Additionally, at some point we may put a more strict size limit on these properties.
-
-In addition, please be aware that using Rules and/or the Management Dashboard may further limit the amount of metadata you can store.
-:::
-
-::: warning
-Please note that an authenticated user can perform actions that modify data in their profile's **user_metadata**, but they can't do anything that modifies their **app_metadata**.
-:::
-
-::: note
-Use a consistent datatype each time you create or update a given metadata field. Using `user.user_metadata.age = "23"` for one user and `user.user_metadata.age = 23` for another user will cause issues when retrieving the data.
-:::
-
-Lastly, there is a section called `Identity Provider Attributes`. Here you will find all the information retrieved from the authentication provider (such as Facebook, Twitter, Google, SAML, your own provider, and so on). This section will always contain at least one identity provider, and it is the one the user originally authenticated against. This data is read-only.
-
-Auth0 also supports the ability for users to [link their profile to multiple identity providers](/link-accounts), and when they do, those additional identities show up in this array. The contents of an individual identity provider object varies by provider, but it will typically include a user identifier, the name of the provider, the name of the connection set up in Auth0 for that provider, whether it is a social provider, and in some cases an API Access Token that can be used with that provider.
-
-## Storing Custom Profile Data
-
-You can use `user_profile` to store custom attributes such as the user's favorite color or phone number.
-
-Auth0 provides a [JS widget](https://github.com/auth0/auth0-editprofile-widget) that allows the user to update their profile information.
-
-## Application Access to User Profile
-
-The User Profile will be provided to an app 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](/).
-
-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.
-
-## Management API Access to User Profiles
-
-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. The documentation for these Authentication API calls can be found [here](/auth-api). Typically, most of these endpoints are used by the various Auth0 SDKs, not your own code. However, one endpoint that is particularly important for User Profile is [`/userinfo`](/api/authentication/reference#get-user-info), which will be discussed later in this article.
-
-## 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](/jwt) (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:
-
-* an Auth0 `access_token`;
-* a 3rd party provider Access Token;
-* a `refresh_token`.
-
-For more information on tokens and claims see the [Token Overview](/tokens).
-
-## Modification of User Profiles
-
-The information contained in a User Profile and in an `id_token` can be modified in a number of ways.
-
-### 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). Examples of different scopes are discussed [here](/scopes).
-
-### Dashboard
-
-The User Profile can also be modified through the Auth0 Management 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.
-
-In the Auth0 dashboard, click on "Users", then the user to be edited, then "EDIT". The User Profile attributes within USER metadata and APP metadata can be edited by specifying profile data in JSON format with a key (attribute name) and value (value of the attribute). Pressing "SAVE" will save the information to the Auth0 cache of User Profile information for the user where it will be visible by applications integrated with Auth0. This "SAVE" will not alter information in the core user profile which is provided by the Connection.
-
-::: note
-The User Details page will show “pending” when a user is first created until they have logged in for the first time.
-:::
-
-### Management API
-
-The Auth0 Management API provides access to read, update, and delete User Profiles stored in the Auth0 database.
-
-::: note
-You can setup Access Control List (ACL)/Roles functionality by adding custom attributes to the user profile. We actually have a [sample](https://github.com/auth0-samples/auth0-roles-permissions-dashboard-sample), that you can use a guide.
-:::
-
-#### Limitations
-As with the dashboard, the API does not alter data sourced from Connections such as Facebook or Active Directory.
-
-Not all User Profile attributes can be altered via the API. For example, the identities array, which contains information from 3rd party authentication providers, cannot be altered.
-
-::: panel Modify identities array
-You may not be able to alter the identities array information, but there are some workarounds you could use. For example, let's say you want to modify the picture that is coming from the user's Facebook profile. You cannot change the attribute in the `Identity Provider Attributes` section, so instead you need to set the `picture` attribute in the `user_metadata` property and then in your application you could use `${'<%= user.user_metadata.picture || user.picture %>'}`. This code snippet tries to use the `picture` property from `user_metadata` and if it doesn't exist it uses the default (`user.picture`). You could set this as the `src` of the image to display.
-:::
-
-Another example is that the password can be set via the create or update call, 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.
-
-The [`/users`](/api/v2#!/Users/get_users) endpoint is used to retrieve information about all users. You may provide search criteria to find specific user(s).
-
-There is also [an endpoint](/api/v2#!/Users/get_users_by_id) to retrieve information about one user based on the `user_id`. Note that 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`.
-
-In addition, two other endpoints are available to retrieve User Profile information based on either the Auth0 `access_token` or the Auth0 `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.
-
-### Creating Users in a Custom Database
-
-The above APIs are used for creating and managing users in the Auth0 Database. If a [custom database](/connections/database/mysql) is used as the Connection, scripts must be written to implement lifecycle events such as Create, Login, Verify, Delete and Change Password. Auth0 provides templates for these scripts, but they must be modified as needed for the particular database and schema in use by a particular customer.
-
-The User Profile in the custom DB can be implemented with any User Profile structure desired, but it must be mapped in the Login call to the Auth0 normalized User Profile attributes as shown in the "Login" custom DB template. The Login script can also write to the `app_metadata` portion of the User Profile.
-
-The custom DB templates are accessed via
-*Connections* -> *Database* -> *Custom Database*. Be sure to turn on the "Use my own database" toggle to enable editing the scripts.
-
-If additional attributes need to be added to the profile, this can be done with Rules, as explained below.
-
-### Rules
-
-The Auth0 Rules feature is a powerful capability which allows developers to extend the core functionality of Auth0. Rules execute after a user has been authenticated and can be used to augment the User Profile during the authentication transaction, and optionally persist those changes back to Auth0.
-
-Auth0 provides several sample rules to provide examples of how to achieve certain results. In the Auth0 dashboard, these samples can be viewed by clicking on "Rules" and "NEW RULE". There are several samples in the "ENRICH PROFILE" section that show how to add User Profile attributes.
-
-#### Persistent vs Transient profiles
-
-The "ADD ATTRIBUTES TO A USER FOR SPECIFIC CONNECTION" sample shows how to add attributes to a User Profile for a particular login transaction. These attributes will not be persisted in the cached User Profile, so they will not be visible to any other authentication transactions.
-
-The "ADD PERSISTENT ATTRIBUTES TO THE USER" sample shows how to use the `updateUserMetadata` function within a rule to persist the altered User Profile data to the cache of the user's profile data stored in the Auth0 database. This mechanism can be used to alter the `user_metadata` section of the User Profile.
-
-The "SET ROLES TO A USER" sample shows how to use the `updateAppMetadata` function within a rule to persist changes to the `app_metadata` section of the User Profile to the cached User Profile in the Auth0 database.
-
-The altered `user_metadata` and `app_metadata` information that is written to the Auth0 User Profile will be visible by subsequent authentication transactions. Mechanisms for viewing User Profile data that do not occur in the context of an authentication transaction, such as viewing profile information in the Auth0 dashboard, will not show the results of modifications made in Rules, unless those modifications are persisted as described above.
-
-Finally, as with API calls, altering the User Profile in Auth0 does not alter core data sourced from the original Connection.
-
-More info:
-
-* [Rules](/rules)
-* [User profile metadata in rules](/rules/metadata-in-rules)
-* [Altering SAML authentication assertion attributes/claims for a SAML app](https://github.com/auth0/rules/blob/master/rules/saml-attribute-mapping.md)
-
-### Rules and their Usage
-
-The impact of rules which alter User Profile information will be visible in some situations but not in others. The results of rules will be visible when the profile is viewed or accessed in the context of a user's login transaction. If an application calls an Auth0 library in the context of a user session, the SDK call will return the User Profile including any modifications made within rules. This also holds true for use of the [`/userinfo`](/api/authentication/reference#get-user-info) authentication endpoint.
-
-When the profile is viewed outside the context of the user login transaction, the results of rules will not be included. This is the case when using the [`/tokeninfo`](/api/authentication/reference#get-token-info) authentication endpoint, or the Auth0 Dashboard.
-
-## Mapping User Profile Attributes in 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.
-
-## Mapping User Profile Attributes in 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**.
-
-## User Profile with Account Linking
-
-Users may log into an application initially via one Connection (such as a database). They may 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 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 that the User Profile attributes from the multiple providers are not merged. The core User Profile attributes will be sourced from the first provider used.
-
-Information on linking accounts and examples of profiles are located [here](/link-accounts).
diff --git a/articles/user-profile/user-profile-structure.md b/articles/user-profile/user-profile-structure.md
deleted file mode 100644
index e5881ba86b..0000000000
--- a/articles/user-profile/user-profile-structure.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Structure of the User Profile
-description: This page lists the attributes that are available on the Auth0 user profile
----
-
-# Structure of the User Profile
-
-The Auth0 user profile is the set of attributes that contains specific information about a user. User profile information may include the user's name, email address, contact information, and so on.
-
-The following attributes are available on the user profile.
-
-* `app_metadata`: Custom fields storing information about a user. These attributes contain information that influences the user's access. For more info see [Metadata](/metadata).
-
-* `blocked`: The `true/false` value indicating if the user has been blocked.
-
-* `created_at`: The timestamp of when the user profile was first created.
-
-* `email` (unique): The user's email address.
-
-* `email_verified`: The `true/false` value indicating if the user has verified their email address.
-
-* `identities`: The array of objects with information about the user's identities:
-
-    * `connection`: The name of the connection used to authenticate the user
-    * `isSocial`: The `true/false` value indicating if the connection is a social one or not
-    * `provider`: The entity that is authenticating the user (such as Facebook, Twitter, and so on)
-    * `user_id`: The user's unique identifier for this connection/provider
-
-
-* `multifactor`: The list of multifactor providers in which the user is enrolled.
-
-* `last_ip`: The IP address associated with the user's last login.
-
-* `last_login`: 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).
-
-* `logins_count`: The number of times the user has logged in.
-
-* `name`: The user's name.
-
-* `nickname`: The user's nickname.
-
-* `phone_number`: The user's phone number.
-
-* `phone_verified`: The `true/false` value indicating whether the user's phone number has been verified (only valid for users with SMS connections).
-
-* `picture`: [The user's profile picture](/user-profile/user-picture).
-
-* `updated_at`: The timestamp of when the user's profile was last updated/modified.
-
-* `user_id` (unique): The user's unique identifier.
-
-* `user_metadata`: The custom fields storing information about a user. These attributes should contain information about the user that does not impact what they can or cannot access (such as work and home addresses). For more info see [Metadata](/metadata).
-
-* `username` (unique): The user's username.
-
-Most user profile fields are not returned as part of [ID Token](/tokens/id-token), nor are they included in the response from the [/userinfo endpoint](/api/authentication#get-user-info) of the Authentication API. To retrieve user datails from these fields you will need to utilize one of the [User endpoints](/api/management/v2#!/Users/get_users) of the Management API. For more info on the endpoints you can use to retrieve users, see [User Search Best Practices
-](/users/search/best-practices).
-
-## Blacklisting 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 on how to do that refer to [Blacklisting User Attributes](/tutorials/blacklisting-attributes).
diff --git a/articles/users/_includes/_account-linking-id-tokens.md b/articles/users/_includes/_account-linking-id-tokens.md
new file mode 100644
index 0000000000..a0f35dedb5
--- /dev/null
+++ b/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/articles/users/_includes/_connection-synch-note.md b/articles/users/_includes/_connection-synch-note.md
new file mode 100644
index 0000000000..a9f14724eb
--- /dev/null
+++ b/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/articles/users/_includes/_password-encoding-description.md b/articles/users/_includes/_password-encoding-description.md
new file mode 100644
index 0000000000..0031b41049
--- /dev/null
+++ b/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/articles/users/_includes/_user-prop-identities.md b/articles/users/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..cbd83244dd
--- /dev/null
+++ b/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/articles/users/concepts/overview-progressive-profiling.md b/articles/users/concepts/overview-progressive-profiling.md
new file mode 100644
index 0000000000..b6595ba26b
--- /dev/null
+++ b/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/articles/users/concepts/overview-user-account-linking.md b/articles/users/concepts/overview-user-account-linking.md
new file mode 100644
index 0000000000..d872887ad9
--- /dev/null
+++ b/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/articles/users/concepts/overview-user-metadata.md b/articles/users/concepts/overview-user-metadata.md
new file mode 100644
index 0000000000..44fed097d4
--- /dev/null
+++ b/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/articles/users/concepts/overview-user-migration.md b/articles/users/concepts/overview-user-migration.md
new file mode 100644
index 0000000000..7f516fafdc
--- /dev/null
+++ b/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/articles/users/concepts/overview-user-profile.md b/articles/users/concepts/overview-user-profile.md
new file mode 100644
index 0000000000..71e68414a4
--- /dev/null
+++ b/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/articles/users/get-user-information-with-unbounce-landing-pages.md b/articles/users/get-user-information-with-unbounce-landing-pages.md
deleted file mode 100644
index 368e331a61..0000000000
--- a/articles/users/get-user-information-with-unbounce-landing-pages.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-description: How to get user information with one-click social authentication on Unbounce landing pages.
----
-# 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/articles/users/guides/azure-access-control.md b/articles/users/guides/azure-access-control.md
new file mode 100644
index 0000000000..29e9fd4940
--- /dev/null
+++ b/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/articles/users/guides/block-and-unblock-users.md b/articles/users/guides/block-and-unblock-users.md
new file mode 100644
index 0000000000..45e57f08d9
--- /dev/null
+++ b/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/articles/users/guides/bulk-user-exports.md b/articles/users/guides/bulk-user-exports.md
new file mode 100644
index 0000000000..3eb1aada24
--- /dev/null
+++ b/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/articles/users/guides/bulk-user-imports.md b/articles/users/guides/bulk-user-imports.md
new file mode 100644
index 0000000000..3545080a49
--- /dev/null
+++ b/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/articles/users/guides/change-user-pictures.md b/articles/users/guides/change-user-pictures.md
new file mode 100644
index 0000000000..44585a59aa
--- /dev/null
+++ b/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/articles/users/guides/configure-automatic-migration.md b/articles/users/guides/configure-automatic-migration.md
new file mode 100644
index 0000000000..bf8c2b6c20
--- /dev/null
+++ b/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/articles/users/guides/create-users.md b/articles/users/guides/create-users.md
new file mode 100644
index 0000000000..92470960c1
--- /dev/null
+++ b/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/articles/users/guides/delete-users.md b/articles/users/guides/delete-users.md
new file mode 100644
index 0000000000..b18a00679d
--- /dev/null
+++ b/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/articles/users/guides/email-verified.md b/articles/users/guides/email-verified.md
new file mode 100644
index 0000000000..02fc5a021d
--- /dev/null
+++ b/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/articles/users/guides/get-user-information-with-unbounce-landing-pages.md b/articles/users/guides/get-user-information-with-unbounce-landing-pages.md
new file mode 100644
index 0000000000..78dc41b345
--- /dev/null
+++ b/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/articles/users/guides/impersonate-users-using-the-dashboard.md b/articles/users/guides/impersonate-users-using-the-dashboard.md
new file mode 100644
index 0000000000..7eaac0e5a9
--- /dev/null
+++ b/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/articles/users/guides/impersonate-users-using-the-impersonation-api.md b/articles/users/guides/impersonate-users-using-the-impersonation-api.md
new file mode 100644
index 0000000000..f7b7edc0b7
--- /dev/null
+++ b/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/articles/users/guides/link-user-accounts-auth-api.md b/articles/users/guides/link-user-accounts-auth-api.md
new file mode 100644
index 0000000000..6de0c67af4
--- /dev/null
+++ b/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/articles/users/guides/link-user-accounts.md b/articles/users/guides/link-user-accounts.md
new file mode 100644
index 0000000000..8de250860c
--- /dev/null
+++ b/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/articles/users/guides/manage-user-access-to-applications.md b/articles/users/guides/manage-user-access-to-applications.md
new file mode 100644
index 0000000000..f16c8845b8
--- /dev/null
+++ b/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/articles/users/guides/manage-user-metadata.md b/articles/users/guides/manage-user-metadata.md
new file mode 100644
index 0000000000..79b85743c9
--- /dev/null
+++ b/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/articles/users/guides/manage-users-using-the-dashboard.md b/articles/users/guides/manage-users-using-the-dashboard.md
new file mode 100644
index 0000000000..865cef7e1b
--- /dev/null
+++ b/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/articles/users/guides/manage-users-using-the-management-api.md b/articles/users/guides/manage-users-using-the-management-api.md
new file mode 100644
index 0000000000..c1ede2f52b
--- /dev/null
+++ b/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/articles/users/guides/read-metadata.md b/articles/users/guides/read-metadata.md
new file mode 100644
index 0000000000..6392c91e8c
--- /dev/null
+++ b/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/articles/users/guides/redirect-users-after-login.md b/articles/users/guides/redirect-users-after-login.md
new file mode 100644
index 0000000000..72258e9615
--- /dev/null
+++ b/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/articles/users/guides/set-metadata-properties-on-creation.md b/articles/users/guides/set-metadata-properties-on-creation.md
new file mode 100644
index 0000000000..4568835620
--- /dev/null
+++ b/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/articles/users/guides/unlink-user-accounts.md b/articles/users/guides/unlink-user-accounts.md
new file mode 100644
index 0000000000..1604457605
--- /dev/null
+++ b/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/articles/users/guides/update-metadata-properties-with-management-api.md b/articles/users/guides/update-metadata-properties-with-management-api.md
new file mode 100644
index 0000000000..766b76747c
--- /dev/null
+++ b/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/articles/users/guides/update-user-profiles-using-your-database.md b/articles/users/guides/update-user-profiles-using-your-database.md
new file mode 100644
index 0000000000..2bd4d91c41
--- /dev/null
+++ b/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/articles/users/guides/view-users.md b/articles/users/guides/view-users.md
new file mode 100644
index 0000000000..733afddc62
--- /dev/null
+++ b/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/articles/users/index.md b/articles/users/index.md
index cf099a7de1..2b8b93b77d 100644
--- a/articles/users/index.md
+++ b/articles/users/index.md
@@ -1,120 +1,30 @@
 ---
+url: /users
+title: Manage Users
+description: Learn about working with users, user profiles, and user metadata in Auth0.
 classes: topic-page
-title: Users
-description: Learn about working with users in Auth0
+topics:
+  - users
+  - user-management
+contentType:
+  - index
+useCase:
+  - manage-users
+v2: true
 ---
+# Manage Users
 
-
        
-  
        
-  
        Users
        
-  
        
-    Learn about working with users, user profiles, and the endpoints used to retrieve users in Auth0.
-  
        
-
        
+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/articles/users/migrations/automatic.md b/articles/users/migrations/automatic.md
deleted file mode 100644
index 94650bf94f..0000000000
--- a/articles/users/migrations/automatic.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Automatic User Migration with Custom Database Connections
-description: Auth0 supports automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database as each person logs in and avoids asking your users to reset their passwords due to migration.
-crews: crew-2
-toc: true
----
-
-# Automatic User Migration with Custom Database Connections
-
-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. Your users are 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).
-:::
-
-## The Migration Process
-
-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.
-:::
-
-## Enable Data Validation
-
-There are certain validations that Auth0 can run before adding the user to the Auth0 database:
-
-- The email must be set and unique
-- If the connection requires a username (for example, the **Requires Username** toggle is enabled at the connection's settings), then one must be set
-- If a username is set, then it must be unique
-- The email format must be valid
-
-Additionally, both the email and the username will be converted to lowercase before they are stored.
-
-You can enable these validations for a connection using the [Update a connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) of the Management APIv2.
-
-```har
-{
-  "method": "PATCH",
-  "url": "https://${account.namespace}/api/v2/connections/{connection-id}",
-  "httpVersion": "HTTP/1.1",
-  "cookies": [],
-  "headers": [
-    { "name": "Authorization", "value": "Bearer {access-token}" }, 
-    { "name": "Content-Type", "value": "application/json"}
-  ],
-  "queryString": [],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{ \"options\": { \"strategy_version\": 2, \"nextOptionParam\": \"...\" } }"
-  },
-  "headersSize": -1,
-  "bodySize": -1,
-  "comment": ""
-}
-```
-
-- The parameter that enables the validations is the `"strategy_version": 2`. However, when you update `options`, the whole object is overridden, so all the parameters should be present. You can use the [Get a connection endpoint](/api/management/v2#!/Connections/get_connections_by_id) to get the whole object. Replace the `"nextOptionParam": "..."` placeholder with the list of parameters you get.
-- You should replace `{connection-id}` with the Id of the custom database connection you want to update. If you don't know it, you can use the [Get all connections endpoint](/api/management/v2#!/Connections/get_connections) to find it.
-- To access any Management APIv2 endpoint you need an Access Token (which you should set at the `{access-token}` placeholder of the `Authorization` header). For information on how to get one refer to [The Auth0 Management APIv2 Token](/api/management/v2/tokens).
-
-## Enable Automatic Migration
-
-### 1. Create a Custom Database
-
-You can create a new database connection in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard.
-
-On the **Custom Database** page, enable the **Use my own database** option:
-
-![DB Login Page in Dashboard](/media/articles/connections/database/custom-database.png)
-
-### 2. Turn on Automatic Migration
-
-On the **Settings** page for your database, enable the **Import Users to Auth0** option:
-
-![Dashboard Import Users Option](/media/articles/connections/database/import-users.png)
-
-### 3. Configure the Database Action Scripts
-
-On the **Custom Database** page, under *Database Action Scripts*, you will see the *Login* and *GetUser* scripts you need to configure.
-
-![Database Action Scripts page](/media/articles/connections/database/import-scripts.png)
-
-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**, **Oracle**, **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).
-
-The **Login** script executes each time a user that is not found in Auth0 database attempts to log in. It verifies that the user exists in the legacy database without prompting the user for their password again.
-
-The **Get User** script executes following any of these actions:
-
-* A user attempts to *sign-up*.
-* A user clicks on a valid [password change confirmation](/libraries/lock/customization#rememberlastlogin-boolean-) link.
-* The 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.
-:::
-
-### 4. Complete the Migration
-
-After you've enabled migration, you can verify the users that have migrated by:
-
-* Using the [List or search users](/api/v2#!/Users/get_users) Management API endpoint;
-* Reviewing the [Users](${manage_url}/#/users) list on the Dashboard.
-
-![Database Users](/media/articles/connections/database/migrated-users.png)
-
-Once all your users are in the Auth0 database, you are ready to convert the database to 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.
-
-At this point, you can disconnect your legacy database (**not** the Auth0 database). You will also want to keep **Import Users to Auth0** (on the **Settings** page) enabled. Your users will then be directed to use the new database workflow. You can configure [rules](/rules) to execute other functions when a user authenticates to your application.
diff --git a/articles/users/migrations/azure-access-control.md b/articles/users/migrations/azure-access-control.md
deleted file mode 100644
index 807f957470..0000000000
--- a/articles/users/migrations/azure-access-control.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Migrate from Azure Access Control Service to Auth0
-description: How to migrate from Azure Access Control Service to Auth0.
-toc: true
----
-
-# 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](/docs/applications). Create a new application on the [Dashboard](https://manage.auth0.com/#/applications).
-
-![Create Application window](/media/articles/applications/create-application-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.
-
-![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 Hosted Login Page](/hosted-pages/login)
-* [Manage user access with groups, roles, and permissions](/extensions/authorization-extension)
-:::
diff --git a/articles/users/migrations/bulk-import.md b/articles/users/migrations/bulk-import.md
deleted file mode 100644
index 26ccd5a6d6..0000000000
--- a/articles/users/migrations/bulk-import.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Bulk User Imports with the Management API
-description: How to perform bulk user imports with the Management API.
-crews: crew-2
-toc: true
----
-
-# Bulk User Imports with the Management API
-
-If you already have a user base, you can use our [/post_users_imports Management API endpoint](/api/management/v2#!/Jobs/post_users_imports) to populate a database connection with this information. The user data should first be exported in JSON format. You can then import that file using our API. 
-
-::: note
-Each affected user will need to reset their password when they log in the first time after the bulk import.
-:::
-
-## Pre-requisites
-
-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. For more information on how to configure a database connection at your [dashboard](${manage_url}), refer to [Database Identity Providers](/connections/database).
-
-## File schema
-
-The users file must have an array with the users' information in JSON format. The following [JSON schema](http://json-schema.org) describes valid users:
-
-```json
-{
-    "type": "object",
-    "properties": {
-        "email_verified": {
-            "type": "boolean"
-        },
-        "email": {
-            "type": "string",
-            "description": "The email of the user.",
-            "format": "email"
-        },
-        "username": {
-            "type": "string",
-            "description": "The username."
-        },
-        "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."
-        }
-    },
-    "required": ["email", "email_verified"],
-    "additionalProperties": false
-}
-```
-
-### User `app_metadata` schema
-
-Additionally, the `app_metadata` should **not** contain any of these properties:
-
-* `clientID`
-* `globalClientID`
-* `global_client_id`
-* `email_verified`
-* `user_id`
-* `identities`
-* `lastIP`
-* `lastLogin`
-* `metadata`
-* `created_at`
-* `loginsCount`
-* `_id`
-
-::: note
-The `app_metadata` stores information that can impact how an application functions or what the user can access (for example, a user's support plan or roles and access groups). For more information, refer to [User Metadata](/metadata).
-:::
-
-### File example
-
-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"
-    }
-  }
-]
-```
-
-::: note
-The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
-:::
-
-## How does it work?
-
-Using the bulk import endpoints, you should be able to [request a bulk import of users to a connection](/api/management/v2#!/Jobs/post_users_imports), receive a response, [check on a job's status](/api/management/v2#!/Jobs/get_jobs_by_id), and [check for details on any failed entries in your job](/api/management/v2#!/Jobs/get_errors).
-
-### Request a Bulk Import
-
-[The users import endpoint](/api/management/v2#!/Jobs/post_users_imports) requires that your `POST` request be of encoding type `multipart/form-data`.
-
-Your request should contain the following parameters:
-
-| Parameter | Description |
-|-----------|-------------|
-| `users` | The file, that containing the users to import, in JSON format. |
-| `connection_id` | The id of the connection to which the above users will be inserted. You can retrieve this information, using the [GET /api/v2/connections](/api/management/v2#!/Connections/get_connections) endpoint.|
-| `upsert` | A boolean value, `false` by default. If it is false, users will only be inserted. If there are already user(s) with the same emails as one or more of those being inserted, they will fail. If this value is set to `true` and the user being imported already exists, the user will be updated with the new information. |
-| `external_id` | This is an optional user defined string that can be used for correlating multiple jobs, and is returned as part of the job status response. |
-| `send_completion_email` | A boolean value which when set to `true`, sends a completion email to all tenant owners when the job is finished. The default is `true`, so you must explicitly set this parameter to `false` if you do *not* want emails sent. |
-
-If it works, you will get a response similar to the following one:
-
-```json
-{
-    "status":"pending",
-    "type":"users_import",
-    "id":"job_abcdef1234567890",
-    "connection":"abcd",
-    "external_id":"contoso"
-}
-```
-
-The returned entity represents the import job.
-
-Once the job finishes, whether it failed or was successful, the owner of the Auth0 tenant that the job is being run on will get an e-mail notifying them about the result (if `send_completion_email` was set to `true`). A notification email for a job that failed might notify the owner(s) that it failed to parse the users file JSON when importing users.
-
-### Query for Job Status
-
-You can query a job's status using the [GET /api/v2/jobs/{id} endpoint](/api/management/v2#!/jobs/get_jobs_by_id). If the job is complete, the job status response will show summary totals of successful/failed/inserted/updated records, as well. If there is an error in the job, it will return as failed (however, note that invalid user information, such as an invalid email, for example, will not make the entire job fail). 
-
-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).
-
-### Retrieve Failed Entries
-
-You can query and retrieve details on failed entries via the API using the [GET /api/v2/jobs/{id}/errors endpoint](/api/management/v2#!/Jobs/get_errors).
diff --git a/articles/users/migrations/gigya.md b/articles/users/migrations/gigya.md
deleted file mode 100644
index 2473691165..0000000000
--- a/articles/users/migrations/gigya.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Migrate Users from Gigya to Auth0
-description: How to import users from Gigya to Auth0.
-crews: crew-2
-toc: true
----
-
-# Migrate Users from Gigya to Auth0
-
-The tutorial will walk you through the process of configuring a custom database connection to import users from Gigya. It assumes that you have an Gigya account.
-
-## Configuring the Custom Database Connection
-
-### 1. Create a Custom Database
-
-You can 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 Application
-
-Now you'll need to connect your database to an 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-applications.png)
-
-## Export Gigya Users
-
-You can 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 [Auth0's user schema](/users/migrations/bulk-import#file-schema) and export the transformed data to JSON format.
-
-## Import Gigya Users 
-
-Next, you can import your Gigya users into Auth0 with the User Import/Export Extension or the Management API.
-
-### Import Users with the User Import / Export Extension
-
-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.
-
-::: note
-For more information on the User Import / Export Extension, check out the [User Import/Export Extension](/extensions/user-import-export) page.
-:::
-
-### Import Users with the Management API
-
-As an alternative option to using the User Import/Export extension, you can leverage the Auth0 Management API to [create a job](/api/management/v2#!/Jobs/post_users_imports) to import your users to Auth0. For further instructions on this process, see the [Bulk User Imports with the Management API](/users/migration/bulk-import) page.
diff --git a/articles/users/migrations/index.md b/articles/users/migrations/index.md
deleted file mode 100644
index b3f2d9931c..0000000000
--- a/articles/users/migrations/index.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-classes: topic-page
-title: User Migration
-description: Overview of importing users from external applications into Auth0.
----
-
-
-
        
-  
        
-  
        User Migration
        
-  
        
-    Auth0 supports importing users from external applications using custom database connections, the Auth0 Management API, or the User Import / Export Extension.
-  
        
-
        
-
-
diff --git a/articles/users/migrations/okta.md b/articles/users/migrations/okta.md
deleted file mode 100644
index 0d2fd82ae1..0000000000
--- a/articles/users/migrations/okta.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Migrate Users from Okta to Auth0
-description: Auth0 supports automatic migration of users to Auth0 from external applications such as Okta. This feature adds your users to the Auth0 database as each person logs in and avoids asking your users to reset their passwords due to migration.
-crews: crew-2
-toc: true
----
-
-# Migrate Users from Okta to Auth0
-
-Auth0 supports [automatic migration](/users/migrations/automatic) of users from a [custom database connection](/connections/database/custom-db) to Auth0. This feature allows you to configure a custom database connection which will migrate users from an external application, such as Okta, to Auth0. It allows for a smooth migration of users over time, without requiring users to reset their password as a result of the migration.
-
-For a more detailed overview, also refer to [The Migration Process](/connections/database/migrating#the-migration-process).
-
-The rest of this document will walk you through the process of configuring a custom database connection which imports users from Okta. It assumes that you have an Okta account.
-
-## Configuring the Custom Database Connection
-
-### 1. Create a Custom Database
-
-You can create a new database connection in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard.
-
-![Create a new DB Connection](/media/articles/connections/database/okta/create-database-connection.png)
-
-On the **Custom Database** page, enable the **Use my own database** option:
-
-![DB Login Page in Dashboard](/media/articles/connections/database/okta/own-database.png)
-
-### 2. Turn on Automatic Migration
-
-On the **Settings** page for your database connection, enable the **Import Users to Auth0** option:
-
-![Dashboard Import Users Option](/media/articles/connections/database/okta/import-users.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 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.
-
-### 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 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
-    });
-  });
-}
-```
-
-You can click the **Try** button above the script to test and see whether the script works.
-
-## Testing the Custom Database Connection
-
-At this point you can 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)
-
-If you navigate to the [Users](${manage_url}/#/users) section in the Auth0 Dashboard, you will see the newly imported user listed:
-
-![Imported User](/media/articles/connections/database/okta/user-imported.png)
diff --git a/articles/users/migrations/stormpath.md b/articles/users/migrations/stormpath.md
deleted file mode 100644
index f0c7576710..0000000000
--- a/articles/users/migrations/stormpath.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-title: Migrate Users from Stormpath to Auth0
-description: Auth0 supports automatic migration of users to Auth0 from external applications such as Stormpath. This feature adds your users to the Auth0 database as each person logs in and avoids asking your users to reset their passwords due to migration.
-crews: crew-2
-toc: true
----
-
-# Migrate Users from Stormpath to Auth0
-
-Auth0 supports [automatic migration](/users/migrations/automatic) of users from a [custom database connection](/connections/database/custom-db) to Auth0. This feature allows you to configure a custom database connection which will migrate users from an external application, such as Stormpath, to Auth0. It allows for a smooth migration of users over time, without requiring users to reset their password as a result of the migration.
-
-For a more detailed overview, also refer to [The Migration Process](/users/migrations/automatic#the-migration-process).
-
-The rest of this document will walk you through the process of configuring a custom database connection which imports users from Stormpath. It assumes that you have a Stormpath account.
-
-::: note
-Check out the [Migrating Stormpath Users to Auth0 Demo](https://github.com/auth0-blog/migrate-stormpath-users-to-auth0) on GitHub
-:::
-
-## Configuring the Custom Database Connection
-
-### 1. Create a Custom Database
-
-You can create a new database connection in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard.
-
-![Create a new Database Connection](/media/articles/users/migrations/create-database-connection.png)
-
-On the **Custom Database** page, enable the **Use my own database** option:
-
-![Database Login Page in Dashboard](/media/articles/users/migrations/own-database.png)
-
-### 2. Turn on Automatic Migration
-
-On the **Settings** page for your database connection, enable the **Import Users to Auth0** option:
-
-![Dashboard Import Users Option](/media/articles/users/migrations/import-users.png)
-
-### 3. Enable Applications
-
-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)
-
-### 4. 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
-      });
-    });
-  });
-}
-```
-
-You can click the **Try** button above the script to test and see whether the script works.
-
-### 5. 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
-    });
-  });
-}
-```
-
-You can click the **Try** button above the script to test and see whether the script works.
-
-## Testing the Custom Database Connection
-
-At this point you can 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)
-
-If you 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)
diff --git a/articles/users/normalized/auth0/identify-users.md b/articles/users/normalized/auth0/identify-users.md
new file mode 100644
index 0000000000..4fab34f775
--- /dev/null
+++ b/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/articles/users/normalized/auth0/index.md b/articles/users/normalized/auth0/index.md
new file mode 100644
index 0000000000..5593c4d5da
--- /dev/null
+++ b/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/articles/users/normalized/auth0/normalized-user-profile-schema.md b/articles/users/normalized/auth0/normalized-user-profile-schema.md
new file mode 100644
index 0000000000..63c43e0532
--- /dev/null
+++ b/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/articles/users/normalized/auth0/sample-user-profiles.md b/articles/users/normalized/auth0/sample-user-profiles.md
new file mode 100644
index 0000000000..1a12d81ad6
--- /dev/null
+++ b/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/articles/users/normalized/auth0/store-user-data.md b/articles/users/normalized/auth0/store-user-data.md
new file mode 100644
index 0000000000..d6bc8a02b9
--- /dev/null
+++ b/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/articles/users/normalized/auth0/update-root-attributes.md b/articles/users/normalized/auth0/update-root-attributes.md
new file mode 100644
index 0000000000..222a954535
--- /dev/null
+++ b/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/articles/users/normalized/index.yml b/articles/users/normalized/index.yml
new file mode 100644
index 0000000000..b833aeb219
--- /dev/null
+++ b/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/articles/users/normalized/oidc/index.md b/articles/users/normalized/oidc/index.md
new file mode 100644
index 0000000000..d63f0591db
--- /dev/null
+++ b/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/articles/users/redirecting-users.md b/articles/users/redirecting-users.md
deleted file mode 100644
index 4c4295fe2f..0000000000
--- a/articles/users/redirecting-users.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Redirect Users After Login
-description: How to redirect users to URLs that have not been whitelisted
----
-# Redirect Users After Login
-
-To make your login process as easy-to-use and seamless as possible, you'll need to keep track of where you want to route users inside your application once Auth0 redirects users back to your application after authentication.
-
-During a user's authentication, the `redirect_uri` request parameter is used as a callback URL. This is where your application will receive and process the response from Auth0, and where the users will be redirected, once the authentication is complete.
-
-Because callback URLs can be manipulated by unauthorized parties, Auth0 recognizes only whitelisted URLs set in the **Allowed Callback URLs** field of a [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings) as valid.
-
-However the callback URL is not necessarily the same URL to which you want users redirected after authentication.
-
-## Redirect users to a non-callback URL
-
-To redirect authenticated users to a URL that is *not* the callback URL, you can store the desired URL:
-
-- In web storage (for single page apps, running on the browser), or
-- In a a cookie (for regular web apps, running on the server)
-
-You can then create the necessary logic in your application to retrieve the stored URL and redirect your users where you want.
diff --git a/articles/users/references/bulk-import-database-schema-examples.md b/articles/users/references/bulk-import-database-schema-examples.md
new file mode 100644
index 0000000000..241bef14dc
--- /dev/null
+++ b/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/articles/users/references/link-accounts-client-side-scenario.md b/articles/users/references/link-accounts-client-side-scenario.md
new file mode 100644
index 0000000000..82b00b0e95
--- /dev/null
+++ b/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/articles/users/references/link-accounts-server-side-scenario.md b/articles/users/references/link-accounts-server-side-scenario.md
new file mode 100644
index 0000000000..5650982f28
--- /dev/null
+++ b/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/articles/users/references/user-data-storage-scenario.md b/articles/users/references/user-data-storage-scenario.md
new file mode 100644
index 0000000000..ee6a0624e3
--- /dev/null
+++ b/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/articles/users/references/user-migration-scenarios.md b/articles/users/references/user-migration-scenarios.md
new file mode 100644
index 0000000000..fa834ca472
--- /dev/null
+++ b/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/articles/users/references/user-profile-structure.md b/articles/users/references/user-profile-structure.md
new file mode 100644
index 0000000000..3dddca16be
--- /dev/null
+++ b/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/articles/users/search-best-practices.md b/articles/users/search-best-practices.md
deleted file mode 100644
index a588b74042..0000000000
--- a/articles/users/search-best-practices.md
+++ /dev/null
@@ -1,454 +0,0 @@
----
-name: User Search Best Practices
-description: Best practices when searching for users in Auth0
-url: /users/search/best-practices
-toc: true
----
-
-# User Search Best Practices
-
-Auth0 provides multiple endpoints you can use to retrieve users. Each one offers slightly different functionality, and in this document, we'll cover the best practices for using each of the endpoints.
-
-## User search options
-
-Currently, Auth0 offers three different ways by which you can search for users:
-
-* [Users](#users)
-* [Users by ID](#users-by-id)
-* [Users by Email](#users-by-email)
-* [User Export](#user-export)
-
-::: note
-The following sections contain examples on how to call the various user search endpoints. To do so, you'll need to obtain a valid [Access Token](/api/management/v2/tokens) and provide it in the header of your call (simply replace the `YOUR_MGMT_API_ACCESS_TOKEN` placeholder value).
-:::
-
-### Definitions
-
-In this document, we use the terms **eventually consistent** and **immediately consistent**.
-
-* **Eventually consistent**: When you request information about a user (or a group of users), the response might not reflect the results of a recently-complete write operation. However, if you repeat your request after a short period of time, the response will return up-to-date data.
-
-* **Immediately consistent**: When you request information about a user (or a group of users), the response will reflect the results of all successful write operations, including those that occured shortly prior to your request.
-
-## General principles
-
-When running user searches:
-
-* Use an immediately consistent endpoint during authentication processes
-* Use exact match searches (with the `raw` subfield) whenever possible
-* Use a well-known schema for metadata:
-  * Use consistent data types for properties
-  * Avoid dynamic property names
-  * Avoid large schema sizes and deep structures
-  * Avoid storing data you do not need for authentication and authorization purposes
-
-To optimize the performance of your user searches, we don't recommend:
-
-* Existence queries (for example, "give me all users with a property regardless of its value")
-* Full text search or partial searches
-* Polling the search APIs
-* Using large metadata field (try to keep metadata fields to 2 KB or less)
-
-## Users
-
-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
-
-*Required Scopes*: `read:users`
-
-```har
-{
-    "method": "GET",
-    "url": "https://${account.namespace}/api/v2/users",
-    "headers": [{
-        "name": "Authorization",
-        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
-    }]
-}
-```
-
-**Sample Response**
-
-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": ""
-  }
-]
-```
-
-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.
-
-We do **not** recommend that you use this endpoint for:
-
-* Operations that require immediate consistency - please use the [Users by Email endpoint](#users-by-email) or the [Users by ID endpoint](#users-by-id) for such actions
-* User exports - please use the [User Export endpoint](#user-export) for such actions
-* Operations that require user search as part of authentication processes - please use the [Users by Email endpoint](#users-by-email) or the [Users by ID endpoint](#users-by-id) for such actions
-* Searching for Users for [Account Linking](/link-accounts) by Email - please use the [Users by Email endpoint](#users-by-email) for such actions
-
-## Users by ID
-
-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.
-
-*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 Response**
-
-```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": ""
-}
-```
-
-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.
-
-## Users by email
-
-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.
-
-*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 Response**
-
-```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": ""
-  }
-]
-```
-
-The Users by Email 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.
-
-## User export
-
-The [`POST /api/v2/jobs/users-exports`](/api/management/v2#!/Jobs/post_users_exports) endpoint allows you to create a job that exports all users associated with a [connection](/identityproviders).
-
-When you create your job, you'll need to provide:
-
-* The ID for the connection whose users you want exported
-* The format of the export file (CSV or JSON)
-* The maximum number of user records to be exported
-* The user-related fields (such as user ID or name) that you want included in the export
-
-*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 Response**
-
-```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"
-}
-```
-
-### Export metadata
-
-If you export user data in CSV and want to include metadata information, you must specify each metadata field that you want exported. 
-
-For example, for metadata structured like this:
-
-```json
-{
-  "consent": {
-      "given": true,
-      "date": "01/23/2018",
-      "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": ""
-}
-```
-
-If you export the data in JSON, you need only provide the root property; you do not need to name each individual inner property since they will be included automatically.
-
-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": ""
-}
-```
-
-### Get the results
-
-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). 
-
-You'll need to 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 Response**
-
-```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"
-}
-```
-
-You can access your export using the URL provided as the value for the **location** parameter. When you navigate to the URL, you'll automatically begin downloading the file. 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`.
-
-::: note
-The download link is valid for 60 seconds. If this time period has expired, you'll need to initiate a new job.
-:::
-
-![Exported user data](/media/articles/users/data.png)
-
-## Summary
-
-When retrieving users in Auth0, there are three different API endpoints you can use. Here's a summary of when you should use each endpoint:
-
-| Requirement | Endpoint to Use |
-| - | - |
-| Back of the office processes, such as changing a user's display name | [Users](#users) |
-| Searches involving user attributes | [Users](#users) |
-| Searches returning multiple users | [Users](#users) |
-| Operations requiring immediate consistency | [Users by ID](#users-by-id) or [Users by Email](#users-by-email) |
-| Actions requiring user search as part of authentication processes | [Users by ID](#users-by-id) or [Users by Email](#users-by-email) |
-| Searching for users for account linking by email | [Users by Email](#users-by-email) |
-| User exports | [User Export](#user-export) |
diff --git a/articles/users/search/v2/index.md b/articles/users/search/v2/index.md
index 8bfc0c210c..df2b8516b9 100644
--- a/articles/users/search/v2/index.md
+++ b/articles/users/search/v2/index.md
@@ -2,17 +2,26 @@
 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
-This document covers a previous version of user search. We recommend you use [user search v3](/users/search/v3).
+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 will demonstrate how you can search for users and give some example queries. It is however suggested that you also reference the [Query String Syntax document](/api/management/v2/query-string-syntax) for more examples of the query string syntax.
+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).
@@ -22,7 +31,7 @@ The user search endpoint allows you to return a maximum of **10,000** users. For
 
 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 [The Auth0 Management APIv2 Token](/api/management/v2/tokens) for more information.
+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
 
@@ -44,9 +53,9 @@ For general information on making Postman request, please refer to the [Postman
 
 ## 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. 
+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).
+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.
@@ -126,9 +135,7 @@ Below is an example request for searching all users whose email is exactly "john
 }
 ```
 
-## Next steps
+## Keep reading
 
-::: next-steps
-* [Learn how you can use the query string syntax to build custom queries](/users/search/v2/query-syntax)
-* [Learn about the Auth0 best practices for user search](/users/search/best-practices)
-:::
\ No newline at end of file
+* [Query Syntax](/users/search/v2/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
diff --git a/articles/users/search/v2/query-syntax.md b/articles/users/search/v2/query-syntax.md
index c38e557208..69e99dbdf0 100644
--- a/articles/users/search/v2/query-syntax.md
+++ b/articles/users/search/v2/query-syntax.md
@@ -2,6 +2,15 @@
 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
@@ -20,7 +29,7 @@ The query string is parsed into a series of *terms* and *operators*. A term can
 
 You can search for users using the following fields:
 
-* All the [normalized user profile](/user-profile/normalized) fields
+* All the [normalized user profile](/users/normalized/auth0/normalized-user-profile-schema) fields
 
 * __Only__ the profile information under the `user_metadata` object:
   - `name`
@@ -29,12 +38,10 @@ You can search for users using the following fields:
   - `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
-For more information on user related metadata refer to [User Metadata](/metadata).
+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
 
diff --git a/articles/users/search/v3/_valid-access-token.md b/articles/users/search/v3/_valid-access-token.md
new file mode 100644
index 0000000000..5093842c08
--- /dev/null
+++ b/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/articles/users/search/v3/get-users-by-email-endpoint.md b/articles/users/search/v3/get-users-by-email-endpoint.md
new file mode 100644
index 0000000000..ca3b478de6
--- /dev/null
+++ b/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/articles/users/search/v3/get-users-by-id-endpoint.md b/articles/users/search/v3/get-users-by-id-endpoint.md
new file mode 100644
index 0000000000..e5df676ad3
--- /dev/null
+++ b/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/articles/users/search/v3/get-users-endpoint.md b/articles/users/search/v3/get-users-endpoint.md
new file mode 100644
index 0000000000..034a45a562
--- /dev/null
+++ b/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/articles/users/search/v3/index.md b/articles/users/search/v3/index.md
index c17c93e4eb..fe39072f3a 100644
--- a/articles/users/search/v3/index.md
+++ b/articles/users/search/v3/index.md
@@ -1,185 +1,56 @@
 ---
 title: User Search
-description: Learn about Auth0's user search query string syntax and how to search for users then sort the results.
-toc: true
+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
 
-Looking for someone? You can search for users matching a custom query with the [list or search users](/api/management/v2#!/Users/get_users) endpoint.
-
-In this article you'll learn how to search for users and sort the results.
-
-## Before you start
-
-* Review the [User Search Query Syntax](/users/search/query-syntax).
-* If you are using [user search engine v2](/api/management/v2/user-search), check out the [section on migrating from v2 to v3](#migrate-from-search-engine-v2-to-v3) below.
-* You'll need a token to make requests to the Management API. Check out [the Auth0 Management APIv2 token](/api/management/v2/tokens) for more information.
-* To perform user search requests the `read:users` [scope](/scopes/) is required.
-* Auth0 limits the number of users you can retrieve (1000). If you exceed this threshold, please redefine your search, use the [export job](/api/management/v2#!/Jobs/post_users_exports) or [User Import / Export](/extensions/user-import-export) extension.
-
-## 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).
-
-### Example 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}`
-
-## Sort 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.
-
-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"
-        }
-    ]
-}
-```
-
-For more information on `sort` and other parameters, see the [Management API Explorer documentation](/api/management/v2#!/users/get_users).
-
-## Page results
+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
-Auth0 limits the number of users you can retrieve (1000). If you exceed this threshold, please redefine your search, use the [export job](/api/management/v2#!/Jobs/post_users_exports) or [User Import / Export](/extensions/user-import-export) extension.
+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. 
 :::
 
-To page the user search results, use the `page`, `per_page`, and `include_totals` parameters when making your request:
+When searching for users in Auth0, you can use multiple endpoints to search for ID, email, or other criteria:
 
-Parameter | Description
-----------|------------
-`page` | The page number, zero based.
-`per_page` | The amount of users per page.
-`include_totals` | Set to `true` to include a query summary as part of the result.
+| 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) |
 
-```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"
-        }
-    ]
-}
-```
+## Search Result Terminology
 
-For more information on the `page`, `per_page` and other parameters, see the [Management API Explorer documentation](/api/management/v2#!/users/get_users).
+We use the following terms to describe the user search results:
 
-## Migrate from search engine v2 to v3
+* **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.
 
-The user search engine v2 will be deprecated soon, so we recommend migrating user search functionality to search engine v3 (`search_engine=v3`). Before you start migrating, there's a few things you should know:
+* **Immediately consistent**: Search results will reflect the results of all successful write operations, including those that occurred shortly prior to your request.
 
-* 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. See [page results](#page-results).
-* You can search for strings in `app_metadata`/`user_metadata` arrays, but not in nested `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).
+## Search Best Practices
 
-### Queries to migrate
+For info on best practices, see [User Search Best Practices](/best-practices/search-best-practices).
 
-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*`
+## Keep reading
 
-## Next steps
+* [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)
 
-::: next-steps
-* [Learn how you can use the query string syntax to build custom queries](/users/search/v3/query-syntax)
-* [Learn about the Auth0 best practices for user search](/users/search/best-practices)
-:::
diff --git a/articles/users/search/v3/migrate-search-v2-v3.md b/articles/users/search/v3/migrate-search-v2-v3.md
new file mode 100644
index 0000000000..7496f010a4
--- /dev/null
+++ b/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/articles/users/search/v3/query-syntax.md b/articles/users/search/v3/query-syntax.md
index a2d125253d..ce0d124d4b 100644
--- a/articles/users/search/v3/query-syntax.md
+++ b/articles/users/search/v3/query-syntax.md
@@ -1,7 +1,16 @@
 ---
 title: User Search Query Syntax
-description: Learn about Auth0's user search query string 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
@@ -12,23 +21,36 @@ 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](/metadata) fields.
+* 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 the following fields:
-
-* All the [normalized user profile](/user-profile/normalized/auth0) fields.
-* User metadata fields may be used with:
-    * Booleans
-    * Numeric (integer or double)
-    * Text
-    * Arrays. You can search for strings and numerics in metadata arrays on the root object, but not in nested fields.
-
-Range and wildcard searches are not available on [user metadata](/metadata) 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
 
@@ -60,11 +82,19 @@ For example, to find users with the name `jane smith`, use `q=name:"jane smith"`
 
 ## Wildcards
 
-Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters: `name:john*`.
+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. 
 
-The question mark character (`?`), is currently not supported.
+* `name:j*` returns all users with `j` at the beginning of their names.
 
-For example, to find all users whose names start with `john`, use `q=name:john*`:
+* `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
 {
@@ -90,11 +120,17 @@ For example, to find all users whose names start with `john`, use `q=name:john*`
 
 ## Ranges
 
-You can use ranges in your user search queries. For inclusive ranges use square brackets: `[min TO max]`, and for exclusive ranges use curly brackets: `{min TO max}`.
+You can use ranges in your user search queries. 
+
+* For inclusive ranges use square brackets: `[min TO max]`.
 
-Curly and square brackets can be combined in the same range expression: `logins_count:[100 TO 200}`. You can also use wildcards within ranges.
+* For exclusive ranges use curly brackets: `{min TO max}`.
 
-For example, to find all users with more than 100 logins, use `q=logins_count:{100 TO *]`.
+* 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
 {
@@ -117,3 +153,14 @@ For example, to find all users with more than 100 logins, use `q=logins_count:{1
     ]
 }
 ```
+
+## 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/articles/users/search/v3/sort-search-results.md b/articles/users/search/v3/sort-search-results.md
new file mode 100644
index 0000000000..b62fd85aeb
--- /dev/null
+++ b/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/articles/users/search/v3/view-search-results-by-page.md b/articles/users/search/v3/view-search-results-by-page.md
new file mode 100644
index 0000000000..a097227034
--- /dev/null
+++ b/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/articles/videos/get-started/01-architecture-your-tenant.md b/articles/videos/get-started/01-architecture-your-tenant.md
new file mode 100644
index 0000000000..a7b9bbcbab
--- /dev/null
+++ b/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/articles/videos/get-started/02-provision-user-stores.md b/articles/videos/get-started/02-provision-user-stores.md
new file mode 100644
index 0000000000..71769b3b55
--- /dev/null
+++ b/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/articles/videos/get-started/03-provision-import-users.md b/articles/videos/get-started/03-provision-import-users.md
new file mode 100644
index 0000000000..f81cf4b4a5
--- /dev/null
+++ b/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/articles/videos/get-started/04_01-authenticate-how-it-works.md b/articles/videos/get-started/04_01-authenticate-how-it-works.md
new file mode 100644
index 0000000000..8aa2ee856c
--- /dev/null
+++ b/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/articles/videos/get-started/04_02-authenticate-spa-example.md b/articles/videos/get-started/04_02-authenticate-spa-example.md
new file mode 100644
index 0000000000..8e588388c4
--- /dev/null
+++ b/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/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md b/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md
new file mode 100644
index 0000000000..9550161f31
--- /dev/null
+++ b/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/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md b/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md
new file mode 100644
index 0000000000..bc933daba7
--- /dev/null
+++ b/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/articles/videos/get-started/06-user-profiles.md b/articles/videos/get-started/06-user-profiles.md
new file mode 100644
index 0000000000..5556638b13
--- /dev/null
+++ b/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/articles/videos/get-started/07_01-brand-how-it-works.md b/articles/videos/get-started/07_01-brand-how-it-works.md
new file mode 100644
index 0000000000..64c99d14ab
--- /dev/null
+++ b/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/articles/videos/get-started/07_02-brand-signup-login-pages.md b/articles/videos/get-started/07_02-brand-signup-login-pages.md
new file mode 100644
index 0000000000..ed2a4cd9c8
--- /dev/null
+++ b/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/articles/videos/get-started/08-brand-emails-error-pages.md b/articles/videos/get-started/08-brand-emails-error-pages.md
new file mode 100644
index 0000000000..81f7840e35
--- /dev/null
+++ b/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/articles/videos/get-started/10-logout.md b/articles/videos/get-started/10-logout.md
new file mode 100644
index 0000000000..ea9301a1de
--- /dev/null
+++ b/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/articles/videos/get-started/index.md b/articles/videos/get-started/index.md
new file mode 100644
index 0000000000..ae0f8f4e28
--- /dev/null
+++ b/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/articles/videos/index.md b/articles/videos/index.md
new file mode 100644
index 0000000000..7d5ef5c972
--- /dev/null
+++ b/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/articles/videos/learn-identity/01-introduction-to-identity.md b/articles/videos/learn-identity/01-introduction-to-identity.md
new file mode 100644
index 0000000000..4718aee76b
--- /dev/null
+++ b/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/articles/videos/learn-identity/02-oidc-and-oauth.md b/articles/videos/learn-identity/02-oidc-and-oauth.md
new file mode 100644
index 0000000000..9684482b63
--- /dev/null
+++ b/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/articles/videos/learn-identity/03-web-sign-in.md b/articles/videos/learn-identity/03-web-sign-in.md
new file mode 100644
index 0000000000..2a4385a506
--- /dev/null
+++ b/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/articles/videos/learn-identity/04-calling-an-api.md b/articles/videos/learn-identity/04-calling-an-api.md
new file mode 100644
index 0000000000..2b4de9ae1b
--- /dev/null
+++ b/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/articles/videos/learn-identity/05-desktop-and-mobile-apps.md b/articles/videos/learn-identity/05-desktop-and-mobile-apps.md
new file mode 100644
index 0000000000..7994284e33
--- /dev/null
+++ b/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/articles/videos/learn-identity/06-single-page-apps.md b/articles/videos/learn-identity/06-single-page-apps.md
new file mode 100644
index 0000000000..b873dee324
--- /dev/null
+++ b/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/articles/videos/learn-identity/index.md b/articles/videos/learn-identity/index.md
new file mode 100644
index 0000000000..a8a9a172d0
--- /dev/null
+++ b/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/codemods/clean-redirects-config.js b/codemods/clean-redirects-config.js
new file mode 100644
index 0000000000..92a29723fb
--- /dev/null
+++ b/codemods/clean-redirects-config.js
@@ -0,0 +1,49 @@
+const prettyPrint = require("./common/pretty-print");
+
+const OBJECT_COMMENT_REGEX = /\} (\/\*[^\/\*]+\*\/)\,/g;
+
+/**
+ * clean up redirects that point to some other redirect and merge the 'from' field value
+ * in order to avoid having multiple redirect requests and reduce them to a single one
+ */
+module.exports = function(fileInfo, api) {
+  const j = api.jscodeshift;
+  const root = j(fileInfo.source);
+  const [redirects] = root.findVariableDeclarators('redirects').nodes();
+  const configNodes = redirects.init.elements;
+  root.find(j.ObjectExpression).forEach((toConfigNodePath) => {
+    const toConfig = toConfigNodePath.value;
+    const toNode = toConfig.properties.find((props) => props.key.name === 'to');
+    // Find any 'to' field that is pointing to a 'from' field in some other config
+    const found = configNodes.find((fromConfig) => {
+      const fromNode = fromConfig.properties.find((props) => props.key.name === 'from');
+      if(fromNode.value.type === 'ArrayExpression') {
+        return fromNode.value.elements.some((fromElement) => fromElement.value === toNode.value.value);
+      }
+      // if not ArrayExpression it should be Literal
+      return fromNode.value.value === toNode.value.value;
+    });
+    // If found merge the 'from' fields in the found item and delete the current redirection config
+    if(found) {
+      const allFroms = [];
+      const foundFrom = found.properties.find((props) => props.key.name === 'from');
+      const currentFrom = toConfig.properties.find((props) => props.key.name === 'from');
+      if(foundFrom.value.type === 'ArrayExpression') {
+        foundFrom.value.elements.forEach(({value}) => allFroms.push(value));
+      } else {
+        allFroms.push(foundFrom.value.value);
+      }
+      if(currentFrom.value.type === 'ArrayExpression') {
+        currentFrom.value.elements.forEach(({value}) => allFroms.push(value));
+      } else {
+        allFroms.push(currentFrom.value.value);
+      }
+      const uniqueFroms = [...new Set(allFroms)];
+      foundFrom.value = j.arrayExpression(uniqueFroms.map(val => j.literal(val)));
+      j(toConfigNodePath).remove();
+    }
+  });
+  const transformedSource = prettyPrint(root);
+  // keep position and spaces for block comments within the redirect object
+  return transformedSource.replace(OBJECT_COMMENT_REGEX, (match, group) => `},\n\n  ${group}`);
+}
\ No newline at end of file
diff --git a/codemods/common/pretty-print.js b/codemods/common/pretty-print.js
new file mode 100644
index 0000000000..f05f9107be
--- /dev/null
+++ b/codemods/common/pretty-print.js
@@ -0,0 +1,19 @@
+
+   
+let prettier;
+try {
+  prettier = require("prettier"); // eslint-disable-line
+} catch (err) {
+  prettier = null;
+}
+
+function prettyPrint(root) {
+  const transformedSource = root.toSource({
+    quote: "auto",
+    tabWidth: 2,
+  });
+
+  return prettier ? prettier.format(transformedSource, prettier.resolveConfig.sync(__filename)) : transformedSource;
+}
+
+module.exports = prettyPrint;
\ No newline at end of file
diff --git a/config/app-types.yml b/config/app-types.yml
index abcc294c5f..61da6a797e 100644
--- a/config/app-types.yml
+++ b/config/app-types.yml
@@ -5,34 +5,34 @@
 ## ------------------------------------------------------------
 
 appTypes:
-  - title: Mobile / Native App
+  - title: Native/Mobile App
     name: native
-    description: "Native and hybrid mobile, desktop"
-    example: "eg: iOS, Android, Chrome"
+    description: "Mobile or Desktop app that runs natively on a device"
+    example: "e.g., iOS, Android"
     question: "Select a native SDK"
     budicon: 243
     slug: native-platforms
 
-  - title: Single Page App
+  - title: Single-Page App
     name: spa
-    description: "A JavaScript front-end app that uses an API"
-    example: "eg: AngularJS, React"
+    description: "JavaScript web app that runs in the browser"
+    example: "e.g., AngularJS + Node.js, React"
     question: "What technology are you using for your web app?"
     budicon: 349
     slug: application-platforms
 
-  - title: Web App
+  - title: Regular Web App
     name: webapp
-    description: "Traditional server rendered web app"
-    example: "eg: Express.js, ASP.NET"
+    description: "Traditional web app that runs on the server"
+    example: "e.g., Express.js, ASP.NET"
     question: "What technology are you using for your web app?"
     budicon: 349
     slug: server-platforms
     
-  - title: Backend / API
+  - title: Backend/API
     name: backend
-    description: "An API or service that does JWT validation"
-    example: "eg: Hapi.js API, ASP.NET API"
+    description: "An API or service protected by Auth0"
+    example: "e.g., Express.js API, ASP.NET API"
     question: "Select an API or backend platform"
     budicon: 649
-    slug: server-apis
\ No newline at end of file
+    slug: server-apis
diff --git a/config/cards.yml b/config/cards.yml
index 9aaca066fe..2815aab1aa 100644
--- a/config/cards.yml
+++ b/config/cards.yml
@@ -5,160 +5,113 @@
 ## ------------------------------------------------------------
 
 - id: "getting-started"
-  title: "Getting Started"
-  icon: "icon-budicon-499"
-  color: "orange"
-  description: "Learn the basics of using Auth0."
-  url: "/getting-started"
+  title: "Get Started"
+  icon: "IdenticonGettingStarted"
+  description: "Learn the basics"
+  url: "/get-started"
   articles:
 
-    - title: Auth0 Overview
-      url: /getting-started/overview
-
-    - title: The Basics
-      url: /getting-started/the-basics
-
-    - title: Dashboard Overview
-      url: /getting-started/dashboard-overview
-
-- id: "ui-components"
-  title: "UI Components"
-  icon: "icon-budicon-342"
-  color: "blue-light"
-  description: "Integrate Auth0 login and signup UI into your app."
-  url: "/libraries/when-to-use-lock"
-  articles:
-
-    - title: "Lock for Web"
-      url: "/libraries/lock/v11"
-
-    - title: "Lock for iOS"
-      url: "/libraries/lock-ios/v2"
-
-    - title: "Lock for Android"
-      url: "/libraries/lock-android/v2"
-
-- id: "authentication-flows"
-  title: "Authentication Flows"
-  icon: "icon-budicon-295"
-  color: "oil"
-  description: "Learn about our new authentication flows and how you can adopt them."
-  url: "/api-auth/intro"
-  articles:
-
-    - title: "Introduction"
-      url: "/api-auth/intro"
-
-    - title: "Adoption Guide"
-      url: "/api-auth/tutorials/adoption"
-
-    - title: "API Authorization"
-      url: "/api-auth"
-
-
-- id: "guides"
-  title: "Guides"
-  icon: "icon-budicon-399"
-  color: "green"
-  description: "Guidance and tutorials about common solutions."
-  url: "/topics/guides"
+    - title: "Auth0 Overview"
+      url: "/get-started/auth0-overview"
+      
+    - title: "Tenant Settings"
+      url: "/get-started/tenant-settings"
+   
+    - title: "Authentication and Authorization Flows"
+      url: "/get-started/authentication-and-authorization-flow"
+
+- id: "authenticate"
+  title: "Authenticate"
+  icon: "IdenticonAuthenticationA"
+  description: "Integrate Auth0 login"
+  url: "/authenticate"
   articles:
+  
+    - title: "Universal Login"
+      url: "/authenticate/login/auth0-universal-login"
 
-    - title: "Architecture Scenarios"
-      url: /architecture-scenarios
+    - title: "Identity Providers"
+      url: "/authenticate/identity-providers"
       
-    - title: "Tokens used by Auth0"
-      url: "/tokens"
-
-    - title: "Migration Guides"
-      url: "/migrations"
-
-
-- id: "apis"
-  title: "APIs"
-  icon: "icon-budicon-546"
-  color: "blue"
-  description: "Working directly with Auth0 APIs"
-  url: "/api/info"
+    - title: "User Store"
+      url: "/authenticate/database-connections"
+
+- id: "manage-users"
+  title: "Manage Users"
+  icon: "IdenticonUserManagement"
+  description: "Users, profiles, and sessions"
+  url: "/manage-users"
   articles:
 
-    - title: "API Overview"
-      url: "/api/info"
+    - title: "User Accounts"
+      url: "/manage-users/user-accounts"
 
-    - title: "Authentication API"
-      url: "/api/authentication"
-      forceFullReload: true
+    - title: "Access Control"
+      url: "/manage-users/access-control"
 
-    - title: "Management API"
-      url: "/api/management/v2"
-      forceFullReload: true
+    - title: "Organizations"
+      url: "/manage-users/organizations"
 
-- id: "appliance"
-  title: "PSaaS Appliance"
-  icon: "icon-budicon-359"
-  color: "pink"
-  description: "Deploying and managing a private instance of Auth0."
-  url: "/appliance"
+- id: "customize"
+  title: "Customize"
+  icon: "IdenticonCustomize"
+  description: "Branding and extensibility"
+  url: "/customize"
   articles:
 
-    - title: "PSaaS Appliance Planning"
-      url: "/appliance/appliance-overview"
+    - title: "Universal Login Pages"
+      url: "/customize/login-pages"
 
-    - title: Administrator's Manual
-      url: /appliance/admin
+    - title: "Actions"
+      url: "/customize/actions"
 
-    - title: Onboarding Process
-      url: /onboarding/appliance-sprint
+    - title: "Extensions"
+      url: "/customize/extensions"
 
-- id: "extensibility"
-  title: "Extensibility"
-  icon: "icon-budicon-173"
-  color: "red"
-  description: "Adding to and customizing Auth0's standard feature set."
-  url: "/topics/extensibility"
+- id: "secure"
+  title: "Secure"
+  icon: "IdenticonSecurity"
+  description: "Compliance, privacy, and threats"
+  url: "/secure"
   articles:
 
-    - title: "Rules"
-      url: "/rules/current"
-
-    - title: "Extensions"
-      url: "/extensions"
-
-    - title: "Webtasks"
-      url: "https://webtask.io/docs/101"
-      external: true
+    - title: "Attack Protection"
+      url: "/secure/attack-protection"
+      
+    - title: "Multi-factor Authentication"
+      url: "/secure/multi-factor-authentication"
 
+    - title: "Data Privacy"
+      url: "/secure/data-privacy-and-compliance"
 
-- id: "identity-providers"
-  title: "Identity Providers"
-  icon: "icon-budicon-297"
-  color: "yellow"
-  description: "Integrating Auth0 with identity providers."
-  url: "/identityproviders"
+- id: "deploy-and-monitor"
+  title: "Deploy and Monitor"
+  icon: "IdenticonMonitoring"
+  description: "Deployment models and logs"
+  url: "/deploy-monitor"
   articles:
 
-    - title: "Database Connections"
-      url: "/connections/database"
-
-    - title: "Social Connections"
-      url: "/identityproviders#social"
-
-    - title: "Passwordless"
-      url: "/connections/passwordless"
+    - title: "Deployment Options"
+      url: "/deploy-monitor/deployment-options"
+      
+    - title: "Check Auth0 Status"
+      url: "/deploy-monitor/monitor/check-auth0-status"
 
-- id: "enterprise-identity"
-  title: "Enterprise Identity"
-  icon: "icon-budicon-606"
-  color: "oil"
-  description: "Integrating and integrating enterprise identity solutions."
-  url: "/identityproviders#enterprise"
+    - title: "Logs"
+      url: "/deploy-monitor/logs" 
+      
+- id: "troubleshoot"
+  title: "Troubleshoot"
+  icon: "IdenticonTroubleshoot"
+  description: "Get help and troubleshoot"
+  url: "/troubleshoot"
   articles:
 
-    - title: "Active Directory"
-      url: "/connections/enterprise/active-directory"
-
-    - title: "Active Directory Connector"
-      url: "/connections/passwordless"
+    - title: "Customer Support"
+      url: "/troubleshoot/customer-support"
 
-    - title: "SAML"
-      url: "/saml-configuration"
+    - title: "Troubleshoot Basic Issues"
+      url: "/troubleshoot/basic-issues" 
+      
+    - title: "Deprecations and Migrations"
+      url: "/troubleshoot/product-lifecycle/deprecations-and-migrations"
diff --git a/config/glossary.json b/config/glossary.json
new file mode 100644
index 0000000000..eb364974c2
--- /dev/null
+++ b/config/glossary.json
@@ -0,0 +1,392 @@
+{
+  "access-token": {
+    "title": "Access Token",
+    "definition": "A credential that can be used by an application to access an API. It informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the scope that has been granted. An Access Token can be in any format, but two popular options include opaque strings and JSON Web Tokens (JWT). They should be transmitted to the API as a Bearer credential in an HTTP Authorization header.",
+    "short": "An authorization credential, in the form of an opaque string or JWT, used to access an API."
+  },
+  "account linking": {
+    "title": "Account Linking",
+    "definition": "Connecting user accounts across multiple platforms to allow users access to more than one resource or application by providing credentials one time.",
+    "short": "Connecting user accounts across multiple platforms."
+  },
+  "actions": {
+    "title": "Actions",
+    "definition": "Secure, tenant-specific, versioned functions written in Node.js that execute at certain points during the Auth0 runtime. Actions are used to customize and extend Auth0's capabilities with custom logic.",
+    "short": "Secure, tenant-specific, versioned functions written in Node.js that execute at certain points during the Auth0 runtime."
+  },
+  "adaptive-multifactor-authentication": {
+    "title": "Adaptive Multi-factor Authentication",
+    "definition": "Multi-factor authentication (MFA) that is only triggered for users when an attempted login is determined to be a low confidence login. With Adaptive MFA, Auth0 triggers MFA only when needed to add friction for bad actors while keeping the login experience unchanged for good actors.",
+    "short": "Multi-factor authentication (MFA) that is only triggered for users when an attempted login is determined to be a low confidence login. With Adaptive MFA, Auth0 triggers MFA only when needed to add friction for bad actors while keeping the login experience unchanged for good actors."
+  },
+  "application": {
+    "title": "Application",
+    "definition": "Your software that relies on Auth0 for authentication and identity management. Auth0 supports single-page, regular web, native, and machine-to-machine applications.",
+    "short": "A unique identifier, aud in a token, for an application (ID Token) or an API (Access Token)."
+  },
+  "attack-protection": {
+    "title": "Attack Protection",
+    "definition": "Features that Auth0 provides to detect and mitigate attacks, including brute-force protection, suspicious IP throttling, breached password detection, bot detection, and adaptive multi-factor authentication.",
+    "short": "Features that Auth0 provides to detect and mitigate attacks, including brute-force protection, suspicious IP throttling, breached password detection, bot detection, and adaptive multi-factor authentication."
+  },
+  "audience": {
+    "title": "Audience",
+    "definition": "The unique identifier of the audience for an issued token, identified within a JSON Web Token as the `aud` claim. The audience value is either the application (`Client ID`) for an ID Token or the API that is being called (`API Identifier`) for an Access Token. At Auth0, the Audience value sent in a request for an Access Token dictates whether that token is returned in an opaque or JWT format.",
+    "short": "A unique identifier, aud in a token, for an application (ID Token) or an API (Access Token)."
+  },
+  "auth0-dashboard": {
+    "title": "Auth0 Dashboard",
+    "definition": "Auth0’s primary administrator interface in which you can register your application or API, connect to a user store or another identity provider, and configure your Auth0 services.",
+    "short": "Auth0's main product to configure your services."
+  }, 
+  "authentication-server": {
+    "title": "Authentication Server",
+    "definition": "A server that confirms or denies a user’s identity. An authentication server does not limit the actions or resources available to the user (although it can provide context for this purpose).",
+    "short": "A server that confirms or denies a user’s identity."
+  },
+  "authorization-server": {
+    "title": "Authorization Server",
+    "definition": "A centralized server that contributes to defining the boundaries of a user’s access. For example, your authorization server can control the data, tasks, and features available to a user. An authorization server does not authenticate users. It’s the role of the authentication server to verify a user’s identity.",
+    "short": "A centralized server that contributes to defining the boundaries of a user’s access. For example, your authorization server can control the data, tasks, and features available to a user."
+  },
+  "authorization-code": {
+    "title": "Authorization Code",
+    "definition": "A random string generated by the authorization server and returned to the application as part of the authorization response. The authorization code is relatively short-lived and is exchanged for an Access Token at the token endpoint when using the Authorization Code Flow.",
+    "short": "A random string generated by the authorization server and returned to the application as part of the authorization response. The authorization code is relatively short-lived and is exchanged for an Access Token at the token endpoint when using the Authorization Code Flow."
+  },
+  "authorization-flow": {
+    "title": "Authorization Flow",
+    "definition": "Another name for Authorization Grants outlined in OAuth 2.0. Authorization flows are the workflows a resource (i.e. an application or an AIP) uses to grant requestors access. Based on the type of technology (i.e. if an application can store a Client Secret) and the type of requestor, resource owners can use Authorization Code Flow, Proof of Key Code Exchange (PKCE), Resource Owner Password Credential (ROPG), Implicit, or Client Credential.",
+    "short": "Authorization grant (or workflow) specified in the OAuth 2.0 framework."
+  },
+  "bad-actors": {
+    "title": "Bad Actors",
+    "definition": "Also known as threat actors. An entity (a person or group) that poses a threat to the business or environment with the intention to cause harm. Harm can constitute physical or cyber damages, from breaking into a data center to hacking into systems with stolen credentials.",
+    "short": "An entity (a person or group) that poses a threat to the business or environment with the intention to cause harm."
+  },
+  "beta": {
+    "title": "Beta",
+    "definition": "Product release stage during which the referenced feature or behavior is provided to subscribers to give them 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).",
+    "short": "Product release stage during which the referemced feature or behavior is provided to subscribers to give them 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)."
+  },
+  "block-unblock": {
+    "title": "Block/Unblock Users",
+    "definition": "Refers to the features from Auth0's Attack Protection suite: Breached Password Detection, Brute-Force Protection, and Suspicious IP Throttling. Each service assesses login/sign-up trends and blocks IP addresses associated with suspicious activity.",
+    "short": "Removing or restoring a requestors access to a resource."
+  },
+  "bot-detection": {
+    "title": "Bot Detection",
+    "definition": "A form of attack protection in which Auth0 blocks suspected bot traffic by enabling a CAPTCHA during the login process.",
+    "short": "A form of attack protection in which Auth0 blocks suspected bot traffic by enabling a CAPTCHA during the login process."
+  },
+  "breached-password-protection": {
+    "title": "Breached Password Protection",
+    "definition": "A form of attack protection in which Auth0 notifies your users if they use a username/password combination that has been compromised in a data leak on a third-party website or app.",
+    "short": "A form of attack protection in which Auth0 notifies your users if they use a username/password combination that has been compromised in a data leak on a third-party website or app."
+  },
+  "breaking-change": {
+    "title": "Breaking Change",
+    "definition": "Change to the Auth0 platform that, to Auth0's knowledge, will cause failures in the interoperation of the Auth0 platform and customer applications.",
+    "short": "Change to the Auth0 platform that, to Auth0's knowledge, will cause failures in the interoperation of the Auth0 platform and customer applications."
+  },
+  "brute-force-protection": {
+    "title": "Brute-force Protection",
+    "definition": "A form of attack protection that safeguards against brute-force attacks that occur from a single IP address and target a single user account.",
+    "short": "A form of attack protection that safeguards against brute-force attacks that occur from a single IP address and target a single user account."
+  },
+  "callback": {
+    "title": "Callback",
+    "definition": "The URL to which Auth0 sends its response after authentication. It is often the same URL to which a user is redirected after authentication.",
+    "short": "The URL to which Auth0 sends its response after an API call and sometimes where a user is redirected after authentication."
+  },
+  "claim": {
+    "title": "Claim",
+    "definition": "An attribute packaged in a security token which represents a claim that the provider of the token is making about an entity.",
+    "short": "An attribute packaged in a security token which represents a claim that the provider of the token is making about an entity."
+  },
+  "client-id": {
+    "title": "Client ID",
+    "definition": "Identification value assigned to your application after registration. This value is used in conjunction with other third-party services and can be found in Auth0 Dashboard > Application Settings.",
+    "short": "Identification value given to your registered resource from Auth0."
+  },
+  "client-secret":{
+    "title": "Client Secret",
+    "definition": "A secret used by a client (application) to authenticate with the Authorization Server; it should be known to only the client and the Authorization Server and must be sufficiently random to not be guessable.",
+    "short": "A secret used by a client (application) to authenticate with the Authorization Server; it should be known to only the client and the Authorization Server and must be sufficiently random to be not guessable."
+  },
+  "confidential-client": {
+    "title": "Confidential Client",
+    "definition": "According to the OAuth 2.0 protocol, clients (applications) can be classified as either confidential or public depending on whether or not they are able to hold credentials (such as a client ID and secret) securely. Confidential clients can hold credentials in a secure way without exposing them to unauthorized parties and require a trusted backend server to do so. They can use grant types that require them to authenticate by specifying their client ID and secret when calling the token endpoint and can have tokens issued to them that have been signed either symmetrically or asymmetrically.",
+    "short": "A client (application) that can hold credentials securely by using a trusted backend server. Examples include a web application with a secure backend and a machine-to-machine (M2M) application."
+  },
+  "confused-deputy": {
+    "title": "Confused Deputy",
+    "definition": "The term confused deputy refers to a situation in which an attacker tricks a client or service into performing an action on their behalf.",
+    "short": "The term confused deputy refers to a situation in which an attacker tricks a client or service into performing an action on their behalf."
+  },
+  "connection": {
+    "title": "Connection",
+    "definition": "The relationship between Auth0 and the sources of users for your applications. Examples include identity providers (such as Google or Active Directory), passwordless authentication methods, or user databases.",
+    "short": "The relationship between Auth0 and the sources of users for your applications."
+  },
+  "custom-domain": {
+    "title": "Custom Domain",
+    "definition": "A third-party domain with a specialized, or vanity, name. Also known as a CNAME.",
+    "short": "A third-party domain with a specialized, or vanity, name."
+  },
+  "deprecation": {
+    "title": "Deprecation",
+    "definition": "Product release stage indicating that the referenced feature or behavior is not supported for use by new subscribers, is not actively being enhanced, and is being only minimally maintained. Tenants using the feature or behavior at the time of deprecation will continue to have access.",
+    "short": "Product release stage indicating that the referenced feature or behavior is not supported for use by new subscribers, is not actively being enhanced, and is being only minimally maintained. Tenants using the feature or behavior at the time of deprecation will continue to have access."
+  },
+  "digital-identity": {
+    "title": "Digital Identity",
+    "definition": "The set of attributes that define a particular user in the context of a function which is delivered by a particular application.",
+    "short": "The set of attributes that define a particular user in the context of a function which is delivered by a particular application."
+  },
+  "digital-signature": {
+    "title": "Digital Signature",
+    "definition": "A digital signature protects bits in a token from tampering. If the bits are changed or tampered with, the signature will no longer be able to be verified and it will be rejected.",
+    "short": "A digital signature protects bits in a token from tampering."
+  },
+  "directory": {
+    "title": "Directory",
+    "definition": "A centralized repository of users (the most well-known of which is Active Directory) which centralizes credentials and attributes and makes it unnecessary for each application to have their own local identity setup and pool of users. Allows single sign on to all applications that use the same directory of users.",
+    "short": "A centralized repository of users that allows single sign on to all applications that use the same directory."
+  },
+  "early-access": {
+    "title": "Early Access",
+    "definition": "A product release stage during which the referemced feature or behavior is provided to a limited number of subscribers or customer development partners (CDPs) to give them the opportunity to test and provide feedback on future functionality. At this stage, functionality may not be complete, but is ready for validation.",
+    "short": "A product release stage during which the referemced feature or behavior is provided to a limited number of subscribers or customer development partners (CDPs) to give them the opportunity to test and provide feedback on future functionality. At this stage, functionality may not be complete, but is ready for validation."
+  },
+  "end-of-life": {
+    "title": "End of Life",
+    "definition": "A product release stage indicating the referemced feature or behavior is removed from the platform. Continued use of the feature or behavior will likely result in errors. The new behavior will automatically be enabled for Tenants that did not opt in during the migration window.",
+    "short": "A product release stage indicating the referemced feature or behavior is removed from the platform. Continued use of the feature or behavior will likely result in errors. The new behavior will automatically be enabled for Tenants that did not opt in during the migration window."
+  },
+  "end-of-life-date": {
+    "title": "End of Life Date",
+    "definition": "The date that access to a feature or behavior is removed from the platform. End Of Life Dates can vary between different plan types.",
+    "short": "The date that access to a feature or behavior is removed from the platform. End Of Life Dates can vary between different plan types."
+  },
+  "fapi": {
+    "title": "OpenID FAPI",
+    "definition": "A suite of security and privacy specifications developed by the OpenID Foundation to allow applications to interact with and use data from financial accounts.",
+    "short": "A suite of security and privacy specifications developed by the OpenID Foundation."
+  },
+  "fine-grained-auth": {
+    "title": "Fine Grained Authorization (FGA) ",
+    "definition": "Auth0’s SaaS product gives individual users access to specific objects or resources within your application.",
+    "short": "A product allowing individual users access to specific objects or resources."
+  },
+  "flow": {
+    "title": "Flow",
+    "definition": "Processes that can be extended using Actions. Each Flow is made up of one or more Triggers and represents the logical pipeline through which information moves during a single point in the Auth0 journey.",
+    "short": "Processes that can be extended using Actions. Each Flow is made up of one or more Triggers and represents the logical pipeline through which information moves during a single point in the Auth0 journey."  
+  },
+  "general-availability": {
+    "title": "General Availability",
+    "definition": "A product release stage during which the referenced feature or behavior is fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, Auth0 provides a period of backward compatibility in accordance with our deprecation policy and informs customers so they have time to adopt the new release.",
+    "short": "A product release stage during which the referemced feature or behavior is fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, Auth0 provides a period of backward compatibility in accordance with our deprecation policy and informs customers so they have time to adopt the new release."
+  },
+  "group": {
+    "title": "Group",
+    "definition": "A set of one or more users. In the Auth0 Authorization Extension, use groups to grant access to many users at a time.",
+    "short": "A set of one or more users. In the Auth0 Authorization Extension, use groups to grant access to many users at a time."
+  },
+  "id-token": {
+    "title": "ID Token",
+    "definition": "A credential meant for the client itself, rather than for accessing a resource. It has a fixed format that clients can parse and validate.",
+    "short": "A credential meant for the client itself, rather than for accessing a resource."
+  },
+  "idp": {
+    "title": "Identity Provider (IdP)",
+    "definition": "A service that stores and manages digital identities. Auth0 supports trusted social, enterprise, and legal identity providers. Auth0 also can function as an identity provider for your applications.",
+    "short": "A service that stores and manages digital identities."
+  },
+  "json-web-token": {
+    "title": "JSON Web Token (JWT)",
+    "definition": "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 are often in JWT format. You may decode well-formed JWTs at JWT.io to view their claims. See JSON Web Tokens.",
+    "short": "The standard ID Token format and often Access Token format used to represent claims securely between two parties."
+  },
+  "localization": {
+    "title": "Localization",
+    "definition": "Ability to render the New Universal Login experience into a supported languages.",
+    "short": "Ability to render NUL into a supported language."
+  },
+  "lock": {
+    "title": "Lock",
+    "definition": "Auth0's UI widget for authenticating users. It is ready to go as-is and is the default face of the Classic Universal Login experience. Lock allows you to customize minor behavioral and appearance options, but its primary goal is ease of use. See Lock.",
+    "short": "Auth0's UI widget for authenticating users."
+  },
+  "management-api": {
+    "title": "Management API",
+    "definition": "Auth0's API to manage Auth0 services and perform administrative tasks programatically.",
+    "short": "A product to allow customers to perform administrative tasks. "
+  },
+  "metadata": {
+    "title": "Metadata",
+    "definition": "Information users can update, such as preferences or profile settings. Metadata is added to ID tokens and can be stored in user profiles.",
+    "short": "User information stored in user profiles."
+  },
+  "migration": {
+    "title": "Migration",
+    "definition": "A process by which a customer moves away from a particular feature or behavior. Migrations should occur during the Deprecation product release stage.",
+    "short": "A process by which a customer moves away from a particular feature or behavior. Migrations should occur during the Deprecation product release stage."
+  },
+  "multifactor-authentication": {
+    "title": "Multi-factor authentication (MFA)",
+    "definition": "An authentication process that considers multiple factors. Typically at Auth0, the first factor is the standard username/password exchange, and the second is a code or link via email or SMS, a one-time-password via an app such as Authy or Google Authenticator, or a push notification via a phone app such as Guardian or Duo. Using multiple factors allows your account to remain secure if someone captures one or the other factor--acquires your password or steals your phone, for example. See Multi-factor Authentication.",
+    "short": "A user authentication process that uses a factor in addition to username and password such as a code via SMS."
+  },
+  "nonce": {
+    "title": "Nonce",
+    "definition": "An arbitrary (often random or pseudo-random) number issued in an authentication protocol that can be used to help detect and mitigate replay attacks using old communications. In other words, the nonce is only issued once, so if an attacker attempts to replay a transaction with a different nonce, its false transaction can be detected more easily. See Nonce.",
+    "short": "An arbitrary number issued once in an authentication protocol to detect and prevent replay attacks."
+  },
+  "oath2": {
+    "title": "OAuth 2.0",
+    "definition": "An authorization framework that defines authorization protocols and workflows. OAuth 2.0 defines roles, authorization grants (or workflows), authorization requests and responses, and token handling. OpenID Connect (OIDC) protocols to verify user identity extends OAuth 2.0.",
+    "short": "An authorization framework that defines authorization protocols and workflows."
+  },
+  "openid": {
+    "title": "OpenID",
+    "definition": "An open standard for authentication that allows applications to verify users are who they say they are without needing to collect, store, and therefore become liable for a user’s login information. See OpenID Connect (OIDC).",
+    "short": "An open standard for authentication that allows applications to verify users' identities without collecting and storing login information." 
+  },
+  "organizations": {
+    "title": "Organizations",
+    "definition": "A product for B2B customers to categorize end-users and define specific roles, login experience, and access to resources.",
+    "short": "A product to categorize end-users and define specific roles."
+},  
+  "passwordless": {
+    "title": "Passwordless",
+    "definition": "A form of authentication where the first factor is not a password. Instead, it could be a one-time password received by email or SMS, a push notification, or a biometric sensor. Passwordless uses one-time passwords, so users are less susceptible to the typical password-based attacks (e.g., dictionary or credential stuffing) than with traditional username/password logins. See Passwordless.",
+    "short": "A form of authentication that does not rely on a password as the first factor."
+  },
+  "perimeter": {
+    "title": "Perimeter",
+    "definition": "A set of boundaries that encompass a directory, all of its users, and all of the applications which use the directory. In some implementations, this perimeter is a physical location; in others, it is a set of networks or devices connected via VPN.",
+    "short": "A set of boundaries that encompass a directory, all of its users, and all of the applications which use the directory."
+  },
+  "product-release-stages": {
+    "title": "Product Release Stages",
+    "definition": "Phases that describe how Auth0 stages, releases, and retires 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.",
+    "short": "Phases that describe how Auth0 stages, releases, and retires product functionality."
+  },
+  "public-client": {
+    "title": "Public Client",
+    "definition": "According to the OAuth 2.0 protocol, clients (applications) can be classified as either confidential or public depending on whether or not they are able to hold credentials (such as a client ID and secret) securely. Public clients cannot hold credentials securely, so should only use grant types that do not require the use of their client secret. ID Tokens issued to them must be signed asymmetrically using a private key (RS256) and verified using the public key corresponding to the private key used to sign the token. See Application Types - Confidential vs. Public.",
+    "short": "A client (application) that cannot hold credentials securely. Examples include a native desktop or mobile application and a JavaScript-based client-side web application (such as a single-page app (SPA))."
+  },
+  "raw-credentials": {
+    "title": "Raw Credentials",
+    "definition": "A shared secret or set of information that are agreed upon between the user and the resource that allow the resource to verify the identity of a user.",
+    "short": "A shared secret or set of information that are agreed upon between the user and the resource that allow the resource to verify the identity of a user."
+  },
+  "refresh-token": {
+    "title": "Refresh Token",
+    "definition": "A special kind of token that can be used to obtain a renewed Access Token. It is useful for renewing expiring Access Tokens without forcing the user to log in again. Using the Refresh Token, you can request a new Access Token at any time until the Refresh Token is blacklisted. See Refresh Tokens.",
+    "short": "A token used to obtain a renewed Access Token without forcing users to log in again."
+  },
+  "refresh-token-rotation": {
+    "title": "Refresh Token Rotation",
+    "definition": "A strategy of frequently replacing refresh tokens to minimize vulnerability. With refresh token rotation, every time your application exchanges a refresh token to get a new access token, Auth0 also returns a new refresh token.",
+    "short": "A strategy of frequently replacing refresh tokens to minimize vulnerability. With refresh token rotation, every time your application exchanges a refresh token to get a new access token, Auth0 also returns a new refresh token."
+  },
+  "relying-party": {
+    "title": "Relying Party",
+    "definition": "An entity (such as a service or application) that depends on a third-party identity provider to authenticate a user.",
+    "short": "An entity (such as a service or application) that depends on a third-party identity provider to authenticate a user."
+  },
+  "resource-owner": {
+    "title": "Resource Owner",
+    "definition": "An entity (such as a user or application) capable of granting access to a protected resource.",
+    "short": "An entity (such as a user or application) capable of granting access to a protected resource."
+  },
+  "resource-server": {
+    "title": "Resource Server",
+    "definition": "A server hosting protected resources. Resource servers accept and respond to protected resource requests.",
+    "short": "A server hosting protected resources. Resource servers accept and respond to protected resource requests."
+  },
+  "role": {
+    "title": "Role",
+    "definition": "An aspect of a user’s identity assigned to the user to indicate the level of access they should have to the system. Roles are essentially collections of permissions. See Role-based Access Control (RBAC).",
+    "short": "An aspect of a user’s identity assigned to the user to give them a certain set of permissions."
+  },
+  "scope": {
+    "title": "Scope",
+    "definition": "A mechanism that defines the specific actions applications can be allowed to do or information that they can request on a user’s behalf. Often, 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. 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. See Scopes.",
+    "short": "A mechanism that determines actions applications can perform on a user's behalf with information previously created in an online resource."
+  },
+  "security-assertion-markup-language": {
+    "title": "Security Assertion Markup Language (SAML)",
+    "definition": "An XML-based standardized protocol by which two parties can exchange authentication information without the use of a password. See SAML.",
+    "short": "A standardized protocol allowing two parties to exchange authentication information without a password."
+  },
+  "security-token": {
+    "title": "Security Token",
+    "definition": "A digitally-signed artifact used to prove that the user was successfully authenticated.",
+    "short": "A digitally-signed artifact used to prove that the user was successfully authenticated."
+  },
+  "session-cookie": {
+    "title": "Session Cookie",
+    "definition": "An entity emitted by middleware after it establishes that the token it is receiving is signed, valid, and comes from a trusted source (the identity provider). This entity represents the fact that successful authentication occurred with the identity provider. This cookie prevents this process with tokens from needing to be continually repeated, by allowing the user to be considered authenticated as long as the cookie is present.",
+    "short": "An entity that, when present, allows the user to be considered authenticated."
+  },
+  "shadow-accounts": {
+    "title": "Shadow Accounts",
+    "definition": "A difficult to sustain practice of manually provisioning a user from a local directory separately in a remote directory (essentially creating a copy, or shadow, of the original account) when they need access to remote applications.",
+    "short": "A difficult to sustain practice of manually provisioning a user from a local directory separately in a remote directory."
+  },
+  "signing-algorithm": {
+    "title": "Signing Algorithm",
+    "definition": "A hashing algorithm used to digitally sign tokens to ensure the token has not been tampered with by bad actors.",
+    "short": "An algorithm used to digitally sign tokens to ensure the token has not been tampered with."
+  },
+  "single-sign-on": {
+    "title": "Single Sign-On (SSO)",
+    "definition": "A service that, after a user logs into one application, automatically logs that user in to other applications, regardless of the platform, technology, or domain the user is using. The user signs in only one time (hence the name of the feature). Similarly, Single Logout (SLO) occurs when, after a user logs out from one application, they are logged out of each application or service where they were logged in. SSO and SLO are possible through the use of sessions. See Single Sign-On and Single Logout.",
+    "short": "A service that, after a user logs into one applicaton, automatically logs that user in to other applications."
+  },
+  "subscription": {
+    "title": "Subscription",
+    "definition": "An agreement that defines the features and quotas available for each of your tenants. Auth0 has multiple subscription levels to meet the needs of different developers and organizations.",
+    "short": "An agreement that defines the features and quotas available for each of your tenants. Auth0 has multiple subscription levels to meet the needs of different developers and organizations."
+  },
+  "suspicious-ip-throttling": {
+    "title": "Suspicious IP Throttling",
+    "definition": "A form of attack protection that protects your tenant against suspicious logins targeting too many accounts from a single IP address.",
+    "short": "A form of attack protection that protects your tenant against suspicious logins targeting too many accounts from a single IP address."
+  },
+  "tenant": {
+    "title": "Tenant",
+    "definition": "At Auth0, a logically-isolated group of users who share common access with specific privileges to a single software instance. No tenant can access the data of another tenant, even though multiple tenants might be running on the same machine. Tenant, in general, is a term borrowed from software multitenant architecture.",
+    "short": "At Auth0, a logically-isolated group of users who share common access with specific privileges to a single software instance. No tenant can access the data of another tenant, even though multiple tenants might be running on the same machine. Tenant, in general, is a term borrowed from software multitenant architecture."
+  },
+  "token-endpoint": {
+    "title": "Token Endpoint",
+    "definition": "The endpoint on the Authorization Server that is used to programmatically request tokens.",
+    "short": "The endpoint on the Authorization Server that is used to programmatically request tokens."
+  },
+  "trigger": {
+    "title": "Trigger",
+    "definition": "An event that automatically invokes an Action when a specific operation, such as a user logging in, occurs at runtime. Some Triggers are executed synchronously, blocking the Flow in which they are involved, and some are executed asynchronously.",
+    "short": "An event that automatically invokes an Action when a specific operation, such as a user logging in, occurs at runtime."  
+  },
+  "trust": {
+    "title": "Trust",
+    "definition": "A resource trusts an identity provider or authority when that resource is willing to believe what the authority says about its users.",
+    "short": "A resource trusts an identity provider or authority when that resource is willing to believe what the authority says about its users."
+  },
+ "universal-login": {
+   "title": "Universal Login",
+   "definition": "Auth0’s implementation of the authentication 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’s needed to guarantee the user’s identity. See Auth0 Universal Login.",
+   "short": "Your application redirects to Universal Login, hosted on Auth0's Authorization Server, to verify a user's identity."
+ },
+ "ws-fed": {
+  "title": "Web Service Federation (WS-Fed)",
+  "definition": "A protocol for managing user identities between systems, domains, and identity providers with established trust using WS-Trust. This protocol is mainly used for Microsoft products and defines policies on how to share federation metadata. ",
+  "short": "A protocol for managing user identities across domains."
+ }
+}
diff --git a/config/included-folders.yml b/config/included-folders.yml
new file mode 100644
index 0000000000..1c5281ae7c
--- /dev/null
+++ b/config/included-folders.yml
@@ -0,0 +1,9 @@
+- /articles/api/authentication
+- /articles/api/authorization-extension
+- /articles/microsites
+- /articles/quickstart
+- /fr-ca/articles/quickstart
+- /ja-jp/articles/quickstart
+- /articles/_includes
+- /snippets
+- /updates
diff --git a/config/redirects.js b/config/redirects.js
index 4f9af8e83f..5719f79b0b 100644
--- a/config/redirects.js
+++ b/config/redirects.js
@@ -1,4 +1,4 @@
-// This is the list of APIs used in the old two-step quickstarts.
+//  This is the list of APIs used in the old two-step quickstarts.
 const apiNames = [
   'aspnet-webapi',
   'aws',
@@ -18,1743 +18,9090 @@ const apiNames = [
   'php',
   'python',
   'rails',
-  'relay',
   'ruby',
   'salesforce-sandbox',
   'salesforce',
   'sap-odata',
   'wcf-service',
-  'webapi-owin'
+  'webapi-owin',
 ];
 
 const apis = `:api(${apiNames.join('|')})`;
 
-module.exports = [
+const redirects = [
+  /* MISCELLANEOUS AND OUTDATED  */
 
-  /* Quickstart aliases */
-
-  {
-    from: ['/android-tutorial', '/native-platforms/android'],
-    to: '/quickstart/native/android'
-  },
   {
     from: [
-      '/angular-tutorial',
-      '/client-platforms/angularjs',
-      '/quickstart/spa/angular/:client?'
+      '/addons',
+      '/firebaseapi-tutorial',
+      '/salesforcesandboxapi-tutorial',
+      '/salesforceapi-tutorial',
+      '/sapapi-tutorial',
+      '/clients/addons',
+      '/applications/addons',
+      '/addons/azure-blob-storage',
+      '/addons/azure-mobile-services',
+      '/addons/azure-sb',
     ],
-    to: '/quickstart/spa/angularjs'
+    to: '/',
   },
   {
-    from: '/client-platforms/angular2',
-    to: '/quickstart/spa/angular2'
+    from: '/topics/guides',
+    to: '/',
   },
   {
-    from: ['/aspnet-tutorial', '/mvc3-tutorial'],
-    to: '/quickstart/webapp/aspnet'
+    from: ['/design', '/design/web'],
+    to: '/',
   },
   {
-    from: ['/aspnet-owin-tutorial', '/aspnetwebapi-owin-tutorial'],
-    to: '/quickstart/webapp/aspnet-owin'
+    from: ['/contentful-test-1', '/contentful-test-2', '/contentful-test-3', '/contentful-test-4'],
+    to: '/',
   },
   {
     from: [
-      '/aspnetwebapi-tutorial',
-      '/tutorials/aspnet-mvc4-enterprise-providers',
-      '/webapi'
+      '/design/browser-based-vs-native-experience-on-mobile',
+      '/tutorials/browser-based-vs-native-experience-on-mobile',
+      '/best-practices/mobile-device-login-flow-best-practices',
+      '/get-started/authentication-and-authorization-flow/mobile-device-login-flow-best-practices',
     ],
-    to: '/quickstart/backend/aspnet-webapi'
-  },
-  {
-    from: '/awsapi-tutorial',
-    to: '/integrations/aws'
-  },
-  {
-    from: '/quickstart/native/chrome-extension',
-    to: '/quickstart/native/chrome'
+    to: '/get-started/authentication-and-authorization-flow/device-authorization-flow/mobile-device-login-flow-best-practices',
   },
   {
-    from: ['/ember-tutorial', '/client-platforms/emberjs'],
-    to: '/quickstart/spa/emberjs'
+    from: '/topics/identity-glossary',
+    to: '/glossary',
   },
   {
-    from: '/firebaseapi-tutorial',
-    to: '/applications/addons'
-  },
-  {
-    from: '/ionic-tutorial',
-    to: '/quickstart/native/ionic'
-  },
-  {
-    from: ['/ios-tutorial', '/native-platforms/ios-objc'],
-    to: '/quickstart/native/ios-objc'
-  },
-  {
-    from: '/java-tutorial',
-    to: '/quickstart/webapp/java'
+    from: ['/deploy/checklist', '/deploy/deploy-checklist'],
+    to: '/deploy-monitor/deploy-checklist',
   },
+
+  /* QUICKSTARTS */
+
   {
-    from: '/javaapi-tutorial',
-    to: '/quickstart/backend/java'
+    from: [
+      '/quickstart/hybrid/:platform',
+      '/quickstart/native-mobile/:platform',
+      `/quickstart/hybrid/:platform/${apis}`,
+      `/quickstart/native-mobile/:platform/${apis}`,
+      `/quickstart/native/:platform/${apis}`,
+    ],
+    to: '/quickstart/native/:platform',
   },
   {
-    from: '/server-platforms/golang',
-    to: '/quickstart/webapp/golang'
+    from: `/quickstart/spa/:platform/${apis}`,
+    to: '/quickstart/spa/:platform',
   },
   {
-    from: '/laravel-tutorial',
-    to: '/quickstart/webapp/laravel'
+    from: `/quickstart/backend/:platform/${apis}`,
+    to: '/quickstart/backend/:platform',
   },
   {
-    from: '/laravelapi-tutorial',
-    to: '/quickstart/backend/php-laravel'
+    from: ['/quickstart/:platform/reactnative-ios/:backend?', '/quickstart/:platform/reactnative-android/:backend?'],
+    to: '/quickstart/native/react-native',
   },
   {
-    from: '/mvc-tutorial-enterprise',
-    to: '/tutorials/aspnet-mvc4-enterprise-providers'
+    from: ['/android-tutorial', '/native-platforms/android', '/quickstart/native/android-vnext'],
+    to: '/quickstart/native/android',
   },
   {
-    from: '/nodeapi-tutorial',
-    to: '/quickstart/backend/nodejs'
+    from: [
+      '/angular-tutorial',
+      '/client-platforms/angularjs',
+      '/client-platforms/angular2',
+      '/quickstart/spa/angularjs',
+      '/quickstart/spa/angular-next',
+      '/quickstart/spa/angular2',
+      '/quickstart/spa/angular2/00-login',
+      '/quickstart/spa/angular2/03-user-profile',
+      '/quickstart/spa/angular2/04-calling-an-api',
+      '/quickstart/spa/angular2/05-authorization',
+      '/quickstart/spa/angular2/06-token-renewal',
+    ],
+    to: '/quickstart/spa/angular',
   },
   {
-    from: ['/nodejs-tutorial', '/server-platforms/nodejs'],
-    to: '/quickstart/webapp/nodejs'
+    from: '/quickstarts/spa/vanillajs/01-login',
+    to: '/quickstart/spa/vanillajs/01-login',
   },
   {
-    from: '/phonegap-plugin-tutorial',
-    to: '/native-platforms/cordova'
+    from: [
+      '/quickstart/webapp/aspnet',
+      '/aspnet-tutorial',
+      '/mvc3-tutorial',
+      '/servicestack-tutorial',
+      '/quickstart/webapp/servicestack',
+      '/quickstart/webapp/play-2-scala',
+      '/quickstart/webapp/scala',
+      '/symfony-tutorial',
+      '/quickstart/webapp/symfony',
+    ],
+    to: '/quickstart/webapp',
   },
   {
-    from: '/phpapi-tutorial',
-    to: '/quickstart/backend/php'
+    from: ['/aspnet-owin-tutorial', '/aspnetwebapi-owin-tutorial'],
+    to: '/quickstart/webapp/aspnet-owin',
   },
   {
-    from: '/pythonapi-tutorial',
-    to: '/quickstart/backend/python'
+    from: [
+      '/aspnetwebapi-tutorial',
+      '/tutorials/aspnet-mvc4-enterprise-providers',
+      '/webapi',
+      '/mvc-tutorial-enterprise',
+      '/quickstart/backend/aspnet-webapi',
+      '/wcf-tutorial',
+      '/quickstart/backend/wcf-service',
+      '/quickstart/backend/falcor/00-getting-started',
+      '/quickstart/backend/falcor',
+      '/quickstart/backend/hapi/00-getting-started',
+      '/quickstart/backend/hapi',
+      '/quickstart/backend/symfony/00-getting-started',
+      '/quickstart/backend/symfony',
+    ],
+    to: '/quickstart/backend',
   },
   {
-    from: '/client-platforms/react',
-    to: '/quickstart/spa/react'
+    from: [
+      '/quickstart/native-mobile',
+      '/quickstart/hybrid',
+      '/quickstart/native/chrome-extension',
+      '/quickstart/native/chrome',
+      '/phonegap-tutorial',
+      '/quickstart/native/phonegap',
+      '/win8-tutorial',
+      '/windowsstore-js-auth0-tutorial',
+      '/native-platforms/windows-store-javascript',
+      '/quickstart/native-mobile/windows8/:client',
+      '/quickstart/native/windows-uwp-javascript',
+      '/windowsphone-tutorial',
+      '/quickstart/native/windowsphone',
+    ],
+    to: '/quickstart/native',
   },
   {
-    from: '/quickstart/native/ios-reactnative',
-    to: '/quickstart/native/react-native'
+    from: [
+      '/ionic-tutorial',
+      '/quickstart/native/ionic',
+      '/quickstart/native/ionic4',
+      '/quickstart/native/ionic/00-intro',
+      '/quickstart/native/ionic/02-custom-login',
+      '/quickstart/native/ionic/03-user-profile',
+      '/quickstart/native/ionic/04-linking-accounts',
+      '/quickstart/native/ionic/05-rules',
+      '/quickstart/native/ionic/06-authorization',
+      '/quickstart/native/ionic/08-mfa',
+      '/quickstart/native/ionic/09-customizing-lock',
+    ],
+    to: '/quickstart/native/ionic-angular',
   },
   {
-    from: '/rubyapi-tutorial',
-    to: '/quickstart/backend/rails'
+    from: [
+      '/ios-tutorial',
+      '/quickstart/native/ios',
+      '/quickstart/native/ios-objc',
+      '/native-platforms/ios-objc',
+      '/quickstart/native/ios-swift-facebook-login',
+      '/quickstart/native/ios-swift-siwa',
+      '/quickstart/native/ios-swift/00-login',
+      '/quickstart/native/ios-swift/01-embedded-login',
+      '/quickstart/native/ios-swift/02-custom-login-form',
+      '/quickstart/native/ios-swift/03-user-sessions',
+      '/quickstart/native/ios-swift/04-calling-apis',
+      '/quickstart/native/ios-swift/05-authorization',
+      '/quickstart/native/ios-swift/07-linking-accounts',
+      '/quickstart/native/ios-swift/08-touch-id-authentication',
+      '/quickstart/native/swift-beta',
+    ],
+    to: '/quickstart/native/ios-swift',
   },
   {
-    from: '/rails-tutorial',
-    to: '/quickstart/webapp/rails'
+    from: '/server-platforms/golang',
+    to: '/quickstart/webapp/golang',
   },
   {
-    from: '/server-apis/ruby',
-    to: '/quickstart/backend/ruby'
+    from: '/laravel-tutorial',
+    to: '/quickstart/webapp/laravel',
   },
   {
-    from: '/python-tutorial',
-    to: '/quickstart/webapp/python'
+    from: ['/laravelapi-tutorial', '/quickstart/backend/php-laravel', '/quickstart/backend/laravel/00-getting-started'],
+    to: '/quickstart/backend/laravel',
   },
   {
-    from: ['/php-tutorial', '/server-platforms/php'],
-    to: '/quickstart/webapp/php'
+    from: ['/nodeapi-tutorial', '/quickstart/backend/nodejs/00-getting-started'],
+    to: '/quickstart/backend/nodejs',
   },
   {
-    from: '/phonegap-tutorial',
-    to: '/quickstart/native/phonegap'
+    from: ['/phpapi-tutorial', '/quickstart/backend/php/00-getting-started'],
+    to: '/quickstart/backend/php',
   },
   {
-    from: '/salesforcesandboxapi-tutorial',
-    to: '/applications/addons'
+    from: ['/pythonapi-tutorial', '/quickstart/backend/python/00-getting-started'],
+    to: '/quickstart/backend/python',
   },
   {
-    from: '/salesforceapi-tutorial',
-    to: '/applications/addons'
+    from: [
+      '/client-platforms/react',
+      '/quickstart/spa/auth0-react',
+      '/quickstart/spa/auth0-react/01',
+      '/quickstart/spa/react/03-user-profile',
+      '/quickstart/spa/react/04-user-profile',
+    ],
+    to: '/quickstart/spa/react',
   },
   {
-    from: '/sapapi-tutorial',
-    to: '/applications/addons'
+    from: [
+      '/quickstart/native/ios-reactnative',
+      '/quickstart/native/react-native-ios',
+      '/quickstart/native/react-native-android',
+    ],
+    to: '/quickstart/native/react-native',
   },
   {
-    from: '/servicestack-tutorial',
-    to: '/quickstart/webapp/servicestack'
+    from: [
+      '/rails-tutorial',
+      '/quickstart/webapp/rails/00-introduction',
+      '/quickstart/webapp/rails/02-custom-login',
+      '/quickstart/webapp/rails/03-session-handling',
+      '/quickstart/webapp/rails/02-session-handling',
+      '/quickstart/webapp/rails/04-user-profile',
+      '/quickstart/webapp/rails/03-user-profile',
+      '/quickstart/webapp/rails/05-linking-accounts',
+      '/quickstart/webapp/rails/06-rules',
+      '/quickstart/webapp/rails/07-authorization',
+      '/quickstart/webapp/rails/08-mfa',
+      '/quickstart/webapp/rails/09-customizing-lock',
+    ],
+    to: '/quickstart/webapp/rails',
   },
   {
     from: [
-      '/singlepageapp-tutorial',
-      '/client-platforms/vanillajs',
-      '/quickstart/spa/javascript/:client?'
+      '/server-apis/ruby',
+      '/quickstart/backend/ruby/00-getting-started',
+      '/quickstart/backend/ruby',
+      '/rubyapi-tutorial',
+      '/quickstart/backend/rails/00-getting-started',
     ],
-    to: '/quickstart/spa/vanillajs'
+    to: '/quickstart/backend/rails',
   },
   {
-    from: '/quickstart/webapp/play-2-scala',
-    to: '/quickstart/webapp/scala'
+    from: '/python-tutorial',
+    to: '/quickstart/webapp/python',
   },
   {
-    from: '/symfony-tutorial',
-    to: '/quickstart/webapp/symfony'
+    from: ['/php-tutorial', '/server-platforms/php'],
+    to: '/quickstart/webapp/php',
   },
   {
-    from: '/wcf-tutorial',
-    to: '/quickstart/backend/wcf-service'
+    from: ['/singlepageapp-tutorial', '/client-platforms/vanillajs', '/quickstart/spa/javascript/:client?'],
+    to: '/quickstart/spa/vanillajs',
   },
   {
     from: [
       '/win8-cs-tutorial',
       '/windowsstore-auth0-tutorial',
       '/native-platforms/windows-store-csharp',
+      '/quickstart/native/windows8-cp',
       '/quickstart/native-mobile/windows8-cp/:client?',
-      '/quickstart/native/windows8-cp'
-    ],
-    to: '/quickstart/native/windows-uwp-csharp'
-  },
-  {
-    from: [
-      '/win8-tutorial',
-      '/windowsstore-js-auth0-tutorial',
-      '/native-platforms/windows-store-javascript',
-      '/quickstart/native-mobile/windows8/:client'
     ],
-    to: '/quickstart/native/windows-uwp-javascript'
-  },
-  {
-    from: '/windowsphone-tutorial',
-    to: '/quickstart/native/windowsphone'
+    to: '/quickstart/native/windows-uwp-csharp',
   },
   {
     from: '/wpf-winforms-tutorial',
-    to: '/quickstart/native/wpf-winforms'
+    to: '/quickstart/native/wpf-winforms',
   },
   {
     from: '/xamarin-tutorial',
-    to: '/quickstart/native/xamarin'
+    to: '/quickstart/native/xamarin',
   },
   {
-    from: '/quickstart/:platform/reactnative-ios/:backend?',
-    to: '/quickstart/native/react-native'
+    from: '/quickstart/native/xamarin',
+    to: '/quickstart/native/net-android-ios',
   },
   {
-    from: '/quickstart/:platform/reactnative-android/:backend?',
-    to: '/quickstart/native/react-native'
+    from: '/quickstart/native/xamarin/interactive',
+    to: '/quickstart/native/net-android-ios/interactive',
   },
   {
-    from: '/quickstart/native/react-native-ios',
-    to: '/quickstart/native/react-native'
+    from: '/quickstart/spa/auth0-react/02',
+    to: '/quickstart/spa/react/02-calling-an-api',
   },
   {
-    from: '/quickstart/native/react-native-android',
-    to: '/quickstart/native/react-native'
+    from: [
+      '/quickstart/backend/webapi-owin/04-authentication-rs256-deprecated',
+      '/quickstart/backend/webapi-owin/04-authentication-rs256-legacy',
+      '/quickstart/backend/webapi-owin/05-authentication-hs256-deprecated',
+      '/quickstart/backend/webapi-owin/05-authentication-hs256-legacy',
+      '/quickstart/backend/webapi-owin/06-authorization-deprecated',
+      '/quickstart/backend/webapi-owin/06-authorization-legacy',
+      '/quickstart/backend/webapi-owin/00-getting-started',
+    ],
+    to: '/quickstart/backend/webapi-owin',
   },
-
-  /* --- Renamed quickstart articles --- */
-
   {
-    from: '/quickstart/backend/webapi-owin/04-authentication-rs256-deprecated',
-    to: '/quickstart/backend/webapi-owin/04-authentication-rs256-legacy'
+    from: [
+      '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-deprecated',
+      '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-legacy',
+      '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-deprecated',
+      '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-legacy',
+      '/quickstart/backend/aspnet-core-webapi/06-authorization-deprecated',
+      '/quickstart/backend/aspnet-core-webapi/06-authorization-legacy',
+      '/quickstart/backend/aspnet-core-webapi/00-getting-started',
+      '/quickstart/backend/aspnet-core-webapi-2',
+    ],
+    to: '/quickstart/backend/aspnet-core-webapi',
   },
   {
-    from: '/quickstart/backend/webapi-owin/05-authentication-hs256-deprecated',
-    to: '/quickstart/backend/webapi-owin/05-authentication-hs256-legacy'
+    from: ['/quickstart/webapp/aspnet-core-3', '/quickstart/webapp/aspnet-core-2'],
+    to: '/quickstart/webapp/aspnet-core',
   },
   {
-    from: '/quickstart/backend/webapi-owin/06-authorization-deprecated',
-    to: '/quickstart/backend/webapi-owin/06-authorization-legacy'
+    from: [
+      '/quickstart/spa/aurelia',
+      '/ember-tutorial',
+      '/client-platforms/emberjs',
+      '/quickstart/spa/emberjs',
+      '/quickstart/spa/ember',
+      '/quickstart/spa/jquery',
+    ],
+    to: '/quickstart/spa',
   },
   {
-    from: '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-deprecated',
-    to: '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-legacy'
+    from: ['/quickstart', '/quickstart/'],
+    to: '/quickstarts',
   },
   {
-    from: '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-deprecated',
-    to: '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-legacy'
+    from: '/quickstart/backend/golang/00-getting-started',
+    to: '/quickstart/backend/golang',
   },
   {
-    from: '/quickstart/backend/aspnet-core-webapi/06-authorization-deprecated',
-    to: '/quickstart/backend/aspnet-core-webapi/06-authorization-legacy'
+    from: [
+      '/javaapi-tutorial',
+      '/quickstart/backend/java',
+      '/quickstart/backend/java-spring-security',
+      '/quickstart/backend/java-spring-security/00-getting-started',
+    ],
+    to: '/quickstart/backend/java-spring-security5',
   },
   {
-    from: '/quickstart/spa/react/03-user-profile',
-    to: '/quickstart/spa/react/04-user-profile'
+    from: ['/quickstart/webapp/java/getting-started', '/java-tutorial'],
+    to: '/quickstart/webapp/java',
   },
-
-  /* --- Two-step quickstarts to single-step quickstarts --- */
-
   {
     from: [
-      '/quickstart/hybrid',
-      '/quickstart/native-mobile'
+      '/quickstart/webapp/java-spring-mvc/getting-started',
+      '/quickstart/webapp/java-spring-mvc',
+      '/quickstart/webapp/java-spring-security-mvc/00-intro',
+      '/quickstart/webapp/java-spring-security-mvc',
     ],
-    to: '/quickstart/native'
+    to: '/quickstart/webapp/java-spring-boot',
   },
   {
     from: [
-      '/quickstart/hybrid/:platform',
-      '/quickstart/native-mobile/:platform',
-      `/quickstart/hybrid/:platform/${apis}`,
-      `/quickstart/native-mobile/:platform/${apis}`,
-      `/quickstart/native/:platform/${apis}`
+      '/quickstart/webapp/nodejs',
+      '/nodejs-tutorial',
+      '/server-platforms/nodejs',
+      '/quickstart/webapp/nodejs/02-user-profile',
+      '/quickstart/webapp/nodejs/01-login',
     ],
-    to: '/quickstart/native/:platform'
-  },
-  {
-    from: `/quickstart/spa/:platform/${apis}`,
-    to: '/quickstart/spa/:platform'
+    to: '/quickstart/webapp/express',
   },
   {
-    from: `/quickstart/backend/:platform/${apis}`,
-    to: '/quickstart/backend/:platform'
+    from: ['/quickstart/native/cordova'],
+    to: '/quickstart',
   },
 
-  /* --- Connections --- */
+  /* CONNECTIONS */
 
   {
-    from: '/37signals-clientid',
-    to: '/connections/social/37signals'
-  },
-  {
-    from: '/amazon-clientid',
-    to: '/connections/social/amazon'
+    from: ['/37signals-clientid', '/connections/social/37signals', '/connections/social/basecamp'],
+    to: 'https://marketplace.auth0.com/integrations/37signals-social-connection',
   },
   {
-    from: '/aol-clientid',
-    to: '/connections/social/aol'
+    from: ['/amazon-clientid', '/connections/social/amazon'],
+    to: 'https://marketplace.auth0.com/integrations/amazon-social-connection',
   },
   {
-    from: '/connections/enterprise/azure-active-directory',
-    to: '/connections/enterprise/azure-active-directory/v2'
+    from: [
+      '/connections/enterprise/azure-active-directory-classic',
+      '/connections/enterprise/azure-active-directory/v1',
+      '/connections/enterprise/azure-active-directory',
+      '/connections/social/active-directory',
+      '/waad-clientid',
+      '/users/guides/azure-access-control',
+      '/connections/enterprise/azure-active-directory/v2',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2',
   },
   {
-    from: '/connections/enterprise/azure-active-directory-classic',
-    to: '/connections/enterprise/azure-active-directory/v1'
+    from: ['/connections/enterprise/google-apps'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/google-apps',
   },
   {
-    from: '/dwolla-clientid',
-    to: '/connections/social/dwolla'
+    from: [
+      '/connections/enterprise/samlp',
+      '/connections/enterprise/saml',
+      '/connections/enterprise/sharepoint-online',
+      '/connections/enterprise/ws-fed',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/saml',
   },
   {
-    from: '/baidu-clientid',
-    to: '/connections/social/baidu'
+    from: ['/dwolla-clientid', '/connections/social/dwolla'],
+    to: 'https://marketplace.auth0.com/integrations/dwolla-social-connection',
   },
   {
-    from: '/box-clientid',
-    to: '/connections/social/box'
+    from: ['/baidu-clientid', '/connections/social/baidu'],
+    to: 'https://marketplace.auth0.com/integrations/baidu-social-connection',
   },
   {
-    from: '/evernote-clientid',
-    to: '/connections/social/evernote'
+    from: ['/box-clientid', '/connections/social/box'],
+    to: 'https://marketplace.auth0.com/integrations/box-social-connection',
   },
   {
-    from: '/exact-clientid',
-    to: '/connections/social/exact'
+    from: ['/evernote-clientid', '/connections/social/evernote'],
+    to: 'https://marketplace.auth0.com/integrations/evernote-social-connection',
   },
   {
-    from: '/facebook-clientid',
-    to: '/connections/social/facebook'
+    from: ['/exact-clientid', '/connections/social/exact'],
+    to: 'https://marketplace.auth0.com/integrations/exact-social-connection',
   },
   {
-    from: '/fitbit-clientid',
-    to: '/connections/social/fitbit'
+    from: ['/facebook-clientid', '/connections/social/facebook'],
+    to: 'https://marketplace.auth0.com/integrations/facebook-social-connection',
   },
   {
-    from: '/github-clientid',
-    to: '/connections/social/github'
+    from: ['/fitbit-clientid', '/connections/social/fitbit'],
+    to: 'https://marketplace.auth0.com/integrations/fitbit-social-connection',
   },
   {
-    from: '/goodreads-clientid',
-    to: '/connections/social/goodreads'
+    from: ['/github-clientid', '/connections/social/github'],
+    to: 'https://marketplace.auth0.com/integrations/github-social-connection',
   },
   {
-    from: '/goog-clientid',
-    to: '/connections/social/google'
+    from: ['/goog-clientid', '/connections/social/google'],
+    to: 'https://marketplace.auth0.com/integrations/google-social-connection',
   },
   {
-    from: '/miicard-clientid',
-    to: '/connections/social/miicard'
+    from: ['/ms-account-clientid', '/connections/social/microsoft-account'],
+    to: 'https://marketplace.auth0.com/integrations/microsoft-account-social-connection',
   },
   {
-    from: '/ms-account-clientid',
-    to: '/connections/social/microsoft-account'
+    from: [
+      '/protocols/oidc/identity-providers/okta',
+      '/protocols/configure-okta-as-oidc-identity-provider',
+      '/protocols/configure-okta-as-oauth2-identity-provider',
+      '/authorization/protocols/configure-okta-as-oauth2-identity-provider',
+      '/connections/social/configure-okta-as-oauth2-identity-provider',
+      '/authenticate/identity-providers/social-identity-providers/configure-okta-as-oauth2-identity-provider',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/okta',
   },
   {
-    from: '/o365-clientid',
-    to: '/connections/enterprise/o365-deprecated'
+    from: ['/connections/social/auth0-oidc', '/connections/enterprise/oidc'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/oidc',
   },
   {
-    from: '/oauth2',
-    to: '/connections/social/oauth2'
+    from: ['/connections/enterprise/okta'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/okta',
   },
   {
-    from: '/paypal-clientid',
-    to: '/connections/social/paypal'
+    from: ['/paypal-clientid', '/connections/social/paypal'],
+    to: 'https://marketplace.auth0.com/integrations/paypal-social-connection',
   },
   {
-    from: '/planningcenter-clientid',
-    to: '/connections/social/planning-center'
+    from: ['/planningcenter-clientid', '/connections/social/planning-center'],
+    to: 'https://marketplace.auth0.com/integrations/planningcenter-social-connection',
   },
   {
-    from: ['/salesforce-clientid', '/salesforce-community'],
-    to: '/connections/social/salesforce'
+    from: ['/salesforce-clientid', '/connections/social/salesforce'],
+    to: 'https://marketplace.auth0.com/integrations/salesforce-social-connection',
   },
   {
-    from: '/renren-clientid',
-    to: '/connections/social/renren'
+    from: ['/renren-clientid', '/connections/social/renren'],
+    to: 'https://marketplace.auth0.com/integrations/renren-social-connection',
   },
   {
-    from: '/sharepoint-clientid',
-    to: '/connections/enterprise/sharepoint-online'
+    from: ['/shopify-clientid', '/connections/social/shopify'],
+    to: 'https://marketplace.auth0.com/integrations/shopify-social-connection',
   },
   {
-    from: '/shopify-clientid',
-    to: '/connections/social/shopify'
+    from: ['/twitter-clientid', '/connections/social/twitter'],
+    to: 'https://marketplace.auth0.com/integrations/twitter-social-connection',
   },
   {
-    from: '/soundcloud-clientid',
-    to: '/connections/social/soundcloud'
+    from: ['/vkontakte-clientid', '/connections/social/vkontakte'],
+    to: 'https://marketplace.auth0.com/integrations/vkontakte-social-connection',
   },
   {
-    from: '/thecity-clientid',
-    to: '/connections/social/thecity'
+    from: ['/weibo-clientid', '/connections/social/weibo'],
+    to: 'https://marketplace.auth0.com/integrations/weibo-social-connection',
   },
   {
-    from: '/twitter-clientid',
-    to: '/connections/social/twitter'
+    from: ['/wordpress-clientid', '/connections/social/wordpress'],
+    to: 'https://marketplace.auth0.com/integrations/wordpress-social-connection',
   },
   {
-    from: '/vkontakte-clientid',
-    to: '/connections/social/vkontakte'
+    from: ['/yahoo-clientid', '/connections/social/yahoo'],
+    to: 'https://marketplace.auth0.com/integrations/yahoo-social-connection',
   },
   {
-    from: '/waad-clientid',
-    to: '/connections/enterprise/azure-active-directory'
+    from: ['/yandex-clientid', '/connections/social/yandex'],
+    to: 'https://marketplace.auth0.com/integrations/yandex-social-connection',
   },
   {
-    from: '/weibo-clientid',
-    to: '/connections/social/weibo'
+    from: ['/linkedin-clientid', '/connections/social/linkedin'],
+    to: 'https://marketplace.auth0.com/integrations/linkedin-social-connection',
   },
   {
-    from: '/wordpress-clientid',
-    to: '/connections/social/wordpress'
+    from: '/connections/social/bitbucket',
+    to: 'https://marketplace.auth0.com/integrations/bitbucket-social-connection',
   },
   {
-    from: '/yahoo-clientid',
-    to: '/connections/social/yahoo'
+    from: '/connections/social/digitalocean',
+    to: 'https://marketplace.auth0.com/integrations/digitalocean-social-connection',
   },
   {
-    from: '/yandex-clientid',
-    to: '/connections/social/yandex'
+    from: '/connections/social/discord',
+    to: 'https://marketplace.auth0.com/integrations/discord-social-connection',
   },
   {
-    from: '/instagram-clientid',
-    to: '/connections/social/instagram'
+    from: '/connections/social/docomo',
+    to: 'https://marketplace.auth0.com/integrations/daccount-social-connection',
   },
   {
-    from: '/linkedin-clientid',
-    to: '/connections/social/linkedin'
+    from: '/connections/social/dribbble',
+    to: 'https://marketplace.auth0.com/integrations/dribbble-social-connection',
   },
   {
-    from: '/mysql-connection-tutorial',
-    to: '/connections/database/mysql'
+    from: '/connections/social/dropbox',
+    to: 'https://marketplace.auth0.com/integrations/dropbox-social-connection',
   },
   {
-    from: '/migrating',
-    to: '/connections/database/migrating'
+    from: '/connections/social/evernote-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/evernote-sandbox-social-connection',
   },
   {
-    from: '/ad',
-    to: '/connections/enterprise/active-directory'
+    from: '/connections/social/figma',
+    to: 'https://marketplace.auth0.com/integrations/figma-social-connection',
   },
   {
-    from: '/adfs',
-    to: '/connections/enterprise/adfs'
+    from: '/connections/social/paypal-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/paypal-sandbox-social-connection',
   },
   {
-    from: '/passwordless',
-    to: '/connections/passwordless'
+    from: '/connections/social/quickbooks-online',
+    to: 'https://marketplace.auth0.com/integrations/quickbooks-social-connection',
   },
   {
-    from: '/connections/passwordless/ios-sms',
-    to: '/connections/passwordless/ios-sms-objc'
+    from: ['/salesforce-community', '/connections/social/salesforce-community'],
+    to: 'https://marketplace.auth0.com/integrations/salesforce-community-social-connection',
   },
-
-/* --- Clients --- */
-
   {
-    from: '/clients',
-    to: '/applications'
+    from: '/connections/social/salesforce-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/salesforce-sandbox-social-connection',
   },
   {
-    from: '/clients/addons',
-    to: '/applications/addons'
+    from: '/connections/social/slack',
+    to: 'https://marketplace.auth0.com/integrations/sign-in-with-slack',
   },
   {
-    from: '/clients/client-grant-types',
-    to: '/applications/application-grant-types'
+    from: '/connections/social/spotify',
+    to: 'https://marketplace.auth0.com/integrations/spotify-social-connection',
   },
   {
-    from: '/clients/client-types',
-    to: '/applications/application-types'
+    from: '/connections/social/stripe-connect',
+    to: 'https://marketplace.auth0.com/integrations/stripe-connect-social-connection',
   },
   {
-    from: '/clients/connections',
-    to: '/applications/connections'
+    from: '/connections/social/twitch',
+    to: 'https://marketplace.auth0.com/integrations/twitch-social-connection',
   },
   {
-    from: '/clients/enable-android-app-links',
-    to: '/applications/enable-android-app-links'
+    from: '/connections/social/vimeo',
+    to: 'https://marketplace.auth0.com/integrations/vimeo-social-connection',
   },
   {
-    from: '/clients/enable-universal-links',
-    to: '/applications/enable-universal-links'
+    from: '/connections/social/yammer',
+    to: 'https://marketplace.auth0.com/integrations/yammer-social-connection',
   },
   {
-    from: '/clients/how-to-rotate-client-secret',
-    to: '/applications/how-to-rotate-client-secret'
+    from: [
+      '/ad',
+      '/connections/enterprise/active-directory',
+      '/connections/enterprise/ldap',
+      '/connections/enterprise/active-directory-ldap',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap',
   },
   {
-    from: '/applications/how-to-rotate-application-secret',
-    to: '/applications/how-to-rotate-client-secret'
+    from: ['/adfs', '/connections/enterprise/adfs'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/adfs',
   },
   {
-    from: '/clients/client-settings',
-    to: '/applications/application-settings'
+    from: [
+      '/passwordless',
+      '/dashboard/guides/connections/set-up-connections-passwordless',
+      '/api-auth/passwordless',
+      '/connections/passwordless/ios',
+      '/connections/passwordless/native-passwordless-universal',
+      '/connections/passwordless/reference/troubleshoot',
+      '/connections/passwordless/faq',
+      '/connections/passwordless/spa-email-code',
+      '/connections/passwordless/spa-email-link',
+      '/connections/passwordless/spa-sms',
+      '/connections/passwordless/guides/',
+      '/connections/passwordless/ios-sms-objc',
+      '/connections/passwordless/ios-sms',
+      '/connections/passwordless',
+    ],
+    to: '/authenticate/passwordless',
   },
-
-  /* --- Scenarios to Tutorials --- */
-
   {
-    from: '/scenarios/amazon-cognito',
-    to: '/tutorials/integrating-auth0-amazon-cognito-mobile-apps'
+    from: [
+      '/connections/passwordless/guides/embedded-login',
+      '/connections/passwordless/embedded-login',
+      '/connections/passwordless/implement-login/embedded-login',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login',
   },
   {
-    from: '/scenarios/github',
-    to: '/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise'
+    from: ['/password-strength', '/connections/database/password-strength'],
+    to: '/authenticate/database-connections/password-strength',
   },
   {
-    from: ['/scenarios/keenio', '/scenarios-keenio'],
-    to: '/tutorials/sending-events-to-keenio'
+    from: [
+      '/identityproviders',
+      '/applications/concepts/connections',
+      '/applications/connections',
+      '/clients/connections',
+      '/connections',
+    ],
+    to: '/authenticate/identity-providers',
   },
   {
     from: [
-      '/scenarios-mixpanel-fullcontact-salesforce',
-      '/scenarios/mixpanel-fullcontact-salesforce'
+      '/connections/database/mysql',
+      '/mysql-connection-tutorial',
+      '/connections/database/custom-db/custom-db-connection-overview',
+      '/connections/database/custom-db',
     ],
-    to: '/tutorials/track-signups-enrich-user-profile-generate-leads'
+    to: '/authenticate/database-connections/custom-db',
   },
   {
-    from: ['/scenarios-mqtt', '/scenarios/mqtt'],
-    to: '/tutorials/authenticating-devices-using-mqtt'
+    from: ['/connections/database/password', '/connections/database/password-options'],
+    to: '/authenticate/database-connections/password-options',
   },
   {
-    from: ['/scenarios-rapleaf-salesforce', '/scenarios/rapleaf-salesforce'],
-    to: '/tutorials/tracking-new-leads-in-salesforce-and-raplead'
+    from: [
+      '/tutorials/adding-scopes-for-an-external-idp',
+      '/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp',
+      '/connections/adding-scopes-for-an-external-idp',
+    ],
+    to: '/authenticate/identity-providers/adding-scopes-for-an-external-idp',
   },
   {
-    from: ['/scenarios-segmentio', '/scenarios/segmentio'],
-    to: '/tutorials/sending-events-to-segmentio'
+    from: [
+      '/tutorials/calling-an-external-idp-api',
+      '/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api',
+      '/connections/calling-an-external-idp-api',
+    ],
+    to: '/authenticate/identity-providers/calling-an-external-idp-api',
   },
   {
-    from: '/scenarios/slack',
-    to: '/tutorials/integrating-with-slack'
+    from: [
+      '/tutorials/how-to-test-partner-connection',
+      '/test-partner-connection',
+      '/connections/how-to-test-partner-connection',
+      '/authenticate/identity-providers/how-to-test-partner-connection',
+      '/dashboard/guides/connections/test-connections-social',
+    ],
+    to: '/authenticate/identity-providers/test-connections',
   },
   {
-    from: ['/scenarios-splunk', '/scenarios/splunk'],
-    to: '/tutorials/sending-events-to-splunk'
+    from: '/connections/social/imgur',
+    to: 'https://marketplace.auth0.com/integrations/imgur-social-connection',
   },
   {
-    from: ['/scenarios-tessel', '/scenarios/tessel'],
-    to: '/tutorials/authenticating-a-tessel-device'
+    from: [
+      '/connections/grean/bankid-no',
+      '/connections/criipto/bankid-no',
+      '/connections/grean/bankid-se',
+      '/connections/criipto/bankid-se',
+      '/connections/grean/nemid',
+      '/connections/criipto/nemid',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/criipto-verify-e-id',
   },
   {
-    from: ['/scenarios-unbounce', '/scenarios/unbounce'],
-    to: '/tutorials/get-user-information-with-unbounce-landing-pages'
+    from: [
+      '/connections/passwordless/sms-gateway',
+      '/connections/passwordless/guides/use-sms-gateway-passwordless',
+      '/connections/passwordless/use-sms-gateway-passwordless',
+      '/connections/passwordless/authentication-methods/use-sms-gateway-passwordless',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/use-sms-gateway-passwordless',
   },
   {
-    from: '/scenarios',
-    to: '/tutorials'
+    from: [
+      '/connections/apple-setup',
+      '/connections/apple-siwa/set-up-apple',
+      '/connections/apple-siwa/add-siwa-web-app',
+      '/connections/apple-siwa/add-siwa-to-web-app',
+      '/connections/social/apple',
+      '/connections/apple-siwa/test-siwa-connection',
+      '/connections/apple-siwa/troubleshooting',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/apple-social-connection',
   },
-
-  /* --- Miscellaneous --- */
-
   {
-    from: '/widget',
-    to: '/login-widget2'
+    from: [
+      '/connections/apple-siwa/add-siwa-to-native-app',
+      '/connections/nativesocial/add-siwa-to-native-app',
+      '/connections/nativesocial/apple',
+      '/connections/social/apple-native',
+    ],
+    to: '/authenticate/identity-providers/social-identity-providers/apple-native',
   },
   {
-    from: '/adldap-auth',
-    to: '/connector/install'
+    from: [
+      '/connections/nativesocial/facebook-native',
+      '/connections/nativesocial/facebook',
+      '/connections/social/facebook-native',
+    ],
+    to: '/authenticate/identity-providers/social-identity-providers/facebook-native',
   },
   {
-    from: '/adldap-x',
-    to: '/connector/install-other-platforms'
+    from: [
+      '/connections/passwordless/email',
+      '/connections/passwordless/guides/email-otp',
+      '/connections/passwordless/email-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/email-otp',
   },
   {
-    from: '/sharepoint-apps',
-    to: '/integrations/sharepoint-apps'
+    from: [
+      '/connections/passwordless/sms',
+      '/connections/passwordless/guides/sms-otp',
+      '/connections/passwordless/sms-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/sms-otp',
   },
   {
-    from: '/auth0js',
-    to: '/libraries/auth0js'
+    from: [
+      '/connections/passwordless/spa',
+      '/connections/passwordless/guides/universal-login',
+      '/connections/passwordless/regular-web-app',
+      '/connections/passwordless/universal-login',
+      '/connections/passwordless/implement-login/universal-login',
+    ],
+    to: '/authenticate/passwordless/implement-login/universal-login',
   },
   {
-    from: '/aws',
-    to: '/integrations/aws'
+    from: [
+      '/connections/identity-providers-social',
+      '/connections/social/identityproviders',
+      '/connections/social/identity-providers',
+      '/connections/social/aol',
+      '/aol-clientid',
+      '/connections/social/thecity',
+      '/thecity-clientid',
+      '/connections/social/miicard',
+      '/miicard-clientid',
+      '/connections/nativesocial/',
+      '/connections/social',
+    ],
+    to: '/authenticate/identity-providers/social-identity-providers',
   },
   {
-    from: '/lock',
-    to: '/libraries/lock'
+    from: [
+      '/connections/identity-providers-enterprise',
+      '/connections/enterprise/identityproviders',
+      '/connections/enterprise/identity-providers',
+      '/connections/enterprise/sharepoint-apps',
+      '/sharepoint-clientid',
+      '/connections/enterprise',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers',
   },
   {
-    from: ['/okta', '/saml/identity-providers/okta'],
-    to: '/protocols/saml/identity-providers/okta'
+    from: ['/connections/identity-providers-legal', '/connections/legal'],
+    to: '/authenticate/identity-providers/legal',
   },
   {
-    from: ['/onelogin', '/saml/identity-providers/onelogin'],
-    to: '/protocols/saml/identity-providers/onelogin'
+    from: ['/line', '/connections/social/line'],
+    to: 'https://marketplace.auth0.com/integrations/line-social-connection',
   },
   {
-    from: ['/ping7', '/saml/identity-providers/ping7'],
-    to: '/protocols/saml/identity-providers/ping7'
+    from: [
+      '/connections/passwordless/concepts/sample-use-cases-rules',
+      '/connections/passwordless/sample-use-cases-rules',
+    ],
+    to: '/authenticate/passwordless/sample-use-cases-rules',
   },
   {
-    from: ['/siteminder', '/saml/identity-providers/siteminder'],
-    to: '/protocols/saml/identity-providers/siteminder'
+    from: ['/connections/azure-active-directory-native', '/connections/enterprise/azure-active-directory-native'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory-native',
   },
   {
-    from: '/ssocircle',
-    to: '/protocols/saml/identity-providers/ssocircle'
+    from: ['/connections/passwordless/authentication-factors', '/connections/passwordless/authentication-methods'],
+    to: '/authenticate/passwordless/authentication-methods',
   },
   {
-    from: '/wsfedwebapp-tutorial',
-    to: '/tutorials/wsfed-web-app'
+    from: [
+      '/connections/passwordless/email-otp',
+      '/connections/passwordless/email',
+      '/connections/passwordless/authentication-factors/email-otp',
+      '/connections/passwordless/authentication-methods/email-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/email-otp',
   },
   {
-    from: '/api',
-    to: '/api/info'
+    from: [
+      '/connections/passwordless/email-magic-link',
+      '/connections/passwordless/authentication-factors/email-magic-link',
+      '/connections/passwordless/authentication-methods/email-magic-link',
+      '/connections/passwordless/guides/email-magic-link',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/email-magic-link',
   },
   {
-    from: ['/auth-api', '/api/authentication/reference'],
-    to: '/api/authentication'
+    from: [
+      '/connections/passwordless/sms-otp',
+      '/connections/passwordless/sms',
+      '/connections/passwordless/authentication-factors/sms-otp',
+      '/connections/passwordless/authentication-methods/sms-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/sms-otp',
   },
   {
-    from: '/api/v1',
-    to: '/api/management/v1'
+    from: [
+      '/connections/passwordless/embedded-login-spa',
+      '/connections/passwordless/embedded-login/spa',
+      '/connections/passwordless/implement-login/embedded-login/spa',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login/spa',
   },
   {
-    from: ['/api-reference', '/api/v1/reference'],
-    to: '/api/management/v1/reference'
+    from: [
+      '/connections/passwordless/embedded-login-webapps',
+      '/connections/passwordless/embedded-login/webapps',
+      '/connections/passwordless/implement-login/embedded-login/webapps',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login/webapps',
   },
   {
-    from: '/api/v1/use-cases',
-    to: '/api/management/v1/use-cases'
+    from: [
+      '/connections/passwordless/embedded-login-native',
+      '/connections/passwordless/guides/embedded-login-native',
+      '/connections/passwordless/embedded-login/native',
+      '/connections/passwordless/implement-login/embedded-login/native',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login/native',
   },
   {
-    from: ['/apiv2', '/api/v2'],
-    to: '/api/management/v2'
+    from: [
+      '/connections/passwordless/relevant-api-endpoints',
+      '/connections/passwordless/embedded-login/relevant-api-endpoints',
+      '/connections/passwordless/implement-login/embedded-login/relevant-api-endpoints',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login/relevant-api-endpoints',
   },
   {
-    from: ['/apiv2Changes', '/api/v2/changes'],
-    to: '/api/management/v2/changes'
+    from: ['/connections/azuread-adfs-email-verification', '/connections/enterprise/azuread-adfs-email-verification'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification',
   },
   {
-    from: ['/tokens/apiv2', '/api/v2/tokens'],
-    to: '/api/management/v2/tokens'
+    from: ['/database/custom-db/templates/get-user', '/connections/database/custom-db/templates/get-user'],
+    to: '/authenticate/database-connections/custom-db/templates/get-user',
   },
   {
-    from: ['/metadata-in-rules', '/metadata/rules'],
-    to: '/rules/metadata-in-rules'
+    from: ['/connections/database/custom-db/templates/login'],
+    to: '/authenticate/database-connections/custom-db/templates/login',
   },
   {
-    from: [
-      '/mfa',
-      '/multi-factor-authentication',
-      '/multi-factor-authentication2',
-      '/multifactor-authentication/custom-provider'
-    ],
-    to: '/multifactor-authentication'
+    from: ['/connections/database'],
+    to: '/authenticate/database-connections',
   },
   {
-    from: '/multi-factor-authentication/yubikey',
-    to: '/multifactor-authentication/yubikey'
+    from: ['/connections/social/devkeys'],
+    to: '/authenticate/identity-providers/social-identity-providers/devkeys',
   },
   {
-    from: '/quickstart',
-    to: '/'
+    from: ['/connections/database/custom-db/overview-custom-db-connections'],
+    to: '/authenticate/database-connections/custom-db/overview-custom-db-connections',
   },
   {
-    from: '/link-accounts/user-initiated',
-    to: '/link-accounts/user-initiated-linking'
+    from: ['/connections/passwordless/best-practices'],
+    to: '/authenticate/passwordless/best-practices',
   },
   {
-    from: '/libraries/lock/using-refresh-tokens',
-    to: '/libraries/lock/using-a-refresh-token'
+    from: ['/connections/database/custom-db/templates'],
+    to: '/authenticate/database-connections/custom-db/templates',
   },
   {
-    from: '/premium-support',
-    to: '/support'
+    from: ['/connections/database/require-username'],
+    to: '/authenticate/database-connections/require-username',
   },
   {
-    from: '/password-strength',
-    to: '/connections/database/password-strength'
+    from: ['/connections/database/custom-db/create-db-connection'],
+    to: '/authenticate/database-connections/custom-db/create-db-connection',
   },
   {
-    from: '/users-search',
-    to: '/api/v2/user-search'
+    from: ['/connections/pass-parameters-to-idps'],
+    to: '/authenticate/identity-providers/pass-parameters-to-idps',
   },
   {
-    from: '/api/v2/user-search',
-    to: '/api/management/v2/user-search'
+    from: ['/connections/database/password-change'],
+    to: '/authenticate/database-connections/password-change',
   },
   {
-    from: [
-      '/appliance/checksum',
-      '/appliance/proxy-updater',
-      '/appliance/update',
-      '/updating-appliance'
-    ],
-    to: '/appliance'
+    from: ['/connections/pass-parameters-to-idps'],
+    to: '/authenticate/identity-providers/pass-parameters-to-idps',
   },
   {
-    from: '/enterprise-support',
-    to: '/onboarding/enterprise-support'
+    from: ['/connections/database/custom-db/error-handling'],
+    to: '/authenticate/database-connections/custom-db/error-handling',
   },
   {
-    from: '/extensions/azure-blog-storage',
-    to: '/extensions/azure-blob-storage'
+    from: [`/authenticate/database-connections/test-custom-db`],
+    to: `/authenticate/database-connections/custom-db/test-custom-database-connections`,
   },
+
+  /* MICROSITES */
   {
-    from: '/quickstart/backend/java',
-    to: '/quickstart/backend/java-spring-security',
-    status: 302
+    from: ['/microsites/call-api/call-api-m2m-app'],
+    to: '/get-started/authentication-and-authorization-flow/client-credentials-flow',
   },
   {
-    from: ['/rate-limits', '/policies/rate-limit'],
-    to: '/policies/rate-limits'
+    from: ['/microsites/add-login/add-login-native-mobile-app'],
+    to: '/quickstart/native',
   },
   {
-    from: '/i18n/password-strength',
-    to: '/i18n/password-options'
+    from: ['/microsites/add-login/add-login-regular-web-app'],
+    to: '/quickstart/webapp',
   },
   {
-    from: '/sso/single-sign-on',
-    to: '/sso'
+    from: ['/microsites/add-login/add-login-single-page-app'],
+    to: '/quickstart/spa',
   },
   {
-    from: '/libraries/lock/v10/installation',
-    to: '/libraries/lock',
-    status: 302
+    from: ['/microsites/call-api/call-api-device'],
+    to: '/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow',
   },
   {
-    from: '/libraries/lock/customization',
-    to: '/libraries/lock/v11/configuration',
-    status: 302
+    from: ['/microsites/call-api/call-api-native-mobile-app'],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce',
   },
   {
-    from: '/libraries/lock/display-modes',
-    to: '/libraries/lock/v11/customization#container-string-',
-    status: 302
+    from: ['/microsites/call-api/call-api-regular-web-app'],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow',
   },
   {
-    from: '/cancel-paid-subscriptions',
-    to: '/tutorials/cancel-paid-subscriptions'
+    from: ['/microsites/call-api/call-api-single-page-app'],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce',
   },
   {
-    from: '/pricing-per-app-per-connection',
-    to: '/tutorials/pricing-per-app-per-connection'
+    from: ['/microsites/manage-users/define-maintain-custom-user-data'],
+    to: '/manage-users/user-accounts/metadata',
   },
   {
-    from: '/local-testing-and-development',
-    to: '/tutorials/local-testing-and-development'
+    from: ['/microsites/manage-users/manage-users-and-user-profiles'],
+    to: '/manage-users/user-accounts/metadata',
   },
+
+  /* ARCHITECTURE SCENARIOS */
+
   {
-    from: '/moving-out',
-    to: '/tutorials/removing-auth0-exporting-data'
+    from: ['/architecture-scenarios'],
+    to: '/get-started/architecture-scenarios',
   },
   {
-    from: '/lifecycle',
-    to: '/tutorials/development-lifecycle-with-auth0'
+    from: ['/architecture-scenarios/application/mobile-api', '/architecture-scenarios/mobile-api'],
+    to: '/get-started/architecture-scenarios/mobile-api',
   },
   {
-    from: '/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp',
-    to: '/tutorials/adding-scopes-for-an-external-idp'
+    from: ['/architecture-scenarios/application/server-api', '/architecture-scenarios/server-api'],
+    to: '/get-started/architecture-scenarios/server-application-api',
   },
   {
-    from: '/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api',
-    to: '/tutorials/calling-an-external-idp-api'
+    from: [
+      '/architecture-scenarios/application/spa-api',
+      '/architecture-scenarios/sequence-diagrams',
+      '/sequence-diagrams',
+      '/architecture-scenarios/spa-api',
+    ],
+    to: '/get-started/architecture-scenarios/spa-api',
   },
   {
-    from: '/enable-simple-connection',
-    to: '/tutorials/enabling-a-connection'
+    from: ['/architecture-scenarios/spa-api/part-1'],
+    to: '/get-started/architecture-scenarios/spa-api/part-1',
   },
   {
-    from: '/oauth1',
-    to: '/tutorials/adding-generic-oauth1-connection'
+    from: ['/architecture-scenarios/spa-api/part-2'],
+    to: '/get-started/architecture-scenarios/spa-api/part-2',
   },
   {
-    from: '/oauth2-examples',
-    to: '/tutorials/generic-oauth2-connection-examples'
+    from: ['/architecture-scenarios/spa-api/part-3'],
+    to: '/get-started/architecture-scenarios/spa-api/part-3',
   },
   {
-    from: '/tutorials/setup-up-authentication',
-    to: '/multifactor-authentication/developer/step-up-with-acr'
+    from: ['/architecture-scenarios/application/web-app-sso', '/architecture-scenarios/web-app-sso'],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps',
   },
   {
-    from: ['/refresh-token', '/tokens/refresh_token'],
-    to: '/tokens/refresh-token'
+    from: ['/architecture-scenarios/business/b2b', '/architecture-scenarios/b2b'],
+    to: '/get-started/architecture-scenarios/business-to-business',
   },
   {
-    from: '/tokens/access_token',
-    to: '/tokens/access-token'
+    from: [
+      '/architecture-scenarios/b2b/b2b-architecture',
+      '/architecture-scenarios/implementation/b2b/b2b-architecture',
+      '/architecture-scenarios/b2b/architecture',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/architecture',
   },
   {
-    from: '/update-client-secret',
-    to: '/tutorials/how-to-update-applications-client-secret'
+    from: [
+      '/architecture-scenarios/b2b/b2b-authentication',
+      '/architecture-scenarios/implementation/b2b/b2b-authentication',
+      '/architecture-scenarios/b2b/authentication',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/authentication',
   },
   {
-    from: '/test-partner-connection',
-    to: '/tutorials/how-to-test-partner-connection'
+    from: [
+      '/architecture-scenarios/b2b/b2b-authorization',
+      '/architecture-scenarios/implementation/b2b/b2b-authorization',
+      '/architecture-scenarios/b2b/authorization',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/authorization',
   },
   {
-    from: '/bulk-import',
-    to: '/tutorials/bulk-importing-users-into-auth0'
+    from: [
+      '/architecture-scenarios/b2b/b2b-branding',
+      '/architecture-scenarios/implementation/b2b/b2b-branding',
+      '/architecture-scenarios/b2b/branding',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/branding',
   },
   {
-    from: '/creating-users',
-    to: '/tutorials/creating-users-in-the-management-portal'
+    from: [
+      '/architecture-scenarios/b2b/b2b-deployment',
+      '/architecture-scenarios/implementation/b2b/b2b-deployment',
+      '/architecture-scenarios/b2b/deployment',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/deployment',
   },
   {
-    from: ['/custom-signup', '/libraries/lock/v10/custom-signup', '/libraries/lock/v11/custom-signup'],
-    to: '/libraries/custom-signup'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch',
+      '/architecture-scenarios/implementation/b2b/b2b-launch',
+      '/architecture-scenarios/b2b/launch',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch',
   },
   {
-    from: '/google-admin-sdk',
-    to: '/tutorials/configuration-to-query-users-from-google-apps'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch-compliance',
+      '/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance',
+      '/architecture-scenarios/b2b/launch/compliance-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch/compliance-readiness',
   },
   {
-    from: '/invite-only',
-    to: '/tutorials/creating-invite-only-applications'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch-launch',
+      '/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch',
+      '/architecture-scenarios/b2b/launch/launch-day',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch/launch-day',
   },
   {
-    from: '/saas-apps',
-    to: '/tutorials/using-auth0-with-multi-tenant-apps'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch-operations',
+      '/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations',
+      '/architecture-scenarios/b2b/launch/operations-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch/operations-readiness',
   },
   {
-    from: '/sla',
-    to: '/support/sla'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch-support',
+      '/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support',
+      '/architecture-scenarios/b2b/launch/support-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch/support-readiness',
   },
   {
-    from: '/versioning',
-    to: '/tutorials/how-auth0-versions-software'
+    from: [
+      '/architecture-scenarios/b2b/b2b-launch-testing',
+      '/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing',
+      '/architecture-scenarios/b2b/launch/testing',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/launch/testing',
   },
   {
-    from: '/oidc-rs256-owin',
-    to: '/tutorials/openid-connect-discovery'
+    from: [
+      '/architecture-scenarios/b2b/b2b-logout',
+      '/architecture-scenarios/implementation/b2b/b2b-logout',
+      '/architecture-scenarios/b2b/logout',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/logout',
   },
   {
-    from: '/cli',
-    to: '/tutorials/using-auth0-to-secure-a-cli'
+    from: [
+      '/architecture-scenarios/b2b/b2b-operations',
+      '/architecture-scenarios/implementation/b2b/b2b-operations',
+      '/architecture-scenarios/b2b/operations',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/operations',
   },
   {
-    from: '/tutorials/using-auth0-to-secure-an-api',
-    to: '/tutorials/using-auth0-to-secure-a-cli'
+    from: [
+      '/architecture-scenarios/b2b/b2b-profile-mgmt',
+      '/architecture-scenarios/implementation/b2b/b2b-profile-mgmt',
+      '/architecture-scenarios/b2b/profile-management',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/profile-management',
   },
   {
-    from: '/apps-apis',
-    to: '/tutorials/web-apps-vs-web-apis-cookies-vs-tokens'
+    from: [
+      '/architecture-scenarios/b2b/b2b-provisioning',
+      '/architecture-scenarios/implementation/b2b/b2b-provisioning',
+      '/architecture-scenarios/b2b/provisioning',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/provisioning',
   },
   {
-    from: ['/har', '/tutorials/troubleshootings-with-har-files'],
-    to: '/tutorials/troubleshooting-with-har-files'
+    from: [
+      '/architecture-scenarios/b2b/b2b-qa',
+      '/architecture-scenarios/implementation/b2b/b2b-qa',
+      '/architecture-scenarios/b2b/quality-assurance',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-business/quality-assurance',
   },
   {
-    from: '/hrd',
-    to: '/libraries/lock/v11/selecting-the-connection-for-multiple-logins'
+    from: ['/architecture-scenarios/business/b2c', '/architecture-scenarios/b2c'],
+    to: '/get-started/architecture-scenarios/business-to-consumer',
   },
   {
-    from: '/blacklist-attributes',
-    to: '/tutorials/blacklisting-attributes'
+    from: [
+      '/architecture-scenarios/b2c/b2c-architecture',
+      '/architecture-scenarios/implementation/b2c/b2c-architecture',
+      '/architecture-scenarios/b2c/architecture',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/architecture',
   },
   {
-    from: '/brute-force-protection',
-    to: '/anomaly-detection/brute-force-protection'
+    from: [
+      '/architecture-scenarios/b2c/b2c-authentication',
+      '/architecture-scenarios/implementation/b2c/b2c-authentication',
+      '/architecture-scenarios/b2c/authentication',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/authentication',
   },
   {
-    from: '/breached-password',
-    to: '/anomaly-detection/breached-passwords'
+    from: [
+      '/architecture-scenarios/b2c/b2c-authorization',
+      '/architecture-scenarios/implementation/b2c/b2c-authorization',
+      '/architecture-scenarios/b2c/authorization',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/authorization',
   },
   {
-    from: '/office365-deprecated',
-    to: '/tutorials/office365-connection-deprecation-guide'
+    from: [
+      '/architecture-scenarios/b2c/b2c-branding',
+      '/architecture-scenarios/implementation/b2c/b2c-branding',
+      '/architecture-scenarios/b2c/branding',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/branding',
   },
   {
-    from: '/sequence-diagrams',
-    to: '/architecture-scenarios/application/spa-api'
+    from: [
+      '/architecture-scenarios/b2c/b2c-deployment',
+      '/architecture-scenarios/implementation/b2c/b2c-deployment',
+      '/architecture-scenarios/b2c/deployment',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/deployment',
   },
   {
-    from: '/architecture-scenarios/sequence-diagrams',
-    'to:': '/architecture-scenarios/application/spa-api'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch',
+      '/architecture-scenarios/implementation/b2c/b2c-launch',
+      '/architecture-scenarios/b2c/launch',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch',
   },
   {
-    from: '/deployment',
-    to: '/overview/deployment-models'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch-compliance',
+      '/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance',
+      '/architecture-scenarios/b2c/launch/compliance-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch/compliance-readiness',
   },
   {
-    from: '/overview',
-    to: '/getting-started/overview'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch-launch',
+      '/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch',
+      '/architecture-scenarios/b2c/launch/launch-day',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch/launch-day',
   },
   {
-    from: '/overview/apis',
-    to: '/api-auth/apis'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch-operations',
+      '/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations',
+      '/architecture-scenarios/b2c/launch/operations-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch/operations-readiness',
   },
-
   {
-    from: '/overview/deployment-models',
-    to: '/getting-started/deployment-models'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch-support',
+      '/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support',
+      '/architecture-scenarios/b2c/launch/support-readiness',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch/support-readiness',
   },
   {
-    from: '/java-overview',
-    to: '/dev-centers/java'
+    from: [
+      '/architecture-scenarios/b2c/b2c-launch-testing',
+      '/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing',
+      '/architecture-scenarios/b2c/launch/testing',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch/testing',
   },
   {
-    from: ['/oauth-web-protocol', '/protocols/oauth-web-protocol', '/protocols/oauth2/oauth-web-protocol'],
-    to: '/client-auth/current/server-side-web'
+    from: [
+      '/architecture-scenarios/b2c/b2c-logout',
+      '/architecture-scenarios/implementation/b2c/b2c-logout',
+      '/architecture-scenarios/b2c/logout',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/logout',
   },
   {
-    from: '/oauth-implicit-protocol',
-    to: '/protocols/oauth2/oauth-implicit-protocol'
+    from: [
+      '/architecture-scenarios/b2c/b2c-operations',
+      '/architecture-scenarios/implementation/b2c/b2c-operations',
+      '/architecture-scenarios/b2c/operations',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/operations',
   },
   {
-    from: '/protocols/oauth-state',
-    to: '/protocols/oauth2/oauth-state'
+    from: [
+      '/architecture-scenarios/b2c/b2c-profile-mgmt',
+      '/architecture-scenarios/implementation/b2c/b2c-profile-mgmt',
+      '/architecture-scenarios/b2c/profile-management',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/profile-management',
   },
   {
-    from: '/metadata/apiv2',
-    to: '/metadata/management-api'
+    from: [
+      '/architecture-scenarios/b2c/b2c-provisioning',
+      '/architecture-scenarios/implementation/b2c/b2c-provisioning',
+      '/architecture-scenarios/b2c/provisioning',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/provisioning',
   },
   {
-    from: '/saml-apps',
-    to: '/protocols/saml/saml-apps'
+    from: [
+      '/architecture-scenarios/b2c/b2c-qa',
+      '/architecture-scenarios/implementation/b2c/b2c-qa',
+      '/architecture-scenarios/b2c/quality-assurance',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/quality-assurance',
   },
   {
-    from: '/saml-configuration',
-    to: '/protocols/saml/saml-configuration'
+    from: ['/architecture-scenarios/business/b2e', '/architecture-scenarios/b2e'],
+    to: '/get-started/architecture-scenarios/b2e',
   },
   {
-    from: '/saml-idp-generic',
-    to: '/protocols/saml/saml-idp-generic'
+    from: [
+      '/architecture-scenarios/application/mobile-api/api-implementation-nodejs',
+      '/architecture-scenarios/mobile-api/api-implementation-nodejs',
+    ],
+    to: '/get-started/architecture-scenarios/mobile-api/api-implementation-nodejs',
   },
   {
-    from: '/saml-sp-generic',
-    to: '/protocols/saml/saml-sp-generic'
+    from: [
+      '/architecture-scenarios/application/mobile-api/mobile-implementation-android',
+      '/architecture-scenarios/mobile-api/mobile-implementation-android',
+    ],
+    to: '/get-started/architecture-scenarios/mobile-api/mobile-implementation-android',
   },
   {
-    from: '/saml2webapp-tutorial',
-    to: '/protocols/saml/saml2webapp-tutorial'
+    from: ['/architecture-scenarios/mobile-api/part-1'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-1',
   },
   {
-    from: '/samlp-providers',
-    to: '/protocols/saml/samlp-providers'
+    from: ['/architecture-scenarios/mobile-api/part-2'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-2',
   },
   {
-    from: '/samlp',
-    to: '/protocols/saml/samlp'
+    from: ['/architecture-scenarios/mobile-api/part-3'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-3',
   },
   {
-    from: '/samlsso-auth0-to-auth0',
-    to: '/protocols/saml/samlsso-auth0-to-auth0'
+    from: [
+      '/architecture-scenarios/application/server-api/api-implementation-nodejs',
+      '/architecture-scenarios/server-api/api-implementation-nodejs',
+    ],
+    to: '/get-started/architecture-scenarios/server-application-api/api-implementation-nodejs',
   },
   {
-    from: ['/error-pages', '/error-pages/generic'],
-    to: '/hosted-pages/error-pages'
+    from: [
+      '/architecture-scenarios/application/server-api/cron-implementation-python',
+      '/architecture-scenarios/server-api/cron-implementation-python',
+    ],
+    to: '/get-started/architecture-scenarios/server-application-api/cron-implementation-python',
   },
   {
-    from: '/error-pages/custom',
-    to: '/hosted-pages/custom-error-pages'
+    from: ['/architecture-scenarios/server-api/part-1'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-1',
   },
   {
-    from: '/saml/identity-providers/salesforce',
-    to: '/protocols/saml/identity-providers/salesforce'
+    from: ['/architecture-scenarios/server-api/part-2'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-2',
   },
   {
-    from: '/saml-apps/cisco-webex',
-    to: '/protocols/saml/saml-apps/cisco-webex'
+    from: ['/architecture-scenarios/server-api/part-3'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-3',
   },
   {
-    from: '/saml-apps/datadog',
-    to: '/protocols/saml/saml-apps/datadog'
+    from: [
+      '/architecture-scenarios/application/spa-api/spa-implementation-angular2',
+      '/architecture-scenarios/spa-api/spa-implementation-angular2',
+    ],
+    to: '/get-started/architecture-scenarios/spa-api/spa-implementation-angular2',
   },
   {
-    from: '/saml-apps/freshdesk',
-    to: '/protocols/saml/saml-apps/freshdesk'
+    from: [
+      '/architecture-scenarios/application/spa-api/api-implementation-nodejs',
+      '/architecture-scenarios/spa-api/api-implementation-nodejs',
+    ],
+    to: '/get-started/architecture-scenarios/spa-api/api-implementation-nodejs',
+  },
+  {
+    from: [
+      '/architecture-scenarios/application/web-app-sso/implementation-aspnetcore',
+      '/architecture-scenarios/web-app-sso/implementation-aspnetcore',
+    ],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore',
+  },
+  {
+    from: ['/architecture-scenarios/web-app-sso/part-1'],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1',
+  },
+  {
+    from: ['/architecture-scenarios/web-app-sso/part-2'],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2',
+  },
+  {
+    from: ['/architecture-scenarios/web-app-sso/part-3'],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/provisioning',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/provisioning',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/provisioning',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/provisioning',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authentication',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/authentication',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/authentication',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authentication',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/branding',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/branding',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/authorization',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/authorization',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/profile-management',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/profile-management',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/logout',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/single-identity-provider-organizations/logout',
+      '/architecture-scenarios/multiple-organization-architecture/single-idp-orgs/logout',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/logout',
+  },
+  {
+    from: [
+      '/architecture-scenarios/multiple-organization-architecture/multiple-identity-provider-organizations',
+      '/architecture-scenarios/multiple-organization-architecture/users-isolated-by-organization/multiple-identity-provider-organizations',
+      '/architecture-scenarios/multiple-organization-architecture/multiple-idp-orgs',
+    ],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture/multiple-idp-orgs',
+  },
+  {
+    from: ['/architecture-scenarios/multiple-organization-architecture'],
+    to: '/get-started/architecture-scenarios/multiple-organization-architecture',
+  },
+  {
+    from: ['/architecture-scenarios/checklists'],
+    to: '/get-started/architecture-scenarios/checklists',
+  },
+  {
+    from: ['/architecture-scenarios/implementation-resources'],
+    to: '/get-started/architecture-scenarios/implementation-resources',
+  },
+
+  /* CONTENTFUL REDIRECTS */
+
+  /* Tenants */
+
+  {
+    from: [
+      '/dashboard/tenant-settings',
+      '/get-started/dashboard/tenant-settings',
+      '/best-practices/tenant-settings-best-practices',
+      '/best-practices/tenant-settings',
+      '/dashboard/reference/settings-tenant',
+      '/tutorials/dashboard-tenant-settings',
+      '/dashboard-account-settings',
+      '/dashboard/dashboard-tenant-settings',
+      '/config/tenant-settings',
+      '/configure/tenant-settings',
+    ],
+    to: '/get-started/tenant-settings',
+  },
+  {
+    from: [
+      '/tokens/manage-signing-keys',
+      '/tokens/guides/manage-signing-keys',
+      '/config/tenant-settings/signing-keys',
+      '/configure/tenant-settings/signing-keys',
+    ],
+    to: '/get-started/tenant-settings/signing-keys',
+  },
+  {
+    from: [
+      '/config/tenant-settings/signing-keys/rotate-signing-keys',
+      '/configure/tenant-settings/signing-keys/rotate-signing-keys',
+    ],
+    to: '/get-started/tenant-settings/signing-keys/rotate-signing-keys',
+  },
+  {
+    from: [
+      '/config/tenant-settings/signing-keys/revoke-signing-keys',
+      '/configure/tenant-settings/signing-keys/revoke-signing-keys',
+    ],
+    to: '/get-started/tenant-settings/signing-keys/revoke-signing-keys',
+  },
+  {
+    from: [
+      '/config/tenant-settings/signing-keys/view-signing-certificates',
+      '/configure/tenant-settings/signing-keys/view-signing-certificates',
+    ],
+    to: '/get-started/tenant-settings/signing-keys/view-signing-certificates',
+  },
+  {
+    from: [
+      '/get-started/dashboard/configure-device-user-code-settings',
+      '/dashboard/guides/tenants/configure-device-user-code-settings',
+      '/config/tenant-settings/configure-device-user-code-settings',
+      '/configure/tenant-settings/configure-device-user-code-settings',
+    ],
+    to: '/get-started/tenant-settings/configure-device-user-code-settings',
+  },
+  {
+    from: [
+      '/get-started/dashboard/enable-sso-for-legacy-tenants',
+      '/dashboard/guides/tenants/enable-sso-tenant',
+      '/configure/tenant-settings/enable-sso-for-legacy-tenants',
+    ],
+    to: '/get-started/tenant-settings/enable-sso-for-legacy-tenants',
+  },
+
+  /* Applications */
+
+  {
+    from: [
+      '/applications',
+      '/application',
+      '/applications/concepts/app-types-auth0',
+      '/clients',
+      '/api-auth/tutorials/adoption/oidc-conformant',
+      '/api-auth/client-types',
+      '/clients/client-types',
+      '/applications/application-types',
+      '/applications/concepts/client-secret',
+      '/configure/applications',
+    ],
+    to: '/get-started/applications',
+  },
+  {
+    from: [
+      '/clients/client-settings',
+      '/dashboard/reference/settings-application',
+      '/get-started/dashboard/application-settings',
+      '/best-practices/application-settings',
+      '/best-practices/app-settings-best-practices',
+      '/applications/application-settings',
+      '/configure/applications/application-settings',
+    ],
+    to: '/get-started/applications/application-settings',
+  },
+  {
+    from: [
+      '/applications/dynamic-client-registration',
+      '/api-auth/dynamic-client-registration',
+      '/api-auth/dynamic-application-registration',
+      '/configure/applications/dynamic-client-registration',
+    ],
+    to: '/get-started/applications/dynamic-client-registration',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/enable-android-app-links',
+      '/clients/enable-android-app-links',
+      '/applications/enable-android-app-links',
+      '/applications/guides/enable-android-app-links-dashboard',
+      '/applications/enable-android-app-links-support',
+      '/configure/applications/enable-android-app-links-support',
+    ],
+    to: '/get-started/applications/enable-android-app-links-support',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/enable-universal-links',
+      '/clients/enable-universal-links',
+      '/applications/enable-universal-links',
+      '/applications/guides/enable-universal-links-dashboard',
+      '/enable-universal-links-support-in-apple-xcode',
+      '/applications/enable-universal-links-support-in-apple-xcode',
+      '/configure/applications/enable-universal-links-support-in-apple-xcode',
+    ],
+    to: '/get-started/applications/enable-universal-links-support-in-apple-xcode',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/enable-sso-app',
+      '/sso/enable-sso-for-applications',
+      '/configure/applications/enable-sso-for-applications',
+    ],
+    to: '/get-started/applications/enable-sso-for-applications',
+  },
+  {
+    from: ['/applications/configure-application-metadata', '/configure/applications/configure-application-metadata'],
+    to: '/get-started/applications/configure-application-metadata',
+  },
+  {
+    from: [
+      '/applications/reference/grant-types-available',
+      '/applications/reference/grant-types-auth0-mapping',
+      '/clients/client-grant-types',
+      '/applications/concepts/application-grant-types',
+      '/applications/concepts/grant-types-legacy',
+      '/applications/application-grant-types',
+      '/configure/applications/application-grant-types',
+    ],
+    to: '/get-started/applications/application-grant-types',
+  },
+  {
+    from: ['/get-started/applications/how-to-rotate-application-secret'],
+    to: '/get-started/applications/rotate-client-secret',
+  },
+  {
+    from: [
+      '/api-auth/config/using-the-auth0-dashboard',
+      '/api-auth/config/using-the-management-api',
+      '/api/management/guides/applications/update-grant-types',
+      '/dashboard/guides/applications/update-grant-types',
+      '/applications/update-grant-types',
+      '/configure/applications/update-grant-types',
+    ],
+    to: '/get-started/applications/update-grant-types',
+  },
+  {
+    from: [
+      '/authorization/revoke-access-to-apis-using-blacklists-or-application-grants',
+      '/api-auth/blacklists-vs-grants',
+      '/blacklists-vs-application-grants',
+      '/authorization/revoke-api-access',
+      '/configure/applications/revoke-api-access',
+    ],
+    to: '/get-started/applications/revoke-api-access',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/rotate-client-secret',
+      '/api/management/guides/applications/rotate-client-secret',
+      '/get-started/dashboard/rotate-client-secret',
+      '/applications/rotate-client-secret',
+      '/configure/applications/rotate-client-secret',
+      '/applications/how-to-rotate-application-secret',
+    ],
+    to: '/get-started/applications/rotate-client-secret',
+  },
+  {
+    from: [
+      '/tokens/signing-algorithms',
+      '/applications/concepts/signing-algorithms',
+      '/tokens/concepts/signing-algorithms',
+      '/configure/applications/signing-algorithms',
+    ],
+    to: '/get-started/applications/signing-algorithms',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/update-signing-algorithm',
+      '/tokens/guides/update-signing-algorithm-application',
+      '/applications/change-application-signing-algorithms',
+      '/configure/applications/change-application-signing-algorithms',
+    ],
+    to: '/get-started/applications/change-application-signing-algorithms',
+  },
+  {
+    from: [
+      '/applications/set-up-cors',
+      '/dashboard/guides/applications/set-up-cors',
+      '/configure/applications/set-up-cors',
+    ],
+    to: '/get-started/applications/set-up-cors',
+  },
+  {
+    from: [
+      '/tutorials/openid-connect-discovery',
+      '/protocols/oidc/openid-connect-discovery',
+      '/oidc-rs256-owin',
+      '/protocols/configure-applications-with-oidc-discovery',
+      '/configure/applications/configure-applications-with-oidc-discovery',
+    ],
+    to: '/get-started/applications/configure-applications-with-oidc-discovery',
+  },
+  {
+    from: [
+      '/protocols/configure-ws-fed-applications',
+      '/integrations/configure-wsfed-application',
+      '/tutorials/configure-wsfed-application',
+      '/configure/applications/configure-ws-fed-applications',
+    ],
+    to: '/get-started/applications/update-application-connections',
+  },
+  {
+    from: ['/get-started/applications/configure-mtls/set-up-resource-server-for-token-binding'],
+    to: '/get-started/applications/configure-sender-constraining/configure-resource-server-for-sender-constraining',
+  },
+  {
+    from: [
+      '/applications/update-application-connections',
+      '/dashboard/guides/applications/update-app-connections',
+      '/configure/applications/update-application-connections',
+    ],
+    to: '/get-started/applications/update-application-connections',
+  },
+  {
+    from: [
+      '/applications/concepts/app-types-confidential-public',
+      '/applications/confidential-and-public-applications',
+      '/configure/applications/confidential-public-apps',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/view-app-type-confidential-public',
+      '/applications/view-application-type',
+      '/configure/applications/confidential-public-apps/view-application-type',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/view-application-type',
+  },
+  {
+    from: [
+      '/applications/first-party-and-third-party-applications',
+      '/applications/concepts/app-types-first-third-party',
+      '/configure/applications/confidential-public-apps/first-party-and-third-party-applications',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/first-party-and-third-party-applications',
+  },
+  {
+    from: [
+      '/applications/view-application-ownership',
+      '/api/management/guides/applications/view-ownership',
+      '/configure/applications/confidential-public-apps/view-application-ownership',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/view-application-ownership',
+  },
+  {
+    from: [
+      '/api/management/guides/applications/update-ownership',
+      '/api/management/guides/applications/remove-app',
+      '/applications/update-application-ownership',
+      '/configure/applications/confidential-public-apps/update-application-ownership',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/update-application-ownership',
+  },
+  {
+    from: [
+      '/applications/guides/enable-third-party-applications',
+      '/applications/guides/enable-third-party-apps',
+      '/applications/enable-third-party-applications',
+      '/configure/applications/confidential-public-apps/enable-third-party-applications',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/enable-third-party-applications',
+  },
+  {
+    from: [
+      '/api-auth/user-consent',
+      '/authorization/user-consent-and-third-party-applications',
+      '/configure/applications/confidential-public-apps/user-consent-and-third-party-applications',
+    ],
+    to: '/get-started/applications/confidential-and-public-applications/user-consent-and-third-party-applications',
+  },
+  {
+    from: [
+      '/applications/wildcards-for-subdomains',
+      '/applications/reference/wildcard-subdomains',
+      '/configure/applications/wildcards-for-subdomains',
+    ],
+    to: '/get-started/applications/wildcards-for-subdomains',
+  },
+  {
+    from: [
+      '/applications/remove-applications',
+      '/dashboard/guides/applications/remove-app',
+      '/configure/applications/remove-applications',
+    ],
+    to: '/get-started/applications/remove-applications',
+  },
+  {
+    from: [
+      '/dev-lifecycle/work-with-auth0-locally',
+      '/dev-lifecycle/local-testing-and-development',
+      '/applications/work-with-auth0-locally',
+      '/configure/applications/work-with-auth0-locally',
+    ],
+    to: '/get-started/applications/work-with-auth0-locally',
+  },
+  {
+    from: [
+      '/applications/set-up-database-connections',
+      '/dashboard/guides/connections/set-up-connections-database',
+      '/configure/applications/set-up-database-connections',
+    ],
+    to: '/get-started/applications/set-up-database-connections',
+  },
+  {
+    from: [
+      '/get-started/dashboard/test-database-connections',
+      '/dashboard/guides/connections/test-connections-database',
+      '/configure/applications/test-database-connections',
+    ],
+    to: '/get-started/applications/test-database-connections',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams'],
+    to: '/get-started/auth0-teams',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams/tenant-management'],
+    to: '/get-started/auth0-teams/tenant-management',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams/team-member-management'],
+    to: '/get-started/auth0-teams/team-member-management',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams/tenant-member-management'],
+    to: '/get-started/auth0-teams/tenant-member-management',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams/configure-security-policies'],
+    to: '/get-started/auth0-teams/configure-security-policies',
+  },
+  {
+    from: ['/get-started/tenant-settings/auth0-teams/troubleshoot-teams'],
+    to: '/get-started/auth0-teams/troubleshoot-teams',
+  },
+
+  /* APIs */
+
+  {
+    from: ['/authorization/apis', '/api-auth/apis', '/overview/apis', '/apis', '/configure/apis'],
+    to: '/get-started/apis',
+  },
+  {
+    from: [
+      '/api-auth/references/dashboard/api-settings',
+      '/dashboard/reference/settings-api',
+      '/get-started/dashboard/api-settings',
+      '/config/api-settings',
+      '/configure/apis/api-settings',
+    ],
+    to: '/get-started/apis/api-settings',
+  },
+  {
+    from: [
+      '/dashboard/guides/apis/add-permissions-apis',
+      '/api/management/guides/apis/update-permissions-apis',
+      '/scopes/current/guides/define-scopes-using-dashboard',
+      '/scopes/current/guides/define-api-scope-dashboard',
+      '/get-started/dashboard/add-api-permissions',
+      '/config/api-settings/add-api-permissions',
+      '/configure/apis/add-api-permissions',
+    ],
+    to: '/get-started/apis/add-api-permissions',
+  },
+  {
+    from: [
+      '/dashboard/guides/apis/delete-permissions-apis',
+      '/get-started/dashboard/delete-api-permissions',
+      '/config/api-settings/delete-api-permissions',
+      '/configure/apis/delete-api-permissions',
+    ],
+    to: '/get-started/apis/delete-api-permissions',
+  },
+  {
+    from: ['/scopes', '/scopes/current', '/scopes/legacy', '/scopes/preview', '/configure/apis/scopes'],
+    to: '/get-started/apis/scopes',
+  },
+  {
+    from: ['/scopes/api-scopes', '/scopes/current/api-scopes', '/configure/apis/scopes/api-scopes'],
+    to: '/get-started/apis/scopes/api-scopes',
+  },
+  {
+    from: [
+      '/scopes/current/oidc-scopes',
+      '/api-auth/tutorials/adoption/scope-custom-claims',
+      '/scopes/oidc-scopes',
+      '/scopes/openid-connect-scopes',
+      '/configure/apis/scopes/openid-connect-scopes',
+    ],
+    to: '/get-started/apis/scopes/openid-connect-scopes',
+  },
+  {
+    from: [
+      '/scopes/sample-use-cases-scopes-and-claims',
+      '/scopes/current/sample-use-cases',
+      '/configure/apis/scopes/sample-use-cases-scopes-and-claims',
+    ],
+    to: '/get-started/apis/scopes/sample-use-cases-scopes-and-claims',
+  },
+  {
+    from: [
+      '/authorization/set-logical-api',
+      '/authorization/represent-multiple-apis-using-a-single-logical-api',
+      '/api-auth/tutorials/represent-multiple-apis',
+      '/configure/apis/set-logical-api',
+    ],
+    to: '/get-started/apis/set-logical-api',
+  },
+  {
+    from: [
+      '/api/management/guides/apis/enable-rbac',
+      '/dashboard/guides/apis/enable-rbac',
+      '/authorization/guides/dashboard/enable-rbac',
+      '/authorization/rbac/enable-role-based-access-control-for-apis',
+      '/authorization/auth-core-features/enable-role-based-access-control-for-apis',
+      '/configure/apis/enable-role-based-access-control-for-apis',
+    ],
+    to: '/get-started/apis/enable-role-based-access-control-for-apis',
+  },
+  {
+    from: [
+      '/config/api-settings/create-m2m-app-test',
+      '/api/management/v2/create-m2m-app',
+      '/tokens/management-api-access-tokens/create-and-authorize-a-machine-to-machine-application',
+      '/configure/apis/create-m2m-app-test',
+    ],
+    to: '/get-started/apis/create-m2m-app-test',
+  },
+    {
+    from: [
+      '/api/management/v2/blacklists/get-tokens',
+      '/api/management/v2/blacklists/post-tokens',
+    ],
+    to: '/api/management/v2',
+  },
+
+  /* Single Sign-On */
+
+  {
+    from: [
+      '/api-auth/tutorials/adoption/single-sign-on',
+      '/sso/legacy',
+      '/sso/legacy/single-page-apps',
+      '/sso/legacy/regular-web-apps-sso',
+      '/sso/legacy/single-page-apps-sso',
+      '/sso/current/single-page-apps-sso',
+      '/sso/current/single-page-apps',
+      '/sso/current/sso-auth0',
+      '/sso/current/introduction',
+      '/sso/single-sign-on',
+      '/sso/current',
+      '/sso/current/setup',
+      '/sso/current/index_old',
+      '/sso',
+      '/configure/sso',
+    ],
+    to: '/authenticate/single-sign-on',
+  },
+  {
+    from: ['/sso/inbound-single-sign-on', '/sso/current/inbound', '/configure/sso/inbound-single-sign-on'],
+    to: '/authenticate/single-sign-on/inbound-single-sign-on',
+  },
+  {
+    from: ['/sso/outbound-single-sign-on', '/sso/current/outbound', '/configure/sso/outbound-single-sign-on'],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on',
+  },
+  {
+    from: [
+      '/single-sign-on/api-endpoints-for-single-sign-on',
+      '/sso/current/relevant-api-endpoints',
+      '/sso/api-endpoints-for-single-sign-on',
+      '/configure/sso/api-endpoints-for-single-sign-on',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on',
+  },
+
+  /* SAML */
+
+  {
+    from: [
+      '/saml-apps',
+      '/protocols/saml/identity-providers',
+      '/samlp-providers',
+      '/protocols/saml/samlp-providers',
+      '/protocols/saml',
+      '/protocols/saml-protocol',
+      '/configure/saml-protocol',
+      '/config/saml-protocol',
+      '/protocols/saml/saml-apps',
+      '/protocols/saml/saml-configuration/supported-options-and-bindings',
+      '/protocols/saml/saml-configuration/design-considerations',
+      '/protocols/saml/saml-configuration',
+      '/saml-configuration',
+      '/config/saml-configuration',
+      '/configure/saml-configuration',
+    ],
+    to: '/authenticate/protocols/saml/saml-configuration',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options',
+      '/protocols/saml/saml-configuration-options',
+      '/config/saml-configuration/saml-sso-integrations',
+      '/config/saml-configuration/special-saml-configuration-scenarios',
+      '/protocols/saml/saml-configuration/special-configuration-scenarios',
+      '/protocols/saml-protocol/saml-configuration-options/special-saml-configuration-scenarios',
+      '/protocols/saml-protocol/special-saml-configuration-scenarios',
+      '/protocols/saml-protocol/saml-sso-integrations',
+      '/configure/saml-configuration/saml-sso-integrations',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations',
+  },
+  {
+    from: [
+      '/protocols/saml/idp-initiated-sso',
+      '/protocols/saml-configuration-options/identity-provider-initiated-single-sign-on',
+      '/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso',
+      '/protocols/saml-protocol/saml-configuration-options/identity-provider-initiated-single-sign-on',
+      '/protocols/saml-protocol/saml-sso-integrations/identity-provider-initiated-single-sign-on',
+      '/configure/saml-configuration/saml-sso-integrations/identity-provider-initiated-single-sign-on',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/identity-provider-initiated-single-sign-on',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/sign-and-encrypt-saml-requests',
+      '/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests',
+      '/protocols/saml-protocol/saml-configuration-options/sign-and-encrypt-saml-requests',
+      '/protocols/saml-protocol/saml-sso-integrations/sign-and-encrypt-saml-requests',
+      '/configure/saml-configuration/saml-sso-integrations/sign-and-encrypt-saml-requests',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/sign-and-encrypt-saml-requests',
+  },
+  {
+    from: [
+      '/protocols/saml-protocol/saml-configuration-options/work-with-certificates-and-keys-as-strings',
+      '/protocols/saml/saml-configuration/special-configuration-scenarios/work-with-certificates-and-keys-as-strings',
+      '/protocols/saml-protocol/saml-sso-integrations/work-with-certificates-and-keys-as-strings',
+      '/configure/saml-configuration/saml-sso-integrations/work-with-certificates-and-keys-as-strings',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/work-with-certificates-and-keys-as-strings',
+  },
+  {
+    from: [
+      '/saml2webapp-tutorial',
+      '/protocols/saml/saml2webapp-tutorial',
+      '/protocols/saml-protocol/saml-configuration-options/enable-saml2-web-app-addon',
+      '/configure/saml-configuration/saml-sso-integrations/enable-saml2-web-app-addon',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/enable-saml2-web-app-addon',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/configure-auth0-saml-service-provider',
+      '/protocols/saml/saml-sp-generic',
+      '/saml-sp-generic',
+      '/protocols/saml/saml-configuration/auth0-as-service-provider',
+      '/protocols/saml-protocol/configure-auth0-saml-service-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider',
+  },
+  {
+    from: [
+      '/protocols/saml/adfs',
+      '/protocols/saml-protocol/saml-configuration-options/configure-adfs-saml-connections',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-adfs-saml-connections',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-adfs-saml-connections',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-adfs-saml-connections',
+  },
+  {
+    from: [
+      '/protocols/saml/identity-providers/okta',
+      '/okta',
+      '/saml/identity-providers/okta',
+      '/protocols/saml-configuration-options/configure-okta-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration-options/configure-okta-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-okta-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-okta-as-saml-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-okta-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/onelogin',
+      '/saml/identity-providers/onelogin',
+      '/protocols/saml/identity-providers/onelogin',
+      '/protocols/saml-configuration-options/configure-onelogin-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-onelogin-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-onelogin-as-saml-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-onelogin-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/ping7',
+      '/saml/identity-providers/ping7',
+      '/protocols/saml/identity-providers/ping7',
+      '/protocols/saml-configuration-options/configure-pingfederate-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration-options/configure-pingfederate-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration/configure-pingfederate-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-pingfederate-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-pingfederate-as-saml-identity-provider',
+      '/connections/enterprise/ping-federate',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-pingfederate-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/saml/identity-providers/salesforce',
+      '/protocols/saml/identity-providers/salesforce',
+      '/protocols/saml-configuration-options/configure-salesforce-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration-options/configure-salesforce-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-salesforce-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-salesforce-as-saml-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-salesforce-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/siteminder',
+      '/saml/identity-providers/siteminder',
+      '/protocols/saml/identity-providers/siteminder',
+      '/protocols/saml-configuration-options/configure-siteminder-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration-options/configure-siteminder-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-siteminder-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-siteminder-as-saml-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-siteminder-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/ssocircle',
+      '/saml/identity-providers/ssocircle',
+      '/protocols/saml/identity-providers/ssocircle',
+      '/protocols/saml-configuration-options/configure-ssocircle-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-configuration-options/configure-ssocircle-as-saml-identity-provider',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-ssocircle-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-service-provider/configure-ssocircle-as-saml-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider/configure-ssocircle-as-saml-identity-provider',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/configure-auth0-as-saml-identity-provider',
+      '/saml-idp-generic',
+      '/protocols/saml/saml-idp-generic',
+      '/protocols/saml/saml-configuration/auth0-as-identity-provider',
+      '/protocols/saml-protocol/configure-auth0-as-saml-identity-provider',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider',
+  },
+  {
+    from: [
+      '/configure/saml-configuration-options/configure-saml2-web-app-addon-for-aws',
+      '/dashboard/guides/applications/set-up-addon-saml2-aws',
+      '/protocols/saml-protocol/saml-configuration-options/configure-saml2-web-app-addon-for-aws',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-saml2-web-app-addon-for-aws',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-aws',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-aws',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-aws',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/atlassian',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-atlassian',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-atlassian',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-atlassian',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-atlassian',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-atlassian',
+  },
+  {
+    from: [
+      '/saml-apps/cisco-webex',
+      '/protocols/saml/saml-apps/cisco-webex',
+      '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-cisco-webex',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-cisco-webex',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-cisco-webex',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-cisco-webex',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-cisco-webex',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-cisco-webex',
+  },
+  {
+    from: [
+      '/saml-apps/datadog',
+      '/protocols/saml/saml-apps/datadog',
+      '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-datadog',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-datadog',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-datadog',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-datadog',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-datadog',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-datadog',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/egencia',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-egencia',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-egencia',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-egencia',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-egencia',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-egencia',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-idp-eloqua',
+      '/protocols/saml/saml-apps/eloqua',
+      '/protocols/saml-protocol/saml-configuration-options/configure-saml2-addon-eloqua',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-saml2-addon-eloqua',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-saml2-addon-eloqua',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-saml2-addon-eloqua',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-saml2-addon-eloqua',
+  },
+  {
+    from: [
+      '/saml-apps/freshdesk',
+      '/protocols/saml/saml-apps/freshdesk',
+      '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-freshdesk',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-freshdesk',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-freshdesk',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-freshdesk',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-freshdesk',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-freshdesk',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/github-cloud',
+      '/protocols/saml-protocol/saml-configuration-options/configure-saml2-web-app-addon-for-github-enterprise-cloud',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-saml2-web-app-addon-for-github-enterprise-cloud',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-cloud',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-cloud',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-cloud',
+  },
+  {
+    from: [
+      '/integrations/using-auth0-as-an-identity-provider-with-github-enterprise',
+      '/protocols/saml/saml-apps/github-server',
+      '/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise',
+      '/scenarios/github',
+      '/protocols/saml-protocol/saml-configuration-options/configure-saml2-web-app-addon-for-github-enterprise-server',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-saml2-web-app-addon-for-github-enterprise-server',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-server',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-server',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-github-enterprise-server',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/google-apps',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-idp-for-google-g-suite',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-idp-for-google-g-suite',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-idp-for-google-g-suite',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-idp-for-google-g-suite',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-idp-for-google-g-suite',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/heroku',
+      '/saml-apps/heroku-sso',
+      '/protocols/saml-protocol/saml-configuration-options/configure-saml2-web-app-addon-for-heroku',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-saml2-web-app-addon-for-heroku',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-heroku',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-heroku',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-saml2-web-app-addon-for-heroku',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/hosted-graphite',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-hosted-graphite',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-hosted-graphite',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-hosted-graphite',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-hosted-graphite',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-hosted-graphite',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/litmos',
+      '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-litmos',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-litmos',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-litmos',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-litmos',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-litmos',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-litmos',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/pluralsight',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-pluralsight',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-pluralsight',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-pluralsight',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-pluralsight',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-pluralsight',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/sprout-video',
+      '/saml-apps/sprout-video',
+      '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-sprout-video',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-sprout-video',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-sprout-video',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-sprout-video',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-sprout-video',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-sprout-video',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/tableau-online',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-tableau-online',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-tableau-online',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-online',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-online',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-online',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/tableau-server',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-tableau-server',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-tableau-server',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-server',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-server',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-tableau-server',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/workday',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-workday',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-workday',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workday',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workday',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workday',
+  },
+  {
+    from: [
+      '/protocols/saml/saml-apps/workpath',
+      '/protocols/saml-protocol/saml-configuration-options/configure-auth0-as-identity-provider-for-workpath',
+      '/protocols/saml-protocol/saml-sso-integrations/configure-auth0-as-identity-provider-for-workpath',
+      '/configure/saml-configuration/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workpath',
+      '/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workpath',
+    ],
+    to: '/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider/configure-auth0-as-identity-provider-for-workpath',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/saml-identity-provider-configuration-settings',
+      '/samlp',
+      '/protocols/saml/samlp',
+      '/protocols/saml-protocol/saml-identity-provider-configuration-settings',
+      '/configure/saml-configuration/saml-identity-provider-configuration-settings',
+    ],
+    to: '/authenticate/protocols/saml/saml-identity-provider-configuration-settings',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/customize-saml-assertions',
+      '/protocols/saml/saml-configuration/saml-assertions',
+      '/protocols/saml-protocol/customize-saml-assertions',
+      '/configure/saml-configuration/customize-saml-assertions',
+    ],
+    to: '/authenticate/protocols/saml/saml-configuration/customize-saml-assertions',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/test-saml-sso-with-auth0-as-service-and-identity-provider',
+      '/protocols/saml/samlsso-auth0-to-auth0',
+      '/samlsso-auth0-to-auth0',
+      '/protocols/saml-configuration-options/configure-auth0-as-service-and-identity-provider',
+      '/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider',
+      '/protocols/saml-protocol/configure-auth0-as-service-and-identity-provider',
+      '/configure/saml-configuration/configure-auth0-as-service-and-identity-provider',
+    ],
+    to: '/authenticate/protocols/saml/saml-configuration/configure-auth0-as-service-and-identity-provider',
+  },
+  {
+    from: [
+      '/protocols/saml-configuration-options/deprovision-users-in-saml-integrations',
+      '/protocols/saml/saml-configuration/deprovision-users',
+      '/protocols/saml-protocol/deprovision-users-in-saml-integrations',
+      '/configure/saml-configuration/deprovision-users-in-saml-integrations',
+    ],
+    to: '/authenticate/protocols/saml/saml-configuration/deprovision-users-in-saml-integrations',
+  },
+  {
+    from: ['/authorization/protocols/scim'],
+    to: '/authenticate/protocols/scim',
+  },
+  {
+    from: [
+      '/authenticate/protocols/scim/configure-inbound-scim/configure-inbound-scim-for-other-identity-providers-using-openid-or-saml',
+    ],
+    to: '/authenticate/protocols/scim/configure-inbound-scim-for-identity-providers-using-saml-or-openid',
+  },
+  {
+    from: ['/authenticate/protocols/scim/configure-inbound-scim/inbound-scim-for-new-azure-ad-connections'],
+    to: '/authenticate/protocols/scim/inbound-scim-for-new-azure-ad-connections',
+  },
+  {
+    from: ['/authenticate/protocols/scim/configure-inbound-scim/inbound-scim-for-older-azure-ad-connections'],
+    to: '/authenticate/protocols/scim/inbound-scim-for-older-azure-ad-connections',
+  },
+  {
+    from: [
+      '/authenticate/protocols/scim/configure-inbound-scim/manage-an-inbound-scim-deployment-with-the-management-api',
+    ],
+    to: '/authenticate/protocols/scim/manage-an-inbound-scim-deployment-with-the-management-api',
+  },
+  {
+    from: ['/authenticate/protocols/scim/configure-inbound-scim/inbound-scim-for-okta-workforce-saml-connections'],
+    to: '/authenticate/protocols/scim/inbound-scim-for-okta-workforce-saml-connections',
+  },
+  {
+    from: ['/authenticate/protocols/scim/configure-inbound-scim/inbound-scim-for-azure-ad-saml-connections'],
+    to: '/authenticate/protocols/scim/inbound-scim-for-azure-ad-saml-connections',
+  },
+  {
+    from: ['/authenticate/protocols/scim/configure-inbound-scim/inbound-scim-for-okta-workforce-connections'],
+    to: '/authenticate/protocols/scim/inbound-scim-for-okta-workforce-connections',
+  },
+
+  /* Actions */
+  {
+    from: ['/actions'],
+    to: '/customize/actions',
+  },
+  {
+    from: ['/actions/actions-overview'],
+    to: '/customize/actions/actions-overview',
+  },
+  {
+    from: [
+      '/actions/build-actions-flows',
+      '/actions/edit-actions',
+      '/actions/troubleshoot-actions',
+      '/actions/write-your-first-action',
+    ],
+    to: '/customize/actions/write-your-first-action',
+  },
+  {
+    from: [
+      '/actions/actions-context-object',
+      '/actions/actions-event-object',
+      '/actions/blueprints',
+      '/actions/triggers',
+      '/customize/actions/triggers',
+      '/customize/actions/flows-and-triggers',
+    ],
+    to: '/customize/actions/explore-triggers',
+  },
+  {
+    from: ['/actions/manage-action-versions', '/actions/manage-versions', '/customize/actions/manage-action-versions'],
+    to: '/customize/actions/manage-versions',
+  },
+  {
+    from: [
+      '/actions/triggers/send-phone-message',
+      '/customize/actions/triggers/send-phone-message',
+      '/customize/actions/flows-and-triggers/send-phone-message-flow',
+    ],
+    to: '/customize/actions/explore-triggers/mfa-notifications-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/send-phone-message/event-object',
+      '/customize/actions/triggers/send-phone-message/event-object',
+      '/customize/actions/flows-and-triggers/send-phone-message-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/mfa-notifications-trigger/send-phone-message-event-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/send-phone-message-flow/api-object'],
+    to: '/customize/actions/explore-triggers/mfa-notifications-trigger/send-phone-message-api-object',
+  },
+  {
+    from: ['/actions/programming-model-changes', '/customize/actions/programming-model-changes'],
+    to: '/customize/actions/migrate/migrate-from-actions-beta-to-final',
+  },
+  {
+    from: ['/customize/actions/migrate-from-rules-to-actions'],
+    to: '/customize/actions/migrate/migrate-from-rules-to-actions',
+  },
+  {
+    from: ['/actions/limitations'],
+    to: '/customize/actions/limitations',
+  },
+  {
+    from: [
+      '/actions/triggers/post-change-password',
+      '/customize/actions/triggers/post-change-password',
+      '/customize/actions/flows-and-triggers/post-change-password-flow',
+    ],
+    to: '/customize/actions/explore-triggers/password-reset-triggers/post-change-password-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/post-change-password/event-object',
+      '/customize/actions/triggers/post-change-password/event-object',
+      '/customize/actions/flows-and-triggers/post-change-password-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-event-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/post-change-password-flow/api-object'],
+    to: '/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object',
+  },
+  {
+    from: [
+      '/actions/triggers/post-user-registration',
+      '/customize/actions/triggers/post-user-registration',
+      '/customize/actions/flows-and-triggers/post-user-registration-flow',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/post-user-registration-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/post-user-registration/event-object',
+      '/customize/actions/triggers/post-user-registration/event-object',
+      '/customize/actions/flows-and-triggers/post-user-registration-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/post-user-registration-trigger/post-user-registration-event-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/post-user-registration-flow/api-object'],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/post-user-registration-trigger/post-user-registration-api-object',
+  },
+  {
+    from: [
+      '/actions/triggers/pre-user-registration',
+      '/customize/actions/triggers/pre-user-registration',
+      '/customize/actions/flows-and-triggers/pre-user-registration-flow',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/pre-user-registration-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/pre-user-registration/event-object',
+      '/customize/actions/triggers/pre-user-registration/event-object',
+      '/customize/actions/flows-and-triggers/pre-user-registration-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/pre-user-registration-trigger/pre-user-registration-event-object',
+  },
+  {
+    from: [
+      '/actions/triggers/pre-user-registration/api-object',
+      '/customize/actions/triggers/pre-user-registration/api-object',
+      '/customize/actions/flows-and-triggers/pre-user-registration-flow/api-object',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/pre-user-registration-trigger/pre-user-registration-api-object',
+  },
+  {
+    from: ['/actions/triggers/credentials-exchange', '/customize/actions/triggers/credentials-exchange'],
+    to: '/customize/actions/flows-and-triggers/machine-to-machine-flow',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/machine-to-machine-flow'],
+    to: '/customize/actions/explore-triggers/machine-to-machine-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/credentials-exchange/event-object',
+      '/customize/actions/triggers/credentials-exchange/event-object',
+      '/customize/actions/flows-and-triggers/machine-to-machine-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-event-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/machine-to-machine-flow/api-object'],
+    to: '/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-api-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/password-reset'],
+    to: '/customize/actions/explore-triggers/password-reset-triggers',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/password-reset/event-object'],
+    to: '/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-event-object',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/password-reset/api-object'],
+    to: '/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object',
+  },
+  {
+    from: [
+      '/actions/triggers/credentials-exchange/api-object',
+      '/customize/actions/triggers/credentials-exchange/api-object',
+    ],
+    to: '/customize/actions/explore-triggers/machine-to-machine-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/post-login',
+      '/customize/actions/triggers/post-login',
+      '/customize/actions/flows-and-triggers/login-flow',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger',
+  },
+  {
+    from: [
+      '/actions/triggers/post-login/event-object',
+      '/customize/actions/triggers/post-login/event-object',
+      '/customize/actions/flows-and-triggers/login-flow/event-object',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-event-object',
+  },
+  {
+    from: [
+      '/actions/triggers/post-login/api-object',
+      '/customize/actions/triggers/post-login/api-object',
+      '/customize/actions/flows-and-triggers/login-flow/api-object',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object',
+  },
+  {
+    from: [
+      '/actions/triggers/post-login/redirect-with-actions',
+      '/customize/actions/triggers/post-login/redirect-with-actions',
+      '/customize/actions/flows-and-triggers/login-flow/redirect-with-actions',
+    ],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/redirect-with-actions',
+  },
+  {
+    from: ['/customize/actions/flows-and-triggers/login-flow/releases'],
+    to: '/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/releases',
+  },
+
+  /* Attack Protection */
+
+  {
+    from: [
+      '/anomaly-',
+      '/anomaly',
+      '/anomaly-detection/references/anomaly-detection-faqs',
+      '/anomaly-detection/references/anomaly-detection-restrictions-limitations',
+      '/anomaly-detection/guides/set-anomaly-detection-preferences',
+      '/anomaly-detection/set-anomaly-detection-preferences',
+      '/attack-protection/set-attack-protection-preferences',
+      '/anomaly-detection',
+      '/attack-protection',
+      '/configure/attack-protection',
+    ],
+    to: '/secure/attack-protection',
+  },
+  {
+    from: [
+      '/anomaly-detection/references/breached-password-detection-triggers-actions',
+      '/anomaly-detection/concepts/breached-passwords',
+      '/anomaly-detection/breached-passwords',
+      '/anomaly-detection/breached-password-security',
+      '/attack-protection/breached-password-detection',
+      '/configure/attack-protection/breached-password-detection',
+    ],
+    to: '/secure/attack-protection/breached-password-detection',
+  },
+  {
+    from: [
+      '/anomaly-detection/bot-protection',
+      '/anomaly-detection/guides/prevent-credential-stuffing-attacks',
+      '/anomaly-detection/bot-and-credential-stuffing-protection',
+      '/anomaly-detection/bot-detection',
+      '/attack-protection/bot-detection',
+      '/configure/attack-protection/bot-detection',
+    ],
+    to: '/secure/attack-protection/bot-detection',
+  },
+  {
+    from: [
+      '/configure/anomaly-detection/bot-detection/configure-recaptcha-enterprise',
+      '/anomaly-detection/bot-detection/configure-recaptcha-enterprise',
+      '/attack-protection/bot-detection/configure-recaptcha-enterprise',
+      '/configure/attack-protection/bot-detection/configure-recaptcha-enterprise',
+      '/secure/attack-protection/bot-detection/configure-recaptcha-enterprise',
+    ],
+    to: '/secure/attack-protection/bot-detection/configure-captcha',
+  },
+  {
+    from: [
+      '/anomaly-detection/bot-detection/bot-detection-custom-login-pages',
+      '/configure/anomaly-detection/bot-detection/bot-detection-custom-login-pages',
+      '/attack-protection/bot-detection/bot-detection-custom-login-pages',
+      '/configure/attack-protection/bot-detection/bot-detection-custom-login-pages',
+    ],
+    to: '/secure/attack-protection/bot-detection/bot-detection-custom-login-pages',
+  },
+  {
+    from: [
+      '/configure/anomaly-detection/bot-detection/bot-detection-native-apps',
+      '/anomaly-detection/bot-detection/bot-detection-native-apps',
+      '/configure/attack-protection/bot-detection/bot-detection-native-apps',
+    ],
+    to: '/secure/attack-protection/bot-detection/bot-detection-native-apps',
+  },
+  {
+    from: [
+      '/anomaly-detection/references/brute-force-protection-triggers-actions',
+      '/anomaly-detection/guides/enable-disable-brute-force-protection',
+      '/anomaly-detection/concepts/brute-force-protection',
+      '/anomaly-detection/enable-and-disable-brute-force-protection',
+      '/anomaly-detection/brute-force-protection',
+      '/attack-protection/brute-force-protection',
+      '/configure/attack-protection/brute-force-protection',
+    ],
+    to: '/secure/attack-protection/brute-force-protection',
+  },
+  {
+    from: [
+      '/configure/anomaly-detection/suspicious-ip-throttling',
+      '/anomaly-detection/suspicious-ip-throttling',
+      '/attack-protection/suspicious-ip-throttling',
+      '/configure/attack-protection/suspicious-ip-throttling',
+    ],
+    to: '/secure/attack-protection/suspicious-ip-throttling',
+  },
+  {
+    from: [
+      '/anomaly-detection/guides/use-tenant-data-for-anomaly-detection',
+      '/anomaly-detection/view-anomaly-detection-events',
+      '/attack-protection/view-attack-protection-events',
+      '/configure/attack-protection/view-attack-protection-events',
+    ],
+    to: '/secure/attack-protection/view-attack-protection-events',
+  },
+  {
+    from: [
+      '/protocols/oauth2/oauth-state',
+      '/protocols/oauth-state',
+      '/protocols/oauth2/mitigate-csrf-attacks',
+      '/protocols/state-parameters',
+      '/authorization/protocols/state-parameters',
+      '/configure/attack-protection/state-parameters',
+    ],
+    to: '/secure/attack-protection/state-parameters',
+  },
+
+  /* API */
+
+  {
+    from: ['/auth-api', '/api/authentication/reference'],
+    to: '/api/authentication',
+  },
+  {
+    from: ['/apiv2', '/api/v2', '/api/management','/api/management/v2/blacklists/get-tokens','/api/management/v2/blacklists/post-tokens' ],
+    to: '/api/management/v2',
+  },
+  {
+    from: ['/auth0-apis', '/api/info'],
+    to: '/api',
+  },
+  {
+    from: ['/api/use-auth0-apis-with-postman-collections', '/api/postman'],
+    to: '/api',
+  },
+  {
+    from: ['/api/management'],
+    to: '/api/management/v2',
+  },
+  {
+    from: ['/api/management/v2/blacklists/get-tokens', '/api/management/v2/blacklists/post-tokens'],
+    to: '/api/management/v2',
+  },
+
+  /* Authorization */
+
+  {
+    from: ['/authorization/concepts/policies', '/authorization/authorization-policies'],
+    to: '/manage-users/access-control/authorization-policies',
+  },
+  {
+    from: [
+      '/authorization/rules-for-authorization-policies',
+      '/authorization/concepts/authz-rules',
+      '/authorization/authorization-policies/rules-for-authorization-policies',
+    ],
+    to: '/manage-users/access-control/rules-for-authorization-policies',
+  },
+  {
+    from: [
+      '/api-auth/restrict-access-api',
+      '/api-auth/restrict-requests-for-scopes',
+      '/authorization/concepts/sample-use-cases-rules',
+      '/authorization/restrict-access-api',
+      '/authorization/sample-use-cases-rules-with-authorization',
+      '/authorization/authorization-policies/sample-use-cases-rules-with-authorization',
+    ],
+    to: '/manage-users/access-control/sample-use-cases-rules-with-authorization',
+  },
+  {
+    from: [
+      '/api-auth',
+      '/api-auth/tutorials',
+      '/api/tutorials',
+      '/authorization',
+      '/flows',
+      '/login/flows',
+      '/flows/concepts/token-exchange',
+      '/authorization/flows',
+      '/authorization/authorization-flows',
+    ],
+    to: '/get-started/authentication-and-authorization-flow',
+  },
+  {
+    from: [
+      '/api-auth/which-oauth-flow-to-use',
+      '/api-auth/faq',
+      '/authorization/authentication-and-authorization-api-faq',
+      '/authorization/which-oauth-2-0-flow-should-i-use',
+      '/authorization/flows/which-oauth-2-0-flow-should-i-use',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use',
+  },
+  {
+    from: [
+      '/flows/concepts/auth-code',
+      '/flows/concepts/regular-web-app-login-flow',
+      '/api-auth/grant/authorization-code',
+      '/api-auth/tutorials/adoption/authorization-code',
+      '/api-auth/adoption/authorization-code',
+      '/flows/authorization-code-flow',
+      '/authorization/flows/authorization-code-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow',
+  },
+  {
+    from: [
+      '/flows/guides/auth-code/call-api-auth-code',
+      '/flows/guides/auth-code/includes/authorize-user-call-api',
+      '/flows/guides/auth-code/includes/sample-use-cases-call-api',
+      '/flows/guides/auth-code/includes/call-api',
+      '/flows/guides/regular-web-app-login-flow/call-api-using-regular-web-app-login-flow',
+      '/api-auth/tutorials/authorization-code-grant',
+      '/flows/call-your-api-using-the-authorization-code-flow',
+      '/authorization/flows/call-your-api-using-the-authorization-code-flow',
+      '/get-started/authentication-and-authorization-flow/call-your-api-using-the-authorization-code-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow',
+  },
+  {
+    from: [
+      '/flows/concepts/auth-code-pkce',
+      '/api-auth/grant/authorization-code-pkce',
+      '/flows/concepts/mobile-login-flow',
+      '/flows/concepts/single-page-login-flow',
+      '/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce',
+      '/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce',
+      '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce',
+  },
+  {
+    from: [
+      '/flows/guides/auth-code-pkce/call-api-auth-code-pkce',
+      '/flows/guides/auth-code-pkce/includes/sample-use-cases-call-api',
+      '/flows/guides/auth-code-pkce/includes/call-api',
+      '/flows/guides/auth-code-pkce/includes/authorize-user-call-api',
+      '/flows/guides/mobile-login-flow/call-api-using-mobile-login-flow',
+      '/api-auth/tutorials/authorization-code-grant-pkce',
+      '/flows/call-your-api-using-the-authorization-code-flow-with-pkce',
+      '/authorization/flows/call-your-api-using-the-authorization-code-flow-with-pkce',
+      '/get-started/authentication-and-authorization-flow/call-your-api-using-the-authorization-code-flow-with-pkce',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce',
+  },
+  {
+    from: [
+      '/flows/guides/implicit/call-api-implicit',
+      '/flows/guides/implicit/includes/sample-use-cases-call-api',
+      '/flows/guides/implicit/includes/call-api',
+      '/flows/guides/implicit/includes/authorize-user-call-api',
+      '/flows/guides/single-page-login-flow/call-api-using-single-page-login-flow',
+      '/api-auth/grant/implicit',
+      '/api-auth/tutorials/adoption/implicit',
+      '/api-auth/tutorials/implicit-grant',
+      '/protocols/oauth2/oauth-implicit-protocol',
+      '/flows/concepts/implicit',
+      '/flows/implicit-flow-with-form-post',
+      '/authorization/flows/implicit-flow-with-form-post',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post',
+  },
+  {
+    from: [
+      '/api-auth/tutorials/nonce',
+      '/authorization/mitigate-replay-attacks-when-using-the-implicit-flow',
+      '/authorization/flows/mitigate-replay-attacks-when-using-the-implicit-flow',
+      '/get-started/authentication-and-authorization-flow/mitigate-replay-attacks-when-using-the-implicit-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/mitigate-replay-attacks-when-using-the-implicit-flow',
+  },
+  {
+    from: ['/flows/hybrid-flow', '/api-auth/grant/hybrid', '/authorization/flows/hybrid-flow'],
+    to: '/get-started/authentication-and-authorization-flow/hybrid-flow',
+  },
+  {
+    from: [
+      '/api-auth/tutorials/hybrid-flow',
+      '/flows/call-api-hybrid-flow',
+      '/authorization/flows/call-api-hybrid-flow',
+      '/get-started/authentication-and-authorization-flow/call-api-hybrid-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/hybrid-flow/call-api-hybrid-flow',
+  },
+  {
+    from: [
+      '/flows/concepts/client-credentials',
+      '/flows/concepts/m2m-flow',
+      '/api-auth/grant/client-credentials',
+      '/api-auth/tutorials/adoption/client-credentials',
+      '/flows/client-credentials-flow',
+      '/authorization/flows/client-credentials-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/client-credentials-flow',
+  },
+  {
+    from: [
+      '/flows/guides/client-credentials/call-api-client-credentials',
+      '/flows/guides/client-credentials/includes/sample-use-cases',
+      '/flows/guides/client-credentials/includes/call-api',
+      '/flows/guides/client-credentials/includes/request-token',
+      '/flows/guides/m2m-flow/call-api-using-m2m-flow',
+      '/api-auth/tutorials/client-credentials',
+      '/api-auth/config/asking-for-access-tokens',
+      '/flows/call-your-api-using-the-client-credentials-flow',
+      '/authorization/flows/call-your-api-using-the-client-credentials-flow',
+      '/get-started/authentication-and-authorization-flow/call-your-api-using-the-client-credentials-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow',
+  },
+  {
+    from: [
+      '/api-auth/tutorials/client-credentials/customize-with-hooks',
+      '/api-auth/grant/using-rules',
+      '/authorization/customize-tokens-using-hooks-with-client-credentials-flow',
+      '/authorization/flows/customize-tokens-using-hooks-with-client-credentials-flow',
+      '/get-started/authentication-and-authorization-flow/customize-tokens-using-hooks-with-client-credentials-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/client-credentials-flow/customize-tokens-using-hooks-with-client-credentials-flow',
+  },
+  {
+    from: [
+      '/flows/concepts/device-auth',
+      '/flows/device-authorization-flow',
+      '/authorization/flows/device-authorization-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/device-authorization-flow',
+  },
+  {
+    from: [
+      '/flows/guides/device-auth/call-api-device-auth',
+      '/authorization/flows/call-your-api-using-the-device-authorization-flow',
+      '/microsites/protect-api/protect-api',
+      '/get-started/authentication-and-authorization-flow/call-your-api-using-the-device-authorization-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow',
+  },
+  {
+    from: [
+      '/api-auth/grant/password',
+      '/api-auth/tutorials/adoption/password',
+      '/flows/resource-owner-password-flow',
+      '/authorization/flows/resource-owner-password-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/resource-owner-password-flow',
+  },
+  {
+    from: [
+      '/flows/call-your-api-using-resource-owner-password-flow',
+      '/api-auth/tutorials/password-grant',
+      '/authorization/flows/call-your-api-using-resource-owner-password-flow',
+      '/get-started/authentication-and-authorization-flow/call-your-api-using-resource-owner-password-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow',
+  },
+  {
+    from: [
+      '/api-auth/tutorials/using-resource-owner-password-from-server-side',
+      '/authorization/avoid-common-issues-with-resource-owner-password-flow-and-anomaly-detection',
+      '/authorization/avoid-common-issues-with-resource-owner-password-flow-and-attack-protection',
+      '/authorization/flows/avoid-common-issues-with-resource-owner-password-flow-and-attack-protection',
+      '/get-started/authentication-and-authorization-flow/avoid-common-issues-with-resource-owner-password-flow-and-attack-protection',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/resource-owner-password-flow/avoid-common-issues-with-resource-owner-password-flow-and-attack-protection',
+  },
+  {
+    from: ['/authorization/concepts/rbac', '/authorization/rbac', '/rbac'],
+    to: '/manage-users/access-control/rbac',
+  },
+  {
+    from: [
+      '/authorization/authorization-core-vs-authorization-extension',
+      '/authorization/concepts/core-vs-extension',
+      '/authorization/rbac/authorization-core-vs-authorization-extension',
+    ],
+    to: '/manage-users/access-control/authorization-core-vs-authorization-extension',
+  },
+  {
+    from: [
+      '/authorization/sample-use-cases-role-based-access-control',
+      '/authorization/concepts/sample-use-cases-rbac',
+      '/authorization/rbac/sample-use-cases-role-based-access-control',
+    ],
+    to: '/manage-users/access-control/sample-use-cases-role-based-access-control',
+  },
+  {
+    from: [
+      '/authorization/how-to-use-auth0s-core-authorization-feature-set',
+      '/authorization/guides/how-to',
+      '/authorization/auth-core-features',
+      '/authorization/rbac/auth-core-features',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac',
+  },
+  {
+    from: ['/authorization/guides/manage-roles', '/authorization/rbac/roles', '/rbac/roles'],
+    to: '/manage-users/access-control/configure-core-rbac/roles',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/create-roles',
+      '/api/management/guides/roles/create-roles',
+      '/authorization/rbac/roles/create-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/create-roles',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/edit-role-definitions',
+      '/api/management/guides/roles/edit-role-definitions',
+      '/authorization/guides/api/edit-role-definitions',
+      '/authorization/rbac/roles/edit-role-definitions',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/edit-role-definitions',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/add-permissions-roles',
+      '/api/management/guides/roles/add-permissions-roles',
+      '/authorization/rbac/roles/add-permissions-to-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/add-permissions-to-roles',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/view-role-permissions',
+      '/api/management/guides/roles/view-role-permissions',
+      '/authorization/rbac/roles/view-role-permissions',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/view-role-permissions',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/remove-role-permissions',
+      '/api/management/guides/roles/remove-role-permissions',
+      '/authorization/rbac/roles/remove-permissions-from-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/remove-permissions-from-roles',
+  },
+  {
+    from: [
+      '/api/management/guides/roles/view-role-users',
+      '/dashboard/guides/roles/view-role-users',
+      '/authorization/rbac/roles/view-users-assigned-to-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/view-users-assigned-to-roles',
+  },
+  {
+    from: [
+      '/dashboard/guides/roles/delete-roles',
+      '/api/management/guides/roles/delete-roles',
+      '/authorization/rbac/roles/delete-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/roles/delete-roles',
+  },
+  {
+    from: [
+      '/authorization/auth-core-features/rbac-users',
+      '/authorization/guides/manage-users',
+      '/authorization/rbac/rbac-users',
+      '/rbac/rbac-users',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users',
+  },
+  {
+    from: [
+      '/users/assign-roles-to-users',
+      '/dashboard/guides/users/assign-roles-users',
+      '/api/management/guides/users/assign-roles-users',
+      '/authorization/rbac/rbac-users/assign-roles-to-users',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users',
+  },
+  {
+    from: [
+      '/dashboard/guides/users/view-user-roles',
+      '/api/management/guides/users/view-user-roles',
+      '/users/view-user-roles',
+      '/authorization/rbac/rbac-users/view-user-roles',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/view-user-roles',
+  },
+  {
+    from: [
+      '/dashboard/guides/users/remove-user-roles',
+      '/dashboard/guides/roles/remove-role-users',
+      '/api/management/guides/users/remove-user-roles',
+      '/users/remove-roles-from-users',
+      '/authorization/rbac/rbac-users/remove-roles-from-users',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/remove-roles-from-users',
+  },
+  {
+    from: [
+      '/dashboard/guides/users/assign-permissions-users',
+      '/api/management/guides/users/assign-permissions-users',
+      '/users/assign-permissions-to-users',
+      '/authorization/rbac/rbac-users/assign-permissions-to-users',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/assign-permissions-to-users',
+  },
+  {
+    from: [
+      '/dashboard/guides/users/view-user-permissions',
+      '/api/management/guides/users/view-user-permissions',
+      '/users/view-user-permissions',
+      '/authorization/rbac/rbac-users/view-user-permissions',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/view-user-permissions',
+  },
+  {
+    from: [
+      '/dashboard/guides/users/remove-user-permissions',
+      '/api/management/guides/users/remove-user-permissions',
+      '/users/remove-permissions-from-users',
+      '/authorization/rbac/rbac-users/remove-permissions-from-users',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/rbac-users/remove-permissions-from-users',
+  },
+  {
+    from: [
+      '/authorization/manage-permissions',
+      '/authorization/guides/manage-permissions',
+      '/authorization/rbac/manage-permissions',
+    ],
+    to: '/manage-users/access-control/configure-core-rbac/manage-permissions',
+  },
+
+  /* Protocols */
+
+  {
+    from: ['/protocols', '/authorization/protocols'],
+    to: '/authenticate/protocols',
+  },
+  {
+    from: ['/protocols/protocol-oauth2', '/protocols/oauth2', '/authorization/protocols/protocol-oauth2'],
+    to: '/authenticate/protocols/oauth',
+  },
+  {
+    from: [
+      '/protocols/openid-connect-protocol',
+      '/protocols/oidc',
+      '/api-auth/intro',
+      '/api-auth/tutorials/adoption',
+      '/authorization/protocols/openid-connect-protocol',
+    ],
+    to: '/authenticate/protocols/openid-connect-protocol',
+  },
+  {
+    from: [
+      '/protocols/ws-fed',
+      '/tutorials/wsfed-web-app',
+      '/wsfedwebapp-tutorial',
+      '/protocols/ws-fed-protocol',
+      '/authorization/protocols/ws-fed-protocol',
+    ],
+    to: '/authenticate/protocols/ws-fed-protocol',
+  },
+
+  /* Best Practices */
+
+  {
+    from: [
+      '/best-practices/custom-db-connections',
+      '/best-practices/custom-db-connections-scripts',
+      '/best-practices/custom-database-connection-and-action-script-best-practices',
+      '/best-practices/custom-database-connections-scripts',
+    ],
+    to: '/authenticate/database-connections/custom-db/custom-database-connections-scripts',
+  },
+  {
+    from: [
+      '/best-practices/custom-db-connections/anatomy',
+      '/best-practices/custom-db-connections/size',
+      '/best-practices/custom-database-connection-and-action-script-best-practices/custom-db-connection-anatomy-best-practices',
+      '/best-practices/custom-database-connections-scripts/anatomy',
+    ],
+    to: '/authenticate/database-connections/custom-db/custom-database-connections-scripts/anatomy',
+  },
+  {
+    from: [
+      '/best-practices/custom-db-connections/environment',
+      '/best-practices/custom-database-connection-and-action-script-best-practices/custom-db-action-script-environment-best-practices',
+      '/best-practices/custom-database-connections-scripts/environment',
+    ],
+    to: '/authenticate/database-connections/custom-db/custom-database-connections-scripts/environment',
+  },
+  {
+    from: [
+      '/best-practices/custom-db-connections/execution',
+      '/best-practices/custom-database-connection-and-action-script-best-practices/custom-database-action-script-execution-best-practices',
+      '/best-practices/custom-database-connections-scripts/execution',
+    ],
+    to: '/authenticate/database-connections/custom-db/custom-database-connections-scripts/execution',
+  },
+  {
+    from: [
+      '/best-practices/custom-db-connections/security',
+      '/best-practices/custom-database-connection-and-action-script-best-practices/custom-db-connection-security-best-practices',
+      '/best-practices/custom-database-connections-scripts/connection-security',
+    ],
+    to: '/authenticate/database-connections/custom-db/custom-database-connections-scripts/connection-security',
+  },
+  {
+    from: ['/best-practices/connection-settings', '/best-practices/connection-settings-best-practices'],
+    to: '/authenticate/connection-settings-best-practices',
+  },
+  {
+    from: ['/best-practices/debugging', '/best-practices/debugging-best-practices'],
+    to: '/troubleshoot/debugging-best-practices',
+  },
+  {
+    from: ['/best-practices/deployment', '/best-practices/deployment-best-practices'],
+    to: '/deploy-monitor/deployment-best-practices',
+  },
+  {
+    from: ['/best-practices/error-handling', '/best-practices/error-handling-best-practices'],
+    to: '/troubleshoot/error-handling-best-practices',
+  },
+  {
+    from: ['/best-practices/operations', '/best-practices/general-usage-and-operations-best-practices'],
+    to: '/troubleshoot/general-usage-and-operations-best-practices',
+  },
+  {
+    from: ['/best-practices/performance', '/best-practices/performance-best-practices'],
+    to: '/troubleshoot/performance-best-practices',
+  },
+  {
+    from: ['/best-practices/rules', '/best-practices/rules-best-practices', '/customize/rules/rules-best-practices'],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/best-practices/search-best-practices',
+      '/users/search/best-practices',
+      '/best-practices/user-search-best-practices',
+    ],
+    to: '/manage-users/user-search/user-search-best-practices',
+  },
+  {
+    from: [
+      '/best-practices/rules-best-practices/rules-anatomy-best-practices',
+      '/customize/rules/rules-best-practices/rules-anatomy-best-practices',
+    ],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/best-practices/rules-best-practices/rules-environment-best-practices',
+      '/customize/rules/rules-best-practices/rules-environment-best-practices',
+    ],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/best-practices/rules-best-practices/rules-execution-best-practices',
+      '/customize/rules/rules-best-practices/rules-execution-best-practices',
+    ],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/best-practices/rules-best-practices/rules-security-best-practices',
+      '/customize/rules/rules-best-practices/rules-security-best-practices',
+    ],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/best-practices/testing',
+      '/best-practices/rules-best-practices/rules-testing-best-practices',
+      '/customize/rules/rules-best-practices/rules-testing-best-practices',
+    ],
+    to: '/customize/actions/action-coding-guidelines',
+  },
+  {
+    from: [
+      '/tokens/concepts/token-best-practices',
+      '/design/web-apps-vs-web-apis-cookies-vs-tokens',
+      '/best-practices/token-best-practices',
+    ],
+    to: '/secure/tokens/token-best-practices',
+  },
+  {
+    from: [
+      '/design/using-auth0-with-multi-tenant-apps',
+      '/applications/concepts/multiple-tenants',
+      '/tutorials/using-auth0-with-multi-tenant-apps',
+      '/saas-apps',
+      '/best-practices/multi-tenant-apps-best-practices',
+    ],
+    to: '/get-started/auth0-overview/create-tenants/multi-tenant-apps-best-practices',
+  },
+
+  /* Brand and Customize */
+
+  {
+    from: ['/branding-customization', '/brand-and-customize'],
+    to: '/customize',
+  },
+  {
+    from: ['/sign-up-prompt-customizations', '/customize/universal-login-pages/customize-signup-and-login-prompts'],
+    to: '/customize/login-pages/universal-login/customize-signup-and-login-prompts',
+  },
+  {
+    from: [
+      '/universal-login/new-experience/universal-login-page-templates',
+      '/universal-login/page-templates',
+      '/universal-login/universal-login-page-customization',
+      '/customize/universal-login-page-templates',
+      '/brand-and-customize/universal-login-page-templates',
+      '/customize/universal-login-pages',
+    ],
+    to: '/customize/login-pages',
+  },
+  {
+    from: [
+      '/universal-login/classic-experience/customization-classic',
+      '/universal-login/customization-classic',
+      '/universal-login/advanced-customization',
+      '/brand-and-customize/customization-classic',
+      '/customize/universal-login-pages/customization-classic',
+    ],
+    to: '/customize/login-pages/classic-login/customization-classic',
+  },
+  {
+    from: [
+      '/universal-login/version-control-universal-login-pages',
+      '/universal-login/version-control',
+      '/hosted-pages/version-control',
+      '/brand-and-customize/version-control-universal-login-pages',
+      '/customize/universal-login-pages/version-control-universal-login-pages',
+      '/customize/universal-login-pages/version-control',
+    ],
+    to: '/customize/login-pages/classic-login/version-control',
+  },
+
+  /* Custom Domains */
+
+  {
+    from: ['/custom-domains', '/brand-and-customize/custom-domains'],
+    to: '/customize/custom-domains',
+  },
+  {
+    from: [
+      '/custom-domains/configure-custom-domains-with-auth0-managed-certificates',
+      '/custom-domains/auth0-managed-certificates',
+      '/brand-and-customize/custom-domains/auth0-managed-certificates',
+    ],
+    to: '/customize/custom-domains/auth0-managed-certificates',
+  },
+  {
+    from: [
+      '/custom-domains/self-managed-certificates',
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates',
+      '/brand-and-customize/custom-domains/self-managed-certificates',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates',
+  },
+  {
+    from: ['/custom-domains/tls-ssl', '/brand-and-customize/custom-domains/self-managed-certificates/tls-ssl'],
+    to: '/customize/custom-domains/self-managed-certificates/tls-ssl',
+  },
+  {
+    from: [
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates/configure-gcp-as-reverse-proxy',
+      '/brand-and-customize/custom-domains/self-managed-certificates/configure-gcp-as-reverse-proxy',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates/configure-gcp-as-reverse-proxy',
+  },
+  {
+    from: [
+      '/custom-domains/set-up-cloudfront',
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy',
+      '/brand-and-customize/custom-domains/self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy',
+  },
+  {
+    from: [
+      '/custom-domains/set-up-cloudflare',
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy',
+      '/brand-and-customize/custom-domains/self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy',
+  },
+  {
+    from: [
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy',
+      '/custom-domains/set-up-azure-cdn',
+      '/brand-and-customize/custom-domains/self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy',
+  },
+  {
+    from: [
+      '/custom-domains/configure-custom-domains-with-self-managed-certificates/configure-akamai-for-use-as-reverse-proxy',
+      '/brand-and-customize/custom-domains/self-managed-certificates/configure-akamai-for-use-as-reverse-proxy',
+    ],
+    to: '/customize/custom-domains/self-managed-certificates/configure-akamai-for-use-as-reverse-proxy',
+  },
+  {
+    from: [
+      '/custom-domains/configure-features-to-use-custom-domains',
+      '/custom-domains/additional-configuration',
+      '/brand-and-customize/custom-domains/configure-features-to-use-custom-domains',
+    ],
+    to: '/customize/custom-domains/configure-features-to-use-custom-domains',
+  },
+
+  /* Email */
+
+  {
+    from: ['/email', '/auth0-email-services', '/brand-and-customize/email'],
+    to: '/customize/email',
+  },
+  {
+    from: [
+      '/email/custom',
+      '/auth0-email-services/manage-email-flow',
+      '/email/manage-email-flow',
+      '/brand-and-customize/email/manage-email-flow',
+    ],
+    to: '/customize/email/manage-email-flow',
+  },
+  {
+    from: [
+      '/email/templates',
+      '/auth0-email-services/customize-email-templates',
+      '/email/spa-redirect',
+      '/auth0-email-services/spa-redirect',
+      '/email/customize-email-templates',
+      '/brand-and-customize/email/customize-email-templates',
+    ],
+    to: '/customize/email/email-templates',
+  },
+  {
+    from: [
+      '/email/customize-email-templates/email-template-descriptions',
+      '/auth0-email-services/email-template-descriptions',
+      '/brand-and-customize/email/email-template-descriptions',
+    ],
+    to: '/customize/email/email-templates/email-template-descriptions',
+  },
+  {
+    from: [
+      '/anomaly-detection/guides/customize-blocked-account-emails',
+      '/anomaly-detection/customize-blocked-account-emails',
+      '/attack-protection/customize-blocked-account-emails',
+      '/brand-and-customize/email/customize-blocked-account-emails',
+    ],
+    to: '/customize/email/customize-blocked-account-emails',
+  },
+  {
+    from: [
+      '/email/liquid-syntax',
+      '/auth0-email-services/customize-email-templates/use-liquid-syntax-in-email-templates',
+      '/email/customize-email-templates/use-liquid-syntax-in-email-templates',
+      '/brand-and-customize/email/use-liquid-syntax-in-email-templates',
+    ],
+    to: '/customize/email/email-templates/use-liquid-syntax-in-email-templates',
+  },
+  {
+    from: [
+      '/design/creating-invite-only-applications',
+      '/invite-only',
+      '/tutorials/creating-invite-only-applications',
+      '/auth0-email-services/send-email-invitations-for-application-signup',
+      '/email/send-email-invitations-for-application-signup',
+      '/brand-and-customize/email/send-email-invitations-for-application-signup',
+    ],
+    to: '/customize/email/send-email-invitations-for-application-signup',
+  },
+
+  /* SAML */
+
+  {
+    from: [
+      '/auth0-email-services/configure-external-smtp-email-providers',
+      '/email/providers',
+      '/email/configure-external-smtp-email-providers',
+      '/brand-and-customize/email/smtp-email-providers',
+    ],
+    to: '/customize/email/smtp-email-providers',
+  },
+  {
+    from: [
+      '/email/configure-external-smtp-email-providers/configure-amazon-ses-as-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-amazon-ses-as-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-amazon-ses-as-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/email/configure-external-smtp-email-providers/configure-mandrill-as-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-mandrill-as-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-mandrill-as-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/email/configure-external-smtp-email-providers/configure-sendgrid-as-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-sendgrid-as-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-sendgrid-as-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/email/configure-external-smtp-email-providers/configure-sparkpost-as-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-sparkpost-as-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-sparkpost-as-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/email/configure-external-smtp-email-providers/configure-mailgun-as-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-mailgun-as-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-mailgun-as-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/auth0-email-services/configure-external-smtp-email-providers/configure-custom-external-smtp-email-provider',
+      '/email/configure-custom-external-smtp-email-provider',
+      '/brand-and-customize/email/smtp-email-providers/configure-custom-external-smtp-email-provider',
+    ],
+    to: '/customize/email/smtp-email-providers/configure-custom-external-smtp-email-provider',
+  },
+  {
+    from: [
+      '/email/testing',
+      '/auth0-email-services/configure-external-smtp-email-providers/configure-test-smtp-email-servers',
+      '/email/configure-test-smtp-email-servers',
+      '/brand-and-customize/email/configure-test-smtp-email-servers',
+    ],
+    to: '/customize/email/configure-test-smtp-email-servers',
+  },
+  {
+    from: [
+      '/universal-login/new-experience/text-customization-new-universal-login',
+      '/universal-login/text-customization',
+      '/brand-and-customize/text-customization-new-universal-login',
+      '/brand-and-customize/customize-login-text-prompts',
+      '/customize/universal-login-pages/customize-login-text-prompts',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/login/universal-login/prompt-common',
+      '/universal-login/prompt-common',
+      '/universal-login/text-customization-prompts/common',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-common',
+      '/brand-and-customize/customize-login-text-prompts/prompt-common',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-common',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-consent',
+      '/universal-login/text-customization-prompts/consent',
+      '/login/universal-login/prompt-consent',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-consent',
+      '/brand-and-customize/customize-login-text-prompts/prompt-consent',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-consent',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-device-flow',
+      '/universal-login/text-customization-prompts/device-flow',
+      '/login/universal-login/prompt-device-flow',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-device-flow',
+      '/brand-and-customize/customize-login-text-prompts/prompt-device-flow',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-device-flow',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-email-otp-challenge',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-email-otp-challenge',
+      '/brand-and-customize/customize-login-text-prompts/prompt-email-otp-challenge',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-email-otp-challenge',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-email-verification',
+      '/universal-login/text-customization-prompts/email-verification',
+      '/login/universal-login/prompt-email-verification',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-email-verification',
+      '/brand-and-customize/customize-login-text-prompts/prompt-email-verification',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-email-verification',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/univeral-login/prompt-accept-invitation',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-accept-invitation',
+      '/brand-and-customize/customize-login-text-prompts/prompt-accept-invitation',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-accept-invitation',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/login/universal-login/prompt-login',
+      '/universal-login/prompt-login',
+      '/universal-login/text-customization-prompts/login',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-login',
+      '/brand-and-customize/customize-login-text-prompts/prompt-login',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-login',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-login-email-verification',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-login-email-verification',
+      '/brand-and-customize/customize-login-text-prompts/prompt-login-email-verification',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-login-email-verification',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-login-id',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-login-id',
+      '/brand-and-customize/customize-login-text-prompts/prompt-login-id',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-login-id',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-login-password',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-login-password',
+      '/brand-and-customize/customize-login-text-prompts/prompt-login-password',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-login-password',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa',
+      '/universal-login/text-customization-prompts/mfa',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-email',
+      '/universal-login/text-customization-prompts/mfa-email',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-email',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-email',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-email',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-otp',
+      '/universal-login/text-customization-prompts/mfa-otp',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-otp',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-otp',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-otp',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-phone',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-phone',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-phone',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-phone',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-push',
+      '/universal-login/text-customization-prompts/mfa-push',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-push',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-push',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-push',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-recovery-code',
+      '/universal-login/text-customization-prompts/mfa-recovery-code',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-recovery-code',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-recovery-code',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-recovery-code',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-sms',
+      '/universal-login/text-customization-prompts/mfa-sms',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-sms',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-sms',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-sms',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-voice',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-voice',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-voice',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-voice',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-mfa-webauthn',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-mfa-webauthn',
+      '/brand-and-customize/customize-login-text-prompts/prompt-mfa-webauthn',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-mfa-webauthn',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-organization-selection',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-organization-selection',
+      '/brand-and-customize/customize-login-text-prompts/prompt-organization-selection',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-organization-selection',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-reset-password',
+      '/universal-login/text-customization-prompts/reset-password',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-reset-password',
+      '/brand-and-customize/customize-login-text-prompts/prompt-reset-password',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-reset-password',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-signup',
+      '/universal-login/text-customization-prompts/signup',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-signup',
+      '/brand-and-customize/customize-login-text-prompts/prompt-signup',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-signup',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-signup-id',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-signup-id',
+      '/brand-and-customize/customize-login-text-prompts/prompt-signup-id',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-signup-id',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/universal-login/prompt-signup-password',
+      '/brand-and-customize/text-customization-new-universal-login/prompt-signup-password',
+      '/brand-and-customize/customize-login-text-prompts/prompt-signup-password',
+      '/customize/universal-login-pages/customize-login-text-prompts/prompt-signup-password',
+    ],
+    to: '/customize/login-pages/universal-login/customize-text-elements',
+  },
+  {
+    from: [
+      '/scopes/customize-consent-prompts',
+      '/scopes/current/guides/customize-consent-prompt',
+      '/brand-and-customize/customize-consent-prompts',
+      '/customize/universal-login-pages/customize-consent-prompts',
+    ],
+    to: '/customize/login-pages/customize-consent-prompts',
+  },
+  {
+    from: [
+      '/universal-login/custom-error-pages',
+      '/error-pages/custom',
+      '/hosted-pages/custom-error-pages',
+      '/brand-and-customize/custom-error-pages',
+      '/customize/universal-login-pages/custom-error-pages',
+    ],
+    to: '/customize/login-pages/custom-error-pages',
+  },
+  {
+    from: [
+      '/libraries/lock/customize-lock-error-messages',
+      '/libraries/lock/v11/customizing-error-messages',
+      '/libraries/lock/customizing-error-messages',
+      '/brand-and-customize/customize-lock-error-messages',
+      '/customize/customize-lock-error-messages',
+    ],
+    to: '/customize/login-pages/classic-login/customize-lock-error-messages',
+  },
+  {
+    from: [
+      '/universal-login/customize-password-reset-page',
+      '/universal-login/password-reset',
+      '/hosted-pages/password-reset',
+      '/brand-and-customize/customize-password-reset-page',
+      '/customize/universal-login-pages/customize-password-reset-page',
+    ],
+    to: '/customize/login-pages/classic-login/customize-password-reset-page',
+  },
+  {
+    from: [
+      '/multifactor-authentication/administrator/sms-templates',
+      '/mfa/guides/guardian/customize-sms-messages',
+      '/multifactor-authentication/sms-templates',
+      '/mfa/guides/customize-phone-messages',
+      '/mfa/customize-sms-or-voice-messages',
+      '/brand-and-customize/customize-sms-or-voice-messages',
+    ],
+    to: '/customize/customize-sms-or-voice-messages',
+  },
+  {
+    from: ['/login/adopt-oidc-conformant-authentication'],
+    to: '/authenticate/login/oidc-conformant-authentication',
+  },
+  {
+    from: ['/customize/universal-login-pages/customize-new-universal-login-with-the-no-code-editor'],
+    to: '/customize/login-pages/universal-login/customize-themes',
+  },
+
+  {
+    from: ['/customize/universal-login-pages/universal-login-page-templates'],
+    to: '/customize/login-pages/universal-login/customize-templates',
+  },
+
+  {
+    from: ['/customize/universal-login-pages/universal-login-page-customization'],
+    to: '/customize/login-pages/classic-login/customize-with-lock-sdk',
+  },
+
+  /* Internationalization and Localization */
+
+  {
+    from: ['/i18n', '/i18n/i18n-custom-login-page', '/brand-and-customize/i18n'],
+    to: '/customize/internationalization-and-localization',
+  },
+  {
+    from: [
+      '/i18n/universal-login-internationalization',
+      '/universal-login/i18n',
+      '/universal-login/universal-login-internationalization',
+      '/brand-and-customize/i18n/universal-login-internationalization',
+    ],
+    to: '/customize/internationalization-and-localization/universal-login-internationalization',
+  },
+  {
+    from: [
+      '/libraries/lock/v11/i18n',
+      '/libraries/lock/v10/i18n',
+      '/libraries/lock/lock-internationalization',
+      '/brand-and-customize/i18n/lock-internationalization',
+    ],
+    to: '/customize/internationalization-and-localization/lock-internationalization',
+  },
+  {
+    from: [
+      '/libraries/lock-swift/lock-swift-internationalization',
+      '/i18n/i18n-guide-ios',
+      '/libraries/lock-ios/v2/internationalization',
+      '/libraries/lock-swift/lock-swift-internationalization',
+      '/brand-and-customize/i18n/lock-swift-internationalization',
+    ],
+    to: '/customize/internationalization-and-localization/lock-swift-internationalization',
+  },
+  {
+    from: [
+      '/i18n/i18n-guide-android',
+      '/libraries/lock-android/v2/internationalization',
+      '/libraries/lock-android/v1/internationalization',
+      '/libraries/lock-android/lock-android-internationalization',
+      '/brand-and-customize/i18n/lock-android-internationalization',
+    ],
+    to: '/customize/internationalization-and-localization/lock-android-internationalization',
+  },
+  {
+    from: [
+      '/i18n/password-options-translation',
+      '/i18n/password-options',
+      '/i18n/password-strength',
+      '/brand-and-customize/i18n/password-options-translation',
+    ],
+    to: '/customize/internationalization-and-localization/password-options-translation',
+  },
+
+  /* CMS */
+
+  {
+    from: ['/cms/wordpress', '/cms/wordpress/jwt-authentication', '/cms/wordpress-plugin'],
+    to: '/customize/integrations/cms/wordpress-plugin',
+  },
+  {
+    from: ['/cms/wordpress/installation', '/cms/wordpress-plugin/install-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/install-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/configuration', '/cms/wordpress-plugin/configure-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/configure-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/extending', '/cms/wordpress-plugin/extend-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/extend-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/troubleshoot', '/cms/wordpress-plugin/troubleshoot-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/troubleshoot-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/invalid-state', '/cms/wordpress-plugin/troubleshoot-wordpress-plugin-invalid-state-errors'],
+    to: '/customize/integrations/cms/wordpress-plugin/troubleshoot-wordpress-plugin-invalid-state-errors',
+  },
+  {
+    from: ['/cms/wordpress/user-migration', '/cms/wordpress-plugin/user-migration-in-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/user-migration-in-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/user-migration', '/cms/wordpress-plugin/user-migration-in-login-by-auth0'],
+    to: '/customize/integrations/cms/wordpress-plugin/user-migration-in-login-by-auth0',
+  },
+  {
+    from: ['/cms/wordpress/how-does-it-work', '/cms/wordpress-plugin/integrate-with-wordpress'],
+    to: '/customize/integrations/cms/wordpress-plugin/integrate-with-wordpress',
+  },
+
+  /* Compliance */
+
+  {
+    from: ['/compliance-and-certifications', '/compliance'],
+    to: '/secure/data-privacy-and-compliance',
+  },
+  {
+    from: ['/compliance/gdpr/data-processing', '/compliance/data-processing'],
+    to: '/secure/data-privacy-and-compliance/data-processing',
+  },
+  {
+    from: [
+      '/compliance/gdpr/features-aiding-compliance',
+      '/compliance/gdpr/security-advice-for-customers',
+      '/compliance/gdpr/roles-responsibilities',
+      '/compliance/gdpr/gdpr-summary',
+      '/compliance/gdpr/definitions',
+      '/compliance/auth0-gdpr-compliance',
+      '/compliance/gdpr',
+    ],
+    to: '/secure/data-privacy-and-compliance/gdpr',
+  },
+  {
+    from: ['/compliance/gdpr/features-aiding-compliance/user-consent', '/compliance/gdpr/gdpr-conditions-for-consent'],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-conditions-for-consent',
+  },
+  {
+    from: ['/compliance/gdpr/features-aiding-compliance/data-minimization', '/compliance/gdpr/gdpr-data-minimization'],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-data-minimization',
+  },
+  {
+    from: ['/compliance/gdpr/features-aiding-compliance/data-portability', '/compliance/gdpr/gdpr-data-portability'],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-data-portability',
+  },
+  {
+    from: [
+      '/compliance/gdpr/features-aiding-compliance/protect-user-data',
+      '/compliance/gdpr/gdpr-protect-and-secure-user-data',
+    ],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-protect-and-secure-user-data',
+  },
+  {
+    from: [
+      '/compliance/gdpr/features-aiding-compliance/right-to-access-data',
+      '/compliance/gdpr/gdpr-right-to-access-correct-and-erase-data',
+    ],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-right-to-access-correct-and-erase-data',
+  },
+  {
+    from: [
+      '/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui',
+      '/compliance/gdpr/gdpr-track-consent-with-custom-ui',
+    ],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-track-consent-with-custom-ui',
+  },
+  {
+    from: [
+      '/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock',
+      '/compliance/gdpr/gdpr-track-consent-with-lock',
+    ],
+    to: '/secure/data-privacy-and-compliance/gdpr/gdpr-track-consent-with-lock',
+  },
+
+  /* Deploy */
+
+  {
+    from: [
+      '/get-started/deployment-options',
+      '/getting-started/deployment-models',
+      '/overview/deployment-models',
+      '/deployment',
+      '/deploy',
+    ],
+    to: '/deploy-monitor',
+  },
+  {
+    from: [
+      '/private-cloud/private-cloud-deployments/private-cloud-addon-options',
+      '/private-saas-deployment/add-ons',
+      '/private-cloud/add-ons',
+      '/appliance/infrastructure/internet-restricted-deployment',
+      '/private-saas-deployment',
+      '/private-cloud/managed-private-cloud',
+      '/private-cloud',
+      '/appliance',
+      '/appliance/checksum',
+      '/appliance/proxy-updater',
+      '/appliance/update',
+      '/updating-appliance',
+      '/enterprise/private-cloud/overview',
+      '/appliance/dashboard/instrumentation',
+      '/appliance/instrumentation',
+      '/appliance/appliance-overview',
+      '/deploy/private-cloud',
+    ],
+    to: '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws',
+  },
+  {
+    from: [
+      '/services/private-cloud-configuration',
+      '/services/private-saas-configuration',
+      '/private-saas-deployment/onboarding',
+      '/private-saas-deployment/onboarding/private-cloud',
+      '/private-cloud/onboarding',
+      '/private-cloud/onboarding/private-cloud',
+      '/enterprise-support',
+      '/onboarding/appliance-outage',
+      '/onboarding/enterprise-support',
+      '/private-cloud/managed-private-cloud/zones',
+      '/private-cloud/managed-private-cloud/raci',
+      '/private-cloud/private-cloud-onboarding',
+      '/deploy/private-cloud/private-cloud-onboarding',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-onboarding',
+      '/private-cloud/private-cloud-onboarding/private-cloud-ip-domain-and-port-list',
+      '/private-saas-deployment/onboarding/managed-private-cloud/ip-domain-port-list',
+      '/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list',
+      '/appliance/infrastructure/ip-domain-port-list',
+      '/deploy/private-cloud/private-cloud-onboarding/private-cloud-ip-domain-and-port-list',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-onboarding/private-cloud-ip-domain-and-port-list',
+      '/private-cloud/private-cloud-onboarding/standard-private-cloud-infrastructure-requirements',
+      '/private-saas-deployment/private-cloud',
+      '/private-cloud/standard-private-cloud',
+      '/private-saas-deployment/onboarding/managed-private-cloud/infrastructure',
+      '/private-cloud/onboarding/managed-private-cloud/infrastructure',
+      '/private-saas-deployment/managed-private-cloud',
+      '/private-cloud/onboarding/managed-private-cloud',
+      '/private-saas-deployment/onboarding/managed-private-cloud',
+      '/private-cloud/onboarding/managed-private-cloud',
+      '/appliance/infrastructure',
+      '/appliance/infrastructure/security',
+      '/deploy/private-cloud/private-cloud-onboarding/standard-private-cloud-infrastructure-requirements',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-onboarding/standard-private-cloud-infrastructure-requirements',
+      '/private-cloud/private-cloud-operations',
+      '/services/private-saas-management',
+      '/services/private-cloud-management',
+      '/deploy/private-cloud/private-cloud-operations',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-operations',
+      '/private-cloud/private-cloud-migrations',
+      '/deploy/private-cloud/private-cloud-migrations',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-migrations',
+      '/private-cloud/private-cloud-migrations/migrate-from-public-cloud-to-private-cloud',
+      '/deploy/private-cloud/private-cloud-migrations/migrate-from-public-cloud-to-private-cloud',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-migrations/migrate-from-public-cloud-to-private-cloud',
+      '/private-cloud/private-cloud-migrations/migrate-from-standard-private-cloud-to-managed-private-cloud',
+      '/deploy/private-cloud/private-cloud-migrations/migrate-from-standard-private-cloud-to-managed-private-cloud',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-migrations/migrate-from-standard-private-cloud-to-managed-private-cloud',
+      '/private-cloud/private-cloud-migrations/migrate-private-cloud-custom-domains',
+      '/appliance/custom-domains',
+      '/private-saas-deployment/custom-domain-migration',
+      '/private-cloud/custom-domain-migration',
+      '/private-cloud/migrate-private-cloud-custom-domains',
+      '/deploy/private-cloud/private-cloud-migrations/migrate-private-cloud-custom-domains',
+      '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws/private-cloud-migrations/migrate-private-cloud-custom-domains',
+    ],
+    to: '/deploy-monitor/deploy-private-cloud/private-cloud-on-aws',
+  },
+  {
+    from: [
+      '/private-cloud/private-cloud-onboarding/customer-hosted-managed-private-cloud-infrastructure-requirements',
+      '/deploy/private-cloud/private-cloud-onboarding/customer-hosted-managed-private-cloud-infrastructure-requirements',
+      '/private-cloud/private-cloud-onboarding/private-cloud-remote-access-options',
+      '/private-cloud/onboarding/managed-private-cloud/remote-access-options',
+      '/private-cloud/private-cloud-onboarding/private-cloud-remote-access-options',
+      '/deploy/private-cloud/private-cloud-onboarding/private-cloud-remote-access-options',
+    ],
+    to: '/deploy-monitor/deploy-private-cloud',
+  },
+  {
+    from: ['/pre-deployment', '/deploy/pre-deployment'],
+    to: '/deploy-monitor/pre-deployment-checks',
+  },
+  {
+    from: [
+      '/pre-deployment/how-to-run-production-checks',
+      '/pre-deployment/how-to-run-test',
+      '/deploy/pre-deployment/how-to-run-production-checks',
+    ],
+    to: '/deploy-monitor/pre-deployment-checks/how-to-run-production-checks',
+  },
+  {
+    from: [
+      '/deploy/pre-deployment/how-to-run-production-checks/production-check-required-fixes',
+      '/pre-deployment/how-to-run-production-checks/production-check-required-fixes',
+      '/pre-deployment/tests/required',
+      '/deploy/pre-deployment/production-check-required-fixes',
+    ],
+    to: '/deploy-monitor/pre-deployment-checks/production-check-required-fixes',
+  },
+  {
+    from: [
+      '/pre-deployment/how-to-run-production-checks/production-check-recommended-fixes',
+      '/pre-deployment/tests/recommended',
+      '/deploy/pre-deployment/how-to-run-production-checks/production-check-recommended-fixes',
+      '/deploy/pre-deployment/production-check-recommended-fixes',
+    ],
+    to: '/deploy-monitor/pre-deployment-checks/production-check-recommended-fixes',
+  },
+  {
+    from: [
+      '/pre-deployment/how-to-run-production-checks/production-checks-best-practices',
+      '/pre-deployment/tests/best-practice',
+      '/deploy/pre-deployment/how-to-run-production-checks/production-checks-best-practices',
+      '/deploy/pre-deployment/production-checks-best-practices',
+    ],
+    to: '/deploy-monitor/pre-deployment-checks/production-checks-best-practices',
+  },
+  {
+    from: ['/support/predeployment-tests', '/support/testing', '/deploy/pre-deployment/predeployment-tests'],
+    to: '/deploy-monitor/pre-deployment-checks/predeployment-tests',
+  },
+  {
+    from: [
+      '/pre-deployment/pre-launch-tips',
+      '/pre-deployment/prelaunch-tips',
+      '/deploy/pre-deployment/pre-launch-tips',
+    ],
+    to: '/deploy-monitor/pre-deployment-checks/pre-launch-tips',
+  },
+  {
+    from: [
+      '/extensions/using-provided-extensions',
+      '/topics/extensibility',
+      '/extend-integrate',
+      '/extensions/visual-studio-team-services-deploy',
+      '/extensions/visual-studio-team-services-deployments',
+      '/extensions',
+    ],
+    to: '/customize/extensions',
+  },
+  {
+    from: [
+      '/extensions/authorization-extension/v2',
+      '/extensions/authorization-extension/v1',
+      '/api/authorization-dashboard-extension',
+      '/extensions/authorization-dashboard-extension',
+      '/extensions/authorization-extension',
+    ],
+    to: '/customize/extensions/authorization-extension',
+  },
+  {
+    from: ['/extensions/authorization-extension/install-authorization-extension'],
+    to: '/customize/extensions/authorization-extension/install-authorization-extension',
+  },
+  {
+    from: ['/extensions/authorization-extension/configure-authorization-extension'],
+    to: '/customize/extensions/authorization-extension/configure-authorization-extension',
+  },
+  {
+    from: ['/extensions/authorization-extension/enable-api-access-to-authorization-extension'],
+    to: '/customize/extensions/authorization-extension/enable-api-access-to-authorization-extension',
+  },
+  {
+    from: ['/extensions/authorization-extension/import-and-export-authorization-extension-data'],
+    to: '/customize/extensions/authorization-extension/import-and-export-authorization-extension-data',
+  },
+  {
+    from: ['/extensions/authorization-extension/use-rules-with-the-authorization-extension'],
+    to: '/customize/extensions/authorization-extension/use-rules-with-the-authorization-extension',
+  },
+  {
+    from: [
+      '/extensions/authorization-extension/v2/implementation/setup',
+      '/extensions/authorization-extension/set-up-authorization-extension-users',
+    ],
+    to: '/customize/extensions/authorization-extension/set-up-authorization-extension-users',
+  },
+  {
+    from: [
+      '/get-started/dashboard/create-sso-dashboard-application',
+      '/dashboard/guides/extensions/sso-dashboard-create-app',
+      '/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-install-extension',
+      '/extensions/single-sign-on-dashboard-extension/install-sso-dashboard-extension',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/install-sso-dashboard-extension',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-add-apps',
+      '/extensions/single-sign-on-dashboard-extension/add-applications-to-the-sso-dashboard',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/add-applications-to-the-sso-dashboard',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-update-apps',
+      '/extensions/single-sign-on-dashboard-extension/update-applications-on-the-sso-dashboard',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/update-applications-on-the-sso-dashboard',
+  },
+  {
+    from: ['/deploy/private-cloud-on-azure'],
+    to: '/deploy-monitor/deploy-private-cloud/private-cloud-on-azure',
+  },
+
+  /* Deploy CLI Tool */
+
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/install-and-configure-the-deploy-cli-tool'],
+    to: '/deploy-monitor/deploy-cli-tool',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/create-and-configure-the-deploy-cli-application'],
+    to: '/deploy-monitor/deploy-cli-tool',
+  },
+  {
+    from: [
+      '/deploy-monitor/auth0-deploy-cli/configuring-the-deploy-cli',
+      '/deploy-monitor/deploy-cli-tool/configuring-the-deploy-cli',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/configure-the-deploy-cli',
+  },
+  {
+    from: [
+      '/deploy-monitor/deploy-cli-tool/call-deploy-cli-tool-programmatically',
+      '/deploy-monitor/deploy-cli-tool/using-as-a-node-module',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/use-as-a-node-module',
+  },
+  {
+    from: [
+      '/deploy-monitor/deploy-cli-tool/incorporate-deploy-cli-into-build-environment',
+      '/deploy-monitor/deploy-cli-tool/incorporating-into-multi-environment-workflows',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/incorporate-into-multi-environment-workflows',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/import-export-tenant-configuration-to-yaml-file'],
+    to: '/deploy-monitor/deploy-cli-tool/keyword-replacement',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/import-export-tenant-configuration-to-directory-structure'],
+    to: '/deploy-monitor/deploy-cli-tool/keyword-replacement',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/environment-variables-and-keyword-mappings'],
+    to: '/deploy-monitor/deploy-cli-tool/keyword-replacement',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/deploy-cli-tool-options', '/deploy-monitor/deploy-cli-tool/using-as-a-cli'],
+    to: '/deploy-monitor/deploy-cli-tool/use-as-a-cli',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/auth0-terraform-provider'],
+    to: '/deploy-monitor/auth0-terraform-provider',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/how-to-contribute'],
+    to: '/deploy-monitor/deploy-cli-tool',
+  },
+  {
+    from: ['/deploy-monitor/deploy-cli-tool/excluding-resources-from-management'],
+    to: '/deploy-monitor/deploy-cli-tool/exclude-resources-from-management',
+  },
+
+  /* Extensions */
+
+  {
+    from: [
+      '/connector',
+      '/connector/overview',
+      '/connector/considerations-non-ad',
+      '/ad-ldap-connector',
+      '/extensions/ad-ldap-connector',
+      '/customize/extensions/ad-ldap-connector',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector',
+  },
+  {
+    from: [
+      '/extensions/ad-ldap-connector-health-monitor',
+      '/extensions/ad-ldap-connector/ad-ldap-connector-health-monitor',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-health-monitor',
+    ],
+    to: '/customize/extensions/ad-ldap-connector-health-monitor',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3',
+      '/extensions/delegated-admin/v2',
+      '/extensions/delegated-admin',
+      '/extensions/delegated-administration-extension',
+    ],
+    to: '/customize/extensions/delegated-administration-extension',
+  },
+  {
+    from: ['/extensions/delegated-administration-extension/delegated-administration-manage-users'],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-manage-users',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks',
+      '/extensions/delegated-admin/v2/hooks',
+      '/extensions/delegated-admin/hooks',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks/access',
+      '/extensions/delegated-admin/v2/hooks/access',
+      '/extensions/delegated-admin/hooks/access',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-access-hook',
+      '/extensions/delegated-administration-extension/delegated-administration-access-hook',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-access-hook',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks/filter',
+      '/extensions/delegated-admin/v2/hooks/filter',
+      '/extensions/delegated-admin/hooks/filter',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-filter-hook',
+      '/extensions/delegated-administration-extension/delegated-administration-filter-hook',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-filter-hook',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks/membership',
+      '/extensions/delegated-admin/v2/hooks/membership',
+      '/extensions/delegated-admin/hooks/membership',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-memberships-query-hook',
+      '/extensions/delegated-administration-extension/delegated-administration-memberships-query-hook',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-memberships-query-hook',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks/settings',
+      '/extensions/delegated-admin/v2/hooks/settings',
+      '/extensions/delegated-admin/hooks/settings',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-settings-query-hook',
+      '/extensions/delegated-administration-extension/delegated-administration-settings-query-hook',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-settings-query-hook',
+  },
+  {
+    from: [
+      '/extensions/delegated-admin/v3/hooks/write',
+      '/extensions/delegated-admin/v2/hooks/write',
+      '/extensions/delegated-admin/hooks/write',
+      '/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-write-hook',
+      '/extensions/delegated-administration-extension/delegated-administration-write-hook',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/delegated-administration-hooks/delegated-administration-write-hook',
+  },
+  {
+    from: ['/extensions/sso-dashboard', '/extensions/single-sign-on-dashboard-extension'],
+    to: '/customize/extensions/single-sign-on-dashboard-extension',
+  },
+  {
+    from: [
+      '/get-started/dashboard/create-sso-dashboard-application',
+      '/dashboard/guides/extensions/sso-dashboard-create-app',
+      '/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-install-extension',
+      '/extensions/single-sign-on-dashboard-extension/install-sso-dashboard-extension',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/install-sso-dashboard-extension',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-add-apps',
+      '/extensions/single-sign-on-dashboard-extension/add-applications-to-the-sso-dashboard',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/add-applications-to-the-sso-dashboard',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/sso-dashboard-update-apps',
+      '/extensions/single-sign-on-dashboard-extension/update-applications-on-the-sso-dashboard',
+    ],
+    to: '/customize/extensions/single-sign-on-dashboard-extension/update-applications-on-the-sso-dashboard',
+  },
+
+  /* LDAP Connector */
+
+  {
+    from: ['/protocols/ldap-protocol', '/protocols/ldap'],
+    to: '/authenticate/protocols/ldap-protocol',
+  },
+  {
+    from: [
+      '/connector/prerequisites',
+      '/ad-ldap-connector/ad-ldap-connector-requirements',
+      '/extensions/ad-ldap-connector/ad-ldap-connector-requirements',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-requirements',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-requirements',
+  },
+  {
+    from: [
+      '/adldap-x',
+      '/connector/install-other-platforms',
+      '/connector/install',
+      '/adldap-auth',
+      '/extensions/ad-ldap-connector/install-configure-ad-ldap-connector',
+      '/customize/extensions/ad-ldap-connector/install-configure-ad-ldap-connector',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/install-configure-ad-ldap-connector',
+  },
+  {
+    from: [
+      '/connector/client-certificates',
+      '/ad-ldap-connector/configure-ad-ldap-connector-authentication-with-client-certificates',
+      '/extensions/ad-ldap-connector/configure-ad-ldap-connector-client-certificates',
+      '/customize/extensions/ad-ldap-connector/configure-ad-ldap-connector-client-certificates',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/configure-ad-ldap-connector-client-certificates',
+  },
+  {
+    from: [
+      '/connector/kerberos',
+      '/ad-ldap-connector/configure-ad-ldap-connector-authentication-with-kerberos',
+      '/extensions/ad-ldap-connector/configure-ad-ldap-connector-with-kerberos',
+      '/customize/extensions/ad-ldap-connector/configure-ad-ldap-connector-with-kerberos',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/configure-ad-ldap-connector-with-kerberos',
+  },
+  {
+    from: [
+      '/extensions/ad-ldap-connector/ad-ldap-connector-config-file-schema',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-config-file-schema',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-config-file-schema',
+  },
+  {
+    from: [
+      '/extensions/ad-ldap-connector/import-export-ad-ldap-connector-configs',
+      '/customize/extensions/ad-ldap-connector/import-export-ad-ldap-connector-configs',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/import-export-ad-ldap-connector-configs',
+  },
+  {
+    from: [
+      '/extensions/ad-ldap-connector/map-ad-ldap-profile-attributes-to-auth0',
+      '/customize/extensions/ad-ldap-connector/map-ad-ldap-profile-attributes-to-auth0',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/map-ad-ldap-profile-attributes-to-auth0',
+  },
+  {
+    from: [
+      '/connector/high-availability',
+      '/ad-ldap-connector/ad-ldap-high-availability',
+      '/extensions/ad-ldap-connector/ad-ldap-high-availability',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-high-availability',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-high-availability',
+  },
+  {
+    from: [
+      '/dashboard/guides/connections/disable-cache-ad-ldap',
+      '/extensions/ad-ldap-connector/disable-credential-caching',
+      '/customize/extensions/ad-ldap-connector/disable-credential-caching',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/disable-credential-caching',
+  },
+  {
+    from: [
+      '/connector/scom-monitoring',
+      '/ad-ldap-connector/ad-ldap-connector-scorm',
+      '/extensions/ad-ldap-connector/ad-ldap-connector-scom',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-scom',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-scom',
+  },
+  {
+    from: [
+      '/connector/modify',
+      '/ad-ldap-connector/ad-ldap-connectors-to-auth0',
+      '/extensions/ad-ldap-connector/ad-ldap-connector-to-auth0',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-to-auth0',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-to-auth0',
+  },
+  {
+    from: [
+      '/connector/test-dc',
+      '/ad-ldap-connector/ad-ldap-connector-test-environment',
+      '/extensions/ad-ldap-connector/ad-ldap-connector-test-environment',
+      '/customize/extensions/ad-ldap-connector/ad-ldap-connector-test-environment',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-test-environment',
+  },
+  {
+    from: [
+      '/connector/update',
+      '/ad-ldap-connector/update-ad-ldap-connectors',
+      '/extensions/ad-ldap-connector/update-ad-ldap-connectors',
+      '/customize/extensions/ad-ldap-connector/update-ad-ldap-connectors',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/update-ad-ldap-connectors',
+  },
+  {
+    from: ['/extensions/account-link', '/extensions/account-link-extension'],
+    to: '/customize/extensions/account-link-extension',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-extensions',
+      '/logs/log-export-extensions',
+      '/extensions/log-export-extensions',
+      '/customize/extensions/export-log-events-with-extensions',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-application-insights',
+      '/extensions/application-insight',
+      '/extensions/log-export-extensions/export-logs-to-application-insights',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-application-insights',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-cloudwatch',
+      '/extensions/cloudwatch',
+      '/extensions/log-export-extensions/export-logs-to-cloudwatch',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-cloudwatch',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-azure-blob-storage',
+      '/extensions/azure-blob-storage',
+      '/extensions/log-export-extensions/export-logs-to-azure-blob-storage',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-azure-blob-storage',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-logentries',
+      '/extensions/logentries',
+      '/extensions/log-export-extensions/export-logs-to-logentries',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-logentries',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-loggly',
+      '/extensions/loggly',
+      '/extensions/log-export-extensions/export-logs-to-loggly',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-loggly',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-logstash',
+      '/extensions/logstash',
+      '/extensions/log-export-extensions/export-logs-to-logstash',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-logstash',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-mixpanel',
+      '/extensions/mixpanel',
+      '/extensions/log-export-extensions/export-logs-to-mixpanel',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-mixpanel',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-papertrail',
+      '/extensions/papertrail',
+      '/extensions/log-export-extensions/export-logs-to-papertrail',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-papertrail',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-segment',
+      '/extensions/segment',
+      '/extensions/log-export-extensions/export-logs-to-segment',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-segment',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/export-logs-to-splunk',
+      '/extensions/splunk',
+      '/extensions/log-export-extensions/export-logs-to-splunk',
+      '/customize/extensions/export-log-events-with-extensions/export-logs-to-splunk',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/extensions/auth0-logs-to-sumo-logic',
+      '/extensions/sumologic',
+      '/extensions/log-export-extensions/auth0-logs-to-sumo-logic',
+      '/customize/extensions/export-log-events-with-extensions/auth0-logs-to-sumo-logic',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: ['/extensions/authentication-api-debugger', '/extensions/authentication-api-debugger-extension'],
+    to: '/customize/extensions/authentication-api-debugger-extension',
+  },
+  {
+    from: [
+      '/extensions/authentication-api-webhooks',
+      '/extensions/auth0-authentication-api-webhooks',
+      '/customize/extensions/auth0-authentication-api-webhooks',
+    ],
+    to: '/customize/extensions',
+  },
+  {
+    from: ['/extensions/user-import-export', '/extensions/user-import-export-extension'],
+    to: '/customize/extensions/user-import-export-extension',
+  },
+  {
+    from: ['/extensions/bitbucket-deploy', '/extensions/bitbucket-deployments'],
+    to: 'https://marketplace.auth0.com/integrations/bitbucket-pipeline',
+  },
+  {
+    from: [
+      '/extensions/custom-social-connections',
+      '/extensions/custom-social-extensions',
+      '/connections/adding-generic-oauth1-connection',
+      '/oauth2',
+      '/connections/social/oauth2',
+    ],
+    to: '/authenticate/identity-providers/social-identity-providers/oauth2',
+  },
+  {
+    from: ['/extensions/github-deploy', '/extensions/github-deployments'],
+    to: 'https://marketplace.auth0.com/integrations/github-actions',
+  },
+  {
+    from: ['/extensions/gitlab-deploy', '/extensions/gitlab-deployments'],
+    to: 'https://marketplace.auth0.com/integrations/gitlab-pipeline',
+  },
+  {
+    from: [
+      '/extensions/management-api-webhooks',
+      '/extensions/auth0-management-api-webhooks',
+      '/customize/extensions/auth0-management-api-webhooks',
+    ],
+    to: '/customize/extensions',
+  },
+  {
+    from: ['/extensions/realtime-webtask-logs', '/extensions/real-time-webtask-logs'],
+    to: '/customize/extensions/real-time-webtask-logs',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/delegated-admin-create-app',
+      '/extensions/delegated-administration-extension/create-delegated-admin-applications',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/create-delegated-admin-applications',
+  },
+  {
+    from: [
+      '/dashboard/guides/extensions/delegated-admin-install-extension',
+      '/dashboard/guides/extensions/delegated-admin-use-extension',
+      '/extensions/delegated-administration-extension/install-delegated-admin-extension',
+    ],
+    to: '/customize/extensions/delegated-administration-extension/install-delegated-admin-extension',
+  },
+
+  /* Deploy CLI Tool */
+
+  {
+    from: [
+      '/extensions/deploy-cli-tool',
+      '/extensions/deploy-cli',
+      '/extensions/deploy-cli/references/whats-new',
+      '/extensions/deploy-cli/references/whats-new-v2',
+      '/deploy/deploy-cli-tool/whats-new-in-deploy-cli-tool',
+      '/deploy/deploy-cli-tool',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli-tool/call-deploy-cli-tool-programmatically',
+      '/extensions/deploy-cli/guides/call-deploy-cli-programmatically',
+      '/deploy/deploy-cli-tool/call-deploy-cli-tool-programmatically',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/call-deploy-cli-tool-programmatically',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/guides/create-deploy-cli-application-manually',
+      '/extensions/deploy-cli-tool/create-and-configure-the-deploy-cli-application-manually',
+      '/extensions/deploy-cli-tool/create-and-configure-the-deploy-cli-application',
+      '/deploy/deploy-cli-tool/create-and-configure-the-deploy-cli-application',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/create-and-configure-the-deploy-cli-application',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/guides/import-export-directory-structure',
+      '/extensions/deploy-cli-tool/import-export-tenant-configuration-to-directory-structure',
+      '/deploy/deploy-cli-tool/import-export-tenant-configuration-to-directory-structure',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/import-export-tenant-configuration-to-directory-structure',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/guides/import-export-yaml-file',
+      '/extensions/deploy-cli-tool/import-export-tenant-configuration-to-yaml-file',
+      '/deploy/deploy-cli-tool/import-export-tenant-configuration-to-yaml-file',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/import-export-tenant-configuration-to-yaml-file',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment',
+      '/extensions/deploy-cli-tool/incorporate-deploy-cli-into-build-environment',
+      '/deploy/deploy-cli-tool/incorporate-deploy-cli-into-build-environment',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/incorporate-deploy-cli-into-build-environment',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/guides/install-deploy-cli',
+      '/extensions/deploy-cli-tool/install-and-configure-the-deploy-cli-tool',
+      '/deploy/deploy-cli-tool/install-and-configure-the-deploy-cli-tool',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/install-and-configure-the-deploy-cli-tool',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/references/deploy-cli-options',
+      '/extensions/deploy-cli-tool/deploy-cli-tool-options',
+      '/deploy/deploy-cli-tool/deploy-cli-tool-options',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/deploy-cli-tool-options',
+  },
+  {
+    from: [
+      '/extensions/deploy-cli/references/environment-variables-keyword-mappings',
+      '/extensions/deploy-cli-tool/environment-variables-and-keyword-mappings',
+      '/deploy/deploy-cli-tool/environment-variables-and-keyword-mappings',
+    ],
+    to: '/deploy-monitor/deploy-cli-tool/environment-variables-and-keyword-mappings',
+  },
+
+  /* Get Started */
+
+  {
+    from: ['/configuration-overview', '/config', '/configure', '/getting-started'],
+    to: '/get-started',
+  },
+  {
+    from: ['/overview', '/get-started/overview', '/getting-started/overview'],
+    to: '/get-started/auth0-overview',
+  },
+  {
+    from: ['/get-started/dashboard'],
+    to: '/get-started/auth0-overview/dashboard',
+  },
+  {
+    from: ['/get-started/dashboard/activity'],
+    to: '/get-started/auth0-overview/dashboard/activity',
+  },
+  {
+    from: [
+      '/authorization/authentication-and-authorization',
+      '/authorization/concepts/authz-and-authn',
+      '/application-auth/current',
+      '/application-auth/legacy',
+      '/application-auth',
+      '/get-started/authentication-and-authorization',
+    ],
+    to: '/get-started/identity-fundamentals/authentication-and-authorization',
+  },
+  {
+    from: ['/getting-started/set-up-app', '/applications/set-up-an-application', '/get-started/create-apps'],
+    to: '/get-started/auth0-overview/create-applications',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/register-app-m2m',
+      '/applications/application-settings/non-interactive',
+      '/applications/application-settings/machine-to-machine',
+      '/applications/machine-to-machine',
+      '/applications/set-up-an-application/register-machine-to-machine-applications',
+      '/get-started/create-apps/machine-to-machine-apps',
+    ],
+    to: '/get-started/auth0-overview/create-applications/machine-to-machine-apps',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/register-app-native',
+      '/applications/application-settings/native',
+      '/applications/native',
+      '/applications/set-up-an-application/register-native-applications',
+      '/get-started/create-apps/native-apps',
+    ],
+    to: '/get-started/auth0-overview/create-applications/native-apps',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/register-app-regular-web',
+      '/applications/application-settings/regular-web-app',
+      '/applications/webapps',
+      '/applications/register-regular-web-applications',
+      '/applications/set-up-an-application/register-regular-web-applications',
+      '/get-started/create-apps/regular-web-apps',
+    ],
+    to: '/get-started/auth0-overview/create-applications/regular-web-apps',
+  },
+  {
+    from: [
+      '/dashboard/guides/applications/register-app-spa',
+      '/applications/spa',
+      '/applications/application-settings/single-page-app',
+      '/applications/register-single-page-app',
+      '/applications/set-up-an-application/register-single-page-app',
+      '/get-started/create-apps/single-page-web-apps',
+    ],
+    to: '/get-started/auth0-overview/create-applications/single-page-web-apps',
+  },
+  {
+    from: ['/getting-started/set-up-api', '/dashboard/reference/views-api', '/get-started/set-up-apis'],
+    to: '/get-started/auth0-overview/set-up-apis',
+  },
+  {
+    from: [
+      '/dashboard',
+      '/getting-started/dashboard-overview',
+      '/get-started/dashboard/upcoming-dashboard-changes',
+      '/get-started/dashboard',
+    ],
+    to: '/get-started/auth0-overview/dashboard',
+  },
+  {
+    from: [
+      '/get-started/learn-the-basics',
+      '/getting-started/the-basics',
+      '/getting-started/create-tenant',
+      '/get-started/create-tenants',
+    ],
+    to: '/get-started/auth0-overview/create-tenants',
+  },
+  {
+    from: ['/dev-lifecycle/child-tenants', '/get-started/create-tenants/child-tenants'],
+    to: '/get-started/auth0-overview/create-tenants/child-tenants',
+  },
+  {
+    from: [
+      '/dev-lifecycle/set-up-multiple-environments',
+      '/dev-lifecycle/setting-up-env',
+      '/get-started/create-tenants/set-up-multiple-environments',
+    ],
+    to: '/get-started/auth0-overview/create-tenants/set-up-multiple-environments',
+  },
+  {
+    from: [
+      '/get-started/dashboard/create-multiple-tenants',
+      '/dashboard/guides/tenants/create-multiple-tenants',
+      '/get-started/create-tenants/create-multiple-tenants',
+    ],
+    to: '/get-started/auth0-overview/create-tenants/create-multiple-tenants',
+  },
+  {
+    from: [
+      '/dashboard/guides/connections/set-up-connections-social',
+      '/get-started/dashboard/set-up-social-connections',
+    ],
+    to: 'https://marketplace.auth0.com/features/social-connections',
+  },
+  {
+    from: [
+      '/dashboard/guides/connections/test-connections-enterprise',
+      '/get-started/dashboard/test-enterprise-connections',
+      '/connections/enterprise/test-enterprise-connections',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/test-enterprise-connections',
+  },
+  {
+    from: [
+      '/dashboard/guides/connections/view-connections',
+      '/get-started/dashboard/view-connections',
+      '/connections/view-connections',
+    ],
+    to: '/authenticate/identity-providers/view-connections',
+  },
+  {
+    from: [
+      '/dashboard/guides/connections/enable-connections-enterprise',
+      '/get-started/dashboard/enable-enterprise-connections',
+      '/connections/enterprise/enable-enterprise-connections',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/enable-enterprise-connections',
+  },
+  {
+    from: [
+      '/api/management/guides/connections/promote-connection-domain-level',
+      '/get-started/dashboard/promote-connections-to-domain-level',
+      '/connections/promote-connections-to-domain-level',
+    ],
+    to: '/authenticate/identity-providers/promote-connections-to-domain-level',
+  },
+  {
+    from: [
+      '/api/management/guides/connections/retrieve-connection-options',
+      '/api/management/guides/retrieve-connection-options',
+      '/get-started/dashboard/retrieve-connection-options',
+      '/connections/retrieve-connection-options',
+    ],
+    to: '/authenticate/identity-providers/retrieve-connection-options',
+  },
+  {
+    from: [
+      '/dashboard-access/dashboard-roles',
+      '/dashboard-access/manage-dashboard-users',
+      '/dashboard/manage-dashboard-admins',
+      '/tutorials/manage-dashboard-admins',
+      '/get-started/dashboard/manage-dashboard-users',
+      '/dashboard-access',
+    ],
+    to: '/get-started/manage-dashboard-access',
+  },
+  {
+    from: ['/dashboard-access/dashboard-roles/feature-access-by-role', '/dashboard-access/feature-access-by-role'],
+    to: '/get-started/manage-dashboard-access/feature-access-by-role',
+  },
+  {
+    from: ['/dashboard-access/add-change-remove-mfa/add-multi-factor-authentication-for-auth0-dashboard-access'],
+    to: '/get-started/manage-dashboard-access/add-change-remove-mfa/add-mfa',
+  },
+  {
+    from: ['/dashboard-access/add-dashboard-users'],
+    to: '/get-started/manage-dashboard-access/add-dashboard-users',
+  },
+
+  /* Hooks */
+
+  {
+    from: [
+      '/hooks/cli',
+      '/auth0-hooks/cli',
+      '/hooks/dashboard',
+      '/hooks/overview',
+      '/auth0-hooks',
+      '/auth0-hooks/dashboard',
+      '/hooks',
+    ],
+    to: '/customize/hooks',
+  },
+  {
+    from: [
+      '/hooks/concepts/extensibility-points',
+      '/hooks/concepts/overview-extensibility-points',
+      '/hooks/extensibility-points',
+      '/customize/hooks/extensibility-points',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/hooks/concepts/credentials-exchange-extensibility-point',
+      '/hooks/guides/use-the-credentials-exchange-extensibility-point',
+      '/hooks/client-credentials-exchange',
+      '/hooks/extensibility-points/credentials-exchange',
+      '/hooks/extensibility-points/client-credentials-exchange',
+      '/customize/hooks/extensibility-points/client-credentials-exchange',
+    ],
+    to: '/customize/hooks',
+  },
+  {
+    from: [
+      '/hooks/create',
+      '/hooks/dashboard/create-delete',
+      '/hooks/cli/create-delete',
+      '/hooks/guides/create-hooks-using-cli',
+      '/hooks/guides/create-hooks-using-dashboard',
+      '/auth0-hooks/cli/create-delete',
+      '/hooks/create-hooks',
+      '/create-hooks',
+    ],
+    to: '/customize/hooks/create-hooks',
+  },
+  {
+    from: [
+      '/hooks/delete',
+      '/hooks/guides/delete-hooks-using-cli',
+      '/hooks/guides/delete-hooks-using-dashboard',
+      '/hooks/delete-hooks',
+    ],
+    to: '/customize/hooks/delete-hooks',
+  },
+  {
+    from: [
+      '/hooks/enable-disable',
+      '/hooks/cli/enable-disable',
+      '/hooks/dashboard/enable-disable',
+      '/hooks/guides/enable-disable-hooks-using-cli',
+      '/hooks/guides/enable-disable-hooks-using-dashboard',
+      '/auth0-hooks/cli/enable-disable',
+      '/hooks/enable-disable-hooks',
+    ],
+    to: '/customize/hooks/enable-disable-hooks',
+  },
+  {
+    from: [
+      '/hooks/guides/post-change-password',
+      '/hooks/post-change-password',
+      '/hooks/extensibility-points/post-change-password',
+      '/customize/hooks/extensibility-points/post-change-password',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/hooks/concepts/post-user-registration-extensibility-point',
+      '/hooks/guides/use-the-post-user-registration-extensibility-point',
+      '/hooks/post-user-registration',
+      '/hooks/extensibility-points/post-user-registration',
+      '/customize/hooks/extensibility-points/post-user-registration',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/hooks/concepts/pre-user-registration-extensibility-point',
+      '/hooks/guides/use-the-pre-user-registration-extensibility-point',
+      '/auth0-hooks/extensibility-points/pre-user-registration',
+      '/hooks/pre-user-registration',
+      '/hooks/extensibility-points/pre-user-registration',
+      '/customize/hooks/extensibility-points/pre-user-registration',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: ['/hooks/secrets/create', '/hooks/hook-secrets/create-hook-secrets'],
+    to: '/customize/hooks/hook-secrets/create-hook-secrets',
+  },
+  {
+    from: ['/hooks/secrets/delete', '/hooks/hook-secrets/delete-hook-secrets'],
+    to: '/customize/hooks/hook-secrets/delete-hook-secrets',
+  },
+  {
+    from: ['/hooks/secrets', '/hooks/hook-secrets'],
+    to: '/customize/hooks/hook-secrets',
+  },
+  {
+    from: ['/hooks/secrets/update', '/hooks/hook-secrets/update-hook-secrets'],
+    to: '/customize/hooks/hook-secrets/update-hook-secrets',
+  },
+  {
+    from: ['/hooks/secrets/view', '/hooks/hook-secrets/view-hook-secrets'],
+    to: '/customize/hooks/hook-secrets/view-hook-secrets',
+  },
+  {
+    from: [
+      '/hooks/update',
+      '/hooks/cli/edit',
+      '/hooks/dashboard/edit',
+      '/hooks/guides/edit-hooks-using-cli',
+      '/hooks/guides/edit-hooks-using-dashboard',
+      '/hooks/update-hooks',
+    ],
+    to: '/customize/hooks/update-hooks',
+  },
+  {
+    from: [
+      '/hooks/view-logs',
+      '/hooks/cli/logs',
+      '/hooks/logs',
+      '/hooks/guides/logging-hooks-using-cli',
+      '/auth0-hooks/cli/logs',
+      '/hooks/view-logs-for-hooks',
+    ],
+    to: '/customize/hooks/view-logs-for-hooks',
+  },
+  {
+    from: ['/hooks/view', '/hooks/view-hooks'],
+    to: '/customize/hooks/view-hooks',
+  },
+  {
+    from: [
+      '/hooks/extensibility-points/send-phone-message',
+      '/customize/hooks/extensibility-points/send-phone-message',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+
+  /* Identity Labs */
+
+  {
+    from: ['/labs', '/identity-labs'],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/01-web-sign-in', '/identity-labs/lab-1-web-sign-in'],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/01-web-sign-in/exercise-01', '/identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-1'],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/01-web-sign-in/exercise-02', '/identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-2'],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/02-calling-an-api', '/identity-labs/identity-lab-2-calling-api'],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/02-calling-an-api/exercise-01',
+      '/identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-1',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/02-calling-an-api/exercise-02',
+      '/identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-2',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/02-calling-an-api/exercise-03',
+      '/identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-3',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/03-mobile-native-app', '/identity-labs/lab-3-mobile-native-app'],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/03-mobile-native-app/exercise-01',
+      '/identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-1',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/03-mobile-native-app/exercise-02',
+      '/identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-2',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/03-mobile-native-app/exercise-03',
+      '/identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-3',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: ['/identity-labs/04-single-page-app', '/identity-labs/lab-4-single-page-app'],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/04-single-page-app/exercise-01',
+      '/identity-labs/lab-4-single-page-app/identity-lab-4-exercise-1',
+    ],
+    to: '/get-started',
+  },
+  {
+    from: [
+      '/identity-labs/04-single-page-app/exercise-02',
+      '/identity-labs/lab-4-single-page-app/identity-lab-4-exercise-2',
+    ],
+    to: '/get-started',
+  },
+
+  /* Integrations */
+
+  {
+    from: ['/integration', '/integrations'],
+    to: '/customize/integrations',
+  },
+  {
+    from: ['/aws-api-setup', '/integrations/how-to-set-up-aws-for-delegated-authentication'],
+    to: '/customize/integrations/aws/how-to-set-up-aws-for-delegated-authentication',
+  },
+  {
+    from: [
+      '/integrations/aws/sso',
+      '/configure-amazon-web-services-for-sso',
+      '/integrations/aws/configure-amazon-web-services-for-sso',
+    ],
+    to: '/customize/integrations/aws/configure-amazon-web-services-for-sso',
+  },
+  {
+    from: [
+      '/integrations/aws/tokens',
+      '/integrations/call-aws-apis-and-resources-with-tokens',
+      '/integrations/aws-api-gateway-delegation',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation',
+  },
+  {
+    from: [
+      '/scenarios/amazon-cognito',
+      '/tutorials/integrating-auth0-amazon-cognito-mobile-apps',
+      '/integrations/integrating-auth0-amazon-cognito-mobile-apps',
+      '/integrations/integrate-with-amazon-cognito',
+      '/integrations/amazon-cognito',
+    ],
+    to: '/customize/integrations/aws/amazon-cognito',
+  },
+  {
+    from: [
+      '/scenarios-mqtt',
+      '/tutorials/authenticating-devices-using-mqtt',
+      '/integrations/authenticating-devices-using-mqtt',
+      '/integrations/authenticate-devices-using-mqtt',
+    ],
+    to: '/customize/integrations/authenticate-devices-using-mqtt',
+  },
+  {
+    from: [
+      '/scenarios-tessel',
+      '/tutorials/authenticating-a-tessel-device',
+      '/integrations/authenticating-a-tessel-device',
+      '/integrations/authenticating-and-authorizing-a-tessel-device-with-auth0',
+    ],
+    to: '/customize/integrations/authenticating-and-authorizing-a-tessel-device-with-auth0',
+  },
+  {
+    from: ['/aws', '/awsapi-tutorial', '/integrations/aws'],
+    to: '/customize/integrations/aws',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation',
+      '/integrations/aws-api-gateway',
+      '/integrations/aws-api-gateway-delegation',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/part-1',
+      '/integrations/aws-api-gateway/part-1',
+      '/integrations/aws-api-gateway/aws-api-gateway-step-1',
+      '/integrations/aws-api-gateway-delegation-1',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation/aws-api-gateway-delegation-1',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/part-2',
+      '/integrations/aws-api-gateway/part-2',
+      '/integrations/aws-api-gateway/aws-api-gateway-step-2',
+      '/integrations/aws-api-gateway-delegation-2',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation/aws-api-gateway-delegation-2',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/part-3',
+      '/integrations/aws-api-gateway/part-3',
+      '/integrations/aws-api-gateway/aws-api-gateway-step-3',
+      '/integrations/aws-api-gateway-delegation-3',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation/aws-api-gateway-delegation-3',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/part-4',
+      '/integrations/aws-api-gateway/part-4',
+      '/integrations/aws-api-gateway/aws-api-gateway-step-4',
+      '/integrations/aws-api-gateway-delegation-4',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation/aws-api-gateway-delegation-4',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/part-5',
+      '/integrations/aws-api-gateway/part-5',
+      '/integrations/aws-api-gateway/aws-api-gateway-step-5',
+      '/integrations/aws-api-gateway-delegation-5',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-delegation/aws-api-gateway-delegation-5',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/delegation/secure-api-with-cognito',
+      '/integrations/aws-api-gateway/secure-api-with-cognito',
+      '/integrations/aws-api-gateway-cognito',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-cognito',
+  },
+  {
+    from: [
+      '/integrations/aws-api-gateway/custom-authorizers',
+      '/integrations/aws-api-gateway/custom-authorizers/part-1',
+      '/integrations/aws-api-gateway/custom-authorizers/part-2',
+      '/integrations/aws-api-gateway/custom-authorizers/part-3',
+      '/integrations/aws-api-gateway/custom-authorizers/part-4',
+      '/integrations/aws-api-gateway-custom-authorizers',
+    ],
+    to: '/customize/integrations/aws/aws-api-gateway-custom-authorizers',
+  },
+  {
+    from: [
+      '/sharepoint-apps',
+      '/integrations/sharepoint-apps',
+      '/integrations/connecting-provider-hosted-apps-to-sharepoint-online',
+    ],
+    to: '/customize/integrations/connecting-provider-hosted-apps-to-sharepoint-online',
+  },
+  {
+    from: [
+      '/integrations/google-cloud-platform',
+      '/tutorials/google-cloud-platform',
+      '/integrations/google-cloud-endpoints',
+    ],
+    to: '/customize/integrations/google-cloud-endpoints',
+  },
+  {
+    from: ['/integrations/marketing/salesforce', '/integrations/marketing/export-user-data-salesforce'],
+    to: '/customize/integrations/marketing-tool-integrations/export-user-data-salesforce',
+  },
+  {
+    from: [
+      '/tutorials/office365-connection-deprecation-guide',
+      '/integrations/office365-connection-deprecation-guide',
+      '/office365-deprecated',
+      '/integrations/migrate-office365-connections-to-windows-azure-ad',
+    ],
+    to: '/customize/integrations/migrate-office365-connections-to-windows-azure-ad',
+  },
+  {
+    from: [
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-nodejs-16-to-nodejs-18',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-nodejs-16-to-nodejs-18',
+  },
+  {
+    from: [
+      '/tutorials/using-auth0-to-secure-a-cli',
+      '/integrations/using-auth0-to-secure-a-cli',
+      '/tutorials/using-auth0-to-secure-an-api',
+      '/cli',
+      '/integrations/secure-a-cli-with-auth0',
+    ],
+    to: '/customize/integrations/secure-a-cli-with-auth0',
+  },
+  {
+    from: ['/integrations/sharepoint', '/integrations/sharepoint-2010-2013'],
+    to: '/customize/integrations/sharepoint-2010-2013',
+  },
+  {
+    from: ['/integrations/sso', '/sso/current/integrations', '/integrations/sso-integrations'],
+    to: '/customize/integrations/sso-integrations',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/ad-rms',
+      '/integrations/sso-integrations/ad-rms-sso-integration',
+      '/sso/current/integrations/ad-rms',
+      '/integrations/sso/ad-rms',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/ad-rms-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/box', '/sso/current/integrations/box', '/integrations/sso/box'],
+    to: 'https://marketplace.auth0.com/integrations/box-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/cloudbees',
+      '/sso/current/integrations/cloudbees',
+      '/integrations/sso/cloudbees',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/cloudbees-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/concur', '/sso/current/integrations/concur', '/integrations/sso/concur'],
+    to: 'https://marketplace.auth0.com/integrations/concur-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/disqus',
+      '/sso/current/integrations/disqus',
+      '/integrations/disqus',
+      '/integrations/sso/disqus',
+    ],
+    to: 'https://marketplace.auth0.com/features/sso-integrations',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/dropbox',
+      '/sso/current/integrations/dropbox',
+      '/integrations/dropbox',
+      '/integrations/sso/dropbox',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/dropbox-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/dynamics-crm',
+      '/sso/current/integrations/dynamics-crm',
+      '/integrations/dynamics-crm',
+      '/integrations/sso/dynamics-crm',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/dynamics-crm-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/adobe-sign',
+      '/integrations/sso-integrations/echosign',
+      '/sso/current/integrations/echosign',
+      '/integrations/echosign',
+      '/integrations/sso/adobe-sign',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/adobe-sign-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/egnyte',
+      '/sso/current/integrations/egnyte',
+      '/integrations/egnyte',
+      '/integrations/sso/egnyte',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/egnyte-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/new-relic',
+      '/sso/current/integrations/new-relic',
+      '/integrations/new-relic',
+      '/integrations/sso/new-relic',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/new-relic-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/office-365',
+      '/sso/current/integrations/office-365',
+      '/integrations/office-365',
+      '/integrations/sso/office-365',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/office-365-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/salesforce',
+      '/sso/current/integrations/salesforce',
+      '/integrations/salesforce',
+      '/integrations/sso/salesforce',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/salesforce-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/slack',
+      '/sso/current/integrations/slack',
+      '/integrations/integrating-with-slack',
+      '/tutorials/integrating-with-slack',
+      '/scenarios/slack',
+      '/integrations/slack',
+      '/integrations/sso/slack',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/slack-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/sentry',
+      '/sso/current/integrations/sentry',
+      '/integrations/sentry',
+      '/integrations/sso/sentry',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/sentry-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/sharepoint',
+      '/sso/current/integrations/sharepoint',
+      '/integrations/sso/sharepoint',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/sharepoint-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/springcm',
+      '/sso/current/integrations/springcm',
+      '/integrations/springcm',
+      '/integrations/sso/springcm',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/springcm-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/zendesk',
+      '/sso/current/integrations/zendesk',
+      '/integrations/zendesk',
+      '/integrations/sso/zendesk',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/zendesk-sso',
+  },
+  {
+    from: [
+      '/integrations/sso-integrations/zoom',
+      '/sso/current/integrations/zoom',
+      '/integrations/zoom',
+      '/integrations/sso/zoom',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/zoom-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/cisco-webex', '/integrations/sso/cisco-webex'],
+    to: 'https://marketplace.auth0.com/integrations/cisco-webex-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/datadog', '/integrations/sso/datadog'],
+    to: 'https://marketplace.auth0.com/integrations/datadog-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/egencia', '/integrations/sso/egencia'],
+    to: 'https://marketplace.auth0.com/integrations/egencia-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/eloqua', '/integrations/sso/eloqua'],
+    to: 'https://marketplace.auth0.com/integrations/eloqua-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/freshdesk', '/integrations/sso/freshdesk'],
+    to: 'https://marketplace.auth0.com/integrations/freshdesk-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/g-suite', '/integrations/sso/g-suite'],
+    to: 'https://marketplace.auth0.com/integrations/g-suite-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/github-enterprise-cloud', '/integrations/sso/github-enterprise-cloud'],
+    to: 'https://marketplace.auth0.com/integrations/github-enterprise-cloud-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/github-enterprise-server', '/integrations/sso/github-enterprise-server'],
+    to: 'https://marketplace.auth0.com/integrations/github-enterprise-server-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/heroku', '/integrations/sso/heroku'],
+    to: 'https://marketplace.auth0.com/integrations/heroku-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/hosted-graphite', '/integrations/sso/hosted-graphite'],
+    to: 'https://marketplace.auth0.com/integrations/hosted-graphite-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/litmos', '/integrations/sso/litmos'],
+    to: 'https://marketplace.auth0.com/integrations/litmos-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/pluralsight', '/integrations/sso/pluralsight'],
+    to: 'https://marketplace.auth0.com/integrations/pluralsight-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/sprout-video', '/integrations/sso/sprout-video'],
+    to: 'https://marketplace.auth0.com/integrations/sprout-video-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/tableau-online', '/integrations/sso/tableau-online'],
+    to: 'https://marketplace.auth0.com/integrations/tableau-online-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/tableau-server', '/integrations/sso/tableau-server'],
+    to: 'https://marketplace.auth0.com/integrations/tableau-server-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/workday', '/integrations/sso/workday'],
+    to: 'https://marketplace.auth0.com/integrations/workday-sso',
+  },
+  {
+    from: ['/integrations/sso-integrations/workpath', '/integrations/sso/workpath'],
+    to: 'https://marketplace.auth0.com/integrations/workpath-sso',
+  },
+  {
+    from: [
+      '/integrations/azure-tutorial',
+      '/azure-tutorial',
+      '/tutorials/azure-tutorial',
+      '/integrations/azure-api-management/configure-auth0',
+      '/integrations/azure-api-management/configure-azure',
+      '/integrations/azure-api-management',
+    ],
+    to: '/customize/integrations/azure-api-management',
+  },
+  {
+    from: ['/marketplace-partner-documentation', '/integrations/marketplace-partners'],
+    to: '/customize/integrations/marketplace-partners',
+  },
+  {
+    from: [
+      '/redirect-rules-for-partners',
+      '/marketplace-partner-documentation/redirect-rules-for-partners',
+      '/integrations/marketplace-partners/redirect-rules-for-partners',
+      '/integrations/marketplace-partners/redirect-actions-for-partners',
+    ],
+    to: '/customize/integrations/marketplace-partners/redirect-actions-for-partners',
+  },
+  {
+    from: [
+      '/social-connections-for-partners',
+      '/marketplace-partner-documentation/social-connections-for-partners',
+      '/integrations/marketplace-partners/social-connections-for-partners',
+    ],
+    to: '/customize/integrations/marketplace-partners/social-connections-for-partners',
+  },
+  {
+    from: [
+      '/sso-integrations-for-partners',
+      '/marketplace-partner-documentation/sso-integrations-for-partners',
+      '/integrations/marketplace-partners/sso-integrations-for-partners',
+    ],
+    to: '/customize/integrations/marketplace-partners/sso-integrations-for-partners',
+  },
+  {
+    from: ['/integrations/marketing'],
+    to: '/customize/integrations/marketing-tool-integrations',
+  },
+  {
+    from: ['/integrations/integrate-with-vercel'],
+    to: '/customize/integrations/integrate-with-vercel',
+  },
+
+  /* Libraries */
+
+  {
+    from: '/sdks',
+    to: '/libraries',
+  },
+  {
+    from: ['/custom-signup', '/libraries/lock/v10/custom-signup', '/libraries/lock/v11/custom-signup'],
+    to: '/libraries/custom-signup',
+  },
+  {
+    from: [
+      '/libraries/error-messages',
+      '/libraries/lock-android/error-messages',
+      '/errors/libraries/auth0-js/invalid-token',
+    ],
+    to: '/libraries/common-auth0-library-authentication-errors',
+  },
+  {
+    from: [
+      '/widget',
+      '/login-widget2',
+      '/lock',
+      '/migrations/guides/legacy-lock-api-deprecation',
+      '/libraries/lock/v9',
+      '/libraries/lock/v9/display-modes',
+      '/libraries/lock/v9/types-of-applications',
+      '/libraries/lock/v10',
+      '/libraries/lock/v10/installation',
+      '/libraries/lock/v11',
+      '/libraries/lock/using-refresh-tokens',
+      '/libraries/lock/using-a-refresh-token',
+      '/login/embedded-login/lock',
+    ],
+    to: '/libraries/lock',
+  },
+  {
+    from: [
+      '/libraries/lock/display-modes',
+      '/libraries/lock/customization',
+      '/libraries/lock/v9/customization',
+      '/libraries/lock/v10/customization',
+      '/libraries/lock/v11/customization',
+      '/libraries/lock/v9/configuration',
+      '/libraries/lock/v10/configuration',
+      '/libraries/lock/v11/configuration',
+    ],
+    to: '/libraries/lock/lock-configuration',
+  },
+  {
+    from: [
+      '/libraries/lock/v10/popup-mode',
+      '/libraries/lock/v10/authentication-modes',
+      '/libraries/lock/v11/popup-mode',
+      '/libraries/lock/v11/authentication-modes',
+      '/libraries/lock/authentication-modes',
+    ],
+    to: '/libraries/lock/lock-authentication-modes',
+  },
+  {
+    from: [
+      '/hrd',
+      '/libraries/lock/v11/selecting-the-connection-for-multiple-logins',
+      '/protocols/saml/saml-configuration/selecting-between-multiple-idp',
+      '/libraries/lock/v10/selecting-the-connection-for-multiple-logins',
+    ],
+    to: '/libraries/lock/selecting-from-multiple-connection-options',
+  },
+  {
+    from: ['/libraries/lock/v11/api'],
+    to: '/libraries/lock/lock-api-reference',
+  },
+  {
+    from: [
+      '/libraries/lock/v11/sending-authentication-parameters',
+      '/libraries/lock/sending-authentication-parameters',
+    ],
+    to: '/libraries/lock/lock-authentication-parameters',
+  },
+  {
+    from: ['/libraries/lock/v11/ui-customization', '/libraries/lock/v9/ui-customization'],
+    to: '/libraries/lock/lock-ui-customization',
+  },
+  {
+    from: [
+      '/libraries/lock-ios/v2',
+      '/libraries/lock-ios/delegation-api',
+      '/libraries/lock-ios/v1/delegation-api',
+      '/libraries/lock-ios',
+      '/libraries/lock-ios/v1',
+      '/libraries/lock-ios/lock-ios-api',
+      '/libraries/lock-ios/v1/lock-ios-api',
+      '/libraries/lock-ios/native-social-authentication',
+      '/libraries/lock-ios/v1/native-social-authentication',
+      '/libraries/lock-ios/password-reset-ios',
+      '/libraries/lock-ios/v1/password-reset-ios',
+      '/libraries/lock-ios/save-and-refresh-jwt-tokens',
+      '/libraries/lock-ios/v1/save-and-refresh-jwt-tokens',
+      '/libraries/lock-ios/sending-authentication-parameters',
+      '/libraries/lock-ios/v1/sending-authentication-parameters',
+      '/libraries/lock-ios/swift',
+      '/libraries/lock-ios/v1/swift',
+    ],
+    to: '/libraries/lock-swift',
+  },
+  {
+    from: ['/libraries/lock-ios/logging', '/libraries/lock-ios/v2/logging', '/libraries/lock-ios/v1/logging'],
+    to: '/libraries/lock-swift/lock-swift-logging',
+  },
+  {
+    from: [
+      '/libraries/lock-ios/v2/passwordless',
+      '/libraries/lock-ios/sms-lock-ios',
+      '/libraries/lock-ios/v1/sms-lock-ios',
+      '/libraries/lock-ios/touchid-authentication',
+      '/libraries/lock-ios/v1/touchid-authentication',
+      '/libraries/lock-ios/passwordless',
+      '/libraries/lock-ios/v1/passwordless',
+    ],
+    to: '/libraries/lock-swift/lock-swift-passwordless',
+  },
+  {
+    from: [
+      '/libraries/lock-ios/v2/customization',
+      '/libraries/lock-ios/use-your-own-ui',
+      '/libraries/lock-ios/v1/use-your-own-uis',
+      '/libraries/lock-ios/v1/use-your-own-ui',
+      '/libraries/lock-ios/v1/customization',
+    ],
+    to: '/libraries/lock-swift/lock-swift-customization',
+  },
+  {
+    from: ['/libraries/lock-ios/v2/custom-fields'],
+    to: '/libraries/lock-swift/lock-swift-custom-fields-at-signup',
+  },
+  {
+    from: ['/libraries/lock-ios/v2/configuration'],
+    to: '/libraries/lock-swift/lock-swift-configuration-options',
+  },
+  {
+    from: [
+      '/auth0js',
+      '/libraries/auth0js/v7',
+      '/libraries/auth0js/v8',
+      '/libraries/auth0js/v9',
+      '/libraries/lock/v10/auth0js',
+      '/libraries/lock/v11/auth0js',
+      '/libraries/auth0js-v9-reference',
+      '/login/embedded-login/auth0js',
+    ],
+    to: '/libraries/auth0js',
+  },
+  {
+    from: ['/libraries/auth0-android/configuration'],
+    to: '/libraries/auth0-android/auth0-android-configuration',
+  },
+  {
+    from: [
+      '/libraries/lock-android/v2',
+      '/libraries/lock-android/v1',
+      '/libraries/lock-android/v1/sending-authentication-parameters',
+      '/libraries/lock-android/v1/use-your-own-ui',
+    ],
+    to: '/libraries/lock-android',
+  },
+  {
+    from: [
+      '/libraries/lock-android/v2/custom-authentication-providers',
+      '/libraries/lock-android/v2/custom-oauth-connections',
+    ],
+    to: '/libraries/lock-android/lock-android-custom-authentication-providers',
+  },
+  {
+    from: ['/tutorials/local-testing-and-development', '/local-testing-and-development'],
+    to: '/libraries/secure-local-development',
+  },
+  {
+    from: [
+      '/libraries/lock-android/v2/delegation-api',
+      '/libraries/lock-android/v1/delegation-api',
+      '/libraries/lock-android/lock-android-delegation',
+      '/libraries/lock-android/v2/refresh-jwt-tokens',
+      '/libraries/lock-android/v1/refresh-jwt-tokens',
+      '/libraries/lock-android/refresh-jwt-tokens',
+      '/libraries/auth0-android/save-and-refresh-tokens',
+    ],
+    to: '/libraries/lock-android/lock-android-refresh-jwt',
+  },
+  {
+    from: ['/libraries/lock-android/custom-fields', '/libraries/lock-android/v2/custom-fields'],
+    to: '/libraries/lock-android/lock-android-custom-fields-at-signup',
+  },
+  {
+    from: [
+      '/libraries/auth0-android/passwordless',
+      '/libraries/lock-android/passwordless',
+      '/connections/passwordless/android-email',
+      '/libraries/lock-android/v2/passwordless',
+      '/libraries/lock-android/v1/passwordless',
+    ],
+    to: '/libraries/lock-android/lock-android-passwordless',
+  },
+  {
+    from: ['/libraries/lock-android/v2/configuration', '/libraries/lock-android/v1/configuration'],
+    to: '/libraries/lock-android/lock-android-configuration',
+  },
+  {
+    from: ['/libraries/lock-android/v2/custom-theming'],
+    to: '/libraries/lock-android/lock-android-custom-theming',
+  },
+  {
+    from: [
+      '/libraries/lock-android/v2/native-social-authentication',
+      '/libraries/lock-android/v1/native-social-authentication',
+    ],
+    to: '/libraries/lock-android/lock-android-native-social-authentication',
+  },
+  {
+    from: ['/libraries/lock-android/v2/passwordless-magic-link', '/libraries/lock-android/v1/passwordless-magic-link'],
+    to: '/libraries/lock-android/lock-android-passwordless-with-magic-link',
+  },
+  {
+    from: [
+      '/libraries/lock-android/v2/keystore',
+      '/libraries/lock-android/keystore',
+      '/libraries/lock-android/android-development-keystores-hashes',
+    ],
+    to: '/libraries/auth0-android/android-development-keystores-hashes',
+  },
+  {
+    from: ['/libraries/auth0-android/user-management'],
+    to: '/libraries/auth0-android/auth0-android-user-management',
+  },
+  {
+    from: ['/libraries/auth0-spa-js'],
+    to: '/libraries/auth0-single-page-app-sdk',
+  },
+  {
+    from: ['/libraries/auth0-android/database-authentication'],
+    to: '/libraries/auth0-android/auth0-android-database-authentication',
+  },
+  {
+    from: ['/libraries/auth0-spa-js/migrate-from-auth0js'],
+    to: '/libraries/auth0-single-page-app-sdk/migrate-from-auth0-js-to-the-auth0-single-page-app-sdk',
+  },
+  {
+    from: ['/libraries/auth0-swift/database-authentication'],
+    to: '/libraries/auth0-swift/auth0-swift-database-connections',
+  },
+  {
+    from: ['/libraries/auth0-swift/passwordless'],
+    to: '/libraries/auth0-swift/auth0-swift-passwordless',
+  },
+  {
+    from: ['/libraries/auth0-swift/save-and-refresh-jwt-tokens'],
+    to: '/libraries/auth0-swift/auth0-swift-save-and-renew-tokens',
+  },
+  {
+    from: ['/libraries/auth0-swift/touchid-authentication'],
+    to: '/libraries/auth0-swift/auth0-swift-touchid-faceid',
+  },
+  {
+    from: ['/libraries/auth0-swift/user-management'],
+    to: '/libraries/auth0-swift/auth0-swift-user-management',
+  },
+  {
+    from: ['/libraries/auth0-php/authentication-api'],
+    to: '/libraries/auth0-php/using-the-authentication-api-with-auth0-php',
+  },
+  {
+    from: ['/libraries/auth0-php/basic-use'],
+    to: '/libraries/auth0-php/auth0-php-basic-use',
+  },
+  {
+    from: ['/libraries/auth0-php/jwt-validation'],
+    to: '/libraries/auth0-php/validating-jwts-with-auth0-php',
+  },
+  {
+    from: ['/libraries/auth0-php/management-api'],
+    to: '/libraries/auth0-php/using-the-management-api-with-auth0-php',
+  },
+  {
+    from: ['/libraries/auth0-php/troubleshooting'],
+    to: '/libraries/auth0-php/troubleshoot-auth0-php-library',
+  },
+
+  /* ORGANIZATIONS */
+
+  {
+    from: ['/organizations'],
+    to: '/manage-users/organizations',
+  },
+  {
+    from: ['/organizations/configure-organizations', '/organizations/configure/'],
+    to: '/manage-users/organizations/configure-organizations',
+  },
+  {
+    from: ['/organizations/create-organizations', '/organizations/configure/create-organizations'],
+    to: '/manage-users/organizations/configure-organizations/create-organizations',
+  },
+  {
+    from: ['/organizations/delete-organizations', '/organizations/configure/delete-organizations'],
+    to: '/manage-users/organizations/configure-organizations/delete-organizations',
+  },
+  {
+    from: ['/organizations/define-organization-behavior', '/organizations/configure/define-organization-behavior'],
+    to: '/manage-users/organizations/configure-organizations/define-organization-behavior',
+  },
+  {
+    from: ['/organizations/enable-connections', '/organizations/configure/enable-connections'],
+    to: '/manage-users/organizations/configure-organizations/enable-connections',
+  },
+  {
+    from: ['/organizations/disable-connections', '/organizations/configure/disable-connections'],
+    to: '/manage-users/organizations/configure-organizations/disable-connections',
+  },
+  {
+    from: ['/organizations/invite-members', '/organizations/configure/invite-members'],
+    to: '/manage-users/organizations/configure-organizations/invite-members',
+  },
+  {
+    from: ['/organizations/send-membership-invitations', '/organizations/configure/send-membership-invitations'],
+    to: '/manage-users/organizations/configure-organizations/send-membership-invitations',
+  },
+  {
+    from: ['/organizations/grant-just-in-time-membership', '/organizations/configure/grant-just-in-time-membership'],
+    to: '/manage-users/organizations/configure-organizations/grant-just-in-time-membership',
+  },
+  {
+    from: ['/organizations/assign-members', '/organizations/configure/assign-members'],
+    to: '/manage-users/organizations/configure-organizations/assign-members',
+  },
+  {
+    from: ['/organizations/remove-members', '/organizations/configure/remove-members'],
+    to: '/manage-users/organizations/configure-organizations/remove-members',
+  },
+  {
+    from: ['/organizations/add-member-roles', '/organizations/configure/add-member-roles'],
+    to: '/manage-users/organizations/configure-organizations/add-member-roles',
+  },
+  {
+    from: ['/organizations/remove-member-roles', '/organizations/configure/remove-member-roles'],
+    to: '/manage-users/organizations/configure-organizations/remove-member-roles',
+  },
+  {
+    from: ['/organizations/retrieve-organizations', '/organizations/configure/retrieve-organizations'],
+    to: '/manage-users/organizations/configure-organizations/retrieve-organizations',
+  },
+  {
+    from: ['/organizations/retrieve-connections', '/organizations/configure/retrieve-connections'],
+    to: '/manage-users/organizations/configure-organizations/retrieve-connections',
+  },
+  {
+    from: ['/organizations/retrieve-members', '/organizations/configure/retrieve-members'],
+    to: '/manage-users/organizations/configure-organizations/retrieve-members',
+  },
+  {
+    from: ['/organizations/retrieve-user-membership', '/organizations/configure/retrieve-user-membership'],
+    to: '/manage-users/organizations/configure-organizations/retrieve-user-membership',
+  },
+  {
+    from: ['/organizations/retrieve-member-roles', '/organizations/configure/retrieve-member-roles'],
+    to: '/manage-users/organizations/configure-organizations/retrieve-member-roles',
+  },
+  {
+    from: ['/organizations/using-tokens'],
+    to: '/manage-users/organizations/using-tokens',
+  },
+  {
+    from: ['/organizations/custom-development'],
+    to: '/manage-users/organizations/custom-development',
+  },
+  {
+    from: ['/organizations/create-first-organization'],
+    to: '/manage-users/organizations/create-first-organization',
+  },
+  {
+    from: ['/organizations/organizations-overview'],
+    to: '/manage-users/organizations/organizations-overview',
+  },
+
+  /* LOGIN */
+
+  {
+    from: ['/flows/login', '/login'],
+    to: '/authenticate/login',
+  },
+  {
+    from: [
+      '/hosted-pages/hosted-login-auth0js',
+      '/hosted-pages/login/auth0js',
+      '/hosted-pages/login/lock',
+      '/hosted-pages/login/lock-passwordless',
+      '/hosted-pages/hosted-login-auth0js/v7',
+      '/hosted-pages/hosted-login-auth0js/v8',
+      '/hosted-pages/login',
+      '/hosted-pages',
+      '/universal-login/customization-new',
+      '/login_page',
+      '/universal-login',
+      '/login/universal-login',
+    ],
+    to: '/authenticate/login/auth0-universal-login',
+  },
+  {
+    from: [
+      '/universal-login/new-universal-login-vs-classic-universal-login',
+      '/login/universal-login/new-universal-login-vs-classic-universal-login',
+      '/authenticate/login/auth0-universal-login/new-universal-login-vs-classic-universal-login',
+    ],
+    to: '/authenticate/login/auth0-universal-login/universal-login-vs-classic-login',
+  },
+  {
+    from: [
+      '/universal-login/new-experience',
+      '/universal-login/new',
+      '/login/universal-login/new-experience',
+      '/universal-login/new-experience-limitations',
+      '/authenticate/login/auth0-universal-login/new-experience',
+    ],
+    to: '/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/universal-experience',
+  },
+  {
+    from: [
+      '/universal-login/classic-experience',
+      '/universal-login/classic',
+      '/login/universal-login/classic-experience',
+      '/authenticate/login/auth0-universal-login/classic-experience',
+    ],
+    to: '/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience',
+  },
+  {
+    from: [
+      '/dashboard/guides/universal-login/configure-login-page-passwordless',
+      '/dashboard/guides/connections/configure-passwordless-sms',
+      '/universal-login/configure-universal-login-with-passwordless',
+      '/login/universal-login/passwordless-login/configure-universal-login-with-passwordless',
+      '/login/universal-login/passwordless-login',
+    ],
+    to: '/authenticate/login/auth0-universal-login/passwordless-login',
+  },
+  {
+    from: [
+      '/universal-login/universal-vs-embedded-login',
+      '/guides/login/universal-vs-embedded',
+      '/guides/login/centralized-vs-embedded',
+      '/login/universal-vs-embedded-login',
+      '/libraries/when-to-use-lock',
+    ],
+    to: '/authenticate/login/universal-vs-embedded-login',
+  },
+  {
+    from: [
+      '/universal-login/configure-default-login-routes',
+      '/universal-login/default-login-url',
+      '/hosted-pages/default-login-url',
+      '/login/universal-login/configure-default-login-routes',
+    ],
+    to: '/authenticate/login/auth0-universal-login/configure-default-login-routes',
+  },
+  {
+    from: [
+      '/universal-login/error-pages',
+      '/error-pages',
+      '/error-pages/generic',
+      '/hosted-pages/error-pages',
+      '/login/universal-login/error-pages',
+    ],
+    to: '/authenticate/login/auth0-universal-login/error-pages',
+  },
+  {
+    from: ['/universal-login/identifier-first', '/login/universal-login/identifier-first'],
+    to: '/authenticate/login/auth0-universal-login/identifier-first',
+  },
+  {
+    from: ['/login/embedded', '/flows/login/embedded', '/flows/login/embedded-login', '/login/embedded-login'],
+    to: '/authenticate/login/embedded-login',
+  },
+  {
+    from: [
+      '/cross-origin-authentication',
+      '/flows/login/embedded-login/cross-origin-authentication',
+      '/login/cross-origin-authentication',
+    ],
+    to: '/authenticate/login/cross-origin-authentication',
+  },
+  {
+    from: [
+      '/authorization/configure-silent-authentication',
+      '/api-auth/tutorials/silent-authentication',
+      '/login/configure-silent-authentication',
+    ],
+    to: '/authenticate/login/configure-silent-authentication',
+  },
+  {
+    from: ['/authentication', '/login/authentication'],
+    to: '/authenticate',
+  },
+  {
+    from: [
+      '/flows/guides/auth-code/add-login-auth-code',
+      '/flows/guides/auth-code/includes/authorize-user-add-login',
+      '/flows/guides/auth-code/includes/sample-use-cases-add-login',
+      '/flows/guides/auth-code/includes/refresh-tokens',
+      '/flows/guides/auth-code/includes/request-tokens',
+      '/flows/guides/regular-web-app-login-flow/add-login-using-regular-web-app-login-flow',
+      '/oauth-web-protocol',
+      '/protocols/oauth-web-protocol',
+      '/protocols/oauth2/oauth-web-protocol',
+      '/application-auth/current/server-side-web',
+      '/client-auth/server-side-web',
+      '/application-auth/legacy/server-side-web',
+      '/flows/add-login-auth-code-flow',
+      '/login/authentication/add-login-auth-code-flow',
+      '/get-started/authentication-and-authorization-flow/add-login-auth-code-flow',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow',
+  },
+  {
+    from: [
+      '/flows/guides/auth-code-pkce/add-login-auth-code-pkce',
+      '/flows/guides/auth-code-pkce/includes/sample-use-cases-add-login',
+      '/flows/guides/auth-code-pkce/includes/request-tokens',
+      '/flows/guides/auth-code-pkce/includes/refresh-tokens',
+      '/flows/guides/auth-code-pkce/includes/create-code-verifier',
+      '/flows/guides/auth-code-pkce/includes/create-code-challenge',
+      '/flows/guides/auth-code-pkce/includes/authorize-user-add-login',
+      '/application-auth/current/mobile-desktop',
+      '/application-auth/legacy/mobile-desktop',
+      '/application-auth/legacy/mobile-desktop',
+      '/flows/guides/mobile-login-flow/add-login-using-mobile-login-flow',
+      '/flows/add-login-using-the-authorization-code-flow-with-pkce',
+      '/login/authentication/add-login-using-the-authorization-code-flow-with-pkce',
+      '/get-started/authentication-and-authorization-flow/add-login-using-the-authorization-code-flow-with-pkce',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce',
+  },
+  {
+    from: [
+      '/flows/guides/implicit/add-login-implicit',
+      '/flows/guides/implicit/includes/sample-use-cases-add-login',
+      '/flows/guides/implicit/includes/refresh-tokens',
+      '/flows/guides/implicit/includes/request-tokens',
+      '/flows/guides/implicit/includes/authorize-user-add-login',
+      '/application-auth/current/client-side-web',
+      '/flows/guides/single-page-login-flow/add-login-using-single-page-login-flow',
+      '/client-auth/client-side-web',
+      '/application-auth/legacy/client-side-web',
+      '/flows/add-login-using-the-implicit-flow-with-form-post',
+      '/login/authentication/add-login-using-the-implicit-flow-with-form-post',
+      '/get-started/authentication-and-authorization-flow/add-login-using-the-implicit-flow-with-form-post',
+    ],
+    to: '/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post',
+  },
+  {
+    from: [
+      '/tutorials/redirecting-users',
+      '/users/redirecting-users',
+      '/users/guides/redirect-users-after-login',
+      '/protocols/oauth2/redirect-users',
+      '/users/concepts/redirect-users-after-login',
+      '/users/redirect-users-after-login',
+      '/login/redirect-users-after-login',
+    ],
+    to: '/authenticate/login/redirect-users-after-login',
+  },
+  {
+    from: [
+      '/universal-login/configure-universal-login-with-passwordless/webauthn-device-biometrics',
+      '/login/universal-login/passwordless-login/webauthn-device-biometrics',
+    ],
+    to: '/authenticate/login/auth0-universal-login/passwordless-login/webauthn-device-biometrics',
+  },
+
+  /* LOGOUT */
+
+  {
+    from: ['/logout', '/login/logout'],
+    to: '/authenticate/login/logout',
+  },
+  {
+    from: [
+      '/logout/log-users-out-of-applications',
+      '/logout/guides/logout-applications',
+      '/login/logout/log-users-out-of-applications',
+    ],
+    to: '/authenticate/login/logout/log-users-out-of-applications',
+  },
+  {
+    from: ['/logout/log-users-out-of-auth0', '/logout/guides/logout-auth0', '/login/logout/log-users-out-of-auth0'],
+    to: '/authenticate/login/logout/log-users-out-of-auth0',
+  },
+  {
+    from: ['/logout/log-users-out-of-idps', '/logout/guides/logout-idps', '/login/logout/log-users-out-of-idps'],
+    to: '/authenticate/login/logout/log-users-out-of-idps',
+  },
+  {
+    from: [
+      '/logout/log-users-out-of-saml-idps',
+      '/protocols/saml/saml-configuration/logout',
+      '/logout/guides/logout-saml-idps',
+      '/login/logout/log-users-out-of-saml-idps',
+    ],
+    to: '/authenticate/login/logout/log-users-out-of-saml-idps',
+  },
+  {
+    from: [
+      '/logout/redirect-users-after-logout',
+      '/logout/guides/redirect-users-after-logout',
+      '/login/logout/redirect-users-after-logout',
+    ],
+    to: '/authenticate/login/logout/redirect-users-after-logout',
+  },
+  {
+    from: ['/back-channel-logout'],
+    to: '/authenticate/login/logout/back-channel-logout',
+  },
+  {
+    from: ['/configure-back-channel-logout'],
+    to: '/authenticate/login/logout/back-channel-logout/configure-back-channel-logout',
+  },
+
+  /* Monitor - Logs */
+
+  {
+    from: ['/logs', '/logs/concepts/logs-admins-devs', '/monitor-auth0/logs'],
+    to: '/deploy-monitor/logs',
+  },
+  {
+    from: [
+      '/logs/pii-in-logs',
+      '/logs/personally-identifiable-information-pii-in-auth0-logs',
+      '/monitor-auth0/logs/pii-in-logs',
+    ],
+    to: '/deploy-monitor/logs/pii-in-logs',
+  },
+  {
+    from: ['/logs/log-data-retention', '/logs/references/log-data-retention', '/monitor-auth0/logs/log-data-retention'],
+    to: '/deploy-monitor/logs/log-data-retention',
+  },
+  {
+    from: [
+      '/logs/view-log-events',
+      '/logs/guides/view-log-data-dashboard',
+      '/logs/view-log-events-in-the-dashboard',
+      '/monitor-auth0/logs/view-log-events',
+    ],
+    to: '/deploy-monitor/logs/view-log-events',
+  },
+  {
+    from: ['/logs/log-event-filters', '/logs/references/log-event-filters', '/monitor-auth0/logs/log-event-filters'],
+    to: '/deploy-monitor/logs/log-event-filters',
+  },
+  {
+    from: [
+      '/logs/retrieve-log-events-using-mgmt-api',
+      '/logs/guides/retrieve-logs-mgmt-api',
+      '/monitor-auth0/logs/retrieve-log-events-using-mgmt-api',
+    ],
+    to: '/deploy-monitor/logs/retrieve-log-events-using-mgmt-api',
+  },
+  {
+    from: [
+      '/logs/log-event-type-codes',
+      '/logs/references/log-event-data',
+      '/logs/references/log-events-data',
+      '/logs/references/log-event-type-codes',
+      '/monitor-auth0/logs/log-event-type-codes',
+    ],
+    to: '/deploy-monitor/logs/log-event-type-codes',
+  },
+  {
+    from: [
+      '/logs/log-search-query-syntax',
+      '/logs/references/query-syntax',
+      '/logs/query-syntax',
+      '/monitor-auth0/logs/log-search-query-syntax',
+    ],
+    to: '/deploy-monitor/logs/log-search-query-syntax',
+  },
+  {
+    from: [
+      '/monitoring/guides/send-events-to-splunk',
+      '/monitoring/guides/send-events-to-keenio',
+      '/monitoring/guides/send-events-to-segmentio',
+      '/logs/export-log-events-with-rules',
+      '/monitor-auth0/logs/export-log-events-with-rules',
+    ],
+    to: '/deploy-monitor/logs/export-log-events-with-rules',
+  },
+  {
+    from: ['/logs/export-log-events-with-log-streaming', '/logs/streams', '/monitor-auth0/streams'],
+    to: '/customize/log-streams',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-http-event-logs',
+      '/logs/streams/http-event',
+      '/logs/streams/stream-http-event-logs',
+      '/monitor-auth0/streams/custom-log-streams',
+    ],
+    to: '/customize/log-streams/custom-log-streams',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-log-events-to-slack',
+      '/logs/streams/http-event-to-slack',
+      '/monitor-auth0/streams/stream-log-events-to-slack',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/slack-log-streaming',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-logs-to-splunk',
+      '/logs/streams/splunk',
+      '/logs/streams/stream-logs-to-splunk',
+      '/monitor-auth0/streams/stream-logs-to-splunk',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/splunk-log-streaming',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-logs-to-amazon-eventbridge',
+      '/logs/streams/aws-eventbridge',
+      '/integrations/aws-eventbridge',
+      '/logs/streams/amazon-eventbridge',
+      '/logs/streams/stream-logs-to-amazon-eventbridge',
+      '/monitor-auth0/streams/stream-logs-to-amazon-eventbridge',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/amazon-log-streaming',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-logs-to-azure-event-grid',
+      '/logs/streams/azure-event-grid',
+      '/logs/streams/stream-logs-to-azure-event-grid',
+      '/monitor-auth0/streams/stream-logs-to-azure-event-grid',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/azure-log-streaming',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/stream-logs-to-datadog',
+      '/logs/streams/datadog',
+      '/logs/streams/stream-logs-to-datadog',
+      '/monitor-auth0/streams/stream-logs-to-datadog',
+    ],
+    to: 'https://marketplace.auth0.com/integrations/datadog-log-streaming',
+  },
+  {
+    from: ['/monitor-auth0/streams/stream-logs-to-sumo-logic', '/logs/streams/stream-logs-to-sumo-logic'],
+    to: 'https://marketplace.auth0.com/integrations/sumo-logic-log-streaming',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/datadog-dashboard-templates',
+      '/logs/streams/datadog-dashboard-templates',
+      '/monitor-auth0/streams/datadog-dashboard-templates',
+    ],
+    to: '/customize/log-streams/datadog-dashboard-templates',
+  },
+  {
+    from: [
+      '/logs/export-log-events-with-log-streaming/splunk-dashboard',
+      '/logs/streams/splunk-dashboard',
+      '/monitor-auth0/streams/splunk-dashboard',
+    ],
+    to: '/customize/log-streams/splunk-dashboard',
+  },
+  {
+    from: ['/logs/streams/sumo-logic-dashboard', '/monitor-auth0/streams/sumo-logic-dashboard'],
+    to: '/customize/log-streams/sumo-logic-dashboard',
+  },
+  {
+    from: ['/logs/streams/event-filters', '/monitor-auth0/streams/event-filters'],
+    to: '/customize/log-streams/event-filters',
+  },
+
+  /* MFA */
+
+  {
+    from: [
+      '/multi-factor-authentication',
+      '/multi-factor-authentication2',
+      '/multifactor-authentication/custom-provider',
+      '/multifactor-authentication',
+      '/mfa-in-auth0',
+      '/multifactor-authentication/yubikey',
+      '/multifactor-authentication/guardian',
+      '/multifactor-authentication/guardian/user-guide',
+      '/multi-factor-authentication/yubikey',
+      '/mfa',
+      '/login/mfa',
+    ],
+    to: '/secure/multi-factor-authentication',
+  },
+  {
+    from: ['/mfa/enable-mfa', '/mfa/guides/enable-mfa', '/login/mfa/enable-mfa'],
+    to: '/secure/multi-factor-authentication/enable-mfa',
+  },
+  {
+    from: [
+      '/mfa/mfa-factors',
+      '/multifactor-authentication/factors',
+      '/mfa/concepts/mfa-factors',
+      '/login/mfa/mfa-factors',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-factors',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/sns-configuration',
+      '/multifactor-authentication/factors/push',
+      '/mfa/guides/configure-push',
+      '/multifactor-authentication/administrator/push-notifications',
+      '/mfa/configure-push-notifications-for-mfa',
+      '/login/mfa/mfa-factors/configure-push-notifications-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-push-notifications-for-mfa',
+  },
+  {
+    from: [
+      '/multifactor-authentication/administrator/twilio-configuration',
+      '/multifactor-authentication/administrator/sms-notifications',
+      '/multifactor-authentication/twilio-configuration',
+      '/multifactor-authentication/factors/sms',
+      '/mfa/guides/configure-sms',
+      '/mfa/guides/configure-phone',
+      '/mfa/configure-sms-voice-notifications-mfa',
+      '/login/mfa/mfa-factors/configure-sms-voice-notifications-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-sms-voice-notifications-mfa',
+  },
+  {
+    from: [
+      '/multifactor-authentication/factors/otp',
+      '/mfa/guides/configure-otp',
+      '/mfa/configure-otp-notifications-for-mfa',
+      '/login/mfa/mfa-factors/configure-otp-notifications-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-otp-notifications-for-mfa',
+  },
+  {
+    from: [
+      '/mfa/guides/configure-email-universal-login',
+      '/multifactor-authentication/factors/email',
+      '/mfa/guides/configure-email',
+      '/mfa/configure-email-notifications-for-mfa',
+      '/login/mfa/mfa-factors/configure-email-notifications-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-email-notifications-for-mfa',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-amazon-sns',
+      '/mfa/send-phone-message-hook-amazon-sns',
+      '/mfa/configure-amazon-sns-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-amazon-sns-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-amazon-sns-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-amazon-sns-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-esendex',
+      '/mfa/send-phone-message-hook-esendex',
+      '/mfa/configure-esendex-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-esendex-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-esendex-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-esendex-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-infobip',
+      '/mfa/send-phone-message-hook-infobip',
+      '/mfa/configure-infobip-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-infobip-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-infobip-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-infobip-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-mitto',
+      '/mfa/send-phone-message-hook-mitto',
+      '/mfa/configure-mitto-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-mitto-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-mitto-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-mitto-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-telesign',
+      '/mfa/send-phone-message-hook-telesign',
+      '/mfa/configure-telesign-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-telesign-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-telesign-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-telesign-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: ['/mfa/webauthn-as-mfa'],
+    to: '/secure/multi-factor-authentication/webauthn-as-mfa',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-twilio',
+      '/mfa/send-phone-message-hook-twilio',
+      '/mfa/configure-twilio-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-twilio-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-twilio-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-twilio-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/send-phone-message-hook-vonage',
+      '/mfa/send-phone-message-hook-vonage',
+      '/mfa/configure-vonage-as-mfa-sms-provider',
+      '/login/mfa/mfa-factors/configure-vonage-as-mfa-sms-provider',
+      '/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-vonage-as-mfa-sms-provider',
+      '/customize/hooks/extensibility-points/send-phone-message/configure-vonage-as-mfa-sms-provider',
+    ],
+    to: '/customize/actions/flows-and-triggers',
+  },
+  {
+    from: [
+      '/multifactor-authentication/factors/duo',
+      '/multifactor-authentication/duo',
+      '/multifactor-authentication/duo/admin-guide',
+      '/mfa/guides/configure-cisco-duo',
+      '/multifactor-authentication/duo/dev-guide',
+      '/multifactor-authentication/duo/user-guide',
+      '/mfa/configure-cisco-duo-for-mfa',
+      '/login/mfa/configure-cisco-duo-for-mfa',
+      '/login/mfa/mfa-factors/configure-cisco-duo-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/configure-cisco-duo-for-mfa',
+  },
+  {
+    from: ['/mfa/fido-authentication-with-webauthn', '/login/mfa/fido-authentication-with-webauthn'],
+    to: '/secure/multi-factor-authentication/fido-authentication-with-webauthn',
+  },
+  {
+    from: [
+      '/mfa/configure-webauthn-security-keys-for-mfa',
+      '/mfa/configure-webauthn-with-security-keys-for-mfa',
+      '/login/mfa/fido-authentication-with-webauthn/configure-webauthn-security-keys-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-security-keys-for-mfa',
+  },
+  {
+    from: [
+      '/mfa/configure-webauthn-device-biometrics-for-mfa',
+      '/login/mfa/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa',
+  },
+  {
+    from: ['/mfa/adaptive-mfa', '/login/mfa/adaptive-mfa'],
+    to: '/secure/multi-factor-authentication/adaptive-mfa',
+  },
+  {
+    from: ['/mfa/adaptive-mfa/enable-adaptive-mfa', '/login/mfa/adaptive-mfa/enable-adaptive-mfa'],
+    to: '/secure/multi-factor-authentication/adaptive-mfa/enable-adaptive-mfa',
+  },
+  {
+    from: [
+      '/mfa/adpative-mfa/adaptive-mfa-rule-actions',
+      '/login/mfa/adaptive-mfa/adaptive-mfa-rule-actions',
+      '/secure/multi-factor-authentication/adaptive-mfa/adaptive-mfa-rule-actions',
+      '/secure/multi-factor-authentication/adaptive-mfa/adaptive-mfa-rules',
+    ],
+    to: '/secure/multi-factor-authentication/adaptive-mfa/customize-adaptive-mfa',
+  },
+  {
+    from: ['/mfa/adaptive-mfa/adaptive-mfa-log-events', '/login/mfa/adaptive-mfa/adaptive-mfa-log-events'],
+    to: '/secure/multi-factor-authentication/adaptive-mfa/adaptive-mfa-log-events',
+  },
+  {
+    from: [
+      '/mfa/concepts/guardian',
+      '/multifactor-authentication/guardian/dev-guide',
+      '/multifactor-authentication/guardian/admin-guide',
+      '/mfa/auth0-guardian',
+      '/login/mfa/auth0-guardian',
+    ],
+    to: '/secure/multi-factor-authentication/auth0-guardian',
+  },
+  {
+    from: [
+      '/mfa/auth0-guardian/install-guardian-sdk',
+      '/mfa/guides/guardian/install-guardian-sdk',
+      '/login/mfa/auth0-guardian/install-guardian-sdk',
+      '/secure/multi-factor-authentication/auth0-guardian/install-guardian-sdk',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-developer-resources/install-guardian-sdk',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/libraries/ios',
+      '/mfa/guides/guardian/guardian-ios-sdk',
+      '/mfa/guides/guardian/configure-guardian-ios',
+      '/mfa/auth0-guardian/guardian-for-ios-sdk',
+      '/login/mfa/auth0-guardian/guardian-for-ios-sdk',
+    ],
+    to: '/secure/multi-factor-authentication/auth0-guardian/guardian-for-ios-sdk',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/libraries/android',
+      '/mfa/guides/guardian/guardian-android-sdk',
+      '/mfa/auth0-guardian/guardian-for-android-sdk',
+      '/login/mfa/auth0-guardian/guardian-for-android-sdk',
+    ],
+    to: '/secure/multi-factor-authentication/auth0-guardian/guardian-for-android-sdk',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/custom-enrollment-ticket',
+      '/mfa/guides/guardian/create-enrollment-ticket',
+      '/mfa/auth0-guardian/create-custom-enrollment-tickets',
+      '/login/mfa/auth0-guardian/create-custom-enrollment-tickets',
+      '/secure/multi-factor-authentication/auth0-guardian/create-custom-enrollment-tickets',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-developer-resources/create-custom-enrollment-tickets',
+  },
+  {
+    from: [
+      '/mfa/auth0-guardian/guardian-error-code-reference',
+      '/mfa/references/guardian-error-code-reference',
+      '/login/mfa/auth0-guardian/guardian-error-code-reference',
+      '/secure/multi-factor-authentication/auth0-guardian/guardian-error-code-reference',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-developer-resources/guardian-error-code-reference',
+  },
+  {
+    from: [
+      '/multifactor-authentication/custom',
+      '/mfa/guides/customize-mfa-universal-login',
+      '/multifactor-authentication/google-auth/dev-guide',
+      '/mfa/customize-mfa-user-pages',
+      '/login/mfa/customize-mfa-user-pages',
+    ],
+    to: '/secure/multi-factor-authentication/customize-mfa',
+  },
+  {
+    from: ['/secure/multi-factor-authentication/customize-mfa-selection-nul'],
+    to: '/secure/multi-factor-authentication/customize-mfa/customize-mfa-selection-universal-login',
+  },
+  {
+    from: ['/secure/multi-factor-authentication/customize-mfa-enrollments'],
+    to: '/secure/multi-factor-authentication/customize-mfa/customize-mfa-enrollments-universal-login',
+  },
+  {
+    from: [
+      '/universal-login/multifactor-authentication',
+      '/hosted-pages/guardian',
+      '/universal-login/guardian',
+      '/universal-login/classic-experience/mfa-classic-experience',
+      '/login/mfa/customize-mfa-user-pages/mfa-classic-experience',
+      '/secure/multi-factor-authentication/customize-mfa/mfa-classic-experience',
+    ],
+    to: '/secure/multi-factor-authentication/customize-mfa/customize-mfa-classic-login',
+  },
+  {
+    from: [
+      '/mfa/customize-mfa-user-pages/mfa-theme-language-dictionary',
+      '/mfa/references/language-dictionary',
+      '/login/mfa/customize-mfa-user-pages/mfa-theme-language-dictionary',
+    ],
+    to: '/secure/multi-factor-authentication/customize-mfa/mfa-theme-language-dictionary',
+  },
+  {
+    from: [
+      '/mfa/customize-mfa-user-pages/mfa-widget-theme-options',
+      '/mfa/references/mfa-widget-reference',
+      '/login/mfa/customize-mfa-user-pages/mfa-widget-theme-options',
+    ],
+    to: '/secure/multi-factor-authentication/customize-mfa/mfa-widget-theme-options',
+  },
+  {
+    from: [
+      '/api-auth/tutorials/multifactor-resource-owner-password',
+      '/mfa/guides/mfa-api/authenticate',
+      '/mfa/guides/mfa-api/multifactor-resource-owner-password',
+      '/mfa/authenticate-with-ropg-and-mfa',
+      '/login/mfa/ropg-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa',
+  },
+  {
+    from: [
+      '/mfa/guides/mfa-api/phone',
+      '/multifactor-authentication/api/oob',
+      '/mfa/guides/mfa-api/oob',
+      '/mfa/authenticate-with-ropg-and-mfa/enroll-challenge-sms-voice-authenticators',
+      '/login/mfa/ropg-mfa/enroll-challenge-sms-voice-authenticators',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/enroll-challenge-sms-voice-authenticators',
+  },
+  {
+    from: [
+      '/mfa/guides/mfa-api/push',
+      '/mfa/authenticate-with-ropg-and-mfa/enroll-and-challenge-push-authenticators',
+      '/login/mfa/ropg-mfa/enroll-and-challenge-push-authenticators',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/enroll-and-challenge-push-authenticators',
+  },
+  {
+    from: [
+      '/multifactor-authentication/api/otp',
+      '/mfa/guides/mfa-api/otp',
+      '/multifactor-authentication/google-authenticator',
+      '/mfa/authenticate-with-ropg-and-mfa/enroll-and-challenge-otp-authenticators',
+      '/login/mfa/ropg-mfa/enroll-and-challenge-otp-authenticators',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/enroll-and-challenge-otp-authenticators',
+  },
+  {
+    from: [
+      '/multifactor-authentication/api/email',
+      '/mfa/guides/mfa-api/email',
+      '/multifactor-authentication/administrator/guardian-enrollment-email',
+      '/mfa/authenticate-with-ropg-and-mfa/enroll-and-challenge-email-authenticators',
+      '/login/mfa/ropg-mfa/enroll-and-challenge-email-authenticators',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/enroll-and-challenge-email-authenticators',
+  },
+  {
+    from: [
+      '/mfa/import-user-mfa-authenticator-enrollments',
+      '/mfa/guides/import-user-mfa',
+      '/login/mfa/ropg-mfa/import-user-mfa-authenticator-enrollments',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/import-user-mfa-authenticator-enrollments',
+  },
+  {
+    from: [
+      '/mfa/guides/mfa-api/recovery-code',
+      '/mfa/authenticate-with-ropg-and-mfa/manage-authenticator-factors-mfa-api/challenge-with-recovery-codes',
+      '/login/mfa/ropg-mfa/challenge-with-recovery-codes',
+    ],
+    to: '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/challenge-with-recovery-codes',
+  },
+  {
+    from: [
+      '/mfa/guides/mfa-api/manage',
+      '/multifactor-authentication/api/manage',
+      '/mfa/authenticate-with-ropg-and-mfa/manage-authenticator-factors-mfa-api',
+      '/login/mfa/ropg-mfa/manage-authenticator-factors-mfa-api',
+      '/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa/manage-authenticator-factors-mfa-api',
+    ],
+    to: '/secure/multi-factor-authentication/manage-mfa-auth0-apis/manage-authenticator-factors-mfa-api',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/step-up-authentication',
+      '/step-up-authentication',
+      '/tutorials/step-up-authentication',
+      '/tutorials/setup-up-authentication',
+      '/multifactor-authentication/step-up-authentication',
+      '/mfa/concepts/step-up-authentication',
+      '/multifactor-authentication/developer/step-up-with-acr',
+      '/mfa/step-up-authentication',
+      '/login/mfa/step-up-authentication',
+    ],
+    to: '/secure/multi-factor-authentication/step-up-authentication',
+  },
+  {
+    from: [
+      '/multifactor-authentication/api/challenges',
+      '/multifactor-authentication/developer/step-up-authentication/step-up-for-apis',
+      '/multifactor-authentication/step-up-authentication/step-up-for-apis',
+      '/mfa/guides/configure-step-up-apis',
+      '/mfa/step-up-authentication/configure-step-up-authentication-for-apis',
+      '/login/mfa/step-up-authentication/configure-step-up-authentication-for-apis',
+    ],
+    to: '/secure/multi-factor-authentication/step-up-authentication/configure-step-up-authentication-for-apis',
+  },
+  {
+    from: [
+      '/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps',
+      '/multifactor-authentication/step-up-authentication/step-up-for-web-apps',
+      '/mfa/guides/configure-step-up-web-apps',
+      '/mfa/step-up-authentication/configure-step-up-authentication-for-web-apps',
+      '/login/mfa/step-up-authentication/configure-step-up-authentication-for-web-apps',
+    ],
+    to: '/secure/multi-factor-authentication/step-up-authentication/configure-step-up-authentication-for-web-apps',
+  },
+  {
+    from: [
+      '/multifactor-authentication/reset-user',
+      '/multifactor-authentication/administrator/reset-user',
+      '/mfa/guides/reset-user-mfa',
+      '/multifactor-authentication/administrator/disabling-mfa',
+      '/mfa/reset-user-mfa',
+      '/login/mfa/reset-user-mfa',
+    ],
+    to: '/secure/multi-factor-authentication/reset-user-mfa',
+  },
+  {
+    from: [
+      '/mfa/concepts/mfa-developer-resources',
+      '/multifactor-authentication/developer',
+      '/mfa/concepts/developer-resources',
+      '/mfa/mfa-developer-resources',
+      '/login/mfa/mfa-developer-resources',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-developer-resources',
+  },
+  {
+    from: [
+      '/multifactor-authentication/api',
+      '/multifactor-authentication/api/faq',
+      '/mfa/concepts/mfa-api',
+      '/mfa/mfa-api',
+      '/login/mfa/mfa-developer-resources/mfa-api',
+    ],
+    to: '/secure/multi-factor-authentication/multi-factor-authentication-developer-resources/mfa-api',
+  },
+
+  /* Monitoring */
+
+  {
+    from: ['/monitoring', '/tutorials/how-to-monitor-auth0', '/monitoring/how-to-monitor-auth0', '/monitor-auth0'],
+    to: '/deploy-monitor/monitor',
+  },
+  {
+    from: ['/monitoring/guides/check-external-services', '/monitor-auth0/check-external-services-status'],
+    to: '/deploy-monitor/monitor/check-external-services-status',
+  },
+  {
+    from: ['/monitoring/guides/check-status', '/monitor-auth0/check-auth0-status'],
+    to: '/deploy-monitor/monitor/check-auth0-status',
+  },
+  {
+    from: ['/monitoring/guides/monitor-applications', '/monitor-auth0/monitor-applications'],
+    to: '/deploy-monitor/monitor/monitor-applications',
+  },
+  {
+    from: ['/monitoring/guides/monitor-using-SCOM', '/monitor-auth0/monitor-using-scom'],
+    to: '/deploy-monitor/monitor/monitor-using-scom',
+  },
+
+  /* Product-Lifecycle */
+
+  {
+    from: ['/lifecycle', '/product-lifecycle'],
+    to: '/troubleshoot/product-lifecycle',
+  },
+  {
+    from: ['/product-lifecycle/deprecation-eol', '/product-lifecycle/migration-process'],
+    to: '/troubleshoot/product-lifecycle/migration-process',
+  },
+  {
+    from: ['/product-lifecycle/product-release-stages'],
+    to: '/troubleshoot/product-lifecycle/product-release-stages',
+  },
+  {
+    from: ['/product-lifecycle/migrations', '/migrations', '/product-lifecycle/deprecations-and-migrations'],
+    to: '/troubleshoot/product-lifecycle/deprecations-and-migrations',
+  },
+  {
+    from: [
+      '/deprecations-and-migrations/migrate-tenant-member-roles',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-manage-dashboard-new-roles',
+      '/product-lifecycle/deprecations-and-migrations/migrate-tenant-member-roles',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-tenant-member-roles',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-tenant-member-roles',
+  },
+  {
+    from: [
+      '/guides/login/migration-embedded-universal',
+      '/guides/login/migration-embedded-centralized',
+      '/guides/login/migrating-lock-v10-webapp',
+      '/guides/login/migrating-lock-v9-spa',
+      '/guides/login/migrating-lock-v9-spa-popup',
+      '/guides/login/migrating-lock-v9-webapp',
+      '/guides/login/migrating-lock-v10-spa',
+      '/guides/login/migrating-lock-v8',
+      '/guides/login/migration-sso',
+      '/product-lifecycle/deprecations-and-migrations/migrate-from-embedded-login-to-universal-login',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-from-embedded-login-to-universal-login',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-from-embedded-login-to-universal-login',
+  },
+  {
+    from: [
+      '/users/user-search/migrate-v2-v3',
+      '/users/search/v3/migrate-search-v2-v3',
+      '/users/user-search/migrate-search-v2-v3',
+      '/product-lifecycle/deprecations-and-migrations/migrate-v2-v3',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-v2-v3',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-v2-v3',
+  },
+  {
+    from: [
+      '/migrations/guides/unpaginated-requests',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-paginated-queries',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-paginated-queries',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-paginated-queries',
+  },
+  {
+    from: [
+      '/migrations/guides/extensibility-node12',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-nodejs-12',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-nodejs-12',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-12',
+  },
+  {
+    from: [
+      '/api/management/v1',
+      '/api-reference',
+      '/api/v1/reference',
+      '/api/management/v1/reference',
+      '/api/management/v2/changes',
+      '/apiv2Changes',
+      '/api/v2/changes',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-management-api-v2',
+      '/api/management-api-v1-deprecated',
+      '/api/management-api-changes-v1-to-v2',
+      '/migrations/guides/management-api-v1-v2',
+      '/api/management/v1/use-cases',
+      '/api/v1',
+      '/migrations/past-migrations',
+      '/product-lifecycle/deprecations-and-migrations/past-migrations',
+      '/product-lifecycle/past-migrations',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations',
+  },
+  {
+    from: [
+      '/migrations/guides/passwordless-start',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-passwordless',
+      '/product-lifecycle/past-migrations/migrate-to-passwordless',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-passwordless',
+  },
+  {
+    from: [
+      '/migrations/guides/clickjacking-protection',
+      '/product-lifecycle/deprecations-and-migrations/clickjacking-protection-for-universal-login',
+      '/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login',
+  },
+  {
+    from: [
+      '/migrations/guides/calling-api-with-idtokens',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-calling-api-with-access-tokens',
+      '/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens',
+  },
+  {
+    from: [
+      '/migrations/guides/account-linking',
+      '/users/guides/link-user-accounts-auth-api',
+      '/product-lifecycle/deprecations-and-migrations/link-user-accounts-with-access-tokens-migration',
+      '/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration',
+  },
+  {
+    from: [
+      '/migrations/guides/migration-oauthro-oauthtoken',
+      '/product-lifecycle/deprecations-and-migrations/migration-oauthro-oauthtoken',
+      '/product-lifecycle/past-migrations/migration-oauthro-oauthtoken',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migration-oauthro-oauthtoken',
+  },
+  {
+    from: [
+      '/migrations/guides/instagram-deprecation',
+      '/instagram-clientid',
+      '/product-lifecycle/deprecations-and-migrations/instagram-connection-deprecation',
+      '/product-lifecycle/past-migrations/instagram-connection-deprecation',
+      '/connections/social/instagram',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/instagram-connection-deprecation',
+  },
+  {
+    from: [
+      '/migrations/guides/yahoo-userinfo-updates',
+      '/product-lifecycle/deprecations-and-migrations/yahoo-api-changes',
+      '/product-lifecycle/past-migrations/yahoo-api-changes',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/yahoo-api-changes',
+  },
+  {
+    from: [
+      '/migrations/guides/google_cloud_messaging',
+      '/product-lifecycle/deprecations-and-migrations/google-firebase-migration',
+      '/product-lifecycle/past-migrations/google-firebase-migration',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/google-firebase-migration',
+  },
+  {
+    from: [
+      '/migrations/guides/facebook-social-context',
+      '/product-lifecycle/deprecations-and-migrations/facebook-social-context-field-deprecation',
+      '/product-lifecycle/past-migrations/facebook-social-context-field-deprecation',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/facebook-social-context-field-deprecation',
+  },
+  {
+    from: [
+      '/migrations/guides/facebook-graph-api-deprecation',
+      '/product-lifecycle/deprecations-and-migrations/facebook-graph-api-changes',
+      '/product-lifecycle/past-migrations/facebook-graph-api-changes',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/facebook-graph-api-changes',
+  },
+  {
+    from: [
+      '/logs/guides/migrate-logs-v2-v3',
+      '/product-lifecycle/deprecations-and-migrations/migrate-to-tenant-log-search-v3',
+      '/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3',
+  },
+  {
+    from: [
+      '/migrations/guides/migration-oauthro-oauthtoken-pwdless',
+      '/product-lifecycle/deprecations-and-migrations/resource-owner-passwordless-credentials-exchange',
+      '/product-lifecycle/past-migrations/resource-owner-passwordless-credentials-exchange',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/resource-owner-passwordless-credentials-exchange',
+  },
+  {
+    from: [
+      '/product-lifecycle/deprecations-and-migrations/migrate-from-legacy-auth-flows',
+      '/guides/migration-legacy-flows',
+      '/product-lifecycle/past-migrations/migrate-from-legacy-auth-flows',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-from-legacy-auth-flows',
+  },
+  {
+    from: [
+      '/product-lifecycle/deprecations-and-migrations/tenant-hostname-migration',
+      '/troubleshoot/product-lifecycle/deprecations-and-migrations/tenant-hostname-migration',
+    ],
+    to: '/troubleshoot/product-lifecycle/past-migrations/tenant-hostname-migration',
+  },
+  {
+    from: ['/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-from-edge-js-extensibility-features'],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-from-edge-js-extensibility-features',
+  },
+
+  {
+    from: ['/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-from-oracledb-extensibility-features'],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-from-oracledb-extensibility-features',
+  },
+
+  {
+    from: ['/troubleshoot/product-lifecycle/deprecations-and-migrations/custom-claims-migration'],
+    to: '/troubleshoot/product-lifecycle/past-migrations/custom-claims-migration',
+  },
+
+  {
+    from: ['/troubleshoot/product-lifecycle/past-migrations/migrate-actions-nodejs-16-to-nodejs-18'],
+    to: '/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-nodejs-16-to-nodejs-18',
+  },
+
+  {
+    from: ['/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-nodejs-16'],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-16',
+  },
+
+  {
+    from: ['/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-from-log-extensions'],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-from-log-extensions',
+  },
+  {
+    from: [`/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-1-hour-expiration`],
+    to: '/troubleshoot/product-lifecycle/past-migrations/migrate-to-1-hour-expiration',
+  },
+
+  /* Professional Services */
+
+  {
+    from: [
+      '/services',
+      '/auth0-professional-services',
+      '/services/auth0-advanced',
+      '/services/auth0-introduction',
+      '/services/discover-and-design',
+      '/services/maintain-and-improve',
+      '/professional-services',
+      '/troubleshoot/professional-services',
+    ],
+    to: '/get-started/professional-services',
+  },
+  {
+    from: [
+      '/services/architectural-design',
+      '/professional-services/architectural-design-services',
+      '/professional-services/solution-design-services',
+      '/services/solution-design',
+      '/professional-services/discover-design',
+      '/troubleshoot/professional-services/discover-design',
+    ],
+    to: '/get-started/professional-services/discover-design',
+  },
+  {
+    from: [
+      '/professional-services/custom-implementation-services',
+      '/services/custom-implementation',
+      '/services/implement',
+      '/professional-services/implement',
+      '/troubleshoot/professional-services/implement',
+    ],
+    to: '/get-started/professional-services/implement',
+  },
+  {
+    from: [
+      '/services/performance-scalability',
+      '/professional-services/performance-and-scalability-services',
+      '/professional-services/advisory-sessions',
+      '/services/scenario-guidance',
+      '/services/code-review',
+      '/services/pair-programming',
+      '/professional-services/maintain-improve',
+      '/troubleshoot/professional-services/maintain-improve',
+    ],
+    to: '/get-started/professional-services/maintain-improve',
+  },
+  {
+    from: [
+      '/services/packages',
+      '/professional-services/packages',
+      '/troubleshoot/professional-services/packages',
+      '/get-started/professional-services/packages',
+    ],
+    to: '/get-started/professional-services',
+  },
+
+  /* Rules */
+
+  {
+    from: [
+      '/rules/current',
+      '/rules/current/csharp',
+      '/rules/guides/csharp',
+      '/rules/legacy',
+      '/rules/references/legacy',
+      '/rules/references/modules',
+      '/rule',
+      '/rules',
+    ],
+    to: '/customize/rules',
+  },
+  {
+    from: [
+      '/rules/guides/automatically-generate-leads-in-shopify',
+      '/rules/guides/automatically-generate-leads-shopify',
+      '/rules/automatically-generate-leads-in-shopify',
+      '/customize/rules/use-cases/automatically-generate-leads-in-shopify',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: ['/rules/guides/cache-resources', '/rules/cache-expensive-resources-in-rules', '/rules/cache-resources'],
+    to: '/customize/rules/cache-resources',
+  },
+  {
+    from: ['/rules/guides/configuration', '/rules/configuration'],
+    to: '/customize/rules/configuration',
+  },
+  {
+    from: ['/dashboard/guides/rules/configure-variables', '/rules/configure-global-variables-for-rules'],
+    to: '/customize/rules/configure-global-variables-for-rules',
+  },
+  {
+    from: [
+      '/rules/current/context',
+      '/rules/context',
+      '/rules/references/context-object',
+      '/rules/context-prop-authentication',
+      '/rules/context-object',
+    ],
+    to: '/customize/rules/context-object',
+  },
+  {
+    from: [
+      '/api/management/guides/rules/create-rules',
+      '/dashboard/guides/rules/create-rules',
+      '/rules/guides/create',
+      '/rules/create-rules',
+    ],
+    to: '/customize/rules/create-rules',
+  },
+  {
+    from: ['/rules/guides/debug', '/rules/debug-rules'],
+    to: '/customize/rules/debug-rules',
+  },
+  {
+    from: ['/rules/references/samples', '/rules/examples', '/customize/rules/examples'],
+    to: '/customize/actions/actions-overview',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-user-id-verification',
+      '/rules/integrate-user-id-verification',
+      '/customize/rules/use-cases/integrate-user-id-verification',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-efm-solutions',
+      '/rules/integrate-efm-solutions',
+      '/customize/rules/use-cases/integrate-efm-solutions',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-erfm-solutions',
+      '/rules/integrate-erfm-solutions',
+      '/customize/rules/use-cases/integrate-erfm-solutions',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-hubspot',
+      '/rules/integrate-hubspot',
+      '/customize/rules/use-cases/integrate-hubspot',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-maxmind',
+      '/rules/integrate-maxmind',
+      '/customize/rules/use-cases/integrate-maxmind',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-mixpanel',
+      '/rules/integrate-mixpanel',
+      '/customize/rules/use-cases/integrate-mixpanel',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/rules/guides/integrate-salesforce',
+      '/rules/integrate-salesforce',
+      '/customize/rules/use-cases/integrate-salesforce',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: ['/rules/current/redirect', '/rules/redirect', '/rules/guides/redirect', '/rules/redirect-users'],
+    to: '/customize/rules/redirect-users',
+  },
+  {
+    from: ['/rules/references/use-cases', '/rules/use-cases', '/customize/rules/use-cases'],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: ['/rules/current/management-api', '/rules/guides/management-api', '/rules/use-management-api'],
+    to: '/customize/rules/use-management-api',
+  },
+  {
+    from: ['/rules/references/user-object', '/rules/user-object-in-rules'],
+    to: '/customize/rules/user-object-in-rules',
+  },
+  {
+    from: [
+      '/monitoring/guides/track-leads-salesforce',
+      '/tutorials/tracking-new-leads-in-salesforce-and-raplead',
+      '/scenarios-rapleaf-salesforce',
+      '/scenarios/rapleaf-salesforce',
+      '/monitor-auth0/track-new-leads-in-salesforce',
+      '/rules/use-cases/track-new-leads-in-salesforce',
+      '/customize/rules/use-cases/track-new-leads-in-salesforce',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: [
+      '/monitoring/guides/track-signups-salesforce',
+      '/tutorials/track-signups-enrich-user-profile-generate-leads',
+      '/scenarios-mixpanel-fullcontact-salesforce',
+      '/scenarios/mixpanel-fullcontact-salesforce',
+      '/monitor-auth0/track-new-sign-ups-in-salesforce',
+      '/rules/use-cases/track-new-sign-ups-in-salesforce',
+      '/customize/rules/use-cases/track-new-sign-ups-in-salesforce',
+    ],
+    to: '/customize/actions/use-cases',
+  },
+  {
+    from: ['/rules/raise-errors-from-rules'],
+    to: '/customize/rules/raise-errors-from-rules',
+  },
+
+  /* Security */
+  {
+    from: ['/security'],
+    to: '/secure',
+  },
+  {
+    from: ['/security/general-security-tips', '/security/tips'],
+    to: '/secure/security-guidance/tips',
+  },
+  {
+    from: [
+      '/security/blacklist-user-attributes',
+      '/security/blacklisting-attributes',
+      '/tutorials/blacklisting-attributes',
+      '/blacklist-attributes',
+      '/security/denylist-user-attributes',
+      '/security/data-security/denylist',
+    ],
+    to: '/secure/security-guidance/data-security/denylist',
+  },
+  {
+    from: [
+      '/security/whitelist-ip-addresses',
+      '/guides/ip-whitelist',
+      '/security/allowlist-ip-addresses',
+      '/security/data-security/allowlist',
+    ],
+    to: '/secure/security-guidance/data-security/allowlist',
+  },
+  {
+    from: [
+      '/users/normalized/auth0/store-user-data',
+      '/users/store-user-data',
+      '/users/references/user-data-storage-scenario',
+      '/users/user-data-storage-scenario',
+      '/best-practices/user-data-storage-best-practices',
+      '/users/references/user-data-storage-best-practices',
+      '/users/user-data-storage',
+      '/user-profile/user-data-storage',
+      '/security/data-security/user-data-storage',
+    ],
+    to: '/secure/security-guidance/data-security/user-data-storage',
+  },
+  {
+    from: [
+      '/tokens/concepts/token-storage',
+      '/videos/session-and-cookies',
+      '/security/store-tokens',
+      '/tokens/guides/store-tokens',
+      '/tokens/token-storage',
+      '/security/data-security/token-storage',
+    ],
+    to: '/secure/security-guidance/data-security/token-storage',
+  },
+  {
+    from: ['/security/common-threats', '/security/prevent-common-cybersecurity-threats', '/security/prevent-threats'],
+    to: '/secure/security-guidance/prevent-threats',
+  },
+
+  /* Security Bulletins */
+  {
+    from: ['/security/bulletins', '/security/security-bulletins'],
+    to: '/secure/security-guidance/security-bulletins',
+  },
+  {
+    from: [
+      '/security/bulletins/cve-2020-15259',
+      '/security/cve-2020-15259',
+      '/security/security-bulletins/cve-2020-15259',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2020-15259',
+  },
+  {
+    from: [
+      '/security/bulletin/cve-2020-15240',
+      '/security/cve-2020-15240',
+      '/security/security-bulletins/cve-2020-15240',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2020-15240',
+  },
+  {
+    from: [
+      '/security/bulletins/cve-2020-15125',
+      '/security/cve-2020-15125',
+      '/security/security-bulletins/cve-2020-15125',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2020-15125',
+  },
+  {
+    from: [
+      '/security/bulletins/cve-2020-15084',
+      '/security/cve-2020-15084',
+      '/security/security-bulletins/cve-2020-15084',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2020-15084',
+  },
+  {
+    from: [
+      '/security/bulletins/2020-03-31_wpauth0',
+      '/security/2020-03-31-wpauth0',
+      '/security/security-bulletins/2020-03-31-wpauth0',
+    ],
+    to: '/secure/security-guidance/security-bulletins/2020-03-31-wpauth0',
+  },
+  {
+    from: [
+      '/security/bulletins/cve-2020-5263',
+      '/security/cve-2020-5263',
+      '/security/security-bulletins/cve-2020-5263',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2020-5263',
+  },
+  {
+    from: [
+      '/security/bulletins/2019-01-10_rules',
+      '/security/2019-01-10-rules',
+      '/security/security-bulletins/2019-01-10-rules',
+    ],
+    to: '/secure/security-guidance/security-bulletins/2019-01-10-rules',
   },
   {
-    from: '/saml-apps/heroku-sso',
-    to: '/protocols/saml/saml-apps/heroku'
+    from: [
+      '/security/bulletins/2019-09-05_scopes',
+      '/security/2019-09-05-scopes',
+      '/security/security-bulletins/2019-09-05-scopes',
+    ],
+    to: '/secure/security-guidance/security-bulletins/2019-09-05-scopes',
   },
   {
-    from: '/saml-apps/litmos',
-    to: '/protocols/saml/saml-apps/litmos'
+    from: [
+      '/security/bulletins/cve-2019-20174',
+      '/security/cve-2019-20174',
+      '/security/security-bulletins/cve-2019-20174',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2019-20174',
   },
   {
-    from: '/saml-apps/sprout-video',
-    to: '/protocols/saml/saml-apps/sprout-video'
+    from: [
+      '/security/bulletins/cve-2019-20173',
+      '/security/cve-2019-20173',
+      '/security/security-bulletins/cve-2019-20173',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2019-20173',
   },
   {
-    from: '/onboarding/appliance-outage',
-    to: '/appliance/critical-issue'
+    from: [
+      '/security/bulletins/cve-2019-16929',
+      '/security/cve-2019-16929',
+      '/security/security-bulletins/cve-2019-16929',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2019-16929',
   },
   {
-    from: '/tutorials/local-testing-and-development',
-    to: '/dev-lifecycle/local-testing-and-development'
+    from: [
+      '/security/bulletins/cve-2019-13483',
+      '/security/cve-2019-13483',
+      '/security/security-bulletins/cve-2019-13483',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2019-13483',
   },
   {
-    from: '/tutorials/development-lifecycle-with-auth0',
-    to: '/dev-lifecycle/setting-up-env'
+    from: [
+      '/security/bulletins/cve-2019-7644',
+      '/security/cve-2019-7644',
+      '/security/security-bulletins/cve-2019-7644',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2019-7644',
   },
   {
-    from: '/tokens/id_token',
-    to: '/tokens/id-token'
+    from: [
+      '/security/bulletins/cve-2018-15121',
+      '/security/cve-2018-15121',
+      '/security/security-bulletins/cve-2018-15121',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2018-15121',
   },
   {
-    from: '/connections',
-    to: '/identityproviders'
+    from: [
+      '/security/bulletins/cve-2018-11537',
+      '/security/cve-2018-11537',
+      '/security/security-bulletins/cve-2018-11537',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2018-11537',
   },
   {
-    from: '/anomaly-detection/brute-force-protection',
-    to: '/anomaly-detection#brute-force-protection'
+    from: [
+      '/security/bulletins/cve-2018-7307',
+      '/security/cve-2018-7307',
+      '/security/security-bulletins/cve-2018-7307',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2018-7307',
   },
   {
-    from: '/libraries/lock-android/error-messages',
-    to: '/libraries/error-messages'
+    from: [
+      '/security/bulletins/cve-2018-6874',
+      '/security/cve-2018-6874',
+      '/security/security-bulletins/cve-2018-6874',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2018-6874',
   },
   {
-    from: '/api-auth/grant/using-rules',
-    to: '/api-auth/tutorials/client-credentials/customize-with-hooks'
+    from: [
+      '/security/bulletins/cve-2018-6873',
+      '/security/cve-2018-6873',
+      '/security/security-bulletins/cve-2018-6873',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2018-6873',
   },
   {
-    from: '/auth0-hooks',
-    to: '/hooks'
+    from: [
+      '/security/bulletins/cve-2017-16897',
+      '/security/cve-2017-16897',
+      '/security/security-bulletins/cve-2017-16897',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2017-16897',
   },
   {
-    from: '/auth0-hooks/cli/create-delete',
-    to: '/hooks/cli/create-delete'
+    from: [
+      '/security/bulletins/cve-2017-17068',
+      '/security/cve-2017-17068',
+      '/security/security-bulletins/cve-2017-17068',
+    ],
+    to: '/secure/security-guidance/security-bulletins/cve-2017-17068',
   },
   {
-    from: '/auth0-hooks/cli/edit',
-    to: '/hooks/cli/edit'
+    from: ['/security/incident-response-using-logs'],
+    to: '/secure/security-guidance/incident-response-using-logs',
   },
+
+  /* Tokens */
+
   {
-    from: '/auth0-hooks/cli/enable-disable',
-    to: '/hooks/cli/enable-disable'
+    from: ['/tokens', '/security/token-exp', '/token', '/tokens/concepts', '/tokens/guides', '/security/tokens'],
+    to: '/secure/tokens',
   },
   {
-    from: '/auth0-hooks/cli',
-    to: '/hooks/cli'
+    from: [
+      '/tokens/overview-id-tokens',
+      '/tokens/id-token',
+      '/tokens/concepts/id-tokens',
+      '/tokens/id_token',
+      '/tokens/id-tokens',
+      '/security/tokens/id-tokens',
+    ],
+    to: '/secure/tokens/id-tokens',
   },
   {
-    from: '/auth0-hooks/cli/logs',
-    to: '/hooks/cli/logs'
+    from: [
+      '/tokens/id-tokens/validate-id-tokens',
+      '/tokens/guides/validate-id-token',
+      '/tokens/guides/validate-id-tokens',
+      '/tokens/guides/id-token/validate-id-token',
+      '/tokens/id-tokens/validate-id-tokens',
+      '/security/tokens/id-tokens/validate-id-tokens',
+    ],
+    to: '/secure/tokens/id-tokens/validate-id-tokens',
   },
   {
-    from: '/auth0-hooks/dashboard',
-    to: '/hooks/dashboard'
+    from: [
+      '/tokens/id-tokens/get-id-tokens',
+      '/tokens/guides/id-token/get-id-tokens',
+      '/tokens/guides/get-id-tokens',
+      '/security/tokens/id-tokens/get-id-tokens',
+    ],
+    to: '/secure/tokens/id-tokens/get-id-tokens',
   },
   {
-    from: '/auth0-hooks/dashboard/create-delete',
-    to: '/hooks/dashboard/create-delete'
+    from: [
+      '/tokens/id-tokens/id-token-structure',
+      '/tokens/references/id-token-structure',
+      '/security/tokens/id-tokens/id-token-structure',
+    ],
+    to: '/secure/tokens/id-tokens/id-token-structure',
   },
   {
-    from: '/auth0-hooks/dashboard/edit',
-    to: '/hooks/dashboard/edit'
+    from: [
+      '/tokens/id-tokens/update-id-token-lifetime',
+      '/dashboard/guides/applications/update-token-lifetime',
+      '/security/tokens/id-tokens/update-id-token-lifetime',
+    ],
+    to: '/secure/tokens/id-tokens/update-id-token-lifetime',
   },
   {
-    from: '/auth0-hooks/dashboard/enable-disable',
-    to: '/hooks/dashboard/enable-disable'
+    from: [
+      '/api-auth/tutorials/adoption/api-tokens',
+      '/tokens/concepts/access-tokens',
+      '/tokens/concepts/access-token',
+      '/tokens/overview-access-tokens',
+      '/tokens/access-token',
+      '/tokens/access_token',
+      '/api-auth/why-use-access-tokens-to-secure-apis',
+      '/api-auth/asking-for-access-tokens',
+      '/tokens/access-tokens',
+      '/security/tokens/access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens',
   },
   {
-    from: '/auth0-hooks/extensibility-points',
-    to: '/hooks/extensibility-points'
+    from: ['/secure/tokens/access-tokens/token-binding'],
+    to: '/get-started/applications/configure-sender-constraining',
   },
   {
-    from: '/auth0-hooks/extensibility-points/client-credentials-exchange',
-    to: '/hooks/extensibility-points/client-credentials-exchange'
+    from: [
+      '/tokens/guides/validate-access-tokens',
+      '/api-auth/tutorials/verify-access-token',
+      '/tokens/guides/access-token/validate-access-token',
+      '/tokens/access-tokens/validate-access-tokens',
+      '/security/tokens/access-tokens/validate-access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/validate-access-tokens',
   },
   {
-    from: '/auth0-hooks/extensibility-points/credentials-exchange',
-    to: '/hooks/extensibility-points/credentials-exchange'
+    from: [
+      '/tokens/guides/get-access-tokens',
+      '/tokens/get-access-tokens',
+      '/tokens/guides/access-token/get-access-tokens',
+      '/tokens/access-tokens/get-access-tokens',
+      '/security/tokens/access-tokens/get-access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/get-access-tokens',
   },
   {
-    from: '/auth0-hooks/extensibility-points/post-user-registration',
-    to: '/hooks/extensibility-points/post-user-registration'
+    from: [
+      '/tokens/guides/use-access-tokens',
+      '/tokens/use-access-tokens',
+      '/tokens/guides/access-token/use-access-tokens',
+      '/tokens/access-tokens/use-access-tokens',
+      '/security/tokens/access-tokens/use-access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/use-access-tokens',
   },
   {
-    from: '/auth0-hooks/extensibility-points/pre-user-registration',
-    to: '/hooks/extensibility-points/pre-user-registration'
+    from: [
+      '/tokens/concepts/idp-access-tokens',
+      '/tokens/overview-idp-access-tokens',
+      '/tokens/idp',
+      '/tokens/identity-provider-access-tokens',
+      '/security/tokens/access-tokens/identity-provider-access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/identity-provider-access-tokens',
   },
   {
-    from: '/auth0-hooks/overview',
-    to: '/hooks/overview'
+    from: [
+      '/api/management/v2/tokens',
+      '/tokens/apiv2',
+      '/api/v2/tokens',
+      '/api/management/v2/concepts/tokens',
+      '/tokens/management-api-access-tokens',
+      '/api/management/v2/faq-management-api-access-tokens',
+      '/tokens/management-api-access-tokens/management-api-access-token-faqs',
+      '/security/tokens/access-tokens/management-api-access-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/management-api-access-tokens',
   },
   {
-    from: '/libraries/lock-ios/delegation-api',
-    to: '/libraries/lock-ios/v1/delegation-api'
+    from: [
+      '/tokens/management-api-access-tokens/get-management-api-access-tokens-for-production',
+      '/api/management/v2/get-access-tokens-for-production',
+      '/security/tokens/access-tokens/get-management-api-access-tokens-for-production',
+      '/secure/tokens/access-tokens/get-management-api-access-tokens-for-production',
+    ],
+    to: '/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-production',
   },
   {
-    from: '/libraries/lock-ios/lock-ios-api',
-    to: '/libraries/lock-ios/v1/lock-ios-api'
+    from: [
+      '/tokens/management-api-access-tokens/get-management-api-access-tokens-for-testing',
+      '/api/management/v2/get-access-tokens-for-test',
+      '/security/tokens/access-tokens/get-management-api-access-tokens-for-testing',
+      '/secure/tokens/access-tokens/get-management-api-access-tokens-for-testing',
+    ],
+    to: '/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-testing',
   },
   {
-    from: '/libraries/lock-ios/logging',
-    to: '/libraries/lock-ios/v1/logging'
+    from: [
+      '/tokens/management-api-access-tokens/get-management-api-tokens-for-single-page-applications',
+      '/api/management/v2/get-access-tokens-for-spas',
+      '/security/tokens/access-tokens/get-management-api-tokens-for-single-page-applications',
+      '/secure/tokens/access-tokens/get-management-api-tokens-for-single-page-applications',
+    ],
+    to: '/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-tokens-for-single-page-applications',
   },
   {
-    from: '/libraries/lock-ios/native-social-authentication',
-    to: '/libraries/lock-ios/v1/native-social-authentication'
+    from: [
+      '/api/management/v2/tokens-flows',
+      '/tokens/management-api-access-tokens/changes-in-auth0-management-apiv2-tokens',
+      '/security/tokens/access-tokens/changes-in-auth0-management-apiv2-tokens',
+      '/secure/tokens/access-tokens/changes-in-auth0-management-apiv2-tokens',
+    ],
+    to: '/secure/tokens/access-tokens/management-api-access-tokens/changes-in-auth0-management-apiv2-tokens',
   },
   {
-    from: '/libraries/lock-ios/password-reset-ios',
-    to: '/libraries/lock-ios/v1/password-reset-ios'
+    from: [
+      '/tokens/access-tokens/update-access-token-lifetime',
+      '/dashboard/guides/apis/update-token-lifetime',
+      '/security/tokens/access-tokens/update-access-token-lifetime',
+    ],
+    to: '/secure/tokens/access-tokens/update-access-token-lifetime',
   },
   {
-    from: '/libraries/lock-ios/save-and-refresh-jwt-tokens',
-    to: '/libraries/lock-ios/v1/save-and-refresh-jwt-tokens'
+    from: [
+      '/tokens/json-web-tokens',
+      '/tokens/concepts/jwts',
+      '/tokens/concepts/why-use-jwt',
+      '/tokens/jwt',
+      '/jwt',
+      '/security/tokens/json-web-tokens',
+    ],
+    to: '/secure/tokens/json-web-tokens',
   },
   {
-    from: '/libraries/lock-ios/sending-authentication-parameters',
-    to: '/libraries/lock-ios/v1/sending-authentication-parameters'
+    from: [
+      '/tokens/json-web-tokens/validate-json-web-tokens',
+      '/tokens/guides/validate-jwts',
+      '/tokens/guides/jwt/parse-validate-jwt-programmatically',
+      '/tokens/guides/jwt/validate-jwt',
+      '/security/tokens/json-web-tokens/validate-json-web-tokens',
+    ],
+    to: '/secure/tokens/json-web-tokens/validate-json-web-tokens',
   },
   {
-    from: '/libraries/lock-ios/sms-lock-ios',
-    to: '/libraries/lock-ios/v1/sms-lock-ios'
+    from: [
+      '/tokens/json-web-tokens/json-web-token-structure',
+      '/tokens/references/jwt-structure',
+      '/tokens/reference/jwt/jwt-structure',
+      '/security/tokens/json-web-tokens/json-web-token-structure',
+    ],
+    to: '/secure/tokens/json-web-tokens/json-web-token-structure',
   },
   {
-    from: '/libraries/lock-ios/swift',
-    to: '/libraries/lock-ios/v1/swift'
+    from: [
+      '/tokens/json-web-tokens/json-web-token-claims',
+      '/tokens/jwt-claims',
+      '/tokens/concepts/jwt-claims',
+      '/tokens/add-custom-claims',
+      '/scopes/current/custom-claims',
+      '/security/tokens/json-web-tokens/json-web-token-claims',
+    ],
+    to: '/secure/tokens/json-web-tokens/json-web-token-claims',
   },
   {
-    from: '/libraries/lock-ios/touchid-authentication',
-    to: '/libraries/lock-ios/v1/touchid-authentication'
+    from: [
+      '/tokens/create-namespaced-custom-claims',
+      '/tokens/guides/create-namespaced-custom-claims',
+      '/tokens/concepts/claims-namespacing',
+      '/security/tokens/json-web-tokens/create-namespaced-custom-claims',
+      '/secure/tokens/json-web-tokens/create-namespaced-custom-claims',
+    ],
+    to: '/secure/tokens/json-web-tokens/create-custom-claims',
   },
   {
-    from: '/libraries/lock-ios/use-your-own-ui',
-    to: '/libraries/lock-ios/v1/use-your-own-uis'
+    from: [
+      '/tokens/json-web-tokens/json-web-key-sets',
+      '/tokens/jwks',
+      '/jwks',
+      '/tokens/concepts/jwks',
+      '/security/tokens/json-web-tokens/json-web-key-sets',
+    ],
+    to: '/secure/tokens/json-web-tokens/json-web-key-sets',
   },
   {
-    from: '/api-auth/config/asking-for-access-tokens',
-    to: '/api-auth/tutorials/client-credentials'
+    from: [
+      '/tokens/json-web-tokens/json-web-key-sets/locate-json-web-key-sets',
+      '/tokens/guides/locate-jwks',
+      '/tokens/guides/jwt/verify-jwt-signature-using-jwks',
+      '/tokens/guides/jwt/use-jwks',
+      '/security/tokens/json-web-tokens/locate-json-web-key-sets',
+    ],
+    to: '/secure/tokens/json-web-tokens/locate-json-web-key-sets',
   },
   {
-    from: '/protocols/oauth2/oauth-implicit-protocol',
-    to: '/api-auth/tutorials/implicit-grant'
+    from: [
+      '/tokens/json-web-tokens/json-web-key-set-properties',
+      '/tokens/references/jwks-properties',
+      '/tokens/reference/jwt/jwks-properties',
+      '/security/tokens/json-web-tokens/json-web-key-set-properties',
+    ],
+    to: '/secure/tokens/json-web-tokens/json-web-key-set-properties',
   },
   {
-    from: '/quickstart/native/ios',
-    to: '/quickstart/native/ios-swift'
+    from: [
+      '/api-auth/tutorials/adoption/refresh-tokens',
+      '/refresh-token',
+      '/tokens/refresh_token',
+      '/tokens/refresh-token',
+      '/tokens/refresh-token/legacy',
+      '/tokens/refresh-token/current',
+      '/tokens/concepts/refresh-tokens',
+      '/tokens/access-tokens/refresh-tokens',
+      '/tokens/preview/refresh-token',
+      '/tokens/refresh-tokens',
+      '/security/tokens/refresh-tokens',
+    ],
+    to: '/secure/tokens/refresh-tokens',
   },
   {
-    from: '/rules/metadata-in-rules',
-    to: '/rules/current/metadata-in-rules'
+    from: [
+      '/tokens/refresh-tokens/get-refresh-tokens',
+      '/tokens/guides/get-refresh-tokens',
+      '/security/tokens/refresh-tokens/get-refresh-tokens',
+    ],
+    to: '/secure/tokens/refresh-tokens/get-refresh-tokens',
   },
   {
-    from: '/quickstart/native/ionic/00-intro',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/refresh-tokens/use-refresh-tokens',
+      '/tokens/guides/use-refresh-tokens',
+      '/security/tokens/refresh-tokens/use-refresh-tokens',
+    ],
+    to: '/secure/tokens/refresh-tokens/use-refresh-tokens',
   },
   {
-    from: '/quickstart/native/ionic/02-custom-login',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/refresh-tokens/configure-refresh-token-expiration',
+      '/security/tokens/configure-refresh-token-expiration',
+      '/security/tokens/refresh-tokens/configure-refresh-token-expiration',
+    ],
+    to: '/secure/tokens/refresh-tokens/configure-refresh-token-expiration',
   },
   {
-    from: '/quickstart/native/ionic/03-user-profile',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/concepts/refresh-token-rotation',
+      '/tokens/access-tokens/refresh-tokens/refresh-token-rotation',
+      '/tokens/refresh-tokens/refresh-token-rotation',
+      '/security/tokens/refresh-token-rotation',
+      '/security/tokens/refresh-tokens/refresh-token-rotation',
+    ],
+    to: '/secure/tokens/refresh-tokens/refresh-token-rotation',
   },
   {
-    from: '/quickstart/native/ionic/04-linking-accounts',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/refresh-tokens/configure-refresh-token-rotation',
+      '/tokens/guides/configure-refresh-token-rotation',
+      '/security/tokens/refresh-tokens/configure-refresh-token-rotation',
+    ],
+    to: '/secure/tokens/refresh-tokens/configure-refresh-token-rotation',
   },
   {
-    from: '/quickstart/native/ionic/05-rules',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/guides/use-refresh-token-rotation',
+      '/tokens/refresh-token-rotation/use-refresh-token-rotation',
+      '/tokens/refresh-tokens/refresh-token-rotation/use-refresh-token-rotation',
+      '/security/tokens/refresh-tokens/use-refresh-token-rotation',
+    ],
+    to: '/secure/tokens/refresh-tokens/use-refresh-token-rotation',
   },
   {
-    from: '/quickstart/native/ionic/06-authorization',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/guides/disable-refresh-token-rotation',
+      '/tokens/access-tokens/refresh-tokens/disable-refresh-token-rotation',
+      '/tokens/refresh-tokens/disable-refresh-token-rotation',
+      '/security/tokens/refresh-tokens/disable-refresh-token-rotation',
+    ],
+    to: '/secure/tokens/refresh-tokens/disable-refresh-token-rotation',
   },
   {
-    from: '/quickstart/native/ionic/08-mfa',
-    to: '/quickstart/native/ionic'
+    from: [
+      '/tokens/refresh-tokens/revoke-refresh-tokens',
+      '/tokens/guides/revoke-refresh-tokens',
+      '/security/tokens/refresh-tokens/revoke-refresh-tokens',
+    ],
+    to: '/secure/tokens/refresh-tokens/revoke-refresh-tokens',
   },
   {
-    from: '/quickstart/native/ionic/09-customizing-lock',
-    to: '/quickstart/native/ionic'
+    from: ['/tokens/revoke-tokens', '/tokens/guides/revoke-tokens', '/security/tokens/revoke-tokens'],
+    to: '/secure/tokens/revoke-tokens',
   },
   {
-    from: '/quickstart/backend/nodejs/00-getting-started',
-    to: '/quickstart/backend/nodejs'
+    from: [
+      '/api-auth/tutorials/adoption/delegation',
+      '/tokens/delegation',
+      '/tokens/concepts/delegation-tokens',
+      '/tokens/delegation-tokens',
+      '/security/tokens/delegation-tokens',
+    ],
+    to: '/secure/tokens/delegation-tokens',
   },
+
+  /* Support */
+
   {
-    from: '/quickstart/backend/aspnet-core-webapi/00-getting-started',
-    to: '/quickstart/backend/aspnet-core-webapi'
+    from: ['/policies/requests', '/premium-support', '/support'],
+    to: '/troubleshoot/customer-support',
   },
   {
-    from: '/quickstart/backend/falcor/00-getting-started',
-    to: '/quickstart/backend/falcor'
+    from: [
+      '/support/support-overview',
+      '/support/support-plans',
+      '/support/support-procedures',
+      '/troubleshoot/customer-support/support-procedures',
+      '/support/support-hours-and-languages',
+      '/troubleshoot/customer-support/support-hours-and-languages',
+    ],
+    to: '/troubleshoot/customer-support/support-plans',
   },
   {
-    from: '/quickstart/backend/golang/00-getting-started',
-    to: '/quickstart/backend/golang'
+    from: ['/support/matrix', '/support/product-support-matrix'],
+    to: '/troubleshoot/customer-support/product-support-matrix',
   },
   {
-    from: '/quickstart/backend/hapi/00-getting-started',
-    to: '/quickstart/backend/hapi'
+    from: ['/sla', '/support/sla', '/support/sld', '/support/services-level-descriptions'],
+    to: '/troubleshoot/customer-support/services-level-descriptions',
   },
   {
-    from: '/quickstart/backend/java-spring-security/00-getting-started',
-    to: '/quickstart/backend/java-spring-security'
+    from: ['/support/tickets', '/support/open-and-manage-support-tickets'],
+    to: '/troubleshoot/customer-support/open-and-manage-support-tickets',
   },
   {
-    from: '/quickstart/backend/laravel/00-getting-started',
-    to: '/quickstart/backend/laravel'
+    from: ['/support/subscription', '/support/manage-subscriptions'],
+    to: '/troubleshoot/customer-support/manage-subscriptions',
   },
   {
-    from: '/quickstart/backend/php/00-getting-started',
-    to: '/quickstart/backend/php'
+    from: [
+      '/support/cancel-paid-subscriptions',
+      '/tutorials/cancel-paid-subscriptions',
+      '/cancel-paid-subscriptions',
+      '/support/downgrade-or-cancel-subscriptions',
+      '/support/manage-subscriptions/downgrade-or-cancel-subscriptions',
+    ],
+    to: '/troubleshoot/customer-support/manage-subscriptions/downgrade-or-cancel-subscriptions',
   },
   {
-    from: '/quickstart/backend/python/00-getting-started',
-    to: '/quickstart/backend/python'
+    from: [
+      '/support/delete-or-reset-tenant',
+      '/support/delete-reset-tenant',
+      '/tutorials/delete-reset-tenant',
+      '/support/manage-subscriptions/delete-or-reset-tenant',
+    ],
+    to: '/troubleshoot/customer-support/manage-subscriptions/delete-or-reset-tenant',
   },
   {
-    from: '/quickstart/backend/rails/00-getting-started',
-    to: '/quickstart/backend/rails'
+    from: [
+      '/tutorials/removing-auth0-exporting-data',
+      '/support/removing-auth0-exporting-data',
+      '/moving-out',
+      '/support/export-data',
+      '/support/manage-subscriptions/export-data',
+    ],
+    to: '/troubleshoot/customer-support/manage-subscriptions/export-data',
   },
   {
-    from: '/quickstart/backend/relay/00-getting-started',
-    to: '/quickstart/backend/relay'
+    from: [
+      '/support/how-auth0-versions-software',
+      '/tutorials/how-auth0-versions-software',
+      '/versioning',
+      '/support/versioning-strategy',
+    ],
+    to: '/troubleshoot/customer-support/versioning-strategy',
   },
   {
-    from: '/quickstart/backend/ruby/00-getting-started',
-    to: '/quickstart/backend/ruby'
+    from: ['/support/reset-account-password', '/tutorials/reset-account-password', '/support/reset-account-passwords'],
+    to: '/troubleshoot/customer-support/reset-account-passwords',
   },
   {
-    from: '/quickstart/backend/symfony/00-getting-started',
-    to: '/quickstart/backend/symfony'
+    from: ['/support/support-channels'],
+    to: '/troubleshoot/customer-support/support-channels',
   },
   {
-    from: '/quickstart/backend/webapi-owin/00-getting-started',
-    to: '/quickstart/backend/webapi-owin'
+    from: ['/support/software-updates'],
+    to: '/troubleshoot/customer-support/software-updates',
   },
   {
-    from: '/quickstart/webapp/rails/00-introduction',
-    to: '/quickstart/webapp/rails'
+    from: ['/support/whitehat-security-support-tickets'],
+    to: '/troubleshoot/customer-support/responsible-disclosure-program-security-support-tickets',
   },
+
+  /* Policies */
+
   {
-    from: '/quickstart/webapp/rails/02-custom-login',
-    to: '/quickstart/webapp/rails'
+    from: [
+      '/policies',
+      '/policies/dashboard-authentication',
+      '/policies/restore-deleted-tenant',
+      '/policies/unsupported-requests',
+      '/support/policies',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies',
   },
   {
-    from: '/quickstart/webapp/rails/03-session-handling',
-    to: '/quickstart/webapp/rails/02-session-handling'
+    from: ['/policies/billing-policy', '/policies/billing', '/support/policies/billing-policy'],
+    to: '/troubleshoot/customer-support/operational-policies/billing-policy',
   },
   {
-    from: '/quickstart/webapp/rails/04-user-profile',
-    to: '/quickstart/webapp/rails/03-user-profile'
+    from: [
+      '/policies/public-cloud-service-endpoints',
+      '/policies/endpoints',
+      '/security/public-cloud-service-endpoints',
+      '/support/policies/public-cloud-service-endpoints',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/public-cloud-service-endpoints',
   },
   {
-    from: '/quickstart/webapp/rails/05-linking-accounts',
-    to: '/quickstart/webapp/rails'
+    from: [
+      '/policies/data-export-and-transfer-policy',
+      '/policies/data-export',
+      '/policies/data-transfer',
+      '/support/policies/data-export-and-transfer-policy',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/data-export-and-transfer-policy',
   },
   {
-    from: '/quickstart/webapp/rails/06-rules',
-    to: '/quickstart/webapp/rails'
+    from: ['/policies/load-testing-policy', '/policies/load-testing', '/support/policies/load-testing-policy'],
+    to: '/troubleshoot/customer-support/operational-policies/load-testing-policy',
   },
   {
-    from: '/quickstart/webapp/rails/07-authorization',
-    to: '/quickstart/webapp/rails'
+    from: [
+      '/policies/penetration-testing-policy',
+      '/policies/penetration-testing',
+      '/support/policies/penetration-testing-policy',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/penetration-testing-policy',
   },
   {
-    from: '/quickstart/webapp/rails/08-mfa',
-    to: '/quickstart/webapp/rails'
+    from: [
+      '/rate-limits',
+      '/policies/rate-limit',
+      '/policies/rate-limits',
+      '/policies/legacy-rate-limits',
+      '/policies/rate-limit-policy',
+      '/support/policies/rate-limit-policy',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
   },
   {
-    from: '/quickstart/webapp/rails/09-customizing-lock',
-    to: '/quickstart/webapp/rails'
+    from: [
+      '/policies/rate-limit-policy/authentication-api-endpoint-rate-limits',
+      '/policies/rate-limits-auth-api',
+      '/policies/rate-limits-api',
+      '/policies/authentication-api-endpoint-rate-limits',
+      '/support/policies/rate-limit-policy/authentication-api-endpoint-rate-limits',
+      '/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
   },
   {
-    from: '/quickstart/webapp/java/getting-started',
-    to: '/quickstart/webapp/java'
+    from: [
+      '/policies/rate-limit-policy/mgmt-api-endpoint-rate-limits-before-19-may-2020',
+      '/policies/rate-limit-policy/management-api-endpoint-rate-limits',
+      '/policies/rate-limits-mgmt-api',
+      '/policies/management-api-endpoint-rate-limits',
+      '/support/policies/rate-limit-policy/management-api-endpoint-rate-limits',
+      '/troubleshoot/customer-support/operational-policies/rate-limit-policy/management-api-endpoint-rate-limits',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
   },
   {
-    from: '/quickstart/webapp/java-spring-mvc/getting-started',
-    to: '/quickstart/webapp/java-spring-mvc'
+    from: [
+      '/policies/database-connections-rate-limits',
+      '/policies/rate-limit-policy/database-connections-rate-limits',
+      '/connections/database/rate-limits',
+      '/support/policies/database-connections-rate-limits',
+      '/support/policies/rate-limit-policy/database-connections-rate-limits',
+      '/troubleshoot/customer-support/operational-policies/rate-limit-policy/database-connections-rate-limits',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
   },
   {
-    from: '/quickstart/webapp/java-spring-security-mvc/00-intro',
-    to: '/quickstart/webapp/java-spring-security-mvc'
+    from: [
+      '/troubleshoot/customer-support/operational-policies/rate-limit-policy/understand-rate-limit-burst-capability',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
   },
   {
-    from: '/tutorials/step-up-authentication',
-    to: '/multifactor-authentication/developer/step-up-with-acr'
+    from: [
+      '/authorization/reference/rbac-limits',
+      '/authorization/rbac/authorization-core-rbac-limits',
+      '/policies/entity-limit-policy',
+      '/policies/entity-limits',
+      '/policies/global-limit',
+      '/support/policies/entity-limit-policy',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/entity-limit-policy',
   },
   {
-    from: '/quickstart/spa/angular2/00-login',
-    to: '/quickstart/spa/angular2'
+    from: [
+      '/support/support-center-users',
+      '/dashboard-access/support-center-users',
+      '/get-started/manage-dashboard-access/support-center-users',
+    ],
+    to: '/get-started/manage-dashboard-access/feature-access-by-role',
   },
+
+  /* Troubleshoot */
+
   {
-    from: '/quickstart/spa/angular2/03-user-profile',
-    to: '/quickstart/spa/angular2/02-user-profile'
+    from: ['/troubleshoot/basics'],
+    to: '/troubleshoot',
   },
   {
-    from: '/quickstart/spa/angular2/04-calling-an-api',
-    to: '/quickstart/spa/angular2/03-calling-an-api'
+    from: ['/troubleshoot/basic-troubleshooting', '/troubleshoot/concepts/basics', '/troubleshoot/troubleshoot-basic'],
+    to: '/troubleshoot/basic-issues',
   },
   {
-    from: '/quickstart/spa/angular2/05-authorization',
-    to: '/quickstart/spa/angular2/04-authorization'
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-platform',
+      '/troubleshoot/guides/verify-platform',
+      '/troubleshoot/troubleshoot-basic/verify-platform',
+    ],
+    to: '/troubleshoot/basic-issues/verify-platform',
   },
   {
-    from: '/quickstart/spa/angular2/06-token-renewal',
-    to: '/quickstart/spa/angular2/05-token-renewal'
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-connections',
+      '/troubleshoot/guides/verify-connections',
+      '/troubleshoot/troubleshoot-basic/verify-connections',
+    ],
+    to: '/troubleshoot/basic-issues/verify-connections',
   },
   {
-    from: '/security/token-exp',
-    to: '/tokens'
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-domain',
+      '/troubleshoot/guides/verify-domain',
+      '/troubleshoot/troubleshoot-basic/verify-domain',
+    ],
+    to: '/troubleshoot/basic-issues/verify-domain',
   },
   {
-    from: ['/hosted-pages/hosted-login-auth0js'],
-    to: '/hosted-pages/login/auth0js'
+    from: [
+      '/troubleshoot/guides/verify-rules',
+      '/troubleshoot/verify-rules',
+      '/troubleshoot/troubleshoot-basic/verify-rules',
+    ],
+    to: '/troubleshoot/basic-issues/verify-rules',
   },
   {
-    from: ['/hosted-pages/hosted-login-auth0js/v8'],
-    to: '/hosted-pages/login/auth0js'
+    from: [
+      '/troubleshoot/guides/check-error-messages',
+      '/troubleshoot/check-error-messages',
+      '/troubleshoot/troubleshoot-basic/check-error-messages',
+    ],
+    to: '/troubleshoot/basic-issues/check-error-messages',
   },
   {
-    from: ['/hosted-pages/hosted-login-auth0js/v7'],
-    to: '/hosted-pages/login/auth0js'
+    from: [
+      '/product-lifecycle/deprecations-and-migrations/search-logs-for-deprecation-errors',
+      '/errors/deprecations-errors/',
+      '/troubleshoot/troubleshoot-basic/search-logs-for-deprecation-errors',
+    ],
+    to: '/troubleshoot/basic-issues/search-logs-for-deprecation-errors',
   },
   {
-    from: '/connections/database/mysql',
-    to: '/connections/database/custom-db'
+    from: [
+      '/troubleshoot/guides/check-deprecation-errors',
+      '/troubleshoot/troubleshoot-authentication-issues/check-deprecation-errors',
+      '/troubleshoot/troubleshoot-basic/check-deprecation-errors',
+    ],
+    to: '/troubleshoot/basic-issues/check-deprecation-errors',
   },
   {
-    from: '/dashboard-account-settings',
-    to: '/dashboard-tenant-settings'
+    from: [
+      '/troubleshoot/references/invalid-token',
+      '/troubleshoot/invalid-token-errors',
+      '/troubleshoot/troubleshoot-basic/invalid-token-errors',
+    ],
+    to: '/troubleshoot/basic-issues/invalid-token-errors',
   },
   {
-    from: '/metadata/lock',
-    to: '/metadata#using-lock-to-manage-metadata'
+    from: [
+      '/troubleshoot/concepts/auth-issues',
+      '/troubleshoot/troubleshoot-authentication-issues',
+      '/troubleshoot/troubleshoot-authentication',
+    ],
+    to: '/troubleshoot/authentication-issues',
   },
   {
-    from: ['/libraries/lock/v10/customization'],
-    to: '/libraries/lock/v10/configuration',
+    from: [
+      '/troubleshoot/guides/check-api-calls',
+      '/troubleshoot/troubleshoot-authentication-issues/check-api-calls',
+      '/troubleshoot/troubleshoot-authentication/check-api-calls',
+    ],
+    to: '/troubleshoot/authentication-issues/check-api-calls',
   },
   {
-    from: ['/libraries/lock/v11/customization'],
-    to: '/libraries/lock/v11/configuration',
+    from: [
+      '/troubleshoot/guides/check-login-logout-issues',
+      '/troubleshoot/troubleshoot-authentication-issues/check-login-and-logout-issues',
+      '/troubleshoot/troubleshoot-authentication/check-login-and-logout-issues',
+    ],
+    to: '/troubleshoot/authentication-issues/check-login-and-logout-issues',
   },
   {
-    from: '/libraries/lock/v9/customization',
-    to: '/libraries/lock/v9/configuration',
+    from: [
+      '/troubleshoot/guides/check-user-profiles',
+      '/troubleshoot/troubleshoot-authentication-issues/check-user-profiles',
+      '/troubleshoot/troubleshoot-authentication/check-user-profiles',
+    ],
+    to: '/troubleshoot/authentication-issues/check-user-profiles',
   },
   {
-    from: '/libraries/lock/v10/popup-mode',
-    to: '/libraries/lock/v10/authentication-modes',
+    from: [
+      '/authorization/concepts/troubleshooting',
+      '/authorization/troubleshoot-role-based-access-control-and-authorization',
+      '/troubleshoot/troubleshoot-authentication/troubleshoot-rbac-authorization',
+    ],
+    to: '/troubleshoot/authentication-issues/troubleshoot-rbac-authorization',
   },
   {
-    from: '/libraries/lock/v11/popup-mode',
-    to: '/libraries/lock/v11/authentication-modes',
+    from: [
+      '/troubleshoot/references/saml-errors',
+      '/troubleshoot/troubleshoot-authentication-issues/saml-errors',
+      '/troubleshoot/troubleshoot-authentication/saml-errors',
+    ],
+    to: '/troubleshoot/authentication-issues/saml-errors',
   },
   {
-    from: '/libraries/lock/v9/display-modes',
-    to: '/libraries/lock/v9/configuration#container-string-',
+    from: [
+      '/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp',
+      '/protocols/saml/saml-configuration/troubleshoot',
+      '/protocols/saml/saml-configuration/troubleshoot/common-saml-errors',
+      '/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp',
+      '/troubleshoot/troubleshoot-saml-configurations',
+      '/protocols/saml-protocol/troubleshoot-saml-configurations',
+      '/troubleshoot/troubleshoot-authentication/troubleshoot-saml-configurations',
+    ],
+    to: '/troubleshoot/authentication-issues/troubleshoot-saml-configurations',
   },
   {
-    from: '/libraries/lock/v9/types-of-applications',
-    to: '/libraries/lock/v9/display-modes',
+    from: [
+      '/troubleshoot/self-change-password-errors',
+      '/troubleshoot/references/self_change_password',
+      '/troubleshoot/troubleshoot-authentication/self-change-password-errors',
+    ],
+    to: '/troubleshoot/authentication-issues/self-change-password-errors',
   },
   {
-    from: '/tutorials/azure-tutorial',
-    to: '/integrations/azure-tutorial',
+    from: [
+      '/multifactor-authentication/google-auth/admin-guide',
+      '/multifactor-authentication/google-auth/user-guide',
+      '/multifactor-authentication/troubleshooting',
+      '/mfa/references/troubleshoot-mfa',
+      '/mfa/references/troubleshooting',
+      '/mfa/troubleshoot-mfa-issues',
+      '/troubleshoot/troubleshoot-authentication/troubleshoot-mfa-issues',
+    ],
+    to: '/troubleshoot/authentication-issues/troubleshoot-mfa-issues',
   },
   {
-    from: '/tutorials/blacklisting-attributes',
-    to: '/security/blacklisting-attributes',
+    from: [
+      '/extensions/authorization-extension/v2/troubleshooting',
+      '/extensions/authorization-dashboard-extension/troubleshoot-authorization-extension',
+      '/extensions/authorization-extension/troubleshoot-authorization-extension',
+      '/troubleshoot/troubleshoot-authentication/troubleshoot-authorization-extension',
+    ],
+    to: '/troubleshoot/authentication-issues/troubleshoot-authorization-extension',
   },
   {
-    from: '/tutorials/integrating-with-slack',
-    to: '/integrations/integrating-with-slack',
+    from: [
+      '/authorization/renew-tokens-when-using-safari',
+      '/api-auth/token-renewal-in-safari',
+      '/troubleshoot/troubleshoot-authentication/renew-tokens-when-using-safari',
+    ],
+    to: '/troubleshoot/authentication-issues/renew-tokens-when-using-safari',
   },
   {
-    from: '/tutorials/browser-based-vs-native-experience-on-mobile',
-    to: '/design/browser-based-vs-native-experience-on-mobile',
+    from: [
+      '/troubleshoot/concepts/integration-extensibility-issues',
+      '/troubleshoot/troubleshoot-integration-and-extensibility',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues',
   },
   {
-    from: '/tutorials/using-auth0-with-multi-tenant-apps',
-    to: '/design/using-auth0-with-multi-tenant-apps',
+    from: [
+      '/custom-domains/troubleshoot-custom-domains',
+      '/custom-domains/troubleshoot',
+      '/troubleshoot/troubleshoot-integration-and-extensibility/troubleshoot-custom-domains',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues/troubleshoot-custom-domains',
   },
   {
-    from: '/tutorials/adding-generic-oauth1-connection',
-    to: '/connections/adding-generic-oauth1-connection',
+    from: [
+      '/connector/troubleshooting',
+      '/ad-ldap-connector/troubleshoot-ad-ldap-connector',
+      '/extensions/ad-ldap-connector/troubleshoot-ad-ldap-connector',
+      '/troubleshoot/troubleshoot-integration-and-extensibility/troubleshoot-ad-ldap-connector',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues/troubleshoot-ad-ldap-connector',
   },
   {
-    from: '/tutorials/adding-scopes-for-an-external-idp',
-    to: '/connections/adding-scopes-for-an-external-idp',
+    from: [
+      '/extensions/troubleshoot-extensions',
+      '/extensions/troubleshoot',
+      '/troubleshoot/troubleshoot-integration-and-extensibility/troubleshoot-extensions',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues/troubleshoot-extensions',
   },
   {
-    from: '/tutorials/generic-oauth2-connection-examples',
-    to: '/connections/generic-oauth2-connection-examples',
+    from: [
+      '/extensions/deploy-cli/references/troubleshooting',
+      '/extensions/deploy-cli-tool/troubleshoot-the-deploy-cli-tool',
+      '/deploy/deploy-cli-tool/troubleshoot-the-deploy-cli-tool',
+      '/troubleshoot/troubleshoot-integration-and-extensibility/troubleshoot-the-deploy-cli-tool',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues/troubleshoot-the-deploy-cli-tool',
   },
   {
-    from: '/tutorials/calling-an-external-idp-api',
-    to: '/connections/calling-an-external-idp-api',
+    from: ['/troubleshoot/tools'],
+    to: '/troubleshoot/troubleshooting-tools',
   },
   {
-    from: '/tutorials/tracking-new-leads-in-salesforce-and-raplead',
-    to: '/monitoring/tracking-new-leads-in-salesforce-and-raplead',
+    from: [
+      '/har',
+      '/tutorials/troubleshooting-with-har-files',
+      '/troubleshoot/har',
+      '/support/troubleshooting-with-har-files',
+      '/troubleshoot/guides/generate-har-files',
+      '/troubleshoot/generate-and-analyze-har-files',
+      '/troubleshoot/tools/generate-and-analyze-har-files',
+      '/troubleshoot/troubleshooting-tools/sanitize-http-traces',
+    ],
+    to: '/troubleshoot/troubleshooting-tools/generate-and-analyze-har-files',
   },
+
+  /* Tutorials */
+
   {
-    from: '/tutorials/track-signups-enrich-user-profile-generate-leads',
-    to: '/monitoring/track-signups-enrich-user-profile-generate-leads',
+    from: ['/scenarios', '/tutorials'],
+    to: '/',
   },
+
+  /* Manage Users */
+
   {
-    from: '/tutorials/how-to-monitor-auth0',
-    to: '/monitoring/how-to-monitor-auth0',
+    from: ['/users/concepts/overview-users', '/users'],
+    to: '/manage-users',
   },
   {
-    from: '/tutorials/sending-events-to-splunk',
-    to: '/monitoring/sending-events-to-splunk',
+    from: [
+      '/user-profile/normalized',
+      '/user-profile/normalized/oidc',
+      '/user-profile',
+      '/users/concepts/overview-user-profile',
+      '/user-profile/user-profile-details',
+      '/users/normalized/oidc',
+      '/users/user-profiles-returned-from-oidc-compliant-pipelines',
+      '/users/user-profiles',
+    ],
+    to: '/manage-users/user-accounts/user-profiles',
   },
   {
-    from: '/tutorials/sending-events-to-segmentio',
-    to: '/monitoring/sending-events-to-segmentio',
+    from: [
+      '/user-profile/user-profile-structure',
+      '/users/references/user-profile-structure',
+      '/users/user-profile-structure',
+      '/users/user-profiles/user-profile-structure',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/user-profile-structure',
   },
   {
-    from: '/tutorials/sending-events-to-keenio',
-    to: '/monitoring/sending-events-to-keenio',
+    from: [
+      '/users/sample-user-profiles',
+      '/users/normalized/auth0/sample-user-profiles',
+      '/users/user-profiles/sample-user-profiles',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/sample-user-profiles',
   },
   {
-    from: '/tutorials/cancel-paid-subscriptions',
-    to: '/support/cancel-paid-subscriptions',
+    from: [
+      '/users/normalized-user-profiles',
+      '/users/normalized',
+      '/user-profile/normalized/auth0',
+      '/users/normalized/auth0',
+      '/users/user-profiles/normalized-user-profiles',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/normalized-user-profiles',
   },
   {
-    from: '/tutorials/reset-account-password',
-    to: '/support/reset-account-password',
+    from: [
+      '/users/normalized-user-profile-schema',
+      '/users/normalized/auth0/normalized-user-profile-schema',
+      '/users/user-profiles/normalized-user-profile-schema',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/normalized-user-profile-schema',
   },
   {
-    from: '/tutorials/troubleshooting-with-har-files',
-    to: '/support/troubleshooting-with-har-files',
+    from: [
+      '/user-profile/progressive-profiling',
+      '/users/concepts/overview-progressive-profiling',
+      '/users/guides/implement-progressive-profiling',
+      '/users/progressive-profiling',
+      '/users/concepts/overview-progressive-profiling',
+      '/users/user-profiles/progressive-profiling',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/progressive-profiling',
   },
   {
-    from: '/tutorials/delete-reset-tenant',
-    to: '/support/delete-reset-tenant',
+    from: [
+      '/users/updating-user-profile-root-attributes',
+      '/users/normalized/auth0/update-root-attributes',
+      '/users/user-profiles/root-attributes',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/root-attributes',
   },
   {
-    from: '/tutorials/how-to-test-partner-connection',
-    to: '/connections/how-to-test-partner-connection',
+    from: [
+      '/users/set-root-attributes-during-user-import',
+      '/api/management/guides/users/set-root-attributes-user-import',
+      '/users/user-profiles/root-attributes/set-root-attributes-during-user-import',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/root-attributes/set-root-attributes-during-user-import',
   },
   {
-    from: '/tutorials/how-auth0-versions-software',
-    to: '/support/how-auth0-versions-software',
+    from: [
+      '/users/set-root-attributes-during-user-sign-up',
+      '/api/management/guides/users/set-root-attributes-user-signup',
+      '/users/user-profiles/root-attributes/set-root-attributes-during-user-sign-up',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/root-attributes/set-root-attributes-during-user-sign-up',
   },
   {
-    from: '/tutorials/authenticating-a-tessel-device',
-    to: '/integrations/authenticating-a-tessel-device',
+    from: [
+      '/users/update-root-attributes-for-users',
+      '/api/management/guides/users/update-root-attributes-users',
+      '/users/user-profiles/root-attributes/update-root-attributes-for-users',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/root-attributes/update-root-attributes-for-users',
   },
   {
-    from: '/tutorials/authenticating-devices-using-mqtt',
-    to: '/integrations/authenticating-devices-using-mqtt',
+    from: ['/users/verified-email-usage', '/users/guides/email-verified', '/users/user-profiles/verified-email-usage'],
+    to: '/manage-users/user-accounts/user-profiles/verified-email-usage',
   },
   {
-    from: '/tutorials/creating-users-in-the-management-portal',
-    to: '/dashboard/creating-users-in-the-management-portal',
+    from: [
+      '/users/configure-connection-sync-with-auth0',
+      '/dashboard/guides/connections/configure-connection-sync',
+      '/api/management/guides/connections/configure-connection-sync',
+      '/users/user-profiles/configure-connection-sync-with-auth0',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/configure-connection-sync-with-auth0',
   },
   {
-    from: '/tutorials/dashboard-tenant-settings',
-    to: '/dashboard/dashboard-tenant-settings',
+    from: [
+      '/users/update-user-profiles-using-your-database',
+      '/user-profile/customdb',
+      '/users/guides/update-user-profiles-using-your-database',
+      '/users/user-profiles/update-user-profiles-using-your-database',
+    ],
+    to: '/manage-users/user-accounts/user-profiles/update-user-profiles-using-your-database',
   },
   {
-    from: '/tutorials/manage-dashboard-admins',
-    to: '/dashboard/manage-dashboard-admins',
+    from: [
+      '/users/concepts/overview-user-metadata',
+      '/metadata',
+      '/users/read-metadata',
+      '/users/guides/read-metadata',
+      '/users/guides/manage-user-metadata',
+      '/users/manage-user-metadata',
+      '/users/metadata',
+    ],
+    to: '/manage-users/user-accounts/metadata',
   },
   {
-    from: '/tutorials/web-apps-vs-web-apis-cookies-vs-tokens',
-    to: '/design/web-apps-vs-web-apis-cookies-vs-tokens',
+    from: [
+      '/users/references/metadata-field-name-rules',
+      '/best-practices/metadata-best-practices',
+      '/users/metadata/metadata-fields-data',
+    ],
+    to: '/manage-users/user-accounts/metadata/metadata-fields-data',
   },
   {
-    from: '/tutorials/how-to-update-applications-client-secret',
-    to: '/applications/how-to-update-client-secret',
+    from: [
+      '/users/guides/update-metadata-properties-with-management-api',
+      '/update-metadata-with-the-management-api',
+      '/users/update-metadata-with-the-management-api',
+      '/metadata/management-api',
+      '/metadata/apiv2',
+      '/metadata/apis',
+      '/users/guides/set-metadata-properties-on-creation',
+      '/users/set-metadata-properties-on-creation',
+      '/users/metadata/manage-metadata-api',
+    ],
+    to: '/manage-users/user-accounts/metadata/manage-metadata-api',
   },
   {
-    from: '/tutorials/using-auth0-to-secure-a-cli',
-    to: '/integrations/using-auth0-to-secure-a-cli',
+    from: ['/metadata/lock', '/users/metadata/manage-metadata-lock'],
+    to: '/manage-users/user-accounts/metadata/manage-metadata-lock',
   },
   {
-    from: '/tutorials/creating-invite-only-applications',
-    to: '/design/creating-invite-only-applications',
+    from: [
+      '/rules/current/metadata-in-rules',
+      '/rules/guides/metadata',
+      '/rules/metadata-in-rules',
+      '/metadata-in-rules',
+      '/metadata/rules',
+      '/rules/metadata',
+      '/users/metadata/manage-metadata-rules',
+    ],
+    to: '/manage-users/user-accounts/metadata/manage-metadata-rules',
   },
   {
-    from: '/tutorials/google-cloud-platform',
-    to: '/tutorials/google-cloud-platform',
+    from: [
+      '/sessions-and-cookies',
+      '/sessions/concepts/session',
+      '/sessions/concepts/session-lifetime',
+      '/sessions/references/sample-use-cases-sessions',
+      '/sessions-and-cookies/session-use-cases',
+      '/sessions',
+      '/users/sessions',
+    ],
+    to: '/manage-users/sessions',
   },
   {
-    from: '/tutorials/configuration-to-query-users-from-google-apps',
-    to: '/integrations/configuration-to-query-users-from-google-apps',
+    from: ['/sessions/session-layers', '/sessions/concepts/session-layers', '/users/sessions/session-layers'],
+    to: '/manage-users/sessions/session-layers',
   },
   {
-    from: '/tutorials/integrating-auth0-amazon-cognito-mobile-apps',
-    to: '/integrations/integrating-auth0-amazon-cognito-mobile-apps',
+    from: ['/sessions/session-lifetime-limits', '/users/sessions/session-lifetime-limits'],
+    to: '/manage-users/sessions/session-lifetime-limits',
   },
   {
-    from: '/tutorials/office365-connection-deprecation-guide',
-    to: '/integrations/office365-connection-deprecation-guide',
+    from: [
+      '/get-started/dashboard/configure-session-lifetime-settings',
+      '/dashboard/guides/tenants/configure-session-lifetime-settings',
+      '/api/management/guides/tenants/configure-session-lifetime-settings',
+      '/sso/current/configure-session-lifetime-limits',
+      '/sessions/configure-session-lifetime-settings',
+      '/users/sessions/session-lifetimes/configure-session-lifetime-settings',
+      '/users/sessions/configure-session-lifetime-settings',
+    ],
+    to: '/manage-users/sessions/configure-session-lifetime-settings',
   },
   {
-    from: '/tutorials/redirecting-users',
-    to: '/users/redirecting-users',
+    from: [
+      '/sessions/non-persistent-sessions',
+      '/users/sessions/session-lifetimes/non-persistent-sessions',
+      '/users/sessions/non-persistent-sessions',
+    ],
+    to: '/manage-users/sessions/non-persistent-sessions',
   },
   {
-    from: '/tutorials/get-user-information-with-unbounce-landing-pages',
-    to: '/users/get-user-information-with-unbounce-landing-pages',
+    from: [
+      '/sessions/references/example-short-lived-session-mgmt',
+      '/sessions-and-cookies/manage-multi-site-short-long-lived-sessions',
+      '/users/sessions/manage-multi-site-sessions',
+    ],
+    to: '/manage-users/sessions/manage-multi-site-sessions',
   },
   {
-    from: '/tutorials/bulk-importing-users-into-auth0',
-    to: '/users/bulk-importing-users-into-auth0',
+    from: ['/sessions/cookies', '/sessions/concepts/cookies', '/sessions-and-cookies/cookies', '/users/cookies'],
+    to: '/manage-users/cookies',
   },
   {
-    from: '/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise',
-    to: '/integrations/using-auth0-as-an-identity-provider-with-github-enterprise',
+    from: ['/sessions/cookies/authentication-api-cookies', '/users/cookies/authentication-api-cookies'],
+    to: '/manage-users/cookies/authentication-api-cookies',
   },
   {
-    from: '/tutorials/configure-wsfed-application',
-    to: '/integrations/configure-wsfed-application',
+    from: [
+      '/sessions/spa-authenticate-with-cookies',
+      '/login/spa/authenticate-with-cookies',
+      '/sessions-and-cookies/spa-authenticate-with-cookies',
+      '/sessions/cookies/spa-authenticate-with-cookies',
+      '/users/cookies/spa-authenticate-with-cookies',
+    ],
+    to: '/manage-users/cookies/spa-authenticate-with-cookies',
   },
   {
-    from: '/tutorials/openid-connect-discovery',
-    to: '/protocols/oidc/openid-connect-discovery',
+    from: [
+      '/sessions/concepts/cookie-attributes',
+      '/sessions-and-cookies/samesite-cookie-attribute-changes',
+      '/sessions/cookies/samesite-cookie-attribute-changes',
+      '/users/cookies/samesite-cookie-attribute-changes',
+    ],
+    to: '/manage-users/cookies/samesite-cookie-attribute-changes',
   },
   {
-    from: '/tutorials/removing-auth0-exporting-data',
-    to: '/support/removing-auth0-exporting-data',
+    from: ['/users/guides/manage-users-using-the-dashboard', '/users/manage-users-using-the-dashboard'],
+    to: '/manage-users/user-accounts/manage-users-using-the-dashboard',
   },
   {
-    from: '/tutorials',
-    to: '/',
+    from: ['/users/guides/manage-users-using-the-management-api', '/users/manage-users-using-the-management-api'],
+    to: '/manage-users/user-accounts/manage-users-using-the-management-api',
   },
   {
-    from: '/sso/current/single-page-apps-sso',
-    to: '/sso/current/single-page-apps'
+    from: [
+      '/users/guides/link-user-accounts',
+      '/link-accounts/suggested-linking',
+      '/users/link-user-accounts',
+      '/users/user-account-linking/link-user-accounts',
+    ],
+    to: '/manage-users/user-accounts/user-account-linking/link-user-accounts',
   },
   {
-    from: '/sso/legacy/single-page-apps-sso',
-    to: '/sso/legacy/single-page-apps'
+    from: [
+      '/users/unlink-user-accounts',
+      '/users/guides/unlink-user-accounts',
+      '/users/user-account-linking/unlink-user-accounts',
+    ],
+    to: '/manage-users/user-accounts/user-account-linking/unlink-user-accounts',
   },
   {
-    from: '/integrations/slack',
-    to: '/sso/current/integrations/slack'
+    from: [
+      '/link-accounts/user-initiated',
+      '/link-accounts/user-initiated-linking',
+      '/users/references/link-accounts-user-initiated-scenario',
+      '/users/references/link-accounts-client-side-scenario',
+      '/user/references/link-accounts-client-side-scenario',
+      '/users/user-initiated-account-linking-client-side-implementation',
+      '/users/user-account-linking/user-initiated-account-linking-client-side-implementation',
+    ],
+    to: '/manage-users/user-accounts/user-account-linking/user-initiated-account-linking-client-side-implementation',
   },
   {
-    from: '/integrations/integrating-with-slack',
-    to: '/sso/current/integrations/slack'
+    from: [
+      '/users/suggested-account-linking-server-side-implementation',
+      '/users/references/link-accounts-server-side-scenario',
+      '/users/user-account-linking/suggested-account-linking-server-side-implementation',
+    ],
+    to: '/manage-users/user-accounts/user-account-linking/suggested-account-linking-server-side-implementation',
   },
   {
-    from: '/integrations/ad-rms',
-    to: '/sso/current/integrations/ad-rms'
+    from: ['/users/concepts/overview-user-migration', '/users/import-export-users', '/users/import-and-export-users'],
+    to: '/manage-users/user-migration',
   },
   {
-    from: '/integrations/box',
-    to: '/sso/current/integrations/box'
+    from: [
+      '/connections/database/migrating-okta',
+      '/users/migrations/okta',
+      '/users/references/user-migration-scenarios',
+      '/users/migrations',
+      '/users/user-migration-scenarios',
+      '/users/import-and-export-users/user-migration-scenarios',
+    ],
+    to: '/manage-users/user-migration/user-migration-scenarios',
   },
   {
-    from: '/integrations/cloudbees',
-    to: '/sso/current/integrations/cloudbees'
+    from: [
+      '/connections/database/migrating',
+      '/migrating',
+      '/users/migrations/automatic',
+      '/users/guides/configure-automatic-migration',
+      '/users/configure-automatic-migration-from-your-database',
+      '/users/import-and-export-users/configure-automatic-migration-from-your-database',
+    ],
+    to: '/manage-users/user-migration/configure-automatic-migration-from-your-database',
   },
   {
-    from: '/integrations/concur',
-    to: '/sso/current/integrations/concur'
+    from: [
+      '/tutorials/bulk-importing-users-into-auth0',
+      '/users/guides/bulk-user-imports',
+      '/users/guides/bulk-user-import',
+      '/users/bulk-importing-users-into-auth0',
+      '/users/migrations/bulk-import',
+      '/bulk-import',
+      '/users/bulk-user-imports',
+      '/users/import-and-export-users/bulk-user-imports',
+    ],
+    to: '/manage-users/user-migration/bulk-user-imports',
   },
   {
-    from: '/integrations/disqus',
-    to: '/sso/current/integrations/disqus'
+    from: [
+      '/users/bulk-user-import-database-schema-and-examples',
+      '/users/references/bulk-import-database-schema-examples',
+      '/users/import-and-export-users/bulk-user-import-database-schema-and-examples',
+    ],
+    to: '/manage-users/user-migration/bulk-user-import-database-schema-and-examples',
   },
   {
-    from: '/integrations/dropbox',
-    to: '/sso/current/integrations/dropbox'
+    from: [
+      '/users/bulk-user-exports',
+      '/users/guides/bulk-user-exports',
+      '/users/import-and-export-users/bulk-user-exports',
+    ],
+    to: '/manage-users/user-migration/bulk-user-exports',
   },
   {
-    from: '/integrations/dynamic-crm',
-    to: '/sso/current/integrations/dynamics-crm'
+    from: ['/users/guides/block-and-unblock-users', '/users/block-and-unblock-users'],
+    to: '/manage-users/user-accounts/block-and-unblock-users',
   },
   {
-    from: '/integrations/echosign',
-    to: '/sso/current/integrations/echosign'
+    from: ['/users/guides/manage-user-access-to-applications', '/users/manage-user-access-to-applications'],
+    to: '/manage-users/user-accounts/manage-user-access-to-applications',
   },
   {
-    from: '/integrations/egnyte',
-    to: '/sso/current/integrations/egnyte'
+    from: ['/users/guides/delete-users', '/users/delete-users'],
+    to: '/manage-users/user-accounts/delete-users',
   },
   {
-    from: '/integrations/new-relic',
-    to: '/sso/current/integrations/new-relic'
+    from: ['/dashboard/guides/users/unlink-user-devices', '/users/unlink-devices-from-users'],
+    to: '/manage-users/user-accounts/unlink-devices-from-users',
   },
   {
-    from: '/integrations/salesforce',
-    to: '/sso/current/integrations/salesforce'
+    from: ['/user-profile/user-picture', '/users/guides/change-user-pictures', '/users/change-user-picture'],
+    to: '/manage-users/user-accounts/change-user-picture',
   },
   {
-    from: '/integrations/springcm',
-    to: '/sso/current/integrations/springcm'
+    from: [
+      '/tutorials/creating-users-in-the-management-portal',
+      '/users/guides/create-users',
+      '/creating-users',
+      '/dashboard/guides/users/create-users',
+      '/users/create-users',
+    ],
+    to: '/manage-users/user-accounts/create-users',
   },
   {
-    from: '/integrations/zendesk',
-    to: '/sso/current/integrations/zendesk'
+    from: [
+      '/tutorials/get-user-information-with-unbounce-landing-pages',
+      '/users/guides/get-user-information-with-unbounce-landing-pages',
+      '/scenarios-unbounce',
+      '/users/get-user-information-on-unbounce-landing-pages',
+    ],
+    to: '/manage-users/user-accounts/get-user-information-on-unbounce-landing-pages',
   },
   {
-    from: '/integrations/zoom',
-    to: '/sso/current/integrations/zoom'
+    from: ['/users/guides/view-users', '/users/view-user-details'],
+    to: '/manage-users/user-accounts/view-user-details',
   },
   {
-    from: '/clients/how-to-update-client-secret',
-    to: '/applications/how-to-rotate-client-secret',
+    from: ['/users/normalized/auth0/identify-users', '/users/identify-users'],
+    to: '/manage-users/user-accounts/identify-users',
   },
   {
-    from: '/i18n/i18n-custom-login-page',
-    to: '/i18n'
+    from: [
+      '/users/search/v3',
+      '/users/normalized/auth0/retrieve-user-profiles',
+      '/users/search',
+      '/users-search',
+      '/users/user-search',
+    ],
+    to: '/manage-users/user-search',
   },
   {
-    from: '/multifactor-authentication/developer/step-up-with-acr',
-    to: '/multifactor-authentication/developer/step-up-authentication'
+    from: [
+      '/users/search/v3/query-syntax',
+      '/users/user-search/user-search-query-syntax',
+    ],
+    to:  '/manage-users/user-search/user-search-query-syntax',
   },
   {
-    from: '/users/bulk-importing-users-into-auth0',
-    to: '/users/migrations/bulk-import'
+    from: [
+      '/api/management/v2/user-search',
+      '/users/search/v2',
+      '/api/v2/user-search',
+      '/users/user-search/v2',
+      '/manage-users/user-search/v2',
+    ],
+    to: '/manage-users/user-search',
   },
   {
-    from: '/connections/database/migrating',
-    to: '/users/migrations/automatic'
+    from: [
+      '/api/management/v2/query-string-syntax',
+      '/users/search/v2/query-syntax',
+      '/users/user-search/v2/query-syntax',
+      '/manage-users/user-search/v2/query-syntax',
+    ],
+    to: '/manage-users/user-search',
   },
   {
-    from: '/connections/database/migrating-okta',
-    to: '/users/migrations/okta'
+    from: [
+      '/users/search/v3/get-users-by-email-endpoint',
+      '/users/user-search/retrieve-users-with-get-users-by-email-endpoint',
+    ],
+    to: '/manage-users/user-search/retrieve-users-with-get-users-by-email-endpoint',
   },
   {
-    from: `/metadata/management-api`,
-    to: `/metadata/apis`
+    from: [
+      '/users/search/v3/get-users-by-id-endpoint',
+      '/users/user-search/retrieve-users-with-get-users-by-id-endpoint',
+    ],
+    to: '/manage-users/user-search/retrieve-users-with-get-users-by-id-endpoint',
   },
   {
-    from: `/connections/grean/bankid-no`,
-    to: `/connections/criipto/bankid-no`
+    from: [
+      '/users/search/v3/get-users-endpoint',
+      '/users/user-search/retrieve-users-with-the-get-users-endpoint',
+      '/users/user-search/retrieve-users-with-get-users-endpoint',
+    ],
+    to: '/manage-users/user-search/retrieve-users-with-get-users-endpoint',
   },
   {
-    from: `/connections/grean/bankid-se`,
-    to: `/connections/criipto/bankid-se`
+    from: ['/users/search/v3/sort-search-results', '/users/user-search/sort-search-results'],
+    to: '/manage-users/user-search/sort-search-results',
   },
   {
-    from: `/connections/grean/nemid`,
-    to: `/connections/criipto/nemid`
+    from: ['/users/search/v3/view-search-results-by-page', '/users/user-search/view-search-results-by-page'],
+    to: '/manage-users/user-search/view-search-results-by-page',
   },
   {
-    from: '/sso/current/integrations',
-    to: '/integrations/sso'
+    from: [
+      '/link-accounts/auth-api',
+      '/link-accounts',
+      '/users/concepts/overview-user-account-linking',
+      '/users/guide/concepts/overview-user-account-linking',
+      '/users/user-account-linking',
+    ],
+    to: '/manage-users/user-accounts/user-account-linking',
   },
   {
-    from: '/sso/current/integrations/ad-rms',
-    to: '/integrations/sso/ad-rms'
+    from: [
+      '/users/guides/get-user-information-with-unbounce-landing-pages',
+      '/users/get-user-information-on-unbounce-landing-pages',
+    ],
+    to: '/manage-users/user-accounts/get-user-information-on-unbounce-landing-pages',
   },
   {
-    from: '/sso/current/integrations/box',
-    to: '/integrations/sso/box'
+    from: ['/users/verify-emails'],
+    to: '/manage-users/user-accounts/verify-emails',
   },
+
+  /* Videos */
+
   {
-    from: '/sso/current/integrations/cloudbees',
-    to: '/integrations/sso/cloudbees'
+    from: ['/video-series/main/videos', '/videos'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/concur',
-    to: '/integrations/sso/concur'
+    from: ['/videos/learn-identity', '/videos/learn-identity-series'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/disqus',
-    to: '/integrations/sso/disqus'
+    from: [
+      '/videos/learn-identity/01-introduction-to-identity',
+      '/videos/learn-identity-series/learn-identity-series/introduction-to-identity',
+      '/videos/learn-identity-series/introduction-to-identity',
+    ],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/dropbox',
-    to: '/integrations/sso/dropbox'
+    from: ['/videos/learn-identity/02-oidc-and-oauth', '/videos/learn-identity-series/openid-connect-and-oauth2'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/dynamics-crm',
-    to: '/integrations/sso/dynamics-crm'
+    from: ['/videos/learn-identity/03-web-sign-in', '/videos/learn-identity-series/web-sign-in'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/echosign',
-    to: '/integrations/sso/echosign'
+    from: ['/videos/learn-identity/04-calling-an-api', '/videos/learn-identity-series/calling-an-api'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/egnyte',
-    to: '/integrations/sso/egnyte'
+    from: [
+      '/videos/learn-identity/05-desktop-and-mobile-apps',
+      '/videos/learn-identity-series/desktop-and-mobile-apps',
+    ],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/new-relic',
-    to: '/integrations/sso/new-relic'
+    from: ['/videos/learn-identity/06-single-page-apps', '/videos/learn-identity-series/single-page-apps'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/office-365',
-    to: '/integrations/sso/office-365'
+    from: ['/videos/get-started', '/videos/get-started-series'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/salesforce',
-    to: '/integrations/sso/salesforce'
+    from: ['/videos/get-started/01-architecture-your-tenant', '/videos/get-started-series/architect-your-tenant'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/slack',
-    to: '/integrations/sso/slack'
+    from: ['/videos/get-started/02-provision-user-stores', '/videos/get-started-series/provision-user-stores'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/springcm',
-    to: '/integrations/sso/springcm'
+    from: ['/videos/get-started/03-provision-import-users', '/videos/get-started-series/provision-import-users'],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/zendesk',
-    to: '/integrations/sso/zendesk'
+    from: [
+      '/videos/get-started/04_01-authenticate-how-it-works',
+      '/videos/get-started-series/authenticate-how-it-works',
+    ],
+    to: '/articles',
   },
   {
-    from: '/sso/current/integrations/zoom',
-    to: '/integrations/sso/zoom'
+    from: [
+      '/videos/get-started/04_02-authenticate-spa-example',
+      '/videos/get-started/04_01-authenticate-spa-example',
+      '/videos/get-started-series/authenticate-spa-example',
+    ],
+    to: '/articles',
   },
   {
-    from: '/guides/login/centralized-vs-embedded',
-    to: '/guides/login/universal-vs-embedded'
+    from: [
+      '/videos/get-started/05_01-authorize-id-tokens-access-control',
+      '/videos/get-started-series/authorize-id-tokens-and-access-control',
+    ],
+    to: '/articles',
   },
   {
-    from: '/guides/login/migration-embedded-centralized',
-    to: '/guides/login/migration-embedded-universal'
+    from: [
+      '/videos/get-started/05_02-authorize-get-validate-id-tokens',
+      '/videos/get-started-series/authorize-get-and-validate-id-tokens',
+    ],
+    to: '/articles',
   },
   {
-    from: '/api/management/v2/user-search',
-    to: '/users/search/v2'
+    from: ['/videos/get-started/06-user-profiles', '/videos/get-started-series/learn-user-profiles'],
+    to: '/articles',
   },
   {
-    from: '/api/management/v2/query-string-syntax',
-    to: '/users/search/v2/query-syntax'
+    from: ['/videos/get-started/07_01-brand-how-it-works', '/videos/get-started-series/brand-how-it-works'],
+    to: '/articles',
   },
   {
-    from: '/api-auth/dynamic-application-registration',
-    to: '/api-auth/dynamic-client-registration'
+    from: [
+      '/videos/get-started/07_02-brand-signup-login-pages',
+      '/videos/get-started-series/brand-signup-and-login-pages',
+    ],
+    to: '/articles',
   },
   {
-    from: '/videos/rules',
-    to: '/rules/current#video-using-rules'
+    from: [
+      '/videos/get-started/08-brand-emails-error-pages',
+      '/videos/get-started-series/brand-emails-and-error-pages',
+    ],
+    to: '/articles',
   },
   {
-    from: `/guides/login/migration-embedded-centralized`,
-    to: `/guides/login/migration-embedded-universal`
+    from: ['/videos/get-started/10-logout', '/videos/get-started-series/learn-logout'],
+    to: '/articles',
   },
+
+  /* Forms */
+
   {
-    from: `/link-accounts/auth-api`,
-    to: `/link-accounts`
+    from: ['/customize/forms/intro-to-forms', '/customize/forms/fields'],
+    to: '/customize/forms/nodes-and-components',
   },
+
   {
-    from: '/videos/session-and-cookies',
-    to: '/security/store-tokens#understanding-sessions-and-cookies'
-  }
+    from: ['/customize/phone/twilio-phone-providers'],
+    to: '/customize/phone-messages/configure-phone-messaging-providers/configure-twilio-as-a-phone-messaging-provider',
+  },
+  {
+    from: ['/authenticate/single-sign-on/self-service-SSO'],
+    to: '/authenticate/enterprise-connections/self-service-SSO',
+  },
+  
+  {
+	from: [
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/branding-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/client-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/organization-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/prompt-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/screen-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/tenant-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/transaction-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/untrusted-data-settings',
+	  '/customize/login-pages/advanced-customizations/getting-started/context-data/user-settings',
+	  '/customize/login-pages/advanced-customizations/screens',
+	  '/customize/login-pages/advanced-customizations/screens/signup-id',
+	  '/customize/login-pages/advanced-customizations/screens/signup-password',
+	  '/customize/login-pages/advanced-customizations/screens/login-id',
+	  '/customize/login-pages/advanced-customizations/screens/login-password',
+	  '/customize/login-pages/advanced-customizations/screens/login-passwordless-email-code',
+	  '/customize/login-pages/advanced-customizations/screens/login-passwordless-sms-otp',
+	  '/customize/login-pages/advanced-customizations/screens/passkey-enrollment',
+	  '/customize/login-pages/advanced-customizations/screens/passkey-enrollment-local',
+	  '/customize/login-pages/advanced-customizations/screens/phone-identifier-enrollment',
+	  '/customize/login-pages/advanced-customizations/screens/phone-identifier-challenge',
+	  '/customize/login-pages/advanced-customizations/screens/email-identifier-challenge',
+	  '/customize/login-pages/advanced-customizations/screens/interstitial-captcha',
+	  '/customize/login-pages/advanced-customizations/getting-started/sdk-quickstart/auth0-acul-js-sdk-shared-properties',
+	],
+	to: '/customize/login-pages/advanced-customizations',
+  },
+  
 ];
+
+module.exports = redirects;
diff --git a/config/redirectsarchive.js b/config/redirectsarchive.js
new file mode 100644
index 0000000000..af3291683d
--- /dev/null
+++ b/config/redirectsarchive.js
@@ -0,0 +1,4278 @@
+// This is the list of APIs used in the old two-step quickstarts.
+const apiNames = [
+  'aspnet-webapi',
+  'aws',
+  'azure-blob-storage',
+  'azure-mobile-services',
+  'azure-sb',
+  'falcor',
+  'firebase',
+  'golang',
+  'hapi',
+  'java-spring-security',
+  'java',
+  'nginx',
+  'nodejs',
+  'php-laravel',
+  'php-symfony',
+  'php',
+  'python',
+  'rails',
+  'ruby',
+  'salesforce-sandbox',
+  'salesforce',
+  'sap-odata',
+  'wcf-service',
+  'webapi-owin'
+];
+
+const apis = `:api(${apiNames.join('|')})`;
+
+module.exports = [
+
+  
+  {
+    from: '/awsapi-tutorial',
+    to: '/integrations/aws'
+  },
+  
+  {
+    from: '/firebaseapi-tutorial',
+    to: '/applications/addons'
+  },
+  {
+    from: '/applications/addons',
+    to: '/addons'
+  },
+  {
+    from: '/mvc-tutorial-enterprise',
+    to: '/tutorials/aspnet-mvc4-enterprise-providers'
+  },
+  {
+    from: '/migrations',
+    to: '/product-lifecycle/migrations'
+  },
+  {
+    from: '/phonegap-plugin-tutorial',
+    to: '/native-platforms/cordova'
+  },
+  {
+    from: '/salesforcesandboxapi-tutorial',
+    to: '/applications/addons'
+  },
+  {
+    from: '/salesforceapi-tutorial',
+    to: '/applications/addons'
+  },
+  {
+    from: '/sapapi-tutorial',
+    to: '/applications/addons'
+  },
+
+
+  /* --- Two-step quickstarts to single-step quickstarts --- */
+
+  {
+    from: '/quickstart/webapp/nodejs/02-user-profile',
+    to: '/quickstart/webapp/nodejs/01-login'
+  },
+
+  {
+    from: [
+      '/quickstart/hybrid',
+      '/quickstart/native-mobile'
+    ],
+    to: '/quickstart/native'
+  },
+  {
+    from: [
+      '/quickstart/hybrid/:platform',
+      '/quickstart/native-mobile/:platform',
+      `/quickstart/hybrid/:platform/${apis}`,
+      `/quickstart/native-mobile/:platform/${apis}`,
+      `/quickstart/native/:platform/${apis}`
+    ],
+    to: '/quickstart/native/:platform'
+  },
+  {
+    from: `/quickstart/spa/:platform/${apis}`,
+    to: '/quickstart/spa/:platform'
+  },
+  {
+    from: `/quickstart/backend/:platform/${apis}`,
+    to: '/quickstart/backend/:platform'
+  },
+  {
+    from: `/quickstart/spa/emberjs`,
+    to: '/quickstart/spa/ember'
+  },
+
+  /* --- Removed Quickstarts --- */
+
+  {
+    from: [
+      '/quickstart/spa/aurelia',
+      '/quickstart/spa/ember',
+      '/quickstart/spa/jquery'
+    ],
+    to: '/quickstart/spa'
+  },
+  
+  /* --- Connections --- */
+
+  {
+    from: ['/37signals-clientid', '/connections/social/37signals'],
+    to: '/connections/social/basecamp'
+  },
+  {
+    from: '/amazon-clientid',
+    to: '/connections/social/amazon'
+  },
+  {
+    from: '/aol-clientid',
+    to: '/connections/social/aol'
+  },
+  {
+    from: '/connections/enterprise/azure-active-directory',
+    to: '/connections/enterprise/azure-active-directory/v2'
+  },
+  {
+    from: '/connections/enterprise/azure-active-directory-classic',
+    to: '/connections/enterprise/azure-active-directory/v1'
+  },
+  {
+    from: '/connections/enterprise/samlp',
+    to: '/connections/enterprise/saml'
+  },
+  {
+    from: '/dwolla-clientid',
+    to: '/connections/social/dwolla'
+  },
+  {
+    from: '/baidu-clientid',
+    to: '/connections/social/baidu'
+  },
+  {
+    from: '/box-clientid',
+    to: '/connections/social/box'
+  },
+  {
+    from: '/evernote-clientid',
+    to: '/connections/social/evernote'
+  },
+  {
+    from: '/exact-clientid',
+    to: '/connections/social/exact'
+  },
+  {
+    from: '/facebook-clientid',
+    to: '/connections/social/facebook'
+  },
+  {
+    from: '/fitbit-clientid',
+    to: '/connections/social/fitbit'
+  },
+  {
+    from: '/github-clientid',
+    to: '/connections/social/github'
+  },
+  {
+    from: '/goodreads-clientid',
+    to: '/connections/social/goodreads'
+  },
+  {
+    from: '/goog-clientid',
+    to: '/connections/social/google'
+  },
+  {
+    from: '/miicard-clientid',
+    to: '/connections/social/miicard'
+  },
+  {
+    from: '/ms-account-clientid',
+    to: '/connections/social/microsoft-account'
+  },
+  {
+    from: '/oauth2',
+    to: '/connections/social/oauth2'
+  },
+  {
+    from: '/connections/social/auth0-oidc',
+    to: '/connections/enterprise/oidc'
+  },
+  {
+    from: '/paypal-clientid',
+    to: '/connections/social/paypal'
+  },
+  {
+    from: '/planningcenter-clientid',
+    to: '/connections/social/planning-center'
+  },
+  {
+    from: ['/salesforce-clientid', '/salesforce-community'],
+    to: '/connections/social/salesforce'
+  },
+  {
+    from: '/renren-clientid',
+    to: '/connections/social/renren'
+  },
+  {
+    from: '/sharepoint-clientid',
+    to: '/connections/enterprise/sharepoint-apps'
+  },
+  {
+    from: '/shopify-clientid',
+    to: '/connections/social/shopify'
+  },
+  {
+    from: '/soundcloud-clientid',
+    to: '/connections/social/soundcloud'
+  },
+  {
+    from: '/thecity-clientid',
+    to: '/connections/social/thecity'
+  },
+  {
+    from: '/twitter-clientid',
+    to: '/connections/social/twitter'
+  },
+  {
+    from: '/vkontakte-clientid',
+    to: '/connections/social/vkontakte'
+  },
+  {
+    from: '/waad-clientid',
+    to: '/connections/enterprise/azure-active-directory'
+  },
+  {
+    from: '/weibo-clientid',
+    to: '/connections/social/weibo'
+  },
+  {
+    from: '/wordpress-clientid',
+    to: '/connections/social/wordpress'
+  },
+  {
+    from: '/yahoo-clientid',
+    to: '/connections/social/yahoo'
+  },
+  {
+    from: '/yandex-clientid',
+    to: '/connections/social/yandex'
+  },
+  {
+    from: '/instagram-clientid',
+    to: '/connections/social/instagram'
+  },
+  {
+    from: '/linkedin-clientid',
+    to: '/connections/social/linkedin'
+  },
+  {
+    from: '/mysql-connection-tutorial',
+    to: '/connections/database/mysql'
+  },
+  {
+    from: '/migrating',
+    to: '/connections/database/migrating'
+  },
+  {
+    from: '/ad',
+    to: '/connections/enterprise/active-directory-ldap'
+  },
+  {
+    from: '/connections/enterprise/ldap',
+    to: '/connections/enterprise/active-directory-ldap'
+  },
+    {
+    from: '/connections/enterprise/active-directory',
+    to: '/connections/enterprise/active-directory-ldap'
+  },
+  {
+    from: '/adfs',
+    to: '/connections/enterprise/adfs'
+  },
+  {
+    from: ['/passwordless','/dashboard/guides/connections/set-up-connections-passwordless'],
+    to: '/connections/passwordless'
+  },
+  {
+    from: '/connections/passwordless/ios-sms',
+    to: '/connections/passwordless/ios-sms-objc'
+  },
+
+/* --- Clients --- */
+
+  {
+    from: '/clients',
+    to: '/applications'
+  },
+  {
+    from: '/clients/addons',
+    to: '/applications/addons'
+  },
+  {
+    from: '/clients/client-grant-types',
+    to: '/applications/application-grant-types'
+  },
+  {
+    from: '/applications/application-grant-types',
+    to: '/applications/concepts/application-grant-types'
+  },
+  {
+    from: '/applications/concepts/signing-algorithms',
+    to: '/tokens/concepts/signing-algorithms'
+  },
+  {
+    from: '/clients/client-types',
+    to: '/applications/application-types'
+  },
+  {
+    from: '/applications/application-types',
+    to: '/applications'
+  },
+  {
+    from: '/applications/concepts/connections',
+    to: '/connections'
+  },
+  {
+    from: '/applications/machine-to-machine',
+    to: '/applications'
+  },
+  {
+    from: '/applications/concepts/app-types-auth0',
+    to: '/applications'
+  },
+  {
+    from: '/clients/connections',
+    to: '/connections'
+  },
+  {
+    from: '/applications/connections',
+    to: '/connections'
+  },
+  {
+    from: '/clients/enable-android-app-links',
+    to: '/applications/enable-android-app-links'
+  },
+  {
+    from: '/applications/enable-android-app-links',
+    to: '/applications/guides/enable-android-app-links-dashboard'
+  },
+  {
+    from: '/applications/guides/enable-android-app-links-dashboard',
+    to: '/dashboard/guides/applications/enable-android-app-links'
+  },
+  {
+    from: '/clients/enable-universal-links',
+    to: '/applications/enable-universal-links'
+  },
+  {
+    from: '/applications/enable-universal-links',
+    to: '/applications/guides/enable-universal-links-dashboard'
+  },
+  {
+    from: '/applications/guides/enable-universal-links-dashboard',
+    to: '/dashboard/guides/applications/enable-universal-links'
+  },
+  {
+    from: '/clients/how-to-rotate-client-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret'
+  },
+  {
+    from: '/applications/how-to-rotate-client-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret'
+  },
+  {
+    from: '/applications/how-to-rotate-application-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret'
+  },
+  {
+    from: '/clients/client-settings',
+    to: '/applications/application-settings'
+  },
+  {
+    from: '/applications/application-settings',
+    to: '/reference/dashboard/settings-application'
+  },
+
+  /* --- Scenarios to Tutorials --- */
+
+  {
+    from: '/scenarios/amazon-cognito',
+    to: '/tutorials/integrating-auth0-amazon-cognito-mobile-apps'
+  },
+  {
+    from: '/scenarios/github',
+    to: '/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise'
+  },
+  {
+    from: ['/scenarios/keenio', '/scenarios-keenio'],
+    to: '/tutorials/sending-events-to-keenio'
+  },
+  {
+    from: [
+      '/scenarios-mixpanel-fullcontact-salesforce',
+      '/scenarios/mixpanel-fullcontact-salesforce'
+    ],
+    to: '/tutorials/track-signups-enrich-user-profile-generate-leads'
+  },
+  {
+    from: ['/scenarios-mqtt', '/scenarios/mqtt'],
+    to: '/tutorials/authenticating-devices-using-mqtt'
+  },
+  {
+    from: ['/scenarios-rapleaf-salesforce', '/scenarios/rapleaf-salesforce'],
+    to: '/tutorials/tracking-new-leads-in-salesforce-and-raplead'
+  },
+  {
+    from: ['/scenarios-segmentio', '/scenarios/segmentio'],
+    to: '/tutorials/sending-events-to-segmentio'
+  },
+  {
+    from: '/scenarios/slack',
+    to: '/tutorials/integrating-with-slack'
+  },
+  {
+    from: ['/scenarios-splunk', '/scenarios/splunk'],
+    to: '/tutorials/sending-events-to-splunk'
+  },
+  {
+    from: ['/scenarios-tessel', '/scenarios/tessel'],
+    to: '/tutorials/authenticating-a-tessel-device'
+  },
+  {
+    from: ['/scenarios-unbounce', '/scenarios/unbounce'],
+    to: '/tutorials/get-user-information-with-unbounce-landing-pages'
+  },
+  {
+    from: '/scenarios',
+    to: '/tutorials'
+  },
+
+  /* --- Miscellaneous --- */
+
+  {
+    from: '/widget',
+    to: '/login-widget2'
+  },
+  {
+    from: '/adldap-auth',
+    to: '/connector/install'
+  },
+  {
+    from: '/adldap-x',
+    to: '/connector/install-other-platforms'
+  },
+  {
+    from: '/sharepoint-apps',
+    to: '/integrations/sharepoint-apps'
+  },
+  {
+    from: '/auth0js',
+    to: '/libraries/auth0js'
+  },
+  {
+    from: '/aws',
+    to: '/integrations/aws'
+  },
+  {
+    from: ['/lock', '/migrations/guides/legacy-lock-api-deprecation'],
+    to: '/libraries/lock'
+  },
+  {
+    from: ['/okta', '/saml/identity-providers/okta'],
+    to: '/protocols/saml/identity-providers/okta'
+  },
+  {
+    from: ['/onelogin', '/saml/identity-providers/onelogin'],
+    to: '/protocols/saml/identity-providers/onelogin'
+  },
+  {
+    from: ['/ping7', '/saml/identity-providers/ping7'],
+    to: '/protocols/saml/identity-providers/ping7'
+  },
+  {
+    from: ['/siteminder', '/saml/identity-providers/siteminder'],
+    to: '/protocols/saml/identity-providers/siteminder'
+  },
+  {
+    from: '/ssocircle',
+    to: '/protocols/saml/identity-providers/ssocircle'
+  },
+  {
+    from: '/wsfedwebapp-tutorial',
+    to: '/tutorials/wsfed-web-app'
+  },
+  {
+    from: '/api',
+    to: '/api/info'
+  },
+  {
+    from: ['/auth-api', '/api/authentication/reference'],
+    to: '/api/authentication'
+  },
+  {
+    from: '/api/v1',
+    to: '/migrations/guides/management-api-v1-v2'
+  },
+  {
+    from: ['/api-reference', '/api/v1/reference'],
+    to: '/api/management/v1/reference'
+  },
+  {
+    from: ['/apiv2', '/api/v2'],
+    to: '/api/management/v2'
+  },
+  {
+    from: ['/apiv2Changes', '/api/v2/changes'],
+    to: '/api/management/v2/changes'
+  },
+  {
+    from: ['/tokens/apiv2', '/api/v2/tokens', '/api/management/v2/concepts/tokens'],
+    to: '/api/management/v2/tokens'
+  },
+  {
+    from: ['/metadata-in-rules', '/metadata/rules'],
+    to: '/rules/metadata-in-rules'
+  },
+  {
+    from: [
+      '/multi-factor-authentication',
+      '/multi-factor-authentication2',
+      '/multifactor-authentication/custom-provider',
+      '/multifactor-authentication'
+    ],
+    to: '/mfa'
+  },
+  {
+    from: [
+      '/multifactor-authentication/google-auth/user-guide',
+      '/multifactor-authentication/troubleshooting'
+    ],
+    to: '/mfa/references/troubleshoot-mfa'
+  },
+  {
+    from: [
+      '/multi-factor-authentication/yubikey',
+      '/multifactor-authentication/yubikey'
+    ],
+    to: '/mfa'
+  },
+  {
+    from: '/multifactor-authentication/api/email',
+    to: '/mfa/guides/mfa-api/email'
+  },
+  {
+    from: '/multifactor-authentication/api/oob',
+    to: '/mfa/guides/mfa-api/oob'
+  },
+  {
+    from: '/multifactor-authentication/api/otp',
+    to: '/mfa/guides/mfa-api/otp'
+  },
+  {
+    from: ['/multifactor-authentication/api', '/multifactor-authentication/api/faq'],
+    to: '/mfa/concepts/mfa-api'
+  },
+  {
+    from: '/multifactor-authentication/api/manage',
+    to: '/mfa/guides/mfa-api/manage'
+  },
+  {
+    from: '/multifactor-authentication/twilio-configuration',
+    to: '/mfa/guides/configure-phone'
+  },
+  {
+    from: '/multifactor-authentication/sms-templates',
+    to: '/mfa/guides/customize-phone-messages'
+  },
+  {
+    from: '/mfa/guides/guardian/customize-sms-messages',
+    to: '/mfa/guides/customize-phone-messages'
+  },
+  {
+    from: '/multifactor-authentication/reset-user',
+    to: '/mfa/guides/reset-user-mfa'
+  },
+  {
+    from: '/multifactor-authentication/step-up-authentication',
+    to: '/mfa/concepts/step-up-authentication'
+  },
+  {
+    from: '/multifactor-authentication/step-up-authentication/step-up-for-web-apps',
+    to: '/mfa/guides/configure-step-up-web-apps'
+  },
+  {
+    from: '/multifactor-authentication/step-up-authentication/step-up-for-apis',
+    to: '/mfa/guides/configure-step-up-apis'
+  },
+  {
+    from: '/multifactor-authentication/factors',
+    to: '/mfa/concepts/mfa-factors'
+  },
+  {
+    from: ['/multifactor-authentication/factors/sms','/mfa/guides/configure-sms'],
+    to: '/mfa/guides/configure-phone'
+  },
+  {
+    from: '/multifactor-authentication/factors/push',
+    to: '/mfa/guides/configure-push'
+  },
+  {
+    from: '/multifactor-authentication/factors/otp',
+    to: '/mfa/guides/configure-otp'
+  },
+  {
+    from: '/multifactor-authentication/factors/email',
+    to: '/mfa/guides/configure-email'
+  },
+  {
+    from: '/mfa/guides/configure-email-universal-login',
+    to: '/mfa/guides/configure-email'
+  },
+  {
+    from: '/multifactor-authentication/factors/duo',
+    to: '/mfa/guides/configure-cisco-duo'
+  },
+  {
+    from: '/multifactor-authentication/developer',
+    to: '/mfa/concepts/developer-resources'
+  },
+  {
+    from: '/multifactor-authentication/developer/sns-configuration',
+    to: '/mfa/guides/configure-push'
+  },
+  {
+    from: '/multifactor-authentication/developer/libraries/ios',
+    to: '/mfa/guides/guardian/guardian-ios-sdk'
+  },
+  {
+    from: '/multifactor-authentication/developer/libraries/android',
+    to: '/mfa/guides/guardian/guardian-android-sdk'
+  },
+  {
+    from: '/multifactor-authentication/developer/custom-enrollment-ticket',
+    to: '/mfa/guides/guardian/create-enrollment-ticket'
+  },
+  {
+    from: '/multifactor-authentication/custom',
+    to: '/mfa/guides/customize-mfa-universal-login'
+  },
+  {
+    from: '/quickstart',
+    to: '/'
+  },
+  {
+    from: ['/link-accounts/user-initiated', '/link-accounts/user-initiated-linking'],
+    to: '/users/references/link-accounts-client-side-scenario'
+  },
+  {
+    from: '/users/references/link-accounts-user-initiated-scenario',
+    to: '/users/references/link-accounts-client-side-scenario'
+  },
+  {
+    from: '/users/guides/link-user-accounts-auth-api',
+    to: '/migrations/guides/account-linking'
+  },
+  {
+    from: '/libraries/lock/using-refresh-tokens',
+    to: '/libraries/lock/using-a-refresh-token'
+  },
+  {
+    from: '/premium-support',
+    to: '/support'
+  },
+  {
+    from: '/password-strength',
+    to: '/connections/database/password-strength'
+  },
+  {
+    from: '/users-search',
+    to: '/api/v2/user-search'
+  },
+  {
+    from: '/api/v2/user-search',
+    to: '/api/management/v2/user-search'
+  },
+  {
+    from: '/users/normalized/auth0/retrieve-user-profiles',
+    to: `/users/search`
+  },
+  {
+    from: [
+      '/appliance/checksum',
+      '/appliance/proxy-updater',
+      '/appliance/update',
+      '/updating-appliance'
+    ],
+    to: '/private-cloud'
+  },
+  {
+    from: '/enterprise-support',
+    to: '/onboarding/enterprise-support'
+  },
+  {
+    from: '/extensions/azure-blog-storage',
+    to: '/extensions/azure-blob-storage'
+  },
+  {
+    from: '/quickstart/backend/java',
+    to: '/quickstart/backend/java-spring-security',
+    status: 302
+  },
+  {
+    from: ['/rate-limits', '/policies/rate-limit'],
+    to: '/policies/rate-limits'
+  },
+  {
+    from: '/i18n/password-strength',
+    to: '/i18n/password-options'
+  },
+  {
+    from: '/sso/single-sign-on',
+    to: '/sso'
+  },
+  {
+    from: '/libraries/lock/v10/installation',
+    to: '/libraries/lock',
+    status: 302
+  },
+  {
+    from: '/libraries/lock/customization',
+    to: '/libraries/lock/v11/configuration',
+    status: 302
+  },
+  {
+    from: '/libraries/lock/display-modes',
+    to: '/libraries/lock/v11/customization#container-string-',
+    status: 302
+  },
+  {
+    from: '/cancel-paid-subscriptions',
+    to: '/tutorials/cancel-paid-subscriptions'
+  },
+  {
+    from: '/pricing-per-app-per-connection',
+    to: '/tutorials/pricing-per-app-per-connection'
+  },
+  {
+    from: '/local-testing-and-development',
+    to: '/tutorials/local-testing-and-development'
+  },
+  {
+    from: '/moving-out',
+    to: '/tutorials/removing-auth0-exporting-data'
+  },
+  {
+    from: '/lifecycle',
+    to: '/tutorials/development-lifecycle-with-auth0'
+  },
+  {
+    from: '/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp',
+    to: '/tutorials/adding-scopes-for-an-external-idp'
+  },
+  {
+    from: '/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api',
+    to: '/tutorials/calling-an-external-idp-api'
+  },
+  {
+    from: '/enable-simple-connection',
+    to: '/tutorials/enabling-a-connection'
+  },
+  {
+    from: '/oauth1',
+    to: '/tutorials/adding-generic-oauth1-connection'
+  },
+  {
+    from: '/oauth2-examples',
+    to: '/tutorials/generic-oauth2-connection-examples'
+  },
+  {
+    from: '/tutorials/setup-up-authentication',
+    to: '/multifactor-authentication/step-up-authentication'
+  },
+  {
+    from: ['/refresh-token', '/tokens/refresh_token', '/tokens/refresh-token'],
+    to: '/tokens/concepts/refresh-tokens'
+  },
+  {
+    from: '/update-client-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret'
+  },
+  {
+    from: '/test-partner-connection',
+    to: '/tutorials/how-to-test-partner-connection'
+  },
+  {
+    from: '/bulk-import',
+    to: '/tutorials/bulk-importing-users-into-auth0'
+  },
+  {
+    from: '/creating-users',
+    to: '/tutorials/creating-users-in-the-management-portal'
+  },
+  {
+    from: ['/custom-signup', '/libraries/lock/v10/custom-signup', '/libraries/lock/v11/custom-signup'],
+    to: '/libraries/custom-signup'
+  },
+  {
+    from: '/google-admin-sdk',
+    to: '/tutorials/configuration-to-query-users-from-google-apps'
+  },
+  {
+    from: '/invite-only',
+    to: '/tutorials/creating-invite-only-applications'
+  },
+  {
+    from: '/saas-apps',
+    to: '/tutorials/using-auth0-with-multi-tenant-apps'
+  },
+  {
+    from: '/sla',
+    to: '/support/sla'
+  },
+  {
+    from: '/versioning',
+    to: '/tutorials/how-auth0-versions-software'
+  },
+  {
+    from: '/oidc-rs256-owin',
+    to: '/tutorials/openid-connect-discovery'
+  },
+  {
+    from: '/cli',
+    to: '/tutorials/using-auth0-to-secure-a-cli'
+  },
+  {
+    from: '/tutorials/using-auth0-to-secure-an-api',
+    to: '/tutorials/using-auth0-to-secure-a-cli'
+  },
+  {
+    from: '/apps-apis',
+    to: '/tutorials/web-apps-vs-web-apis-cookies-vs-tokens'
+  },
+  {
+    from: ['/har', '/tutorials/troubleshooting-with-har-files', '/troubleshoot/har', '/support/troubleshooting-with-har-files'],
+    to: '/troubleshoot/guides/generate-har-files'
+  },
+  {
+    from: '/hrd',
+    to: '/libraries/lock/v11/selecting-the-connection-for-multiple-logins'
+  },
+  {
+    from: ['/blacklist-attributes', '/security/blacklist-user-attributes'],
+    to: '/security/blacklisting-attributes'
+  },
+  {
+    from: '/office365-deprecated',
+    to: '/tutorials/office365-connection-deprecation-guide'
+  },
+  {
+    from: '/sequence-diagrams',
+    to: '/architecture-scenarios/application/spa-api'
+  },
+  {
+    from: '/architecture-scenarios/sequence-diagrams',
+    'to:': '/architecture-scenarios/application/spa-api'
+  },
+  {
+    from: '/deployment',
+    to: '/overview/deployment-models'
+  },
+  {
+    from: '/overview',
+    to: '/getting-started/overview'
+  },
+  {
+    from: '/overview/apis',
+    to: '/api-auth/apis'
+  },
+  {
+    from: '/overview/deployment-models',
+    to: '/getting-started/deployment-models'
+  },
+  {
+    from: '/java-overview',
+    to: '/dev-centers/java'
+  },
+  {
+    from: ['/oauth-web-protocol', '/protocols/oauth-web-protocol', '/protocols/oauth2/oauth-web-protocol'],
+    to: '/application-auth/current/server-side-web'
+  },
+  {
+    from: ['/application-auth/current/server-side-web'],
+    to: '/flows/guides/regular-web-app-login-flow/add-login-using-regular-web-app-login-flow'
+  },
+  {
+    from: ['/flows/guides/regular-web-app-login-flow/add-login-using-regular-web-app-login-flow'],
+    to: '/flows/guides/auth-code/add-login-auth-code'
+  },
+  {
+    from: ['/flows/guides/regular-web-app-login-flow/call-api-using-regular-web-app-login-flow'],
+    to: '/flows/guides/auth-code/call-api-auth-code'
+  },
+  {
+    from: ['/application-auth/current/client-side-web'],
+    to: '/flows/guides/single-page-login-flow/add-login-using-single-page-login-flow'
+  },
+  {
+    from: ['/flows/guides/single-page-login-flow/add-login-using-single-page-login-flow'],
+    to: '/flows/guides/implicit/add-login-implicit'
+  },
+  {
+    from: ['/flows/guides/single-page-login-flow/call-api-using-single-page-login-flow'],
+    to: '/flows/guides/implicit/call-api-implicit'
+  },
+  {
+    from: ['/application-auth/current/mobile-desktop'],
+    to: '/flows/guides/mobile-login-flow/add-login-using-mobile-login-flow'
+  },
+  {
+    from: ['/flows/guides/mobile-login-flow/add-login-using-mobile-login-flow'],
+    to: '/flows/guides/auth-code-pkce/add-login-auth-code-pkce'
+  },
+  {
+    from: ['/flows/guides/mobile-login-flow/call-api-using-mobile-login-flow'],
+    to: '/flows/guides/auth-code-pkce/call-api-auth-code-pkce'
+  },
+  {
+    from: ['/flows/guides/m2m-flow/call-api-using-m2m-flow'],
+    to: '/flows/guides/client-credentials/call-api-client-credentials'
+  },
+  {
+    from: ['/api-auth/grant/authorization-code-pkce'],
+    to: '/flows/concepts/mobile-login-flow'
+  },
+    {
+    from: ['/flows/concepts/mobile-login-flow'],
+    to: '/flows/concepts/auth-code-pkce'
+  },
+    {
+    from: ['/api-auth/grant/implicit'],
+    to: '/flows/concepts/single-page-login-flow'
+  },
+  {
+    from: ['/flows/concepts/single-page-login-flow'],
+    to: '/flows/concepts/implicit'
+  },
+  {
+    from: ['/api-auth/grant/authorization-code'],
+    to: '/flows/concepts/regular-web-app-login-flow'
+  },
+  {
+    from: ['/flows/concepts/regular-web-app-login-flow'],
+    to: '/flows/concepts/auth-code'
+  },
+    {
+    from: ['/api-auth/grant/client-credentials'],
+    to: '/flows/concepts/m2m-flow'
+  },
+  {
+    from: ['/flows/concepts/m2m-flow'],
+    to: '/flows/concepts/client-credentials'
+  },
+  {
+    from: ['/api-auth/restrict-requests-for-scopes'],
+    to: '/api-auth/restrict-access-api'
+  },
+  {
+    from: '/oauth-implicit-protocol',
+    to: '/protocols/oauth2/oauth-implicit-protocol'
+  },
+  {
+    from: '/protocols/oauth-state',
+    to: '/protocols/oauth2/oauth-state'
+  },
+  {
+    from: '/metadata/apiv2',
+    to: '/metadata/management-api'
+  },
+  {
+    from: '/saml-apps',
+    to: '/protocols/saml/saml-apps'
+  },
+  {
+    from: '/saml-configuration',
+    to: '/protocols/saml/saml-configuration'
+  },
+  {
+    from: '/saml-idp-generic',
+    to: '/protocols/saml/saml-idp-generic'
+  },
+  {
+    from: '/saml-sp-generic',
+    to: '/protocols/saml/saml-sp-generic'
+  },
+  {
+    from: '/saml2webapp-tutorial',
+    to: '/protocols/saml/saml2webapp-tutorial'
+  },
+  {
+    from: '/samlp-providers',
+    to: '/protocols/saml/samlp-providers'
+  },
+  {
+    from: '/samlp',
+    to: '/protocols/saml/samlp'
+  },
+  {
+    from: '/samlsso-auth0-to-auth0',
+    to: '/protocols/saml/samlsso-auth0-to-auth0'
+  },
+  {
+    from: '/saml/identity-providers/salesforce',
+    to: '/protocols/saml/identity-providers/salesforce'
+  },
+  {
+    from: '/saml-apps/cisco-webex',
+    to: '/protocols/saml/saml-apps/cisco-webex'
+  },
+  {
+    from: '/saml-apps/datadog',
+    to: '/protocols/saml/saml-apps/datadog'
+  },
+  {
+    from: '/saml-apps/freshdesk',
+    to: '/protocols/saml/saml-apps/freshdesk'
+  },
+  {
+    from: '/saml-apps/heroku-sso',
+    to: '/protocols/saml/saml-apps/heroku'
+  },
+  {
+    from: '/saml-apps/litmos',
+    to: '/protocols/saml/saml-apps/litmos'
+  },
+  {
+    from: '/saml-apps/sprout-video',
+    to: '/protocols/saml/saml-apps/sprout-video'
+  },
+  {
+    from: '/onboarding/appliance-outage',
+    to: '/onboarding/enterprise-support'
+  },
+  {
+    from: '/appliance/dashboard/instrumentation',
+    to: '/appliance/instrumentation'
+  },
+  {
+    from: '/tutorials/local-testing-and-development',
+    to: '/dev-lifecycle/local-testing-and-development'
+  },
+  {
+    from: '/tutorials/development-lifecycle-with-auth0',
+    to: '/dev-lifecycle/setting-up-env'
+  },
+  {
+    from: ['/tokens/id_token', '/tokens/id-token'],
+    to: '/tokens/concepts/id-tokens'
+  },
+  {
+    from: '/tokens/add-custom-claims',
+    to: '/scopes/current/sample-use-cases#add-custom-claims-to-a-token'
+  },
+  {
+    from: '/tokens/guides/update-signing-algorithm-application',
+    to: '/dashboard/guides/applications/update-signing-algorithm'
+  },
+  {
+    from: ['/scopes/current/custom-claims', '/tokens/jwt-claims#custom-claims'],
+    to: '/tokens/concepts/jwt-claims'
+  },
+  {
+    from: ['/tokens/guides/jwt/verify-jwt-signature-using-jwks', '/tokens/guides/jwt/use-jwks'],
+    to: '/tokens/guides/locate-jwks'
+  },
+  {
+    from: ['/tokens/guides/jwt/parse-validate-jwt-programmatically', '/tokens/guides/jwt/validate-jwt'],
+    to: '/tokens/guides/validate-jwts'
+  },
+  {
+    from: '/tokens/concepts/claims-namespacing',
+    to: '/tokens/guides/create-namespaced-custom-claims'
+  },
+  {
+    from: ['/tokens/concepts/why-use-jwt', '/tokens/jwt'],
+    to: '/tokens/concepts/jwts'
+  },
+  {
+    from: '/tokens/guides/id-token/get-id-tokens',
+    to: '/tokens/guides/get-id-tokens'
+  },
+  {
+    from: '/tokens/guides/id-token/validate-id-token',
+    to: '/tokens/guides/validate-id-tokens'
+  },
+  {
+    from: '/tokens/reference/jwt/jwks-properties',
+    to: '/tokens/references/jwks-properties'
+  },
+  {
+    from: '/tokens/reference/jwt/jwt-structure',
+    to: '/tokens/references/jwt-structure'
+  },
+  {
+    from: '/tokens/delegation',
+    to: '/tokens/concepts/delegation-tokens'
+  },
+  {
+    from: ['/tokens/jwks', '/jwks'],
+    to: '/tokens/concepts/jwks'
+  },
+  {
+    from: '/tokens/jwt-claims',
+    to: '/tokens/concepts/jwt-claims'
+  },
+  {
+    from: '/tokens/overview-idp-access-tokens',
+    to: '/tokens/concepts/idp-access-tokens'
+  },
+  {
+    from: '/connections',
+    to: '/identityproviders'
+  },
+  {
+    from: '/libraries/lock-android/error-messages',
+    to: '/libraries/error-messages'
+  },
+  {
+    from: '/api-auth/grant/using-rules',
+    to: '/api-auth/tutorials/client-credentials/customize-with-hooks'
+  },
+  {
+    from: '/libraries/lock-ios/delegation-api',
+    to: '/libraries/lock-ios/v1/delegation-api'
+  },
+  {
+    from: '/libraries/lock-ios/lock-ios-api',
+    to: '/libraries/lock-ios/v1/lock-ios-api'
+  },
+  {
+    from: '/libraries/lock-ios/logging',
+    to: '/libraries/lock-ios/v1/logging'
+  },
+  {
+    from: '/libraries/lock-ios/native-social-authentication',
+    to: '/libraries/lock-ios/v1/native-social-authentication'
+  },
+  {
+    from: '/libraries/lock-ios/password-reset-ios',
+    to: '/libraries/lock-ios/v1/password-reset-ios'
+  },
+  {
+    from: '/libraries/lock-ios/save-and-refresh-jwt-tokens',
+    to: '/libraries/lock-ios/v1/save-and-refresh-jwt-tokens'
+  },
+  {
+    from: '/libraries/lock-ios/sending-authentication-parameters',
+    to: '/libraries/lock-ios/v1/sending-authentication-parameters'
+  },
+  {
+    from: '/libraries/lock-ios/sms-lock-ios',
+    to: '/libraries/lock-ios/v1/sms-lock-ios'
+  },
+  {
+    from: '/libraries/lock-ios/swift',
+    to: '/libraries/lock-ios/v1/swift'
+  },
+  {
+    from: '/libraries/lock-ios/touchid-authentication',
+    to: '/libraries/lock-ios/v1/touchid-authentication'
+  },
+  {
+    from: '/libraries/lock-ios/use-your-own-ui',
+    to: '/libraries/lock-ios/v1/use-your-own-uis'
+  },
+  {
+    from: '/api-auth/config/asking-for-access-tokens',
+    to: '/api-auth/tutorials/client-credentials'
+  },
+  {
+    from: '/protocols/oauth2/oauth-implicit-protocol',
+    to: '/api-auth/tutorials/implicit-grant'
+  },
+  {
+    from: '/quickstart/native/ios',
+    to: '/quickstart/native/ios-swift'
+  },
+  {
+    from: '/rules/metadata-in-rules',
+    to: '/rules/current/metadata-in-rules'
+  },
+  {
+    from: '/quickstart/native/ionic/00-intro',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/02-custom-login',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/03-user-profile',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/04-linking-accounts',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/05-rules',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/06-authorization',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/08-mfa',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/native/ionic/09-customizing-lock',
+    to: '/quickstart/native/ionic'
+  },
+  {
+    from: '/quickstart/backend/nodejs/00-getting-started',
+    to: '/quickstart/backend/nodejs'
+  },
+  {
+    from: '/quickstart/backend/aspnet-core-webapi/00-getting-started',
+    to: '/quickstart/backend/aspnet-core-webapi'
+  },
+  {
+    from: '/quickstart/backend/falcor/00-getting-started',
+    to: '/quickstart/backend/falcor'
+  },
+  {
+    from: '/quickstart/backend/golang/00-getting-started',
+    to: '/quickstart/backend/golang'
+  },
+  {
+    from: '/quickstart/backend/hapi/00-getting-started',
+    to: '/quickstart/backend/hapi'
+  },
+  {
+    from: '/quickstart/backend/java-spring-security/00-getting-started',
+    to: '/quickstart/backend/java-spring-security'
+  },
+  {
+    from: '/quickstart/backend/laravel/00-getting-started',
+    to: '/quickstart/backend/laravel'
+  },
+  {
+    from: '/quickstart/backend/php/00-getting-started',
+    to: '/quickstart/backend/php'
+  },
+  {
+    from: '/quickstart/backend/python/00-getting-started',
+    to: '/quickstart/backend/python'
+  },
+  {
+    from: '/quickstart/backend/rails/00-getting-started',
+    to: '/quickstart/backend/rails'
+  },
+  {
+    from: '/quickstart/backend/ruby/00-getting-started',
+    to: '/quickstart/backend/ruby'
+  },
+  {
+    from: '/quickstart/backend/symfony/00-getting-started',
+    to: '/quickstart/backend/symfony'
+  },
+  {
+    from: '/quickstart/backend/webapi-owin/00-getting-started',
+    to: '/quickstart/backend/webapi-owin'
+  },
+  {
+    from: '/quickstart/webapp/rails/00-introduction',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/02-custom-login',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/03-session-handling',
+    to: '/quickstart/webapp/rails/02-session-handling'
+  },
+  {
+    from: '/quickstart/webapp/rails/04-user-profile',
+    to: '/quickstart/webapp/rails/03-user-profile'
+  },
+  {
+    from: '/quickstart/webapp/rails/05-linking-accounts',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/06-rules',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/07-authorization',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/08-mfa',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/rails/09-customizing-lock',
+    to: '/quickstart/webapp/rails'
+  },
+  {
+    from: '/quickstart/webapp/java/getting-started',
+    to: '/quickstart/webapp/java'
+  },
+  {
+    from: '/quickstart/webapp/java-spring-mvc/getting-started',
+    to: '/quickstart/webapp/java-spring-mvc'
+  },
+  {
+    from: '/quickstart/webapp/java-spring-security-mvc/00-intro',
+    to: '/quickstart/webapp/java-spring-security-mvc'
+  },
+  {
+    from: '/tutorials/step-up-authentication',
+    to: '/multifactor-authentication/step-up-authentication'
+  },
+  {
+    from: '/multifactor-authentication/developer/step-up-authentication',
+    to: '/multifactor-authentication/step-up-authentication'
+  },
+  {
+    from: '/multifactor-authentication/developer/step-up-authentication/step-up-for-apis',
+    to: '/multifactor-authentication/step-up-authentication/step-up-for-apis'
+  },
+  {
+    from: '/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps',
+    to: '/multifactor-authentication/step-up-authentication/step-up-for-web-apps'
+  },
+  {
+    from: '/quickstart/spa/angular2/00-login',
+    to: '/quickstart/spa/angular2'
+  },
+  {
+    from: '/quickstart/spa/angular2/03-user-profile',
+    to: '/quickstart/spa/angular2/02-user-profile'
+  },
+  {
+    from: '/quickstart/spa/angular2/04-calling-an-api',
+    to: '/quickstart/spa/angular2/03-calling-an-api'
+  },
+  {
+    from: '/quickstart/spa/angular2/05-authorization',
+    to: '/quickstart/spa/angular2/04-authorization'
+  },
+  {
+    from: '/quickstart/spa/angular2/06-token-renewal',
+    to: '/quickstart/spa/angular2/05-token-renewal'
+  },
+  {
+    from: '/security/token-exp',
+    to: '/tokens'
+  },
+  {
+    from: ['/hosted-pages/hosted-login-auth0js', '/hosted-pages/login/auth0js', '/hosted-pages/login/lock', '/hosted-pages/login/lock-passwordless', '/hosted-pages/hosted-login-auth0js', '/hosted-pages/hosted-login-auth0js/v7', '/hosted-pages/hosted-login-auth0js/v8', '/hosted-pages/login', '/hosted-pages'],
+    to: '/universal-login'
+  },
+  {
+    from: ['/error-pages', '/error-pages/generic', '/hosted-pages/error-pages'],
+    to: '/universal-login/error-pages'
+  },
+  {
+    from: ['/error-pages/custom', '/hosted-pages/custom-error-pages'],
+    to: '/universal-login/custom-error-pages'
+  },
+  {
+    from: '/hosted-pages/default-login-url',
+    to: '/universal-login/default-login-url'
+  },
+  {
+    from: '/hosted-pages/version-control',
+    to: '/universal-login/version-control'
+  },
+  {
+    from: '/hosted-pages/guardian',
+    to: '/universal-login/multifactor-authentication'
+  },
+  {
+    from: '/universal-login/guardian',
+    to: '/universal-login/multifactor-authentication'
+  },
+  {
+    from: '/hosted-pages/password-reset',
+    to: '/universal-login/password-reset'
+  },
+  {
+    from: '/connections/database/mysql',
+    to: '/connections/database/custom-db'
+  },
+  {
+    from: '/dashboard-account-settings',
+    to: '/dashboard-tenant-settings'
+  },
+  // {
+  //   from: '/metadata/lock',
+  //   to: '/metadata#using-lock-to-manage-metadata'
+  // },
+  {
+    from: ['/libraries/lock/v11/customization'],
+    to: '/libraries/lock/v11/configuration',
+  },
+  {
+    from: '/tutorials/azure-tutorial',
+    to: '/integrations/azure-tutorial',
+  },
+  {
+    from: '/tutorials/blacklisting-attributes',
+    to: '/security/blacklisting-attributes',
+  },
+  {
+    from: '/tutorials/integrating-with-slack',
+    to: '/integrations/integrating-with-slack',
+  },
+  {
+    from: '/tutorials/browser-based-vs-native-experience-on-mobile',
+    to: '/design/browser-based-vs-native-experience-on-mobile',
+  },
+  {
+    from: '/tutorials/using-auth0-with-multi-tenant-apps',
+    to: '/design/using-auth0-with-multi-tenant-apps',
+  },
+  {
+    from: '/tutorials/adding-generic-oauth1-connection',
+    to: '/connections/adding-generic-oauth1-connection',
+  },
+  {
+    from: '/tutorials/adding-scopes-for-an-external-idp',
+    to: '/connections/adding-scopes-for-an-external-idp',
+  },
+  {
+    from: '/tutorials/generic-oauth2-connection-examples',
+    to: '/connections/generic-oauth2-connection-examples',
+  },
+  {
+    from: '/tutorials/calling-an-external-idp-api',
+    to: '/connections/calling-an-external-idp-api',
+  },
+  {
+    from: '/tutorials/tracking-new-leads-in-salesforce-and-raplead',
+    to: '/monitoring/guides/track-leads-salesforce',
+  },
+  {
+    from: '/tutorials/track-signups-enrich-user-profile-generate-leads',
+    to: '/monitoring/guides/track-signups-salesforce',
+  },
+  {
+    from: '/tutorials/how-to-monitor-auth0',
+    to: '/monitoring',
+  },
+  {
+    from: '/tutorials/sending-events-to-splunk',
+    to: '/monitoring/guides/send-events-to-splunk',
+  },
+  {
+    from: '/tutorials/sending-events-to-segmentio',
+    to: '/monitoring/guides/send-events-to-segmentio',
+  },
+  {
+    from: '/tutorials/sending-events-to-keenio',
+    to: '/monitoring/guides/send-events-to-keenio',
+  },
+  {
+    from: '/tutorials/cancel-paid-subscriptions',
+    to: '/support/cancel-paid-subscriptions',
+  },
+  {
+    from: '/tutorials/reset-account-password',
+    to: '/support/reset-account-password',
+  },
+  {
+    from: '/tutorials/delete-reset-tenant',
+    to: '/support/delete-reset-tenant',
+  },
+  {
+    from: '/tutorials/how-to-test-partner-connection',
+    to: '/connections/how-to-test-partner-connection',
+  },
+  {
+    from: '/tutorials/how-auth0-versions-software',
+    to: '/support/how-auth0-versions-software',
+  },
+  {
+    from: '/tutorials/authenticating-a-tessel-device',
+    to: '/integrations/authenticating-a-tessel-device',
+  },
+  {
+    from: '/tutorials/authenticating-devices-using-mqtt',
+    to: '/integrations/authenticating-devices-using-mqtt',
+  },
+  {
+    from: '/tutorials/creating-users-in-the-management-portal',
+    to: '/users/guides/create-users',
+  },
+  {
+    from: '/tutorials/dashboard-tenant-settings',
+    to: '/dashboard/dashboard-tenant-settings',
+  },
+  {
+    from: '/dashboard/dashboard-tenant-settings',
+    to: '/dashboard/reference/settings-tenant',  
+  },
+  {
+    from: '/tutorials/manage-dashboard-admins',
+    to: '/dashboard/manage-dashboard-admins',
+  },
+  {
+    from: '/tutorials/web-apps-vs-web-apis-cookies-vs-tokens',
+    to: '/design/web-apps-vs-web-apis-cookies-vs-tokens',
+  },
+  {
+    from: '/tutorials/how-to-update-applications-client-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret',
+  },
+  {
+    from: '/tutorials/using-auth0-to-secure-a-cli',
+    to: '/integrations/using-auth0-to-secure-a-cli',
+  },
+  {
+    from: '/tutorials/creating-invite-only-applications',
+    to: '/design/creating-invite-only-applications',
+  },
+  {
+    from: '/tutorials/google-cloud-platform',
+    to: '/integrations/google-cloud-platform',
+  },
+  {
+    from: '/tutorials/configuration-to-query-users-from-google-apps',
+    to: '/integrations/configuration-to-query-users-from-google-apps',
+  },
+  {
+    from: '/tutorials/integrating-auth0-amazon-cognito-mobile-apps',
+    to: '/integrations/integrating-auth0-amazon-cognito-mobile-apps',
+  },
+  {
+    from: '/tutorials/office365-connection-deprecation-guide',
+    to: '/integrations/office365-connection-deprecation-guide',
+  },
+  {
+    from: '/tutorials/redirecting-users',
+    to: '/users/guides/redirect-users-after-login',
+  },
+  {
+    from: '/tutorials/get-user-information-with-unbounce-landing-pages',
+    to: '/users/guides/get-user-information-with-unbounce-landing-pages',
+  },
+  {
+    from: ['/tutorials/bulk-importing-users-into-auth0', '/users/migrations/bulk-import', '/users/guides/bulk-user-import'],
+    to: '/users/guides/bulk-user-imports',
+  },
+  {
+    from: '/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise',
+    to: '/integrations/using-auth0-as-an-identity-provider-with-github-enterprise',
+  },
+  {
+    from: '/tutorials/configure-wsfed-application',
+    to: '/integrations/configure-wsfed-application',
+  },
+  {
+    from: '/tutorials/openid-connect-discovery',
+    to: '/protocols/oidc/openid-connect-discovery',
+  },
+  {
+    from: '/tutorials/removing-auth0-exporting-data',
+    to: '/support/removing-auth0-exporting-data',
+  },
+  {
+    from: '/tutorials',
+    to: '/',
+  },
+  {
+    from: '/sso/current/single-page-apps-sso',
+    to: '/sso/current/single-page-apps'
+  },
+  {
+    from: '/sso/current/introduction',
+    to: '/sso/current/sso-auth0'
+  },
+  {
+    from: '/sso/legacy/single-page-apps-sso',
+    to: '/sso/legacy/single-page-apps'
+  },
+  {
+    from: '/integrations/slack',
+    to: '/sso/current/integrations/slack'
+  },
+  {
+    from: '/integrations/integrating-with-slack',
+    to: '/sso/current/integrations/slack'
+  },
+  {
+    from: '/integrations/ad-rms',
+    to: '/sso/current/integrations/ad-rms'
+  },
+  {
+    from: '/integrations/box',
+    to: '/sso/current/integrations/box'
+  },
+  {
+    from: '/integrations/cloudbees',
+    to: '/sso/current/integrations/cloudbees'
+  },
+  {
+    from: '/integrations/concur',
+    to: '/sso/current/integrations/concur'
+  },
+  {
+    from: '/integrations/disqus',
+    to: '/sso/current/integrations/disqus'
+  },
+  {
+    from: '/integrations/dropbox',
+    to: '/sso/current/integrations/dropbox'
+  },
+  {
+    from: '/integrations/dynamic-crm',
+    to: '/sso/current/integrations/dynamics-crm'
+  },
+  {
+    from: '/integrations/echosign',
+    to: '/sso/current/integrations/echosign'
+  },
+  {
+    from: '/integrations/egnyte',
+    to: '/sso/current/integrations/egnyte'
+  },
+  {
+    from: '/integrations/new-relic',
+    to: '/sso/current/integrations/new-relic'
+  },
+  {
+    from: '/integrations/salesforce',
+    to: '/sso/current/integrations/salesforce'
+  },
+  {
+    from: '/integrations/springcm',
+    to: '/sso/current/integrations/springcm'
+  },
+  {
+    from: '/integrations/zendesk',
+    to: '/sso/current/integrations/zendesk'
+  },
+  {
+    from: '/integrations/zoom',
+    to: '/sso/current/integrations/zoom'
+  },
+  {
+    from: '/analytics/integrations',
+    to: '/analytics',
+  },
+  {
+    from: '/analytics/integrations/facebook-analytics',
+    to: '/analytics/guides/facebook-analytics',
+  },
+  {
+    from: '/analytics/integrations/google-analytics',
+    to: '/analytics/guides/google-analytics',
+  },
+  {
+    from: '/clients/how-to-update-client-secret',
+    to: '/dashboard/guides/applications/rotate-client-secret',
+  },
+  {
+    from: '/i18n/i18n-custom-login-page',
+    to: '/i18n'
+  },
+  {
+    from: ['/users/bulk-importing-users-into-auth0', '/users/migrations/bulk-import'],
+    to: '/users/guides/bulk-user-imports'
+  },
+  {
+    from: ['/connections/database/migrating', '/users/migrations/automatic'],
+    to: '/users/guides/configure-automatic-migration'
+  },
+  {
+    from: ['/connections/database/migrating-okta', '/users/migrations/okta'],
+    to: '/users/references/user-migration-scenarios'
+  },
+  {
+    from: `/metadata/management-api`,
+    to: `/metadata/apis`
+  },
+  {
+    from: `/connections/grean/bankid-no`,
+    to: `/connections/criipto/bankid-no`
+  },
+  {
+    from: `/connections/grean/bankid-se`,
+    to: `/connections/criipto/bankid-se`
+  },
+  {
+    from: `/connections/grean/nemid`,
+    to: `/connections/criipto/nemid`
+  },
+  {
+    from: '/sso/current/integrations',
+    to: '/integrations/sso'
+  },
+  {
+    from: '/sso/current/integrations/ad-rms',
+    to: '/integrations/sso/ad-rms'
+  },
+  {
+    from: '/sso/current/integrations/box',
+    to: '/integrations/sso/box'
+  },
+  {
+    from: '/sso/current/integrations/cloudbees',
+    to: '/integrations/sso/cloudbees'
+  },
+  {
+    from: '/sso/current/integrations/concur',
+    to: '/integrations/sso/concur'
+  },
+  {
+    from: '/sso/current/integrations/disqus',
+    to: '/integrations/sso/disqus'
+  },
+  {
+    from: '/sso/current/integrations/dropbox',
+    to: '/integrations/sso/dropbox'
+  },
+  {
+    from: '/sso/current/integrations/dynamics-crm',
+    to: '/integrations/sso/dynamics-crm'
+  },
+  {
+    from: '/sso/current/integrations/echosign',
+    to: '/integrations/sso/echosign'
+  },
+  {
+    from: '/sso/current/integrations/egnyte',
+    to: '/integrations/sso/egnyte'
+  },
+  {
+    from: '/sso/current/integrations/new-relic',
+    to: '/integrations/sso/new-relic'
+  },
+  {
+    from: '/sso/current/integrations/office-365',
+    to: '/integrations/sso/office-365'
+  },
+  {
+    from: '/sso/current/integrations/salesforce',
+    to: '/integrations/sso/salesforce'
+  },
+  {
+    from: '/sso/current/integrations/slack',
+    to: '/integrations/sso/slack'
+  },
+  {
+    from: '/sso/current/integrations/springcm',
+    to: '/integrations/sso/springcm'
+  },
+  {
+    from: '/sso/current/integrations/zendesk',
+    to: '/integrations/sso/zendesk'
+  },
+  {
+    from: '/sso/current/integrations/zoom',
+    to: '/integrations/sso/zoom'
+  },
+  {
+    from: '/guides/login/centralized-vs-embedded',
+    to: '/guides/login/universal-vs-embedded'
+  },
+  {
+    from: '/guides/login/migration-embedded-centralized',
+    to: '/guides/login/migration-embedded-universal'
+  },
+  {
+    from: '/api/management/v2/user-search',
+    to: '/users/search/v2'
+  },
+  {
+    from: '/api/management/v2/query-string-syntax',
+    to: '/users/search/v2/query-syntax'
+  },
+  {
+    from: '/api-auth/dynamic-application-registration',
+    to: '/api-auth/dynamic-client-registration'
+  },
+  {
+    from: '/videos/rules',
+    to: '/rules/current#video-using-rules'
+  },
+  {
+    from: `/guides/login/migration-embedded-centralized`,
+    to: `/guides/login/migration-embedded-universal`
+  },
+  {
+    from: [`/link-accounts/auth-api`, `/link-accounts`],
+    to: `/users/concepts/overview-user-account-linking`
+  },
+  {
+    from: ['/videos/session-and-cookies', '/security/store-tokens', '/tokens/guides/store-tokens'],
+    to: '/tokens/concepts/token-storage'
+  },
+  {
+    from: '/support/sla',
+    to: '/support/sld'
+  },
+  {
+    from: '/architecture-scenarios/application/mobile-api',
+    to: '/architecture-scenarios/mobile-api'
+  },
+  {
+    from: '/architecture-scenarios/application/server-api',
+    to: '/architecture-scenarios/server-api'
+  },
+  {
+    from: '/architecture-scenarios/application/spa-api',
+    to: '/architecture-scenarios/spa-api'
+  },
+  {
+    from: '/architecture-scenarios/application/web-app-sso',
+    to: '/architecture-scenarios/web-app-sso'
+  },
+  {
+    from: '/architecture-scenarios/application/web-saml',
+    to: '/architecture-scenarios/web-saml'
+  },
+  {
+    from: '/architecture-scenarios/business/b2b-b2e',
+    to: '/architecture-scenarios/b2b-b2e'
+  },
+  {
+    from: '/architecture-scenarios/business/b2b',
+    to: '/architecture-scenarios/b2b'
+  },
+  {
+    from: '/architecture-scenarios/business/b2c',
+    to: '/architecture-scenarios/b2c'
+  },
+  {
+    from: '/architecture-scenarios/business/b2e',
+    to: '/architecture-scenarios/b2e'
+  },
+  {
+    from: '/architecture-scenarios/application/mobile-api/api-implementation-nodejs',
+    to: '/architecture-scenarios/mobile-api/api-implementation-nodejs'
+  },
+  {
+    from: '/architecture-scenarios/application/mobile-api/mobile-implementation-android',
+    to: '/architecture-scenarios/mobile-api/mobile-implementation-android'
+  },
+  {
+    from: '/architecture-scenarios/application/server-api/api-implementation-nodejs',
+    to: '/architecture-scenarios/server-api/api-implementation-nodejs'
+  },
+  {
+    from: '/architecture-scenarios/application/server-api/cron-implementation-python',
+    to: '/architecture-scenarios/server-api/cron-implementation-python'
+  },
+  {
+    from: '/architecture-scenarios/application/spa-api/spa-implementation-angular2',
+    to: '/architecture-scenarios/spa-api/spa-implementation-angular2'
+  },
+  {
+    from: '/architecture-scenarios/application/spa-api/api-implementation-nodejs',
+    to: '/architecture-scenarios/spa-api/api-implementation-nodejs'
+  },
+  {
+    from: '/architecture-scenarios/application/web-app-sso/implementation-aspnetcore',
+    to: '/architecture-scenarios/web-app-sso/implementation-aspnetcore'
+  },
+  {
+     from: '/applications/application-settings/non-interactive',
+     to: '/applications/machine-to-machine#settings'
+   },
+   {
+     from: '/applications/application-settings/machine-to-machine',
+     to: '/applications/machine-to-machine#settings'
+   },
+   {
+     from: '/applications/application-settings/native',
+     to: '/applications/native#settings'
+   },
+   {
+     from: '/applications/application-settings/regular-web-app',
+     to: '/applications/webapps#settings'
+   },
+   {
+     from: '/applications/application-settings/single-page-app',
+     to: '/applications/spa#settings'
+   },
+   {
+     from: '/protocols/saml/saml-configuration/selecting-between-multiple-idp',
+     to: '/hrd'
+   },
+   {
+     from: ['/tokens/overview-access-tokens','/tokens/access-token','/tokens/access_token', '/tokens/access-tokens'],
+     to: '/tokens/concepts/access-tokens'
+   },
+   {
+    from: ['/tokens/overview-id-tokens','/tokens/id-token', '/tokens/id-tokens'],
+    to: '/tokens/concepts/id-tokens'
+  },
+   {
+     from: ['/api-auth/tutorials/verify-access-token', '/tokens/guides/access-token/validate-access-token'],
+     to: '/tokens/guides/validate-access-tokens'
+   },
+   {
+     from: '/user-profile',
+     to: '/users/concepts/overview-user-profile'
+   },
+  //  {
+  //    from: '/user-profile#block-and-unblock-a-user',
+  //    to: '/users/guides/block-and-unblock-users'
+  //  },
+   {
+     from: '/user-profile/user-picture',
+     to: '/users/guides/change-user-pictures'
+   },
+  //  {
+  //    from: '/user-profile#create-a-user',
+  //    to: '/users/guides/create-users'
+  //  },
+  //  {
+  //    from: '/user-profile#delete-a-user',
+  //    to: '/users/guides/delete-users'
+  //  },
+  //  {
+  //    from: '/user-profile#user-access-to-applications',
+  //    to: '/users/guides/manage-user-access-to-applications'
+  //  },
+  //  {
+  //    from: '/user-profile#manage-users-using-the-dashboard',
+  //    to: '/users/guides/manage-users-using-the-dashboard'
+  //  },
+  //  {
+  //    from: '/user-profile#manage-users-using-the-management-api',
+  //    to: '/users/guides/manage-users-using-the-management-api'
+  //  },
+   {
+     from: '/user-profile/progressive-profiling',
+     to: '/users/concepts/overview-progressive-profiling'
+   },
+   {
+     from: '/user-profile/customdb.md',
+     to: '/users/guides/update-user-profiles-using-your-database'
+   },
+  //  {
+  //    from: '/user-profile#view-users',
+  //    to: '/users/guides/view-users'
+  //  },
+   {
+     from: '/user-profile/normalized/auth0',
+     to: '/users/normalized/auth0'
+   },
+   {
+     from: '/user-profile/normalized/oidc',
+     to: '/users/normalized/oidc'
+   },
+   {
+     from: '/users/search/best-practices',
+     to: '/best-practices/search-best-practices'
+   },
+   {
+     from: '/users/user-data-storage',
+     to: '/best-practices/user-data-storage-best-practices'
+   },
+   {
+     from: '/user-profile/user-profile-structure',
+     to: '/users/references/user-profile-structure'
+   },
+   {
+     from: '/metadata',
+     to: '/users/concepts/overview-user-metadata'
+   },
+   {
+     from: '/metadata/apis',
+     to: '/users/guides/manage-user-metadata'
+   },
+   {
+     from: '/metadata/lock',
+     to: '/users/guides/manage-user-metadata'
+   },
+   {
+     from: '/hooks/cli/edit',
+     to: '/hooks/update'
+   },
+   {
+     from: '/hooks/cli/enable-disable',
+      to: '/hooks/enable-disable'
+   },
+   {
+     from: '/hooks/cli/logs',
+     to: '/hooks/view-logs'
+   },
+   {
+     from: '/hooks/cli',
+     to: '/hooks'
+   },
+   {
+     from: ['/multifactor-authentication/yubikey', '/multifactor-authentication/guardian', '/multifactor-authentication/guardian/user-guide'],
+     to: '/mfa'
+   },
+   {
+     from: '/hooks/dashboard/create-delete',
+     to: '/hooks/create'
+   },
+   {
+     from: ['/libraries/lock/v10/auth0js', '/libraries/lock/v11/auth0js'],
+     to: '/libraries/auth0js'
+   },
+  //  {
+  //    from: '/metadata/lock',
+  //    to: '/users/guides/manage-user-metadata'
+  //  }
+  { from: '/rules/current', to: '/rules' },
+  { from: '/rules/legacy', to: '/rules/references/legacy' },
+  { from: '/rules/current/context', to: '/rules/references/context-object' },
+  { from: '/rules/context', to: '/rules/references/context-object' },
+  { from: '/rules/current/redirect', to: '/rules/guides/redirect' },
+  { from: '/rules/current/metadata-in-rules', to: '/rules/guides/metadata' },
+  { from: '/rules/current/csharp', to: '/rules' },
+  { from: '/rules/guides/csharp', to: '/rules' },
+  { from: '/rules/current/management-api', to: '/rules/guides/management-api' },
+  {
+    from: '/hooks/cli/create-delete',
+    to: '/hooks/create'
+   },
+   {
+    from: '/hooks/cli/edit',
+    to: '/hooks/update'
+   },
+   {
+    from: '/hooks/cli/enable-disable',
+    to: '/hooks/enable-disable'
+   },
+   {
+    from: '/hooks/cli/index',
+    to: '/hooks'
+   },
+   {
+    from: '/hooks/cli/logs',
+    to: '/hooks/view-logs'
+   },
+   {
+    from: '/hooks/dashboard/create-delete',
+    to: '/hooks/create'
+   },
+   {
+    from: '/hooks/dashboard/edit',
+    to: '/hooks/update'
+   },
+   {
+    from: '/hooks/dashboard/enable-disable',
+    to: '/hooks/enable-disable'
+   },
+   {
+    from: '/hooks/dashboard/index',
+    to: '/hooks'
+   },
+   {
+    from: '/hooks/overview',
+    to: '/hooks'
+   },
+   {
+     from: '/users/redirecting-users',
+     to: '/users/guides/redirect-users-after-login'
+   },
+   {
+     from: '/applications/spa',
+     to: '/dashboard/guides/applications/register-app-spa'
+   },
+   {
+    from: [
+      '/libraries/lock/v9/customization',
+      '/libraries/lock/v9/configuration',
+      '/libraries/lock/v10/customization',
+      '/libraries/lock/v10/configuration'
+    ],
+    to: '/libraries/lock/v11/configuration'
+    },
+    {
+      from: [
+        '/libraries/lock/v10/popup-mode',
+        '/libraries/lock/v10/authentication-modes',
+        '/libraries/lock/v11/popup-mode'
+      ],
+      to: '/libraries/lock/v11/authentication-modes'
+    },
+    {
+      from: [
+        '/libraries/lock/v9',
+        '/libraries/lock/v9/display-modes',
+        '/libraries/lock/v9/types-of-applications',
+        '/libraries/lock/v10'
+      ],
+      to: '/libraries/lock/v11'
+    },
+    {
+      from: [
+        '/libraries/auth0js/v7',
+        '/libraries/auth0js/v8'
+      ],
+      to: '/libraries/auth0js/v9'
+    },
+    {
+     from: '/rules/redirect',
+     to: '/rules/guides/redirect'
+    },
+    {
+      from: '/integrations/using-auth0-as-an-identity-provider-with-github-enterprise',
+      to: '/protocols/saml/saml-apps/github-server'
+    },
+    {
+      from: ['/tokens/get-access-tokens', '/tokens/guides/access-token/get-access-tokens'],
+      to: '/tokens/guides/get-access-tokens'
+    },
+    {
+      from: ['/tokens/use-access-tokens', '/tokens/guides/access-token/use-access-tokens'],
+      to: '/tokens/guides/use-access-tokens'
+    },
+    {
+      from: '/services/private-saas-configuration',
+      to: '/services/private-cloud-configuration'
+    },
+    {
+      from: '/services/private-saas-management',
+      to: '/services/private-cloud-management'
+    },
+    {
+      from: '/api-auth/intro',
+      to: '/api-auth/tutorials/adoption'
+    },
+    {
+      from: '/authorization/guides/dashboard/enable-rbac',
+      to: '/dashboard/guides/apis/enable-rbac'
+    },
+    {
+      from: '/users/references/user-data-storage-best-practices',
+      to: '/best-practices/user-data-storage-best-practices'
+    },
+    {
+      from: '/enterprise/private-cloud/overview',
+      to: '/private-cloud'
+    },
+    {
+      from: '/private-saas-deployment',
+      to: '/private-cloud'
+    },
+    {
+      from: '/topics/identity-glossary',
+      to: '/glossary'
+    },
+    {
+      from: '/topics/extensibility',
+      to: '/extend-integrate'
+    },
+    {
+      from: '/private-saas-deployment/managed-private-cloud', 
+      to: '/private-cloud/managed-private-cloud'
+    },
+    {
+      from: '/private-saas-deployment/onboarding/managed-private-cloud', 
+      to: '/private-cloud/onboarding/managed-private-cloud'
+    },
+    {
+      from: '/private-saas-deployment/onboarding/managed-private-cloud/infrastructure', 
+      to: '/private-cloud/onboarding/managed-private-cloud/infrastructure'
+    },
+    {
+      from: '/private-saas-deployment/onboarding/managed-private-cloud/ip-domain-port-list', 
+      to: '/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list'
+    },
+    {
+      from: '/private-saas-deployment/onboarding', 
+      to: '/private-cloud/onboarding'
+    },
+    {
+      from: '/private-saas-deployment/onboarding/private-cloud', 
+      to: '/private-cloud/onboarding/private-cloud'
+    },
+    {
+      from: '/private-saas-deployment/private-cloud', 
+      to: '/private-cloud/standard-private-cloud'
+    },
+    {
+      from: '/private-saas-deployment/add-ons', 
+      to: '/private-cloud/add-ons'
+    },
+    {
+      from: '/private-saas-deployment/custom-domain-migration', 
+      to: '/private-cloud/custom-domain-migration'
+    },
+    {
+      from: '/connections/passwordless/sms-gateway',
+      to: '/connections/passwordless/guides/use-sms-gateway-passwordless'
+    },
+    {
+      from: '/policies/requests',
+      to: '/policies/unsupported-requests'
+    },
+    {
+      from: '/rules/guides/create',
+      to: '/dashboard/guides/rules/create-rules'
+    },
+    {
+      from: '/connections/apple-setup',
+      to: '/connections/apple-siwa/set-up-apple'
+    },
+    {
+      from: '/connections/apple-siwa/add-siwa-web-app',
+      to: '/connections/social/apple'
+    },
+    {
+      from: '/connections/apple-siwa/add-siwa-to-native-app',
+      to: '/connections/nativesocial/apple'
+    },
+    {
+      from: '/connections/nativesocial/add-siwa-to-native-app',
+      to: '/connections/nativesocial/apple'
+    },
+    {
+      from: '/connections/passwordless/email',
+      to: '/connections/passwordless/guides/email-otp'
+    },
+    {
+      from: '/connections/passwordless/sms',
+      to: '/connections/passwordless/guides/sms-otp'
+    },
+    {
+      from: '/connections/passwordless/spa',
+      to: '/connections/passwordless/guides/universal-login'
+    },
+    {
+      from: '/connections/passwordless/regular-web-app',
+      to: '/connections/passwordless/guides/universal-login'
+    },
+    {
+      from: [
+        '/connections/passwordless/faq',
+        '/connections/passwordless/reference/troubleshoot'
+      ],
+      to: '/connections/passwordless/troubleshoot'
+    },
+    {
+      from: '/best-practices/custom-db-connections-scripts',
+      to: '/best-practices/custom-db-connections'
+    },
+    {
+      from: '/errors/deprecation-errors',
+      to: '/troubleshoot/guides/check-deprecation-errors'
+    },
+    {
+    from: '/api/management/v1/use-cases',
+    to: '/migrations/guides/management-api-v1-v2'
+    },
+    {
+      from: '/logs/query-syntax',
+      to: '/logs/references/query-syntax'
+    },
+    {
+      from: '/tokens/concepts/token-best-practices',
+      to: '/best-practices/token-best-practices'
+    },
+    {
+      from: '/logs/references/log-event-data',
+      to: '/logs/references/log-event-types-codes'
+    },
+    {
+      from: '/anomaly-detection/references/anomaly-detection-faqs',
+      to: '/anomaly-detection'
+    },
+    {
+      from: '/anomaly-detection/references/anomaly-detection-restrictions-limitations',
+      to: '/anomaly-detection/guides/set-anomaly-detection-preferences'
+    },
+    {      
+      from: [
+        '/hooks/concepts/credentials-exchange-extensibility-point',
+        '/hooks/guides/use-the-credentials-exchange-extensibility-point'
+      ],
+      to: '/hooks/extensibility-points/client-credentials-exchange'
+    },
+    {
+      from: [
+        '/hooks/concepts/post-user-registration-extensibility-point',
+        '/hooks/guides/use-the-post-user-registration-extensibility-point'
+      ],
+      to: '/hooks/extensibility-points/post-user-registration'
+    },
+    {
+      from: [
+        '/hooks/concepts/pre-user-registration-extensibility-point',
+        '/hooks/guides/use-the-pre-user-registration-extensibility-point'
+      ],
+      to: '/hooks/extensibility-points/pre-user-registration'
+    },
+    {
+      from: '/hooks/guides/post-change-password',
+      to: '/hooks/extensibility-points/post-change-password'
+    },
+    {
+      from: '/hooks/concepts/extensibility-points',
+      to: '/hooks/extensibility-points'
+    },
+    {
+      from: [
+        '/hooks/guides/create-hooks-using-cli',
+        '/hooks/guides/create-hooks-using-dashboard'
+      ],
+      to: '/hooks/create'
+    },
+    {
+      from: [
+        '/hooks/guides/delete-hooks-using-cli',
+        '/hooks/guides/delete-hooks-using-dashboard'
+      ],
+      to: '/hooks/delete'
+    },
+    {
+      from: [
+        '/hooks/guides/edit-hooks-using-cli',
+        '/hooks/guides/edit-hooks-using-dashboard'
+      ],
+      to: '/hooks/update'
+    },
+    {
+      from: [
+        '/hooks/guides/enable-disable-hooks-using-cli',
+        '/hooks/guides/enable-disable-hooks-using-dashboard'
+      ],
+      to: '/hooks/enable-disable'
+    },
+    {
+      from: '/hooks/guides/logging-hooks-using-cli',
+      to: '/hooks/view-logs'
+    },
+    {
+      from: '/hooks/client-credentials-exchange',
+      to: '/hooks/extensibility-points/client-credentials-exchange'
+    },
+    {
+      from: '/hooks/post-change-password',
+      to: '/hooks/extensibility-points/post-change-password'
+    },
+    {
+      from: '/hooks/post-user-registration',
+      to: '/hooks/extensibility-points/post-user-registration'
+    },
+    {
+      from: '/hooks/pre-user-registration',
+      to: '/hooks/extensibility-points/pre-user-registration'
+    },
+    {
+      from: '/hooks/logs',
+      to: '/hooks/view-logs'
+    },
+    {
+      from: ['/integrations/aws-eventbridge','/logs/streams/aws-eventbridge'],
+      to: '/logs/streams/amazon-eventbridge'
+    },
+    {
+      from: '/extensions/deploy-cli/references/whats-new-v2',
+      to: 'articles/extensions/deploy-cli/references/whats-new'
+    },
+    {
+      from: '/api/management/guides/retrieve-connection-options',
+      to: '/api/management/guides/connections/retrieve-connection-options'
+    },
+    {
+      from: '/product-lifecycle/deprecation-eol',
+      to: '/product-lifecycle/migration-process'
+    },
+    {
+      from: ['/mfa/reset-user-mfa','/mfa/reset-user-MFA'],
+      to: '/mfa/guides/reset-user-mfa'
+    },
+    {
+      from: '/connections/social/miicard',
+      to: '/connections/identity-providers-social'
+    },
+    {
+      from: '/mfa/references/troubleshooting',
+      to: '/mfa/references/troubleshoot-mfa'
+    },
+    {
+      from: '/line',
+      to: '/connections/social/line'
+    },
+    {
+      from: '/api-auth/tutorials/multifactor-resource-owner-password',
+      to: '/mfa/guides/mfa-api/multifactor-resource-owner-password'
+    },
+  
+    /* - - - - - - - - - - - - - - - - - - - 
+       NOTHING SHOULD REMAIN ABOVE THIS LINE
+       - - - - - - - - - - - - - - - - - - - */
+
+    /* QUICKSTARTS */
+
+    {
+      from: ['/android-tutorial', '/native-platforms/android'],
+      to: '/quickstart/native/android'
+    },
+    {
+      from: [
+        '/angular-tutorial',
+        '/client-platforms/angularjs',
+        '/quickstart/spa/angular/:client?'
+      ],
+      to: '/quickstart/spa/angularjs'
+    },
+    {
+      from: '/client-platforms/angular2',
+      to: '/quickstart/spa/angular2'
+    },
+    {
+      from: ['/aspnet-tutorial', '/mvc3-tutorial'],
+      to: '/quickstart/webapp/aspnet'
+    },
+    {
+      from: ['/aspnet-owin-tutorial', '/aspnetwebapi-owin-tutorial'],
+      to: '/quickstart/webapp/aspnet-owin'
+    },
+    {
+      from: [
+        '/aspnetwebapi-tutorial',
+        '/tutorials/aspnet-mvc4-enterprise-providers',
+        '/webapi'
+      ],
+      to: '/quickstart/backend/aspnet-webapi'
+    },
+    {
+      from: '/quickstart/native/chrome-extension',
+      to: '/quickstart/native/chrome'
+    },
+    {
+      from: ['/ember-tutorial', '/client-platforms/emberjs'],
+      to: '/quickstart/spa/emberjs'
+    },
+    {
+      from: '/ionic-tutorial',
+      to: '/quickstart/native/ionic'
+    },
+    {
+      from: ['/ios-tutorial', '/native-platforms/ios-objc', '/quickstart/native/ios-objc'],
+      to: '/quickstart/native/ios-swift'
+    },
+    {
+      from: '/java-tutorial',
+      to: '/quickstart/webapp/java'
+    },
+    {
+      from: '/javaapi-tutorial',
+      to: '/quickstart/backend/java'
+    },
+    {
+      from: '/server-platforms/golang',
+      to: '/quickstart/webapp/golang'
+    },
+    {
+      from: '/laravel-tutorial',
+      to: '/quickstart/webapp/laravel'
+    },
+    {
+      from: '/laravelapi-tutorial',
+      to: '/quickstart/backend/php-laravel'
+    },
+    {
+      from: '/nodeapi-tutorial',
+      to: '/quickstart/backend/nodejs'
+    },
+    {
+      from: ['/nodejs-tutorial', '/server-platforms/nodejs'],
+      to: '/quickstart/webapp/nodejs'
+    },
+    {
+      from: '/phpapi-tutorial',
+      to: '/quickstart/backend/php'
+    },
+    {
+      from: '/pythonapi-tutorial',
+      to: '/quickstart/backend/python'
+    },
+    {
+      from: '/client-platforms/react',
+      to: '/quickstart/spa/react'
+    },
+    {
+      from: '/quickstart/native/ios-reactnative',
+      to: '/quickstart/native/react-native'
+    },
+    {
+      from: '/rubyapi-tutorial',
+      to: '/quickstart/backend/rails'
+    },
+    {
+      from: '/rails-tutorial',
+      to: '/quickstart/webapp/rails'
+    },
+    {
+      from: '/server-apis/ruby',
+      to: '/quickstart/backend/ruby'
+    },
+    {
+      from: '/python-tutorial',
+      to: '/quickstart/webapp/python'
+    },
+    {
+      from: ['/php-tutorial', '/server-platforms/php'],
+      to: '/quickstart/webapp/php'
+    },
+    {
+      from: '/phonegap-tutorial',
+      to: '/quickstart/native/phonegap'
+    },
+    {
+      from: '/servicestack-tutorial',
+      to: '/quickstart/webapp/servicestack'
+    },
+    {
+      from: [
+        '/singlepageapp-tutorial',
+        '/client-platforms/vanillajs',
+        '/quickstart/spa/javascript/:client?'
+      ],
+      to: '/quickstart/spa/vanillajs'
+    },
+    {
+      from: '/quickstart/webapp/play-2-scala',
+      to: '/quickstart/webapp/scala'
+    },
+    {
+      from: '/symfony-tutorial',
+      to: '/quickstart/webapp/symfony'
+    },
+    {
+      from: '/wcf-tutorial',
+      to: '/quickstart/backend/wcf-service'
+    },
+    {
+      from: [
+        '/win8-cs-tutorial',
+        '/windowsstore-auth0-tutorial',
+        '/native-platforms/windows-store-csharp',
+        '/quickstart/native-mobile/windows8-cp/:client?',
+        '/quickstart/native/windows8-cp'
+      ],
+      to: '/quickstart/native/windows-uwp-csharp'
+    },
+    {
+      from: [
+        '/win8-tutorial',
+        '/windowsstore-js-auth0-tutorial',
+        '/native-platforms/windows-store-javascript',
+        '/quickstart/native-mobile/windows8/:client'
+      ],
+      to: '/quickstart/native/windows-uwp-javascript'
+    },
+    {
+      from: '/windowsphone-tutorial',
+      to: '/quickstart/native/windowsphone'
+    },
+    {
+      from: '/wpf-winforms-tutorial',
+      to: '/quickstart/native/wpf-winforms'
+    },
+    {
+      from: '/xamarin-tutorial',
+      to: '/quickstart/native/xamarin'
+    },
+    {
+      from: '/quickstart/:platform/reactnative-ios/:backend?',
+      to: '/quickstart/native/react-native'
+    },
+    {
+      from: '/quickstart/:platform/reactnative-android/:backend?',
+      to: '/quickstart/native/react-native'
+    },
+    {
+      from: '/quickstart/native/react-native-ios',
+      to: '/quickstart/native/react-native'
+    },
+    {
+      from: '/quickstart/native/react-native-android',
+      to: '/quickstart/native/react-native'
+    },
+    {
+      from: '/quickstart/spa/auth0-react',
+      to: '/quickstart/spa/react'
+    },
+    {
+      from: '/quickstart/spa/auth0-react/01',
+      to: '/quickstart/spa/react'
+    },
+    {
+      from: '/quickstart/spa/auth0-react/02',
+      to: '/quickstart/spa/react/02-calling-an-api'
+    },
+    {
+      from: '/quickstart/backend/webapi-owin/04-authentication-rs256-deprecated',
+      to: '/quickstart/backend/webapi-owin/04-authentication-rs256-legacy'
+    },
+    {
+      from: '/quickstart/backend/webapi-owin/05-authentication-hs256-deprecated',
+      to: '/quickstart/backend/webapi-owin/05-authentication-hs256-legacy'
+    },
+    {
+      from: '/quickstart/backend/webapi-owin/06-authorization-deprecated',
+      to: '/quickstart/backend/webapi-owin/06-authorization-legacy'
+    },
+    {
+      from: '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-deprecated',
+      to: '/quickstart/backend/aspnet-core-webapi/04-authentication-rs256-legacy'
+    },
+    {
+      from: '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-deprecated',
+      to: '/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-legacy'
+    },
+    {
+      from: '/quickstart/backend/aspnet-core-webapi/06-authorization-deprecated',
+      to: '/quickstart/backend/aspnet-core-webapi/06-authorization-legacy'
+    },
+    {
+      from: '/quickstart/spa/react/03-user-profile',
+      to: '/quickstart/spa/react/04-user-profile'
+    },
+
+    /* CONNECTIONS */
+
+
+  
+    /* MICROSITES */
+ 
+  
+  
+    /* ARCHITECTURE SCENARIOS */
+
+  
+
+    /* CONTENTFUL REDIRECTS (ALL LIVE SITE PAGES NOT LISTED ABOVE) */
+  
+    {
+        from: ['/email/spa-redirect'],
+        to: '/auth0-email-services/spa-redirect'
+    },
+    {
+        from: ['/extensions/deploy-cli/guides/call-deploy-cli-programmatically'],
+        to: '/call-deploy-cli-tool-programmatically'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/rules'],
+        to: '/auth0-extensions/authorization-dashboard-extension/use-rules-with-the-authorization-extension'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/import-export-data'],
+        to: '/auth0-extensions/authorization-dashboard-extension/import-and-export-authorization-extension-data'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/troubleshooting'],
+        to: '/auth0-extensions/authorization-dashboard-extension/troubleshoot-authorization-extension'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/implementation/setup'],
+        to: '/auth0-extensions/authorization-dashboard-extension/set-up-authorization-extension-users'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/implementation/configuration'],
+        to: '/auth0-extensions/authorization-dashboard-extension/configure-authorization-extension'
+    },
+    {
+        from: ['/extensions/sso-dashboard'],
+        to: '/auth0-extensions/single-sign-on-dashboard-extension'
+    },
+    {
+        from: ['/extensions'],
+        to: '/auth0-extensions'
+    },
+    {
+        from: ['/extensions/deploy-cli/guides/import-export-directory-structure'],
+        to: '/import-export-tenant-configuration-to-directory-structure'
+    },
+    {
+        from: ['/extensions/deploy-cli'],
+        to: '/deploy-cli-tool'
+    },
+    {
+        from: ['/extensions/deploy-cli/references/troubleshooting'],
+        to: '/troubleshoot-the-deploy-cli-tool'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2'],
+        to: '/auth0-extensions/authorization-dashboard-extension'
+    },
+    {
+        from: ['/extensions/deploy-cli/references/deploy-cli-options'],
+        to: '/deploy-cli-options'
+    },
+    {
+        from: ['/extensions/deploy-cli/guides/create-deploy-cli-application-manually'],
+        to: '/create-and-configure-the-deploy-cli-application-manually'
+    },
+    {
+        from: ['/extensions/deploy-cli/guides/incorporate-deploy-cli-into-build-environment'],
+        to: '/incorporate-deploy-cli-into-build-environment'
+    },
+    {
+        from: ['/extensions/authorization-extension/v2/api-access'],
+        to: '/auth0-extensions/authorization-dashboard-extension/enable-api-access-to-authorization-extension'
+    },
+    {
+        from: ['/extensions/deploy-cli/guides/install-deploy-cli'],
+        to: '/install-and-configure-the-deploy-cli-tool'
+    },
+    {
+        from: ['/extensions/deploy-cli/references/environment-variables-keyword-mappings'],
+        to: '/environment-variables-and-keyword-mappings'
+    },
+    {
+        from: ['/cms/joomla/configuration'],
+        to: '/cms/integrate-with-joomla'
+    },
+    {
+        from: ['/cms/joomla/installation'],
+        to: '/cms/joomla-installation'
+    },
+    {
+        from: ['/cms/wordpress/configuration'],
+        to: '/cms/wordpress-plugin/configure-login-by-auth0'
+    },
+    {
+        from: ['/cms/wordpress/extending'],
+        to: '/cms/wordpress-plugin/extend-login-by-auth0'
+    },
+    {
+        from: ['/cms/wordpress'],
+        to: '/cms/wordpress-plugin'
+    },
+    {
+        from: ['/cms/wordpress/installation'],
+        to: '/cms/wordpress-plugin/install-login-by-auth0'
+    },
+    {
+        from: ['/cms/wordpress/invalid-state'],
+        to: '/cms/wordpress-plugin/troubleshoot-wordpress-plugin-invalid-state-errors'
+    },
+    {
+        from: ['/cms/wordpress/troubleshoot'],
+        to: '/cms/wordpress-plugin/troubleshoot-login-by-auth0'
+    },
+    {
+        from: ['/migrations/guides/calling-api-with-idtokens'],
+        to: '/product-lifecycle/deprecations-and-migrations/migrate-to-calling-api-with-access-tokens'
+    },
+    {
+        from: ['/migrations/guides/extensibility-node12'],
+        to: '/product-lifecycle/deprecations-and-migrations/migrate-to-nodejs-12'
+    },
+    {
+        from: ['/migrations/guides/management-api-v1-v2'],
+        to: '/product-lifecycle/deprecations-and-migrations/migrate-to-management-api-v2'
+    },
+    {
+        from: ['/migrations/guides/passwordless-start'],
+        to: '/product-lifecycle/deprecations-and-migrations/migrate-to-passwordless'
+    },
+    {
+        from: ['/cms/wordpress/user-migration'],
+        to: '/cms/wordpress-plugin/user-migration-in-login-by-auth0'
+    },
+    {
+        from: ['/troubleshoot/concepts/auth-issues'],
+        to: '/troubleshoot/troubleshoot-authentication-issues'
+    },
+    {
+        from: ['/troubleshoot/concepts/basics'],
+        to: '/troubleshoot/basic-troubleshooting'
+    },
+    {
+        from: ['/troubleshoot/concepts/integration-extensibility-issues'],
+        to: '/troubleshoot/troubleshoot-integration-and-extensibility'
+    },
+    {
+        from: ['/troubleshoot/guides/check-api-calls'],
+        to: '/troubleshoot/troubleshoot-authentication-issues/check-api-calls'
+    },
+    {
+        from: ['/troubleshoot/guides/check-deprecation-errors'],
+        to: '/troubleshoot/troubleshoot-authentication-issues/check-deprecation-errors'
+    },
+    {
+        from: ['/troubleshoot/guides/check-error-messages'],
+        to: '/troubleshoot/check-error-messages'
+    },
+    {
+        from: ['/troubleshoot/guides/check-login-logout-issues'],
+        to: '/troubleshoot/troubleshoot-authentication-issues/check-login-and-logout-issues'
+    },
+    {
+        from: ['/troubleshoot/guides/check-user-profiles'],
+        to: '/troubleshoot/troubleshoot-authentication-issues/check-user-profiles'
+    },
+    {
+        from: ['/troubleshoot/guides/generate-har-files'],
+        to: '/troubleshoot/generate-and-analyze-har-files'
+    },
+    {
+        from: ['/troubleshoot/guides/verify-connections'],
+        to: '/troubleshoot/basic-troubleshooting/verify-connections'
+    },
+    {
+        from: ['/troubleshoot/guides/verify-domain'],
+        to: '/troubleshoot/basic-troubleshooting/verify-domain'
+    },
+    {
+        from: ['/troubleshoot/guides/verify-platform'],
+        to: '/troubleshoot/basic-troubleshooting/verify-platform'
+    },
+    {
+        from: ['/troubleshoot/guides/verify-rules'],
+        to: '/troubleshoot/verify-rules'
+    },
+    {
+        from: ['/troubleshoot/references/invalid-token'],
+        to: '/troubleshoot/invalid-token-errors'
+    },
+    {
+        from: ['/pre-deployment/how-to-run-test'],
+        to: '/pre-deployment/how-to-run-production-checks'
+    },
+    {
+        from: ['/pre-deployment/prelaunch-tips'],
+        to: '/pre-deployment/pre-launch-tips'
+    },
+    {
+        from: ['/pre-deployment/tests/best-practice'],
+        to: '/pre-deployment/how-to-run-production-checks/production-checks:-best-practices'
+    },
+    {
+        from: ['/pre-deployment/tests/recommended'],
+        to: '/pre-deployment/how-to-run-production-checks/production-checks:-recommended-fixes'
+    },
+    {
+        from: ['/pre-deployment/tests/required'],
+        to: '/pre-deployment/how-to-run-production-checks/production-checks:-required-fixes'
+    },
+    {
+        from: ['/services'],
+        to: '/auth0-professional-services'
+    },
+    {
+        from: ['/i18n'],
+        to: '/internationalization-and-multilingual-settings'
+    },
+    {
+        from: ['/i18n/password-options'],
+        to: '/password-options-translation'
+    },
+    {
+        from: ['/logs/streams/amazon-eventbridge'],
+        to: '/auth0-logs/export-log-events-with-log-streaming/stream-logs-to-amazon-eventbridge'
+    },
+    {
+        from: ['/logs/streams/datadog'],
+        to: '/auth0-logs/export-log-events-with-log-streaming/stream-logs-to-datadog'
+    },
+    {
+        from: ['/logs/streams/http-event'],
+        to: '/auth0-logs/export-log-events-with-log-streaming/stream-http-event-logs'
+    },
+    {
+        from: ['/logs/streams'],
+        to: '/auth0-logs/export-log-events-with-log-streaming'
+    },
+    {
+        from: ['/compliance'],
+        to: '/compliance-and-certifications'
+    },
+    {
+        from: ['/best-practices/error-handling'],
+        to: '/best-practices/error-handling-best-practices'
+    },
+    {
+        from: ['/best-practices/rules'],
+        to: '/best-practices/rules-best-practices'
+    },
+    {
+        from: ['/logs'],
+        to: '/auth0-logs/export-logs-with-extensions'
+    },
+    {
+        from: ['/deploy/checklist'],
+        to: '/deploy/deploy-checklist'
+    },
+    {
+        from: ['/login/embedded'],
+        to: '/login/embedded-login'
+    },
+    {
+        from: ['/hooks/create'],
+        to: '/hooks/create-hooks'
+    },
+    {
+        from: ['/hooks/delete'],
+        to: '/hooks/delete-hooks'
+    },
+    {
+        from: ['/hooks/enable-disable'],
+        to: '/hooks/enable-disable-hooks'
+    },
+    {
+        from: ['/hooks/extensibility-points/post-change-password'],
+        to: '/hooks/post-change-password'
+    },
+    {
+        from: ['/hooks/extensibility-points/post-user-registration'],
+        to: '/hooks/post-user-registration'
+    },
+    {
+        from: ['/hooks/extensibility-points/pre-user-registration'],
+        to: '/hooks/pre-user-registration'
+    },
+    {
+        from: ['/hooks/extensibility-points/send-phone-message'],
+        to: '/hooks/send-phone-message'
+    },
+    {
+        from: ['/hooks/secrets/create'],
+        to: '/hooks/hook-secrets/create-hook-secrets'
+    },
+    {
+        from: ['/hooks/secrets/delete'],
+        to: '/hooks/hook-secrets/delete-hook-secrets'
+    },
+    {
+        from: ['/hooks/secrets'],
+        to: '/hooks/hook-secrets'
+    },
+    {
+        from: ['/hooks/secrets/update'],
+        to: '/hooks/hook-secrets/update-hook-secrets'
+    },
+    {
+        from: ['/hooks/secrets/view'],
+        to: '/hooks/hook-secrets/view-hook-secrets'
+    },
+    {
+        from: ['/hooks/update'],
+        to: '/hooks/update-hooks'
+    },
+    {
+        from: ['/hooks/view-logs'],
+        to: '/hooks/view-logs-for-hooks'
+    },
+    {
+        from: ['/hooks/view'],
+        to: '/hooks/view-hooks'
+    },
+    {
+        from: ['/protocols/oidc/identity-providers/okta'],
+        to: '/protocols/configure-okta-as-oidc-identity-provider'
+    },
+    {
+        from: ['/protocols/oidc/openid-connect-discovery'],
+        to: '/protocols/configure-applications-with-oidc-discovery'
+    },
+    {
+        from: ['/protocols/saml/adfs'],
+        to: '/protocols/saml-configuration-options/configure-adfs-saml-connections'
+    },
+    {
+        from: ['/protocols/saml/identity-providers/onelogin'],
+        to: '/protocols/saml-configuration-options/configure-onelogin-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/identity-providers/ping7'],
+        to: '/protocols/saml-configuration-options/configure-pingfederate-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/identity-providers/salesforce'],
+        to: '/protocols/saml-configuration-options/configure-salesforce-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/identity-providers/siteminder'],
+        to: '/protocols/saml-configuration-options/configure-siteminder-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/identity-providers/ssocircle'],
+        to: '/protocols/saml-configuration-options/configure-ssocircle-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/idp-initiated-sso'],
+        to: '/protocols/saml-configuration-options/configure-saml-identity-provider-initiated-single-sign-on'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/cisco-webex'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-cisco-webex'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/datadog'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-datadog'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/egencia'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-egencia'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/freshdesk'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-freshdesk'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/github-cloud'],
+        to: '/protocols/saml-configuration-options/configure-saml2-web-app-addon-for-github-enterprise-cloud'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/github-server'],
+        to: '/protocols/saml-configuration-options/configure-saml2-web-app-addon-for-github-enterprise-server'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/hosted-graphite'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-hosted-graphite'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/litmos'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-litmos'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/pluralsight'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-pluralsight'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/sprout-video'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-sprout-video'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/tableau-online'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-tableau-online'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/tableau-server'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-tableau-server'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/workday'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-workday'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/workpath'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-workpath'
+    },
+    {
+        from: ['/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-service-and-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/saml-idp-generic'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-saml-identity-provider'
+    },
+    {
+        from: ['/protocols/saml/saml2webapp-tutorial'],
+        to: '/protocols/saml-configuration-options/configure-saml2-web-applications'
+    },
+    {
+        from: ['/libraries/auth0-android/configuration'],
+        to: '/auth0-libraries/auth0-android/auth0-android-configuration'
+    },
+    {
+        from: ['/libraries/auth0-android'],
+        to: '/auth0-libraries/auth0-android'
+    },
+    {
+        from: ['/libraries/lock/v11/configuration'],
+        to: '/auth0-libraries/lock-v11-for-web/lock-configuration'
+    },
+    {
+        from: ['/applications/concepts/app-types-first-third-party'],
+        to: '/auth0-applications/first-party-and-third-party-applications'
+    },
+    {
+        from: ['/applications'],
+        to: '/auth0-applications'
+    },
+    {
+        from: ['/applications/reference/wildcard-subdomains'],
+        to: '/auth0-applications/wildcards-for-subdomains'
+    },
+    {
+        from: ['/email/custom'],
+        to: '/auth0-email-services/manage-email-flow'
+    },
+    {
+        from: ['/email'],
+        to: '/auth0-email-services'
+    },
+    {
+        from: ['/email/testing'],
+        to: '/auth0-email-services/configure-external-smtp-email-providers/configure-test-smtp-email-servers'
+    },
+    {
+        from: ['/sso/current/relevant-api-endpoints'],
+        to: '/single-sign-on/api-endpoints-for-single-sign-on'
+    },
+    {
+        from: ['/dev-lifecycle/local-testing-and-development'],
+        to: '/development-lifecycle/work-with-auth0-locally'
+    },
+    {
+        from: ['/dev-lifecycle/setting-up-env'],
+        to: '/development-lifecycle/set-up-multiple-environments'
+    },
+    {
+        from: ['/rules/guides/cache-resources'],
+        to: '/rules/cache-expensive-resources-in-rules'
+    },
+    {
+        from: ['/rules/guides/configuration'],
+        to: '/rules/configuration'
+    },
+    {
+        from: ['/rules/guides/debug'],
+        to: '/rules/debug-rules'
+    },
+    {
+        from: ['/rules/guides/management-api'],
+        to: '/rules/use-management-api'
+    },
+    {
+        from: ['/rules/guides/metadata'],
+        to: '/rules/metadata'
+    },
+    {
+        from: ['/rules/guides/redirect'],
+        to: '/rules/redirect-users'
+    },
+    {
+        from: ['/rules/references/context-object'],
+        to: '/rules/context-object'
+    },
+    {
+        from: ['/rules/references/samples'],
+        to: '/rules/examples'
+    },
+    {
+        from: ['/rules/references/use-cases'],
+        to: '/rules/use-cases'
+    },
+    {
+        from: ['/rules/references/user-object'],
+        to: '/rules/user-object-in-rules'
+    },
+    {
+        from: ['/custom-domains/additional-configuration'],
+        to: '/custom-domains/configure-features-to-use-custom-domains'
+    },
+    {
+        from: ['/universal-login/customization-classic'],
+        to: '/universal-login/classic-experience/classic-experience-customization'
+    },
+    {
+        from: ['/universal-login/classic'],
+        to: '/universal-login/classic-experience'
+    },
+    {
+        from: ['/universal-login/multifactor-authentication'],
+        to: '/universal-login/classic-experience/mfa-classic-experience'
+    },
+    {
+        from: ['/universal-login/new-experience-limitations'],
+        to: '/universal-login/new-experience/new-experience-limitations'
+    },
+    {
+        from: ['/universal-login/new'],
+        to: '/universal-login/new-experience'
+    },
+    {
+        from: ['/universal-login/password-reset'],
+        to: '/universal-login/customize-password-reset-page'
+    },
+    {
+        from: ['/universal-login/version-control'],
+        to: '/universal-login/version-control-universal-login-pages'
+    },
+    {
+        from: ['/sessions'],
+        to: '/sessions-and-cookies'
+    },
+    {
+        from: ['/design/creating-invite-only-applications'],
+        to: '/auth0-email-services/send-email-invitations-for-application-signup'
+    },
+    {
+        from: ['/design/using-auth0-with-multi-tenant-apps'],
+        to: '/best-practices/multi-tenant-applications-best-practices'
+    },
+    {
+        from: ['/logout/guides/logout-applications'],
+        to: '/logout/log-users-out-of-applications'
+    },
+    {
+        from: ['/logout/guides/logout-auth0'],
+        to: '/logout/log-users-out-of-auth0'
+    },
+    {
+        from: ['/tokens/concepts/delegation-tokens'],
+        to: '/tokens/delegation-tokens'
+    },
+    {
+        from: ['/tokens/concepts/jwks'],
+        to: '/tokens/json-web-tokens/json-web-key-sets'
+    },
+    {
+        from: ['/tokens/guides/disable-refresh-token-rotation'],
+        to: '/tokens/access-tokens/refresh-tokens/disable-refresh-token-rotation'
+    },
+    {
+        from: ['/tokens/guides/get-id-tokens'],
+        to: '/tokens/id-tokens/get-id-tokens'
+    },
+    {
+        from: ['/tokens/guides/use-refresh-token-rotation'],
+        to: '/tokens/access-tokens/refresh-tokens/refresh-token-rotation/use-refresh-token-rotation'
+    },
+    {
+        from: ['/tokens/references/jwt-structure'],
+        to: '/tokens/json-web-tokens/json-web-token-structure'
+    },
+    {
+        from: ['/scopes/current/api-scopes'],
+        to: '/scopes/api-scopes'
+    },
+    {
+        from: ['/scopes/current/guides/customize-consent-prompt'],
+        to: '/scopes/customize-consent-prompts'
+    },
+    {
+        from: ['/scopes/current'],
+        to: '/scopes'
+    },
+    {
+        from: ['/scopes/current/oidc-scopes'],
+        to: '/scopes/openid-connect-scopes'
+    },
+    {
+        from: ['/scopes/current/sample-use-cases'],
+        to: '/scopes/sample-use-cases-scopes-and-claims'
+    },
+    {
+        from: ['/anomaly-detection/concepts/breached-passwords'],
+        to: '/anomaly-detection/breached-password-security'
+    },
+    {
+        from: ['/anomaly-detection/guides/customize-blocked-account-emails'],
+        to: '/anomaly-detection/customize-blocked-account-emails'
+    },
+    {
+        from: ['/anomaly-detection/guides/prevent-credential-stuffing-attacks'],
+        to: '/anomaly-detection-do-not-publish/automated-attack-and-credential-stuffing-protection-do-not-publish'
+    },
+    {
+        from: ['/anomaly-detection/guides/set-anomaly-detection-preferences'],
+        to: '/anomaly-detection/set-anomaly-detection-preferences-do-not-publish'
+    },
+    {
+        from: ['/anomaly-detection/guides/use-tenant-data-for-anomaly-detection'],
+        to: '/anomaly-detection/view-anomaly-detection-events'
+    },
+    {
+        from: ['/dashboard/guides/apis/enable-rbac'],
+        to: '/authorization/rbac/enable-role-based-access-control-for-apis'
+    },
+    {
+        from: ['/dashboard/guides/apis/update-token-lifetime'],
+        to: '/tokens/access-tokens/update-access-token-lifetime'
+    },
+    {
+        from: ['/dashboard/guides/applications/enable-android-app-links'],
+        to: '/auth0-applications/enable-android-app-links-support'
+    },
+    {
+        from: ['/dashboard/guides/applications/enable-sso-app'],
+        to: '/single-sign-on/enable-sso-for-applications'
+    },
+    {
+        from: ['/dashboard/guides/applications/enable-universal-links'],
+        to: '/enable-universal-links-support-in-apple-xcode'
+    },
+    {
+        from: ['/dashboard/guides/applications/register-app-native'],
+        to: '/auth0-applications/register-native-applications'
+    },
+    {
+        from: ['/dashboard/guides/applications/register-app-regular-web'],
+        to: '/auth0-applications/register-regular-web-applications'
+    },
+    {
+        from: ['/dashboard/guides/applications/remove-app'],
+        to: '/auth0-applications/remove-applications'
+    },
+    {
+        from: ['/dashboard/guides/applications/set-up-addon-saml2-aws'],
+        to: '/protocols/saml-configuration-options/configure-saml2-web-app-addon-for-aws'
+    },
+    {
+        from: ['/dashboard/guides/applications/set-up-cors'],
+        to: '/auth0-applications/set-up-cors'
+    },
+    {
+        from: ['/dashboard/guides/applications/update-app-connections'],
+        to: '/auth0-applications/update-application-connections'
+    },
+    {
+        from: ['/dashboard/guides/applications/update-grant-types'],
+        to: '/auth0-applications/update-grant-types'
+    },
+    {
+        from: ['/dashboard/guides/applications/update-signing-algorithm'],
+        to: '/auth0-applications/change-application-signing-algorithms'
+    },
+    {
+        from: ['/dashboard/guides/applications/update-token-lifetime'],
+        to: '/tokens/id-tokens/update-id-token-lifetime'
+    },
+    {
+        from: ['/dashboard/guides/applications/view-app-type-confidential-public'],
+        to: '/auth0-applications/check-an-applications-confidential-or-public-authentication-method'
+    },
+    {
+        from: ['/dashboard/guides/connections/configure-connection-sync'],
+        to: '/users/configure-connection-sync-with-auth0'
+    },
+    {
+        from: ['/dashboard/guides/connections/disable-cache-ad-ldap'],
+        to: '/ad-ldap-connector/disable-credential-caching'
+    },
+    {
+        from: ['/dashboard/guides/connections/set-up-connections-database'],
+        to: '/auth0-applications/set-up-database-connections'
+    },
+    {
+        from: ['/dashboard/guides/extensions/delegated-admin-install-extension'],
+        to: '/delegated-administration-extension/install-delegated-admin-extension'
+    },
+    {
+        from: ['/dashboard/guides/extensions/sso-dashboard-add-apps'],
+        to: '/auth0-extensions/single-sign-on-dashboard-extension/add-applications-to-the-sso-dashboard'
+    },
+    {
+        from: ['/dashboard/guides/extensions/sso-dashboard-create-app'],
+        to: '/get-started/auth0-dashboard-overview/create-sso-dashboard-application'
+    },
+    {
+        from: ['/dashboard/guides/extensions/sso-dashboard-install-extension'],
+        to: '/auth0-extensions/single-sign-on-dashboard-extension/install-sso-dashboard-extension'
+    },
+    {
+        from: ['/dashboard/guides/extensions/sso-dashboard-update-apps'],
+        to: '/auth0-extensions/single-sign-on-dashboard-extension/update-applications-on-the-sso-dashboard'
+    },
+    {
+        from: ['/dashboard/guides/roles/add-permissions-roles'],
+        to: '/authorization/rbac/roles/add-permissions-to-roles'
+    },
+    {
+        from: ['/dashboard/guides/roles/create-roles'],
+        to: '/authorization/rbac/roles/create-roles'
+    },
+    {
+        from: ['/dashboard/guides/roles/delete-roles'],
+        to: '/authorization/rbac/roles/delete-roles'
+    },
+    {
+        from: ['/dashboard/guides/roles/edit-role-definitions'],
+        to: '/authorization/rbac/roles/edit-role-definitions'
+    },
+    {
+        from: ['/dashboard/guides/roles/remove-role-permissions'],
+        to: '/authorization/rbac/roles/remove-permissions-from-roles'
+    },
+    {
+        from: ['/dashboard/guides/roles/remove-role-users'],
+        to: '/users/remove-users-from-roles'
+    },
+    {
+        from: ['/dashboard/guides/roles/view-role-permissions'],
+        to: '/authorization/rbac/roles/view-role-permissions'
+    },
+    {
+        from: ['/dashboard/guides/roles/view-role-users'],
+        to: '/authorization/rbac/roles/view-users-assigned-to-roles'
+    },
+    {
+        from: ['/dashboard/guides/rules/configure-variables'],
+        to: '/rules/configure-global-variables-for-rules'
+    },
+    {
+        from: ['/dashboard/guides/rules/create-rules'],
+        to: '/rules/create-rules'
+    },
+    {
+        from: ['/dashboard/guides/tenants/configure-device-user-code-settings'],
+        to: '/get-started/auth0-dashboard-overview/configure-device-user-code-settings'
+    },
+    {
+        from: ['/dashboard/guides/tenants/configure-session-lifetime-settings'],
+        to: '/get-started/auth0-dashboard-overview/configure-session-lifetime-settings'
+    },
+    {
+        from: ['/dashboard/guides/tenants/enable-sso-tenant'],
+        to: '/get-started/auth0-dashboard-overview/enable-sso-for-legacy-tenants'
+    },
+    {
+        from: ['/dashboard/guides/tenants/revoke-signing-keys'],
+        to: '/get-started/auth0-dashboard-overview/revoke-signing-keys'
+    },
+    {
+        from: ['/dashboard/guides/tenants/rotate-signing-keys'],
+        to: '/get-started/auth0-dashboard-overview/rotate-signing-keys'
+    },
+    {
+        from: ['/dashboard/guides/tenants/view-signing-keys'],
+        to: '/get-started/auth0-dashboard-overview/view-client-secrets-and-signing-keys'
+    },
+    {
+        from: ['/dashboard/guides/universal-login/configure-login-page-passwordless'],
+        to: '/universal-login/configure-universal-login-with-passwordless'
+    },
+    {
+        from: ['/dashboard/guides/users/assign-permissions-users'],
+        to: '/users/assign-permissions-to-users'
+    },
+    {
+        from: ['/dashboard/guides/users/assign-roles-users'],
+        to: '/users/assign-roles-to-users'
+    },
+    {
+        from: ['/dashboard/guides/users/remove-user-permissions'],
+        to: '/users/remove-permissions-from-users'
+    },
+    {
+        from: ['/dashboard/guides/users/remove-user-roles'],
+        to: '/users/remove-roles-from-users'
+    },
+    {
+        from: ['/dashboard/guides/users/unlink-user-devices'],
+        to: '/users/unlink-devices-from-users'
+    },
+    {
+        from: ['/dashboard/guides/users/view-user-permissions'],
+        to: '/users/view-user-permissions'
+    },
+    {
+        from: ['/dashboard/guides/users/view-user-roles'],
+        to: '/users/view-user-roles'
+    },
+    {
+        from: ['/dashboard/manage-dashboard-admins'],
+        to: '/get-started/auth0-dashboard-overview/manage-dashboard-users'
+    },
+    {
+        from: ['/dashboard/reference/settings-api'],
+        to: '/get-started/auth0-dashboard-overview/api-settings'
+    },
+    {
+        from: ['/dashboard/reference/settings-application'],
+        to: '/get-started/auth0-dashboard-overview/application-settings'
+    },
+    {
+        from: ['/dashboard/reference/settings-tenant'],
+        to: '/get-started/auth0-dashboard-overview/tenant-settings'
+    },
+    {
+        from: ['/api/info'],
+        to: '/auth0-apis'
+    },
+    {
+        from: ['/api/management/guides/applications/update-ownership'],
+        to: '/auth0-applications/update-application-ownership'
+    },
+    {
+        from: ['/api/management/guides/connections/promote-connection-domain-level'],
+        to: '/get-started/auth0-dashboard-overview/promote-connections-to-domain-level'
+    },
+    {
+        from: ['/api/management/guides/connections/retrieve-connection-options'],
+        to: '/get-started/auth0-dashboard-overview/retrieve-connection-options'
+    },
+    {
+        from: ['/api/management/guides/users/set-root-attributes-user-import'],
+        to: '/users/set-root-attributes-during-user-import'
+    },
+    {
+        from: ['/api/management/guides/users/set-root-attributes-user-signup'],
+        to: '/users/set-root-attributes-during-user-sign-up'
+    },
+    {
+        from: ['/api/management/guides/users/update-root-attributes-users'],
+        to: '/users/update-root-attributes-for-users'
+    },
+    {
+        from: ['/api/management/v1/reference'],
+        to: '/auth0-management-api-reference'
+    },
+    {
+        from: ['/api/management/v2/get-access-tokens-for-spas'],
+        to: '/get-management-api-tokens-for-single-page-applications'
+    },
+    {
+        from: ['/api/management/v2/tokens-flows'],
+        to: '/changes-in-auth0-management-apiv2-tokens'
+    },
+    {
+        from: ['/api/postman'],
+        to: '/use-auth0-apis-with-postman-collections'
+    },
+    {
+        from: ['/application-auth/current'],
+        to: '/authentication'
+    },
+    {
+        from: ['/application-auth/legacy'],
+        to: '/application-auth'
+    },
+    {
+        from: ['/authorization/concepts/authz-and-authn'],
+        to: '/authorization/authentication-and-authorization'
+    },
+    {
+        from: ['/authorization/concepts/authz-rules'],
+        to: '/authorization/rules-for-authorization-policies'
+    },
+    {
+        from: ['/authorization/concepts/core-vs-extension'],
+        to: '/authorization/authorization-core-vs-authorization-extension'
+    },
+    {
+        from: ['/authorization/concepts/policies'],
+        to: '/authorization/authorization-policies'
+    },
+    {
+        from: ['/authorization/concepts/rbac'],
+        to: '/authorization/rbac'
+    },
+    {
+        from: ['/authorization/concepts/sample-use-cases-rbac'],
+        to: '/authorization/sample-use-cases-role-based-access-control'
+    },
+    {
+        from: ['/authorization/concepts/sample-use-cases-rules'],
+        to: '/authorization/sample-use-cases-rules-with-authorization'
+    },
+    {
+        from: ['/authorization/concepts/troubleshooting'],
+        to: '/authorization/troubleshoot-role-based-access-control-and-authorization'
+    },
+    {
+        from: ['/authorization/guides/how-to'],
+        to: '/authorization/how-to-use-auth0s-core-authorization-feature-set'
+    },
+    {
+        from: ['/authorization/guides/manage-permissions'],
+        to: '/authorization/manage-permissions'
+    },
+    {
+        from: ['/authorization/guides/manage-roles'],
+        to: '/authorization/rbac/roles'
+    },
+    {
+        from: ['/authorization/guides/manage-users'],
+        to: '/authorization/rbac-users'
+    },
+    {
+        from: ['/flows/concepts/auth-code'],
+        to: '/authentication-and-authorization-flows/authorization-code-flow'
+    },
+    {
+        from: ['/flows/concepts/client-credentials'],
+        to: '/authentication-and-authorization-flows/client-credentials-flow'
+    },
+    {
+        from: ['/flows/concepts/device-auth'],
+        to: '/authentication-and-authorization-flows/device-authorization-flow'
+    },
+    {
+        from: ['/flows/concepts/implicit'],
+        to: '/authentication-and-authorization-flows/implicit-flow-with-form-post'
+    },
+    {
+        from: ['/flows/guides/auth-code/add-login-auth-code'],
+        to: '/authentication-and-authorization-flows/add-login-auth-code-flow'
+    },
+    {
+        from: ['/flows/guides/auth-code/call-api-auth-code'],
+        to: '/authentication-and-authorization-flows/call-your-api-using-the-authorization-code-flow'
+    },
+    {
+        from: ['/flows/guides/auth-code-pkce/add-login-auth-code-pkce'],
+        to: '/authentication-and-authorization-flows/add-login-using-the-authorization-code-flow-with-pkce'
+    },
+    {
+        from: ['/flows/guides/auth-code-pkce/call-api-auth-code-pkce'],
+        to: '/authentication-and-authorization-flows/call-your-api-using-the-authorization-code-flow-with-pkce'
+    },
+    {
+        from: ['/flows/guides/client-credentials/call-api-client-credentials'],
+        to: '/authentication-and-authorization-flows/call-your-api-using-the-client-credentials-flow'
+    },
+    {
+        from: ['/flows/guides/device-auth/call-api-device-auth'],
+        to: '/authentication-and-authorization-flows/call-your-api-using-the-device-authorization-flow'
+    },
+    {
+        from: ['/flows/guides/implicit/add-login-implicit'],
+        to: '/authentication-and-authorization-flows/add-login-using-the-implicit-flow-with-form-post'
+    },
+    {
+        from: ['/flows'],
+        to: '/authentication-and-authorization-flows'
+    },
+    {
+        from: ['/api-auth/blacklists-vs-grants'],
+        to: '/blacklists-vs-application-grants'
+    },
+    {
+        from: ['/api-auth/config/using-the-auth0-dashboard'],
+        to: '/set-up-client-credentials-grants-using-the-dashboard'
+    },
+    {
+        from: ['/api-auth/config/using-the-management-api'],
+        to: '/set-up-client-credentials-grants-using-the-management-api'
+    },
+    {
+        from: ['/api-auth/dynamic-client-registration'],
+        to: '/dynamic-client-registration'
+    },
+    {
+        from: ['/api-auth/faq'],
+        to: '/api-authentication-and-authorization-faq'
+    },
+    {
+        from: ['/api-auth/grant/authorization-code-pkce'],
+        to: '/call-apis-from-mobile-apps'
+    },
+    {
+        from: ['/api-auth/grant/authorization-code'],
+        to: '/call-apis-from-server-side-web-apps'
+    },
+    {
+        from: ['/api-auth/grant/client-credentials'],
+        to: '/client-credentials-grant'
+    },
+    {
+        from: ['/api-auth/grant/hybrid'],
+        to: '/call-apis-using-the-hybrid-flow'
+    },
+    {
+        from: ['/api-auth/grant/implicit'],
+        to: '/call-apis-from-client-side-web-apps'
+    },
+    {
+        from: ['/api-auth/grant/password'],
+        to: '/call-apis-from-highly-trusted-applications'
+    },
+    {
+        from: ['/api-auth/passwordless'],
+        to: '/oidc-conformant-passwordless-authentication'
+    },
+    {
+        from: ['/api-auth/token-renewal-in-safari'],
+        to: '/renew-tokens-when-using-safari'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/api-tokens'],
+        to: '/call-apis-with-auth0-tokens'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/authorization-code'],
+        to: '/authorization-code-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/delegation'],
+        to: '/delegation-and-the-oidc-conformant-pipeline'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/implicit'],
+        to: '/implicit-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption'],
+        to: '/oidc-conformant-authentication-adoption-guide'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/oidc-conformant'],
+        to: '/oidc-conformant-applications'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/password'],
+        to: '/resource-owner-password-credentials-exchange'
+    },
+    {
+        from: ['/api-auth/tutorials/adoption/scope-custom-claims'],
+        to: '/user-profile-claims-and-the-scope-parameter'
+    },
+    {
+        from: ['/api-auth/tutorials/authorization-code-grant-pkce'],
+        to: '/execute-an-authorization-code-grant-flow-with-pkce'
+    },
+    {
+        from: ['/api-auth/tutorials/authorization-code-grant'],
+        to: '/execute-an-authorization-code-grant-flow'
+    },
+    {
+        from: ['/api-auth/tutorials/client-credentials/customize-with-hooks'],
+        to: '/use-hooks-with-client-credentials-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/client-credentials'],
+        to: '/implement-the-client-credentials-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/hybrid-flow'],
+        to: '/implement-the-hybrid-flow'
+    },
+    {
+        from: ['/api-auth/tutorials/implicit-grant'],
+        to: '/implement-the-implicit-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/nonce'],
+        to: '/mitigate-replay-attacks-when-using-the-implicit-flow'
+    },
+    {
+        from: ['/api-auth/tutorials/password-grant'],
+        to: '/implement-the-resource-owner-password-grant'
+    },
+    {
+        from: ['/api-auth/tutorials/represent-multiple-apis'],
+        to: '/represent-multiple-apis-using-a-single-logical-api'
+    },
+    {
+        from: ['/api-auth/tutorials/silent-authentication'],
+        to: '/configure-silent-authentication'
+    },
+    {
+        from: ['/api-auth/tutorials/using-resource-owner-password-from-server-side'],
+        to: '/use-resource-owner-password-grant-from-the-server-side'
+    },
+    {
+        from: ['/api-auth/user-consent'],
+        to: '/user-consent-and-third-party-applications'
+    },
+    {
+        from: ['/mfa/concepts/guardian'],
+        to: '/mfa-in-auth0/auth0-guardian'
+    },
+    {
+        from: ['/mfa/concepts/mfa-api'],
+        to: '/mfa-in-auth0/mfa-api'
+    },
+    {
+        from: ['/mfa/concepts/mfa-developer-resources'],
+        to: '/mfa-in-auth0/mfa-developer-resources'
+    },
+    {
+        from: ['/mfa/concepts/mfa-factors'],
+        to: '/mfa-in-auth0/mfa-factors'
+    },
+    {
+        from: ['/mfa/concepts/step-up-authentication'],
+        to: '/mfa-in-auth0/step-up-authentication'
+    },
+    {
+        from: ['/mfa/guides/configure-cisco-duo'],
+        to: '/mfa-in-auth0/configure-cisco-duo-for-mfa'
+    },
+    {
+        from: ['/mfa/guides/configure-otp'],
+        to: '/mfa-in-auth0/configure-otp-notifications-for-mfa'
+    },
+    {
+        from: ['/mfa/guides/configure-phone'],
+        to: '/mfa-in-auth0/configure-sms-and-voice-notifications-for-mfa'
+    },
+    {
+        from: ['/mfa/guides/configure-step-up-apis'],
+        to: '/mfa-in-auth0/step-up-authentication/configure-step-up-authentication-for-apis'
+    },
+    {
+        from: ['/mfa/guides/configure-step-up-web-apps'],
+        to: '/mfa-in-auth0/step-up-authentication/configure-step-up-authentication-for-web-apps'
+    },
+    {
+        from: ['/mfa/guides/customize-mfa-universal-login'],
+        to: '/mfa-in-auth0/customize-mfa-user-pages'
+    },
+    {
+        from: ['/mfa/guides/enable-mfa'],
+        to: '/mfa-in-auth0/enable-mfa'
+    },
+    {
+        from: ['/mfa/guides/guardian/create-enrollment-ticket'],
+        to: '/mfa-in-auth0/auth0-guardian/create-custom-enrollment-tickets'
+    },
+    {
+        from: ['/mfa/guides/guardian/guardian-ios-sdk'],
+        to: '/mfa-in-auth0/auth0-guardian/guardian-for-ios-sdk'
+    },
+    {
+        from: ['/mfa/guides/guardian/install-guardian-sdk'],
+        to: '/mfa-in-auth0/auth0-guardian/install-guardian-sdk'
+    },
+    {
+        from: ['/mfa/guides/import-user-mfa'],
+        to: '/mfa-in-auth0/import-user-mfa-authenticator-enrollments'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/email'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/enroll-and-challenge-email-authenticators'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/manage'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/manage-authenticator-factors-mfa-api'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/otp'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/enroll-and-challenge-otp-authenticators'
+    },
+    {
+        from: ['/mfa/guides/reset-user-mfa'],
+        to: '/mfa-in-auth0/reset-user-mfa'
+    },
+    {
+        from: ['/mfa'],
+        to: '/mfa-in-auth0'
+    },
+    {
+        from: ['/mfa/references/guardian-error-code-reference'],
+        to: '/mfa-in-auth0/auth0-guardian/guardian-error-code-reference'
+    },
+    {
+        from: ['/mfa/references/language-dictionary'],
+        to: '/mfa-in-auth0/customize-mfa-user-pages/mfa-theme-language-dictionary'
+    },
+    {
+        from: ['/mfa/references/mfa-widget-reference'],
+        to: '/mfa-in-auth0/customize-mfa-user-pages/mfa-widget-theme-options'
+    },
+    {
+        from: ['/mfa/references/troubleshoot-mfa'],
+        to: '/mfa-in-auth0/troubleshoot-mfa-issues'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-amazon-sns'],
+        to: '/mfa-in-auth0/configure-amazon-sns-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-esendex'],
+        to: '/mfa-in-auth0/configure-esendex-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-infobip'],
+        to: '/mfa-in-auth0/configure-infobip-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-mitto'],
+        to: '/mfa-in-auth0/configure-mitto-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-telesign'],
+        to: '/mfa-in-auth0/configure-telesign-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-twilio'],
+        to: '/mfa-in-auth0/configure-twilio-as-mfa-sms-provider'
+    },
+    {
+        from: ['/mfa/send-phone-message-hook-vonage'],
+        to: '/mfa-in-auth0/configure-vonage-as-mfa-sms-provider'
+    },
+    {
+        from: ['/integrations/authenticating-a-tessel-device'],
+        to: '/integrations/authenticating-and-authorizing-a-tessel-device-with-auth0'
+    },
+    {
+        from: ['/integrations/authenticating-devices-using-mqtt'],
+        to: '/integrations/authenticate-devices-using-mqtt'
+    },
+    {
+        from: ['/aws-api-setup'],
+        to: '/integrations/how-to-set-up-aws-for-delegated-authentication'
+    },
+    {
+        from: ['/integrations/aws/sso'],
+        to: '/configure-amazon-web-services-for-sso'
+    },
+    {
+        from: ['/integrations/aws/tokens'],
+        to: '/integrations/call-aws-apis-and-resources-with-tokens'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/custom-authorizers'],
+        to: '/integrations/aws-api-gateway-custom-authorizers'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation'],
+        to: '/build-a-serverless-application-using-token-based-authentication-with-aws-api'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/part-1'],
+        to: '/aws-api-gateway-tutorial-step-1'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/part-2'],
+        to: '/aws-api-gateway-tutorial-step-2'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/part-3'],
+        to: '/aws-api-gateway-tutorial-step-3'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/part-4'],
+        to: '/aws-api-gateway-tutorial-step-4'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/part-5'],
+        to: '/aws-api-gateway-tutorial-step-5'
+    },
+    {
+        from: ['/integrations/aws-api-gateway/delegation/secure-api-with-cognito'],
+        to: '/secure-aws-api-gateway-using-cognito'
+    },
+    {
+        from: ['/integrations/configure-wsfed-application'],
+        to: '/protocols/configure-ws-fed-applications'
+    },
+    {
+        from: ['/integrations/google-cloud-platform'],
+        to: '/integrations/google-cloud-endpoints'
+    },
+    {
+        from: ['/integrations/integrating-auth0-amazon-cognito-mobile-apps'],
+        to: '/integrations/integrate-with-amazon-cognito'
+    },
+    {
+        from: ['/integrations/marketing/salesforce'],
+        to: '/integrations/marketing/export-user-data-salesforce'
+    },
+    {
+        from: ['/integrations/office-365-custom-provisioning'],
+        to: '/office-365-custom-provisioning'
+    },
+    {
+        from: ['/integrations/sharepoint-apps'],
+        to: '/integrations/connecting-provider-hosted-apps-to-sharepoint-online'
+    },
+    {
+        from: ['/integrations/sharepoint'],
+        to: '/integrations/sharepoint-2010-2013'
+    },
+    {
+        from: ['/integrations/using-auth0-to-secure-a-cli'],
+        to: '/integrations/secure-a-cli-with-auth0'
+    },
+    {
+        from: ['/identity-labs/01-web-sign-in'],
+        to: '/auth0-identity-labs/lab-1-web-sign-in'
+    },
+    {
+        from: ['/identity-labs/01-web-sign-in/exercise-01'],
+        to: '/auth0-identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-1'
+    },
+    {
+        from: ['/identity-labs/01-web-sign-in/exercise-02'],
+        to: '/auth0-identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-2'
+    },
+    {
+        from: ['/identity-labs/02-calling-an-api'],
+        to: '/auth0-identity-labs/identity-lab-2-calling-api'
+    },
+    {
+        from: ['/identity-labs/04-single-page-app'],
+        to: '/auth0-identity-labs/lab-4-single-page-app'
+    },
+    {
+        from: ['/identity-labs/02-calling-an-api/exercise-01'],
+        to: '/auth0-identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-1'
+    },
+    {
+        from: ['/identity-labs/02-calling-an-api/exercise-02'],
+        to: '/auth0-identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-2'
+    },
+    {
+        from: ['/identity-labs/02-calling-an-api/exercise-03'],
+        to: '/auth0-identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-3'
+    },
+    {
+        from: ['/identity-labs/03-mobile-native-app/exercise-01'],
+        to: '/auth0-identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-1'
+    },
+    {
+        from: ['/identity-labs/03-mobile-native-app/exercise-02'],
+        to: '/auth0-identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-2'
+    },
+    {
+        from: ['/identity-labs/03-mobile-native-app/exercise-03'],
+        to: '/auth0-identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-3'
+    },
+    {
+        from: ['/identity-labs/04-single-page-app/exercise-01'],
+        to: '/auth0-identity-labs/lab-4-single-page-app/identity-lab-4-exercise-1'
+    },
+    {
+        from: ['/identity-labs/04-single-page-app/exercise-02'],
+        to: '/auth0-identity-labs/lab-4-single-page-app/identity-lab-4-exercise-2'
+    },
+    {
+        from: ['/users/concepts/overview-progressive-profiling'],
+        to: '/users/progressive-profiling'
+    },
+    {
+        from: ['/users/concepts/overview-user-account-linking'],
+        to: '/users/user-account-linking'
+    },
+    {
+        from: ['/users/concepts/overview-user-metadata'],
+        to: '/users/metadata'
+    },
+    {
+        from: ['/users/concepts/overview-user-migration'],
+        to: '/users/import-and-export-users'
+    },
+    {
+        from: ['/users/concepts/overview-user-profile'],
+        to: '/users/user-profiles'
+    },
+    {
+        from: ['/users/guides/block-and-unblock-users'],
+        to: '/users/block-and-unblock-users'
+    },
+    {
+        from: ['/users/guides/bulk-user-exports'],
+        to: '/users/bulk-user-exports'
+    },
+    {
+        from: ['/users/guides/bulk-user-imports'],
+        to: '/users/bulk-user-imports'
+    },
+    {
+        from: ['/users/guides/change-user-pictures'],
+        to: '/users/change-user-pictures'
+    },
+    {
+        from: ['/users/guides/configure-automatic-migration'],
+        to: '/users/configure-automatic-migration-from-your-database'
+    },
+    {
+        from: ['/users/guides/create-users'],
+        to: '/users/create-users'
+    },
+    {
+        from: ['/users/guides/delete-users'],
+        to: '/users/delete-users'
+    },
+    {
+        from: ['/users/guides/email-verified'],
+        to: '/users/verified-email-usage'
+    },
+    {
+        from: ['/users/guides/get-user-information-with-unbounce-landing-pages'],
+        to: '/users/get-user-information-on-unbounce-landing-pages'
+    },
+    {
+        from: ['/users/guides/link-user-accounts'],
+        to: '/users/link-user-accounts'
+    },
+    {
+        from: ['/users/guides/manage-user-access-to-applications'],
+        to: '/users/manage-user-access-to-applications'
+    },
+    {
+        from: ['/users/guides/manage-user-metadata'],
+        to: '/users/manage-user-metadata'
+    },
+    {
+        from: ['/users/guides/manage-users-using-the-dashboard'],
+        to: '/users/manage-users-using-the-dashboard'
+    },
+    {
+        from: ['/users/guides/manage-users-using-the-management-api'],
+        to: '/users/manage-users-using-the-management-api'
+    },
+    {
+        from: ['/users/guides/read-metadata'],
+        to: '/users/read-metadata'
+    },
+    {
+        from: ['/users/guides/redirect-users-after-login'],
+        to: '/users/redirect-users-after-login'
+    },
+    {
+        from: ['/users/guides/set-metadata-properties-on-creation'],
+        to: '/users/set-metadata-properties-on-creation'
+    },
+    {
+        from: ['/users/guides/unlink-user-accounts'],
+        to: '/users/unlink-user-accounts'
+    },
+    {
+        from: ['/users/guides/update-metadata-properties-with-management-api'],
+        to: '/users/update-metadata-with-the-management-api'
+    },
+    {
+        from: ['/users/guides/update-user-profiles-using-your-database'],
+        to: '/users/update-user-profiles-using-your-database'
+    },
+    {
+        from: ['/users/guides/view-users'],
+        to: '/users/view-users'
+    },
+    {
+        from: ['/users/normalized/auth0/identify-users'],
+        to: '/users/identify-users'
+    },
+    {
+        from: ['/users/normalized/auth0'],
+        to: '/users/normalized-user-profiles'
+    },
+    {
+        from: ['/users/normalized/auth0/normalized-user-profile-schema'],
+        to: '/users/normalized-user-profile-schema'
+    },
+    {
+        from: ['/users/normalized/auth0/sample-user-profiles'],
+        to: '/users/sample-user-profiles'
+    },
+    {
+        from: ['/users/normalized/auth0/store-user-data'],
+        to: '/users/store-user-data'
+    },
+    {
+        from: ['/users/normalized/auth0/update-root-attributes'],
+        to: '/users/updating-user-profile-root-attributes'
+    },
+    {
+        from: ['/users/normalized/oidc'],
+        to: '/users/user-profiles-returned-from-oidc-compliant-pipelines'
+    },
+    {
+        from: ['/users/references/bulk-import-database-schema-examples'],
+        to: '/users/bulk-user-import-database-schema-and-examples'
+    },
+    {
+        from: ['/users/references/link-accounts-client-side-scenario'],
+        to: '/users/user-initiated-account-linking-client-side-implementation'
+    },
+    {
+        from: ['/users/references/link-accounts-server-side-scenario'],
+        to: '/users/suggested-account-linking-server-side-implementation'
+    },
+    {
+        from: ['/users/references/user-data-storage-scenario'],
+        to: '/users/user-data-storage-scenario'
+    },
+    {
+        from: ['/users/references/user-migration-scenarios'],
+        to: '/users/user-migration-scenarios'
+    },
+    {
+        from: ['/users/references/user-profile-structure'],
+        to: '/users/user-profile-structure'
+    },
+    {
+        from: ['/users/search/v3/get-users-by-email-endpoint'],
+        to: '/users/user-search/retrieve-users-with-the-get-users-by-email-endpoint'
+    },
+    {
+        from: ['/users/search/v3/get-users-by-id-endpoint'],
+        to: '/users/user-search/retrieve-users-with-the-get-users-by-id-endpoint'
+    },
+    {
+        from: ['/users/search/v3/get-users-endpoint'],
+        to: '/users/user-search/retrieve-users-with-the-get-users-endpoint'
+    },
+    {
+        from: ['/users/search/v3'],
+        to: '/users/user-search'
+    },
+    {
+        from: ['/users/search/v3/query-syntax'],
+        to: '/users/user-search/user-search-query-syntax'
+    },
+    {
+        from: ['/users/search/v3/sort-search-results'],
+        to: '/users/user-search/sort-search-results'
+    },
+    {
+        from: ['/users/search/v3/view-search-results-by-page'],
+        to: '/users/user-search/view-search-results-by-page'
+    },
+    {
+        from: ['/email/providers'],
+        to: '/auth0-email-services/configure-external-smtp-email-providers/configure-amazon-ses-as-external-smtp-email-provider'
+    },
+    {
+        from: ['/protocols/saml/saml-apps/atlassian'],
+        to: '/protocols/saml-configuration-options/configure-auth0-as-identity-provider-for-atlassian'
+    },
+    {
+        from: ['/protocols/oauth2'],
+        to: '/protocols/protocol-oauth2'
+    },
+    {
+        from: ['/protocols/oidc'],
+        to: '/protocols/openid-connect-protocol'
+    },
+    {
+        from: ['/protocols/saml'],
+        to: '/protocols/saml-protocol'
+    },
+    {
+        from: ['/protocols/ws-fed'],
+        to: '/protocols/ws-fed-protocol'
+    },
+    {
+        from: ['/protocols/ldap'],
+        to: '/protocols/ldap-protocol'
+    },
+    {
+        from: ['/tokens/concepts/signing-algorithms'],
+        to: '/tokens/signing-algorithms'
+    },
+    {
+        from: ['/dashboard/guides/applications/register-app-spa'],
+        to: '/auth0-applications/register-single-page-app'
+    },
+    {
+        from: ['/universal-login/text-customization-prompts/consent'],
+        to: '/universal-login/prompt-consent'
+    },
+    {
+        from: ['/logs/streams/azure-event-grid'],
+        to: '/auth0-logs/export-log-events-with-log-streaming/stream-logs-to-azure-event-grid'
+    },
+    {
+        from: ['/logs/streams/http-event-to-slack'],
+        to: '/auth0-logs/export-log-events-with-log-streaming/stream-auth0-log-events-to-slack'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/phone'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/enroll-and-challenge-sms-and-voice-authenticators'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/push'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/enroll-and-challenge-push-authenticators'
+    },
+    {
+        from: ['/mfa/guides/mfa-api/recovery-code'],
+        to: '/mfa-in-auth0/authenticate-with-ropg-and-mfa/manage-authenticator-factors-mfa-api/challenge-with-recovery-codes'
+    },
+    {
+        from: ['/anomaly-detection/references/brute-force-protection-triggers-actions'],
+        to: '/anomaly-detection/brute-force-protection-triggers-and-actions'
+    }
+];
diff --git a/config/sections.yml b/config/sections.yml
index f12c16b91f..bca91a6744 100644
--- a/config/sections.yml
+++ b/config/sections.yml
@@ -4,32 +4,28 @@
 ##
 ## ------------------------------------------------------------
 
-- id: "articles"
-  title: "Articles"
-  url: "/getting-started"
-  folder: "articles"
+- id: 'articles'
+  title: 'Articles'
+  url: '/articles'
+  folder: ''
   default: true
 
-# - id: "sdks"
-#   title: "SDKs"
-#   url: "/sdks"
+- id: 'quickstarts'
+  title: 'Quickstarts'
+  url: '/quickstarts'
+  folder: 'quickstart'
 
-- id: "apis"
-  title: "Auth0 APIs"
-  url: "/api/info"
-  folder: "articles/apis"
+- id: 'apis'
+  title: 'Auth0 APIs'
+  url: '/api'
+  folder: 'api'
 
-- id: "quickstarts"
-  title: "QuickStarts"
-  url: "/quickstarts"
-  folder: "articles/quickstart"
+- id: 'libraries'
+  title: 'SDKs'
+  url: '/libraries'
+  folder: 'libraries'
 
-- id: "libraries"
-  title: "Libraries"
-  url: "/libraries"
-  folder: "articles/libraries"
-
-- id: "appliance"
-  title: "PSaaS Appliance"
-  url: "/appliance"
-  folder: "articles/appliance"
+- id: 'events'
+  title: 'Events Catalog'
+  url: '/events/'
+  folder: ''
diff --git a/config/sidebar.yml b/config/sidebar.yml
index 39b8b21612..01c5701202 100644
--- a/config/sidebar.yml
+++ b/config/sidebar.yml
@@ -1,1200 +1,1679 @@
-## ------------------------------------------------------------
-## Sidebar Nav Configuration
-## This document contains configuration for the sidebar
-##
-## ------------------------------------------------------------
-
 articles:
-
-  - title: Getting Started
-    url: "/getting-started"
+  - title: Get Started 
+    url: /get-started
     children:
-      - title: Auth0 Overview
-        url: /getting-started/overview
-      
-      - title: The Basics
-        url: /getting-started/the-basics
-      
+      - title: How You Can Use Auth0
+        url: /get-started/auth0-overview
       - title: Dashboard Overview
-        url: /getting-started/dashboard-overview
-
-      - title: Deployment Models
-        url: /getting-started/deployment-models
-
+        url: /get-started/dashboard
+      - title: Create Tenants
+        url: /get-started/create-tenants
+        children:
+          - title: Create Multiple Tenants
+            url: /get-started/create-tenants/create-multiple-tenants
+          - title: Request Child Tenants
+            url: /get-started/create-tenants/child-tenants
+          - title: Set Up Multiple Environments
+            url: /get-started/create-tenants/set-up-multiple-environments
+      - title: Create Applications
+        url: /get-started/create-apps
+        children:
+          - title: Native Apps
+            url: /get-started/create-apps/native-apps
+          - title: Single Page Web Apps
+            url: /get-started/create-apps/single-page-web-apps
+          - title: Regular Web Apps
+            url: /get-started/create-apps/regular-web-apps
+          - title: Machine-to-Machine Apps
+            url: /get-started/create-apps/machine-to-machine-apps
+      - title: Register APIs
+        url: /get-started/set-up-apis
+      - title: Authentication and Authorization
+        url: /get-started/authentication-and-authorization
+      - title: Glossary
+        url: /glossary
   - title: Architecture Scenarios
     url: /architecture-scenarios
-
     children:
+      - title: Business to Consumer
+        url: /architecture-scenarios/b2c
+        children:
+          - title: Architecture
+            url: /architecture-scenarios/b2c/architecture
+          - title: Provisioning
+            url: /architecture-scenarios/b2c/provisioning
+          - title: Authentication
+            url: /architecture-scenarios/b2c/authentication
+          - title: Branding
+            url: /architecture-scenarios/b2c/branding
+          - title: Deployment Automation
+            url: /architecture-scenarios/b2c/deployment
+          - title: Quality Assurance
+            url: /architecture-scenarios/b2c/quality-assurance
+          - title: Profile Management
+            url: /architecture-scenarios/b2c/profile-management
+          - title: Authorization
+            url: /architecture-scenarios/b2c/authorization
+          - title: Logout
+            url: /architecture-scenarios/b2c/logout
+          - title: Operations
+            url: /architecture-scenarios/b2c/operations
+          - title: Launch Preparation
+            url: /architecture-scenarios/b2c/launch
+      - title: Business to Business
+        url: /architecture-scenarios/b2b
+        children:
+          - title: Architecture
+            url: /architecture-scenarios/b2b/architecture
+          - title: Provisioning
+            url: /architecture-scenarios/b2b/provisioning
+          - title: Authentication
+            url: /architecture-scenarios/b2b/authentication
+          - title: Branding
+            url: /architecture-scenarios/b2b/branding
+          - title: Deployment Automation
+            url: /architecture-scenarios/b2b/deployment
+          - title: Quality Assurance
+            url: /architecture-scenarios/b2b/quality-assurance
+          - title: Profile Management
+            url: /architecture-scenarios/b2b/profile-management
+          - title: Authorization
+            url: /architecture-scenarios/b2b/authorization
+          - title: Logout
+            url: /architecture-scenarios/b2b/logout
+          - title: Operations
+            url: /architecture-scenarios/b2b/operations
+          - title: Launch Preparation
+            url: /architecture-scenarios/b2b/launch
+      - title: Business to Employees
+        url: /architecture-scenarios/b2e
       - title: SSO for Regular Web Apps
-        url: /architecture-scenarios/application/web-app-sso
+        url: /architecture-scenarios/web-app-sso
+        children:
+          - title: Solution Overview
+            url: /architecture-scenarios/web-app-sso/part-1
+          - title: Configuration
+            url: /architecture-scenarios/web-app-sso/part-2
+          - title: Implementation
+            url: /architecture-scenarios/web-app-sso/part-3
+          - title: Conclusion
+            url: /architecture-scenarios/web-app-sso/part-4
+      - title: Multiple Organization Architecture
+        url: /architecture-scenarios/multiple-organization-architecture
         children:
-           - title: Solution Overview
-             url: /architecture-scenarios/application/web-app-sso/part-1
-           
-           - title: Configuration
-             url: /architecture-scenarios/application/web-app-sso/part-2
-           
-           - title: Implementation
-             url: /architecture-scenarios/application/web-app-sso/part-3
-           
-           - title: Conclusion
-             url: /architecture-scenarios/application/web-app-sso/part-4
-
+          - title: Single Identity Provider Organizations
+            url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations
+            children:
+              - title: Provisioning
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/provisioning
+                hidden: true 
+              - title: Authentication
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authentication
+                hidden: true 
+              - title: Branding
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding
+                hidden: true 
+              - title: Authorization
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization
+                hidden: true 
+              - title: Profile Management
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management
+                hidden: true 
+              - title: Logout
+                url: /architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/logout
+                hidden: true 
+          - title: Multiple Identity Provider Organizations
+            url: /architecture-scenarios/multiple-organization-architecture/multiple-identity-provider-organizations
       - title: Server Application + API
-        url: /architecture-scenarios/application/server-api
+        url: /architecture-scenarios/server-api
         children:
-           - title: Solution Overview
-             url: /architecture-scenarios/application/server-api/part-1
-           
-           - title: Configuration
-             url: /architecture-scenarios/application/server-api/part-2
-           
-           - title: Implementation
-             url: /architecture-scenarios/application/server-api/part-3
-           
-           - title: Conclusion
-             url: /architecture-scenarios/application/server-api/part-4
-
+          - title: Solution Overview
+            url: /architecture-scenarios/server-api/part-1
+          - title: Configuration
+            url: /architecture-scenarios/server-api/part-2
+          - title: Implementation
+            url: /architecture-scenarios/server-api/part-3
+          - title: Conclusion
+            url: /architecture-scenarios/server-api/part-4
       - title: SPA + API
-        url: /architecture-scenarios/application/spa-api
+        url: /architecture-scenarios/spa-api
         children:
-           - title: Solution Overview
-             url: /architecture-scenarios/application/spa-api/part-1
-           
-           - title: Configuration
-             url: /architecture-scenarios/application/spa-api/part-2
-           
-           - title: Implementation
-             url: /architecture-scenarios/application/spa-api/part-3
-           
-           - title: Conclusion
-             url: /architecture-scenarios/application/spa-api/part-4
-
+          - title: Solution Overview
+            url: /architecture-scenarios/spa-api/part-1
+          - title: Configuration
+            url: /architecture-scenarios/spa-api/part-2
+          - title: Implementation
+            url: /architecture-scenarios/spa-api/part-3
+          - title: Conclusion
+            url: /architecture-scenarios/spa-api/part-4
       - title: Mobile + API
-        url: /architecture-scenarios/application/mobile-api
+        url: /architecture-scenarios/mobile-api
         children:
-           - title: Solution Overview
-             url: /architecture-scenarios/application/mobile-api/part-1
-           
-           - title: Configuration
-             url: /architecture-scenarios/application/mobile-api/part-2
-           
-           - title: Implementation
-             url: /architecture-scenarios/application/mobile-api/part-3
-           
-           - title: Conclusion
-             url: /architecture-scenarios/application/mobile-api/part-4
-
-      # - title: SAML for Regular Web Apps
-      #   url: /architecture-scenarios/application/web-saml
-
-      # - title: B2B + B2E
-      #   url: /architecture-scenarios/business/b2b-b2e
-
-      # - title: B2B
-      #   url: /architecture-scenarios/business/b2b
-
-      # - title: B2C
-      #   url: /architecture-scenarios/business/b2c
-
-      # - title: B2E
-      #   url: /architecture-scenarios/business/b2e 
-
-  - title: "Applications"
-    url: "/applications"
+          - title: Solution Overview
+            url: /architecture-scenarios/mobile-api/part-1
+          - title: Configuration
+            url: /architecture-scenarios/mobile-api/part-2
+          - title: Implementation
+            url: /architecture-scenarios/mobile-api/part-3
+          - title: Conclusion
+            url: /architecture-scenarios/mobile-api/part-4
+      - title: Implementation Checklists
+        url: /architecture-scenarios/checklists
+      - title: Implementation Resources
+        url: /architecture-scenarios/implementation-resources
+  - title: Deploy
+    url: /deploy
     children:
-
-      - title: Overview
-        url: /applications
-
-      - title: Connections
-        url: /applications/connections
-
-      - title: Application Types
-        url: /applications/application-types
-
-      - title: Grant Types
-        url: /applications/application-grant-types
-
-  - title: "Authentication"
-    url: "/application-auth/current"
-    children:
-
-      - title: "Server-side App"
-        url: "/application-auth/current/server-side-web"
-      
-      - title: "Client-side App"
-        url: "/application-auth/current/client-side-web"
-        
-      - title: "Mobile App"
-        url: "/application-auth/current/mobile-desktop"
-      
-      - title: "Legacy"
-        url: "/application-auth/legacy"
-        hidden: true
+      - title: Deployment Options
+        url: /deploy/deploy-options
+      - title: Private Cloud Deployment
+        url: /deploy/private-cloud
         children:
-          - title: "Server-side App"
-            url: "/application-auth/legacy/server-side-web"
-            hidden: true
-      
-          - title: "Client-side App"
-            url: "/application-auth/legacy/client-side-web"
+          - title: Onboarding
+            url: /deploy/private-cloud/private-cloud-onboarding
+            children:
+              - title: Infrastructure Requirements
+                url: /deploy/private-cloud/private-cloud-onboarding/customer-hosted-managed-private-cloud-infrastructure-requirements
+                hidden: true 
+              - title: IP/Domain and Port List
+                url: /deploy/private-cloud/private-cloud-onboarding/private-cloud-ip-domain-and-port-list
+                hidden: true 
+              - title: Remote Access Options
+                url: /deploy/private-cloud/private-cloud-onboarding/private-cloud-remote-access-options
+                hidden: true 
+          - title: Operations
+            url: /deploy/private-cloud/private-cloud-operations
+          - title: Migrations
+            url: /deploy/private-cloud/private-cloud-migrations
+            children:
+              - title: Public to Private
+                url: /deploy/private-cloud/private-cloud-migrations/migrate-from-public-cloud-to-private-cloud
+                hidden: true 
+              - title: Performance to Performance Plus
+                url: /deploy/private-cloud/private-cloud-migrations/migrate-from-standard-private-cloud-to-managed-private-cloud
+                hidden: true 
+              - title: Custom Domains
+                url: /deploy/private-cloud/private-cloud-migrations/migrate-private-cloud-custom-domains
+                hidden: true 
+      - title: Pre-Deployment Checks
+        url: /deploy/pre-deployment
+        children:
+          - title: Run Production Checks
+            url: /deploy/pre-deployment/how-to-run-production-checks
+          - title: Run Pre-Deployment Tests
+            url: /deploy/pre-deployment/predeployment-tests
+          - title: Pre-Launch Tips
+            url: /deploy/pre-deployment/pre-launch-tips
+      - title: Deployment Checklist
+        url: /deploy/deploy-checklist
+      - title: Deploy CLI Tool
+        url: /deploy/deploy-cli-tool
+        children:
+          - title: Install Deploy CLI
+            url: /deploy/deploy-cli-tool/install-and-configure-the-deploy-cli-tool
+          - title: Call Deploy CLI
+            url: /deploy/deploy-cli-tool/call-deploy-cli-tool-programmatically
+          - title: Incorporate into Build Environment
+            url: /deploy/deploy-cli-tool/incorporate-deploy-cli-into-build-environment
+          - title: Import/Export Directory Structure
+            url: /deploy/deploy-cli-tool/import-export-tenant-configuration-to-directory-structure
+          - title: Import/Export YAML File
+            url: /deploy/deploy-cli-tool/import-export-tenant-configuration-to-yaml-file
+          - title: Environment Variables
+            url: /deploy/deploy-cli-tool/environment-variables-and-keyword-mappings
+          - title: Deploy CLI Options
+            url: /deploy/deploy-cli-tool/deploy-cli-tool-options
+          - title: What's New
+            url: /deploy/deploy-cli/references/whats-new
             hidden: true
-        
-          - title: "Mobile App"
-            url: "/application-auth/legacy/mobile-desktop"
+          - title: Troubleshoot Deploy CLI
+            url: /deploy/deploy-cli-tool/troubleshoot-the-deploy-cli-tool
             hidden: true
-            
-        
-  - title: "APIs"
-    url: "/apis"
+  - title: Login
+    url: /login
     children:
-
-      - title: "Overview"
-        url: "/apis"
-
-      - title: "Authorization API Index"
-        url: "/api-auth"
-
-      - title: "OIDC Conformant Authentication"
-        url: "/api-auth/intro"
-
-      - title: "OIDC Adoption Guide"
-        url: "/api-auth/tutorials/adoption"
-
-      - title: "Which OAuth Flow to Use"
-        url: "/api-auth/which-oauth-flow-to-use"
-
-      - title: "APIs & Server-side Apps"
-        url: "/api-auth/grant/authorization-code"
-
-      - title: "APIs & Mobile Apps"
-        url: "/api-auth/grant/authorization-code-pkce"
-
-      - title: "APIs & Client-side Apps"
-        url: "/api-auth/grant/implicit"
-
-      - title: "APIs & CLIs"
-        url: "/api-auth/grant/client-credentials"
-
-      - title: "APIs & Trusted Applications"
-        url: "/api-auth/grant/password"
-
-      - title: "Dynamic Application Registration"
-        url: "/api-auth/dynamic-application-registration"
-
-      - title: "Verify Access Tokens"
-        url: "/api-auth/tutorials/verify-access-token"
-
-  - title: "Connections"
-    url: "/connections"
-    children:
-      - title: "Overview"
-        url: "/connections"
-
-      - title: "Username/Password"
-        url: "/connections/database"
-
-      - title: "Social/Enterprise"
-        url: "/identityproviders"
+      - title: Universal Login
+        url: /universal-login
+        children:
+          - title: New Experience
+            url: /universal-login/new-experience
+          - title: Classic Experience
+            url: /universal-login/classic-experience
+          - title: Password Reset
+            url: /universal-login/customize-password-reset-page
+          - title: Multi-factor Authentication
+            url: /universal-login/classic-experience/mfa-classic-experience
+          - title: Passwordless
+            url: /universal-login/configure-universal-login-with-passwordless
+            children:
+              - title: WebAuthn with Device Biometrics
+                url: /universal-login/configure-universal-login-with-passwordless/webauthn-device-biometrics
+              - title: Email or SMS
+                url: /universal-login/configure-universal-login-with-passwordless/email-or-sms
+          - title: Identifier-First Authentication
+            url: /universal-login/identifier-first
+          - title: Error Pages
+            url: /universal-login/error-pages
+          - title: Text Customization
+            url: /universal-login/new-experience/text-customization-new-universal-login
+          - title: Default Login URL
+            url: /universal-login/configure-default-login-routes
+          - title: Version Control
+            url: /universal-login/version-control-universal-login-pages
+      - title: Universal vs. Embedded Login
+        url: /universal-login/universal-vs-embedded-login
+      - title: Embedded Login
+        url: /login/embedded-login
+        children:
+          - title: Lock for Web
+            url: /libraries/lock
+          - title: Auth0.js
+            url: /libraries/auth0js
+          - title: Cross-Origin Authentication
+            url: /login/embedded-login/cross-origin-authentication
+      - title: Authentication Flows
+        url: /flows
+        children:
+          - title: Regular Web App
+            url: /flows/add-login-auth-code-flow
+          - title: Single-Page App
+            url: /flows/add-login-using-the-implicit-flow-with-form-post
+          - title: Native App
+            url: /flows/add-login-using-the-authorization-code-flow-with-pkce
+      - title: Authenticate Single-Page Apps with Cookies
+        url: /sessions/cookies/spa-authenticate-with-cookies
+      - title: Multi-factor Authentication
+        url: /mfa
+        children:
+          - title: Factors
+            url: /mfa/mfa-factors
+          - title: Enable MFA
+            url: /mfa/enable-mfa
+          - title: Adaptive MFA
+            url: /mfa/adaptive-mfa
+            children:
+              - title: Enable Adaptive MFA
+                url: /mfa/adaptive-mfa/enable-adaptive-mfa
+                hidden: true
+              - title: Customize Adaptive MFA
+                url: /mfa/adaptive-mfa/adaptive-mfa-rule-actions
+                hidden: true
+              - title: Adaptive MFA Log Events
+                url: /mfa/adaptive-mfa/adaptive-mfa-log-events
+                hidden: true
+          - title: Guardian
+            url: /mfa/auth0-guardian
+            children:
+              - title: Create Custom Enrollment Ticket
+                url: /mfa/auth0-guardian/create-custom-enrollment-tickets
+                hidden: true
+              - title: Install Guardian SDK
+                url: /mfa/auth0-guardian/install-guardian-sdk
+                hidden: true
+              - title: Guardian for Android SDK
+                url: /mfa/auth0-guardian/guardian-for-android-sdk
+                hidden: true
+              - title: Guardian for iOS SDK
+                url: /mfa/auth0-guardian/guardian-for-ios-sdk
+                hidden: true
+          - title: Customize MFA
+            url: /mfa/customize-mfa-user-pages
+          - title: Reset MFA
+            url: /mfa/reset-user-mfa
+          - title: Step-up Authentication
+            url: /mfa/step-up-authentication
+            children:
+              - title: For APIs
+                url: /mfa/step-up-authentication/configure-step-up-authentication-for-apis
+                hidden: true
+              - title: For Web Apps
+                url: /mfa/step-up-authentication/configure-step-up-authentication-for-web-apps
+                hidden: true
+          - title: MFA Developer Resources
+            url: /mfa/mfa-developer-resources
+            children:
+              - title: MFA Theme Language Dictionary
+                url: /mfa/customize-mfa-user-pages/mfa-theme-language-dictionary
+                hidden: true
+              - title: MFA Widget Theme Options
+                url: /mfa/customize-mfa-user-pages/mfa-widget-theme-options
+                hidden: true
+          - title: Troubleshoot MFA
+            url: /mfa/troubleshoot-mfa-issues
+      - title: Silent Authentication
+        url: /authorization/configure-silent-authentication
+      - title: Redirect After Login
+        url: /users/redirect-users-after-login
+      - title: Logout
+        url: /logout
         children:
-          - title: "Custom Social Extensions"
-            url: "/extensions/custom-social-extensions"
-
-      - title: "Your Database"
-        url: "/connections/database/custom-db"
-
-      - title: "Passwordless Authentication"
-        url: "/connections/passwordless"
+          - title: Apps
+            url: /logout/log-users-out-of-applications
+          - title: Auth0
+            url: /logout/log-users-out-of-auth0
+          - title: Identity Providers
+            url: /logout/log-users-out-of-idps
+          - title: SAML Identity Providers
+            url: /logout/log-users-out-of-saml-idps
+          - title: Redirect After Logout
+            url: /logout/redirect-users-after-logout
+      - title: Adopt OIDC Conformant Auth
+        url: /login/adopt-oidc-conformant-authentication
         children:
-
-          - title: "Native Passwordless"
-            url: "/connections/passwordless/native-passwordless-universal"
-
-          - title: "Using Email"
-            url: "/connections/passwordless/email"
-
-          - title: "Using SMS"
-            url: "/connections/passwordless/sms"
-
-          - title: "FAQ"
-            url: "/connections/passwordless/faq"
-
-  - title: "Hosted Pages"
-    url: "/hosted-pages"
+          - title: APIs
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-apis
+          - title: Access Tokens
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-access-tokens
+          - title: Authorization Code Flow
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-auth-code-flow
+          - title: Client Credentials Flow
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-client-credentials-flow
+          - title: Delegation
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-delegation
+          - title: Implicit Flow
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-implicit-flow
+          - title: Refresh Tokens
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-refresh-tokens
+          - title: Resource Owner Password Flow
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-rop-flow
+          - title: Single Sign-On
+            url: /login/adopt-oidc-conformant-authentication/oidc-adoption-sso
+  - title: Connections
+    url: /connections
     children:
-
-      - title: "Overview"
-        url: "/hosted-pages"
-
-      - title: "Login Page"
-        url: "/hosted-pages/login"
+      - title: Social Identity Providers
+        url: /connections/social/identity-providers
+      - title: Enterprise Identity Providers
+        url: /connections/enterprise/identity-providers
+      - title: Legal Identity Providers
+        url: /connections/legal/identity-providers
+      - title: Database
+        url: /connections/database
         children:
-
-            - title: "Using Lock"
-              url: "/hosted-pages/login/lock"
-
-            - title: "Using Lock Passwordless"
-              url: "/hosted-pages/login/lock-passwordless"
-
-            - title: "Using Auth0.js"
-              url: "/hosted-pages/login/auth0js"
-
-      - title: "Password Reset Page"
-        url: "/hosted-pages/password-reset"
-      
-      - title: "Guardian MFA"
-        url: "/hosted-pages/guardian"
-
-      - title: "Error Pages"
-        url: "/hosted-pages/error-pages"
-
-      - title: "Version Control"
-        url: "/hosted-pages/version-control"
-
-  - title: "Rules"
-    url: "/rules/current"
+          - title: Auth0 User Store
+            url: /connections/database/auth0-user-store
+          - title: Your User Store
+            url: /connections/database/custom-db
+            children:
+              - title: Overview
+                url: /connections/database/custom-db/overview-custom-db-connections
+                hidden: true
+              - title: Create Connections
+                url: /connections/database/custom-db/create-db-connections
+                hidden: true
+              - title: Scripts
+                url: /connections/database/custom-db/templates
+                hidden: true
+          - title: Password Policies
+            url: /connections/database/password-options
+          - title: Password Strength
+            url: /connections/database/password-strength
+      - title: Passwordless
+        url: /connections/passwordless
+        children:
+          - title: Authentication Factors
+            url: /connections/passwordless/authentication-factors
+            children:
+              - title: Email
+                url: /connections/passwordless/email-otp
+              - title: Magic Link
+                url: /connections/passwordless/email-magic-link
+              - title: SMS
+                url: /connections/passwordless/sms-otp
+          - title: Universal Login
+            url: /connections/passwordless/universal-login
+          - title: Embedded Login
+            url: /connections/passwordless/embedded-login
+            children:
+              - title: Passwordless APIs
+                url: /connections/passwordless/relevant-api-endpoints
+              - title: Native Apps
+                url: /connections/passwordless/embedded-login-native
+              - title: Web Apps
+                url: /connections/passwordless/embedded-login-webapps
+              - title: SPAs
+                url: /connections/passwordless/embedded-login-spa
+      - title: View Connections
+        url: /dashboard/guides/connections/view-connections
+      - title: Disable Connection Sync
+        url: /dashboard/guides/connections/configure-connection-sync
+      - title: Pass Parameters to Identity Providers
+        url: /connections/pass-parameters-to-idps
+  - title: Organizations
+    url: /organizations
     children:
-
-      - title: "Overview"
-        url: "/rules/current"
-
-      - title: "User Metadata in Rules"
-        url: "/rules/metadata-in-rules"
-
-      - title: "Use the Management API in rules"
-        url: "/rules/current/management-api"
-      
-      - title: "Using C# in Rules"
-        url: "/rules/current/csharp"
-
-      - title: "Deploy Rules with GitHub"
-        url: "/extensions/github-deploy"
-
-      - title: "Deploy Rules with Bitbucket"
-        url: "/extensions/bitbucket-deploy"
-
-      - title: "Deploy Rules with GitLab"
-        url: "/extensions/gitlab-deploy"
-
-  - title: "Hooks (Beta)"
-    url: "/hooks"
+      - title: How Auth0 Organizations Work
+        url: /organizations/organizations-overview
+      - title: Create Your First Organization
+        url: /organizations/create-first-organization
+      - title: Custom Development
+        url: /organizations/custom-development
+      - title: Work with Multiple Tenants
+        url: /organizations/using-multiple-tenants
+        hidden: true
+      - title: Work with Tokens
+        url: /organizations/using-tokens
+      - title: Configure Organizations
+        url: /organizations/configure-organizations
+        children:
+          - title: Create Organizations
+            url: /organizations/create-organizations
+          - title: Delete Organizations
+            url: /organizations/delete-organizations
+          - title: Define Organization Behavior
+            url: /organizations/define-organization-behavior
+          - title: Enable Connections
+            url: /organizations/enable-connections
+          - title: Disable Connections
+            url: /organizations/disable-connections
+          - title: Invite Members
+            url: /organizations/invite-members
+          - title: Send Membership Invitations
+            url: /organizations/send-membership-invitations
+          - title: Grant Just-In-Time Membership
+            url: /organizations/grant-just-in-time-membership
+          - title: Assign Members Directly
+            url: /organizations/assign-members
+          - title: Remove Members Directly
+            url: /organizations/remove-members
+          - title: Add Roles to Members
+            url: /organizations/add-member-roles
+          - title: Remove Roles from Members
+            url: /organizations/remove-member-roles
+          - title: Retrieve Organizations
+            url: /organizations/retrieve-organizations
+          - title: Retrieve Connections
+            url: /organizations/retrieve-connections
+          - title: Retrieve Members
+            url: /organizations/retrieve-members
+          - title: Retrieve User's Membership
+            url: /organizations/retrieve-user-membership
+          - title: Retrieve Member Roles
+            url: /organizations/retrieve-member-roles
+  - title: Authorization
+    url: /authorization
     children:
-
-      - title: "Index"
-        url: "/hooks"
-
-      - title: "Overview"
-        url: "/hooks/overview"
-
-      - title: "Extensibility Points"
-        url: "/hooks/extensibility-points"
+      - title: Authorization Flows
+        url: /flows
         children:
-
-          - title: "Credentials Exchange"
-            url: "/hooks/extensibility-points/credentials-exchange"
+          - title: Authorization Code
+            url: /flows/call-your-api-using-the-authorization-code-flow
+          - title: Authorization Code with PKCE
+            url: /flows/call-your-api-using-the-authorization-code-flow-with-pkce
+          - title: Client Credentials
+            url: /flows/call-your-api-using-the-client-credentials-flow
+          - title: Device Authorization
+            url: /flows/call-your-api-using-the-device-authorization-flow
+          - title: Hybrid
+            url: /flows/call-api-hybrid-flow
             hidden: true
-
-          - title: "Pre-User Registration"
-            url: "/hooks/extensibility-points/pre-user-registration"
-            hidden: true
-
-          - title: "Post-User Registration"
-            url: "/hooks/extensibility-points/post-user-registration"
-            hidden: true
-
-      - title: "Using the Auth0 CLI"
-        url: "/hooks/cli"
+      - title: Role-based Access Control (RBAC)
+        url: /authorization/rbac
+      - title: Authorization Policies
+        url: /authorization/authorization-policies
+      - title: Rules for Authorization Policies
+        url: /authorization/rules-for-authorization-policies
+      - title: Sample Use Cases - RBAC
+        url: /authorization/sample-use-cases-role-based-access-control
+      - title: Sample Use Cases - Rules
+        url: /authorization/sample-use-cases-rules-with-authorization
+      - title: Authz Core vs. Authz Extension
+        url: /authorization/authorization-core-vs-authorization-extension
+      - title: How to Configure Core RBAC
+        url: /authorization/how-to-use-auth0s-core-authorization-feature-set
         children:
-
-          - title: "Create/Delete Hooks"
-            url: "/hooks/cli/create-delete"
-            hidden: true
-
-          - title: "Edit Hooks"
-            url: "/hooks/cli/edit"
-            hidden: true
-
-          - title: "Enable/Disable Hooks"
-            url: "/hooks/cli/enable-disable"
-            hidden: true
-
-          - title: "Hooks Logs"
-            url: "/hooks/cli/logs"
+          - title: Manage Roles
+            url: /authorization/rbac/roles
+          - title: Manage RBAC Users
+            url: /authorization/rbac-users
+          - title: Manage RBAC Permissions
+            url: /authorization/manage-permissions
+          - title: Enable RBAC for APIs
+            url: /authorization/rbac/enable-role-based-access-control-for-apis
+      - title: Protocols
+        url: /protocols
+        children: 
+          - title: OAuth0 2.0 Authorization Framework
+            url: /protocols/protocol-oauth2
+            hidden: true 
+          - title: OpenID Connect Protocol
+            url: /protocols/openid-connect-protocol
+            hidden: true 
+          - title: WS-Federation 
+            url: /protocols/configure-ws-fed-applications
+            hidden: true 
+  - title: Configure
+    url: /config
+    children:
+      - title: Tenants
+        url: /config/tenant-settings
+        children:
+          - title: Signing Keys
+            url: /config/tenant-settings/signing-keys
+            children:
+              - title: Rotate Signing Keys
+                url: /config/tenant-settings/signing-keys/rotate-signing-keys
+                hidden: true
+              - title: Revoke Signing Keys
+                url: /config/tenant-settings/signing-keys/revoke-signing-keys
+                hidden: true
+              - title: View Signing Certificates
+                url: /config/tenant-settings/signing-keys/view-signing-certificates
+                hidden: true
+          - title: Device User Codes
+            url: /config/tenant-settings/configure-device-user-code-settings
+      - title: Applications
+        url: /applications
+        children:
+          - title: Application Settings
+            url: /applications/application-settings
+          - title: Update Grant Types
+            url: /applications/update-grant-types
+          - title: Android App Links
+            url: /applications/enable-android-app-links-support
+          - title: Apple Universal Links
+            url: /applications/enable-universal-links-support-in-apple-xcode
+          - title: Check Confidential or Public
+            url: /applications/view-application-type
+          - title: Rotate Client Secrets
+            url: /applications/rotate-client-secret
+          - title: Change Application Signing Algorithms
+            url: /applications/change-application-signing-algorithms
+          - title: Subdomain URL Placeholders
+            url: /applications/wildcards-for-subdomains
+          - title: Configure Application Metadata
+            url: /applications/configure-application-metadata
+          - title: Remove Applications
+            url: /applications/remove-applications
+          - title: Dynamic Application Registration
+            url: /applications/dynamic-client-registration
+          - title: Test Applications Locally
+            url: /applications/work-with-auth0-locally
+      - title: APIs
+        url: /config/api-settings 
+        children:
+          - title: Signing Algorithms
+            url: /tokens/signing-algorithms
+          - title: Add API Permissions
+            url: /config/api-settings/add-api-permissions
+          - title: Delete API Permissions
+            url: /config/api-settings/delete-api-permissions
+          - title: Configure Logical API for Multiple APIs
+            url: /authorization/set-logical-api
+      - title: Single Sign-On
+        url: /sso
+        children:
+          - title: Inbound SSO
+            url: /sso/inbound-single-sign-on
+          - title: Outbound SSO
+            url: /sso/outbound-single-sign-on
+          - title: Relevant API Endpoints
+            url: /sso/api-endpoints-for-single-sign-on
+          - title: Single Sign-On with Auth0
+            url: /sso/current/sso-auth0
             hidden: true
-
-      - title: "Using the Dashboard"
-        url: "/hooks/dashboard"
+      - title: Attack Protection
+        url: /attack-protection
+        children:
+          - title: Bot Detection
+            url: /attack-protection/bot-detection
+            children:
+              - title: Custom Login Pages
+                url: /attack-protection/bot-detection/bot-detection-custom-login-pages
+                hidden: true
+              - title: Native Applications
+                url: /attack-protection/bot-detection/bot-detection-native-apps
+                hidden: true 
+              - title: Google reCAPTCHA Enterprise
+                url: /attack-protection/bot-detection/configure-recaptcha-enterprise
+                hidden: true 
+          - title: Breached Passwords
+            url: /attack-protection/breached-password-detection
+          - title: Brute Force Attacks
+            url: /attack-protection/brute-force-protection
+          - title: Suspicious IP Throttling
+            url: /attack-protection/suspicious-ip-throttling
+          - title: Customize Blocked Account Emails
+            url: /attack-protection/customize-blocked-account-emails
+          - title: View Events
+            url: /attack-protection/view-attack-protection-events
+      - title: SAML Configuration Options
+        url: /protocols/saml-protocol
+        children:
+          - title: SAML SSO Integrations
+            url: /protocols/saml-protocol/saml-sso-integrations
+          - title: Auth0 as SP
+            url: /protocols/saml-protocol/configure-auth0-saml-service-provider
+          - title: Auth0 as IdP
+            url: /protocols/saml-protocol/configure-auth0-as-saml-identity-provider
+          - title: Test SAML SSO
+            url: /protocols/saml-protocol/configure-auth0-as-service-and-identity-provider
+          - title: IdP Settings
+            url: /protocols/saml-protocol/saml-identity-provider-configuration-settings
+          - title: Special Scenarios
+            url: /protocols/saml-protocol/special-saml-configuration-scenarios
+            children:
+              - title: Identity Provider-Initiated SSO
+                url: /protocols/saml-protocols/saml-configuration-options/identity-provider-initiated-single-sign-on
+                hidden: true
+              - title: Sign and Encrypt SAML Requests
+                url: /protocols/saml-protocols/saml-configuration-options/sign-and-encrypt-saml-requests
+                hidden: true
+          - title: Customize SAML Assertions
+            url: /protocols/saml-protocol/customize-saml-assertions
+          - title: Deprovision Users
+            url: /protocols/saml-protocol/deprovision-users-in-saml-integrations
+  - title: Manage Users
+    url: /users
+    children:
+      - title: User Profiles
+        url: /users/user-profiles
+        children:
+          - title: Normalized User Profile
+            url: /users/normalized-user-profiles
+          - title: Update Profiles Using Your Database
+            url: /users/update-user-profiles-using-your-database
+          - title: Progressive Profiling
+            url: /users/progressive-profiling
+          - title: User Profile Structure
+            url: /users/user-profile-structure
+      - title: Metadata
+        url: /users/metadata
+        children:
+          - title: Manage with Rules
+            url: /users/metadata/manage-metadata-rules
+          - title: Manage with Management API
+            url: /users/metadata/manage-metadata-api
+          - title: Manage with Lock
+            url: /users/metadata/manage-metadata-lock
+          - title: Field Names and Data Types
+            url: /users/metadata/metadata-fields-data
+      - title: Sessions
+        url: /sessions
+        children:
+          - title: Session Layers
+            url: /sessions/session-layers
+          - title: Session Lifetime Limits
+            url: /sessions/session-lifetime-limits
+          - title: Configure Session Lifetime Settings
+            url: /sessions/configure-session-lifetime-settings
+          - title: Non-Persistent Sessions
+            url: /sessions/non-persistent-sessions
+          - title: Manage Multi-Site Sessions with Auth0 SDK
+            url: /sessions/manage-multi-site-sessions
+          - title: Authentication API Cookies
+            url: /sessions/cookies/authentication-api-cookies
+      - title: Deny Access to an API Using Rules
+        url: /users/deny-api-access
+      - title: Using the Dashboard
+        url: /users/manage-users-using-the-dashboard
+      - title: Using the API
+        url: /users/manage-users-using-the-management-api
+      - title: Verify Emails
+        url: /users/verify-emails
+      - title: Email Verified Usage
+        url: /users/verified-email-usage
+      - title: Link User Accounts
+        url: /users/user-account-linking
+        children:
+          - title: Link User Accounts
+            url: /users/link-user-accounts
+          - title: Unlink User Accounts
+            url: /users/unlink-user-accounts
+          - title: Client-Side SPA Scenario
+            url: /users/user-initiated-account-linking-client-side-implementation
+          - title: Server-Side Regular Web App Scenario
+            url: /users/suggested-account-linking-server-side-implementation
+      - title: Import & Export Users
+        url: /users/import-and-export-users
         children:
-
-          - title: "Create or Delete Hooks"
-            url: "/hooks/dashboard/create-delete"
+          - title: File Schema
+            url: /users/bulk-user-import-database-schema-and-examples
+          - title: Automatic
+            url: /users/configure-automatic-migration-from-your-database
+          - title: Bulk Import
+            url: /users/bulk-user-imports
+          - title: Bulk Export
+            url: /users/bulk-user-exports
+          - title: User Import/Export Extension
+            url: /extensions/user-import-export-extension
+          - title: Examples
+            url: /users/user-migration-scenarios
+      - title: User Search
+        url: /users/user-search
+        children:
+          - title: Get Users
+            url: /users/user-search/retrieve-users-with-get-users-endpoint
+          - title: Get Users by Email
+            url: /users/user-search/retrieve-users-with-get-users-by-email-endpoint
+          - title: Get Users by ID
+            url: /users/user-search/retrieve-users-with-get-users-by-id-endpoint
+          - title: Sort Search Results
+            url: /users/user-search/sort-search-results
+          - title: View Search Results
+            url: /users/user-search/view-search-results-by-page
+          - title: Query Syntax
+            url: /users/user-search/user-search-query-syntax
+          - title: Migrate from Search v2 to V3
+            url: /users/search/v3/migrate-search-v2-v3
             hidden: true
-
-          - title: "Edit Hooks"
-            url: "/hooks/dashboard/edit"
+  - title: Dashboard Access
+    url: /dashboard-access
+    children:
+      - title: Dashboard Access by Role
+        url: /dashboard-access/feature-access-by-role
+      - title: Add Tenant Members
+        url: /dashboard-access/add-dashboard-users
+      - title: Edit Tenant Members
+        url: /dashboard-access/edit-dashboard-users
+      - title: Remove Tenant Members
+        url: /dashboard-access/remove-dashboard-users
+      - title: MFA for Dashboard Users
+        url: /dashboard-access/add-change-remove-mfa
+        children:
+          - title: Add MFA for Dashboard Access
+            url: /dashboard-access/add-change-remove-mfa/add-multi-factor-authentication-for-auth0-dashboard-access
+          - title: Remove/Change Dashboard MFA
+            url: /dashboard-access/add-change-remove-mfa/remove-or-change-dashboard-multi-factor-authentication
+      - title: Update Dashboard User Email
+        url: /dashboard-access/update-dashboard-user-email
+  - title: Brand and Customize
+    url: /brand-and-customize
+    children:
+      - title: Login Pages
+        url: /universal-login/new-experience/universal-login-page-templates
+      - title: Custom Domains
+        url: /custom-domains
+        children:
+          - title: Auth0-Managed Certificates
+            url: /custom-domains/configure-custom-domains-with-auth0-managed-certificates
+          - title: Self-Managed Certificates
+            url: /custom-domains/configure-custom-domains-with-self-managed-certificates
+            children:
+              - title: Google Cloud Platform Reverse Proxy
+                url: /custom-domains/configure-custom-domains-with-self-managed-certificates/configure-gcp-as-reverse-proxy
+              - title: Cloudflare Reverse Proxy
+                url: /custom-domains/configure-custom-domains-with-self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy
+              - title: Cloudfront Reverse Proxy
+                url: /custom-domains/configure-custom-domains-with-self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy
+              - title: Azure CDN Reverse Proxy
+                url: /custom-domains/configure-custom-domains-with-self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy
+              - title: Akamai Reverse Proxy
+                url: /custom-domains/configure-custom-domains-with-self-managed-certificates/configure-akamai-for-use-as-reverse-proxy
+              - title: TLS (SSL) Versions and Ciphers
+                url: /custom-domains/tls-ssl
+          - title: Configure Auth0 Features
+            url: /custom-domains/configure-features-to-use-custom-domains
+          - title: Troubleshoot Custom Domains
+            url: /custom-domains/troubleshoot-custom-domains
+      - title: Emails
+        url: /email
+        children:
+          - title: Email Handling
+            url: /email/manage-email-flow
+          - title: Email Templates
+            url: /email/customize-email-templates
+            children:
+              - title: Liquid Syntax
+                url: /email/customize-email-templates/use-liquid-syntax-in-email-templates
+              - title: Template Descriptions
+                url: /email/customize-email-templates/email-template-descriptions
+          - title: External SMTP Email Providers
+            url: /email/configure-external-smtp-email-providers
+          - title: Custom SMTP Email Provider
+            url: /email/configure-custom-external-smtp-email-provider
+          - title: Test SMTP Email Server
+            url: /email/configure-test-smtp-email-servers
+          - title: Send Email Invitations for Application Signup
+            url: /email/send-email-invitations-for-application-signup
+      - title: Consent Prompts
+        url: /scopes/customize-consent-prompts
+      - title: Internationalization and Localization
+        url: /i18n
+        children:
+          - title: Universal Login Internationalization
+            url: /i18n/universal-login-internationalization
             hidden: true
-
-          - title: "Enable or Disable Hooks"
-            url: "/hooks/dashboard/enable-disable"
+          - title: Customize Translation of Lock Password Options
+            url: /i18n/password-options-translation
             hidden: true
-
-  - title: "Email"
-    url: "/email"
+  - title: Actions
+    url: /actions 
     children:
-      - title: "Overview"
-        url: "/email"
-
-      - title: "Custom Email Handling"
-        url: "/email/custom"
-
-      - title: "Customizing Your Emails"
-        url: "/email/templates"
-
-      - title: "Use your own SMTP Email Provider"
-        url: "/email/providers"
-
-      - title: "Liquid Syntax in Email Templates"
-        url: "/email/liquid-syntax"
-
-      - title: "Set up a Test SMTP Provider"
-        url: "/email/testing"
-
-  - title: "Password Policies"
-    url: "/connections/database/password-options"
+      - title: How Auth0 Actions Work 
+        url: /actions/actions-overview
+      - title: Write Your First Action
+        url: /actions/write-your-first-action
+      - title: Triggers
+        url: /actions/triggers
+        children:
+          - title: post-login
+            url: /actions/triggers/post-login
+            children:
+              - title: Manage user metadata in post-login
+                url: /actions/triggers/post-login/manage-user-metadata
+                hidden: true
+              - title: Redirect with Actions
+                url: /actions/triggers/post-login/redirect-with-actions
+                hidden: true
+          - title: credentials-exchange
+            url: /actions/triggers/credentials-exchange
+          - title: pre-user-registration
+            url: /actions/triggers/pre-user-registration
+          - title: post-user-registration
+            url: /actions/triggers/post-user-registration
+          - title: post-change-password
+            url: /actions/triggers/post-change-password
+          - title: send-phone-message
+            url: /actions/triggers/send-phone-message
+      - title: Limitations
+        url: /actions/limitations
+      - title: Manage Action Versions
+        url: /actions/manage-action-versions
+      - title: Programming Model Changes
+        url: /actions/programming-model-changes
+  - title: Rules
+    url: /rules
     children:
-      - title: "Password Options"
-        url: "/connections/database/password-options"
-
-      - title: "Password Strength"
-        url: "/connections/database/password-strength"
-
-  - title: "User Management"
-    url: "/users"
+      - title: Rule Use Cases
+        url: /rules/use-cases
+      - title: Create Rules
+        url: /rules/create-rules
+      - title: Store Rule Configurations
+        url: /rules/configuration
+      - title: Cache Expensive Resources
+        url: /rules/cache-resources
+      - title: Management API in Rules
+        url: /rules/use-management-api
+      - title: Manage Metadata with Rules
+        url: /users/metadata/manage-metadata-rules
+      - title: Redirect Users from Rules
+        url: /rules/redirect-users
+      - title: Raise Errors from Rules
+        url: /rules/raise-errors-from-rules
+      - title: Export Log Events with Rules
+        url: /logs/export-log-events-with-rules
+      - title: User Object Properties
+        url: /rules/user-object-in-rules
+      - title: Context Object Properties
+        url: /rules/context-object
+      - title: Debug Rules
+        url: /rules/debug-rules
+  - title: Hooks
+    url: /hooks
     children:
-      - title: "User Profile"
-        url: "/user-profile"
+      - title: Create Hooks
+        url: /hooks/create-hooks
+      - title: Update Hooks
+        url: /hooks/update-hooks
+      - title: Delete Hooks
+        url: /hooks/delete-hooks
+      - title: Enable/Disable Hooks
+        url: /hooks/enable-disable-hooks
+      - title: View Hooks
+        url: /hooks/view-hooks
+      - title: View Logs for Hooks
+        url: /hooks/view-logs-for-hooks
+      - title: Extensibility Points
+        url: /hooks/extensibility-points
         children:
-          - title: "Structure"
-            url: "/user-profile/user-profile-structure"
-
-          - title: "Details"
-            url: "/user-profile/user-profile-details"
-
-          - title: "Normalized User Profile"
-            url: "/user-profile/normalized/auth0"
-
-          - title: "Picture"
-            url: "/user-profile/user-picture"
-
-      - title: "User Search"
-        url: "/users/search/v3"
+          - title: Client Credentials Exchange
+            url: /hooks/extensibility-points/client-credentials-exchange
+          - title: Post-Change Password
+            url: /hooks/extensibility-points/post-change-password
+          - title: Post-User Registration
+            url: /hooks/extensibility-points/post-user-registration
+          - title: Pre-User Registration
+            url: /hooks/extensibility-points/pre-user-registration
+          - title: Send Phone Message
+            url: /hooks/extensibility-points/send-phone-message
+      - title: Hook Secrets
+        url: /hooks/hook-secrets
         children:
-          - title: "Query Syntax"
-            url: "/users/search/v3/query-syntax"
-
-          - title: "Best Practices"
-            url: "/users/search/best-practices"
-
-      - title: "User Search"
-        url: "/users/search/v2"
+          - title: Create Secrets
+            url: /hooks/hook-secrets/create-hook-secrets
+          - title: Update Secrets
+            url: /hooks/hook-secrets/update-hook-secrets
+          - title: Delete Secrets
+            url: /hooks/hook-secrets/delete-hook-secrets
+          - title: View Secrets
+            url: /hooks/hook-secrets/view-hook-secrets
+  - title: Extensions
+    url: /extensions
+    children:
+      - title: Authorization Extension
+        url: /extensions/authorization-extension
+      - title: Delegated Administration
+        url: /extensions/delegated-administration-extension
+      - title: Custom Social Connections
+        url: /extensions/custom-social-connections
         hidden: true
-        children:
-          - title: "Query Syntax"
-            url: "/users/search/v2/query-syntax"
+      - title: SSO Dashboard Extension
+        url: /extensions/single-sign-on-dashboard-extension
+      - title: Authentication API Webhooks
+        url: /extensions/auth0-authentication-api-webhooks
+      - title: Management API Webhooks
+        url: /extensions/auth0-management-api-webhooks
+      - title: Authentication API Debugger
+        url: /extensions/authentication-api-debugger-extension
+      - title: AD/LDAP Connector Health Monitor
+        url: /extensions/ad-ldap-connector-health-monitor
+      - title: Real-time Webtask Logs
+        url: /extensions/real-time-webtask-logs
+      - title: Log Export Extensions 
+        url: /extensions/log-export-extensions
+        children: 
+          - title: Auth0 Logs to Application Insights
+            url: /extensions/export-logs-to-application-insights
             hidden: true
-
-          - title: "Best Practices"
-            url: "/users/search/best-practices"
+          - title: Auth0 Logs to AWS Cloudwatch
+            url: /extensions/export-logs-to-cloudwatch
             hidden: true
-
-      - title: "User Metadata"
-        url: "/metadata"
-
-      - title: "User Impersonation"
-        url: "/user-profile/user-impersonation"
-
-      - title: "Delegated Administration"
-        url: "/extensions/delegated-admin"
-
-      - title: "Authorization Extension"
-        url: "/extensions/authorization-extension/v2"
-        children:
-
-          - title: "Installation"
-            url: "/extensions/authorization-extension/v2/implementation/installation"
+          - title: Auth0 Logs to Azure Blob Storage
+            url: /extensions/export-logs-to-azure-blob-storage
             hidden: true
-          
-          - title: "Setup"
-            url: "/extensions/authorization-extension/v2/implementation/setup"
+          - title: Auth0 Logs to Logentries
+            url: /extensions/export-logs-to-logentries
             hidden: true
-
-          - title: "Configuration"
-            url: "/extensions/authorization-extension/v2/implementation/configuration"
+          - title: Auth0 Logs to Loggly
+            url: /extensions/export-logs-to-loggly
             hidden: true
-          
-          - title: "API Access"
-            url: "/extensions/authorization-extension/v2/api-access"
+          - title: Auth0 Logs to Logstash
+            url: /extensions/export-logs-to-logstash
             hidden: true
-
-          - title: "Rules"
-            url: "/extensions/authorization-extension/v2/rules"
+          - title: Auth0 Logs to Mixpanel
+            url: /extensions/export-logs-to-mixpanel
             hidden: true
-
-          - title: "Troubleshooting"
-            url: "/extensions/authorization-extension/v2/troubleshooting"
+          - title: Auth0 Logs to Papertrail
+            url: /extensions/export-logs-to-papertrail
             hidden: true
-
-          - title: "Import / Export Data"
-            url: "/extensions/authorization-extension/v2/import-export-data"
+          - title: Auth0 Logs to Sumo Logic
+            url: /extensions/auth0-logs-to-sumo-logic
             hidden: true
-
-      - title: "Progressive Profiling"
-        url: "/user-profile/progressive-profiling"
-
-      - title: "Data Storage"
-        url: "/user-profile/user-data-storage"
-
-      - title: "User Migration"
-        url: "/users/migrations"
-        children:
-          - title: "Automatic Migration"
-            url: "/users/migrations/automatic"
-
-          - title: "Bulk Migration"
-            url: "/users/migrations/bulk-import"
-
-          - title: "User Import/Export Extension"
-            url: "/extensions/user-import-export"
-
-          - title: "Gigya"
-            url: "/users/migrations/gigya"
-
-          - title: "Okta"
-            url: "/users/migrations/okta"
-
-          - title: "Stormpath"
-            url: "/users/migrations/stormpath"
-
-          - title: "Azure Access Control"
-            url: "/users/migrations/azure-access-control"
+          - title: Auth0 Logs to Splunk
+            url: /extensions/export-logs-to-splunk
             hidden: true
-
-  - title: "Multifactor Authentication"
-    url: "/multifactor-authentication"
+  - title: Integrations
+    url: /integrations
     children:
-      - title: "Overview"
-        url: "/multifactor-authentication"
-
-      - title: "Guardian"
-        url: "/multifactor-authentication/guardian"
-        children:
-          - title: "For Administrators"
-            url: "/multifactor-authentication/administrator"
-
-          - title: "For Developers"
-            url: "/multifactor-authentication/developer"
-
-          - title: "For Users"
-            url: "/multifactor-authentication/guardian/user-guide"
-
-      - title: "Google Authenticator"
-        url: "/multifactor-authentication/google-authenticator"
+      - title: Amazon Web Services (AWS)
+        url: /integrations/aws
+      - title: AWS API Gateway
+        url: /integrations/aws-api-gateway-custom-authorizers
+      - title: Azure API Management
+        url: /integrations/azure-api-management
+      - title: Google Cloud Endpoints
+        url: /integrations/google-cloud-endpoints
+      - title: Single Sign-On
+        url: /integrations/sso
+      - title: Marketing
+        url: /integrations/marketing
         children:
-          - title: "For Administrators"
-            url: "/multifactor-authentication/google-auth/admin-guide"
-
-          - title: "For Developers"
-            url: "/multifactor-authentication/google-auth/dev-guide"
-
-          - title: "For Users"
-            url: "/multifactor-authentication/google-auth/user-guide"
-
-      - title: "Duo Security"
-        url: "/multifactor-authentication/duo"
-        children:
-          - title: "For Administrators"
-            url: "/multifactor-authentication/duo/admin-guide"
-
-          - title: "For Developers"
-            url: "/multifactor-authentication/duo/dev-guide"
-
-          - title: "For Users"
-            url: "/multifactor-authentication/duo/user-guide"
-
-      - title: "Custom MFA"
-        url: "/multifactor-authentication/custom"
-
-      - title: "Yubikey NEO Example"
-        url: "/multifactor-authentication/yubikey"
-        
-      - title: "Step-up Authentication"
-        url: "/multifactor-authentication/developer/step-up-authentication"
+          - title: Adobe Campaign
+            url: /integrations/marketing/adobe-campaign
+          - title: Alterian
+            url: /integrations/marketing/alterian
+          - title: Constant Contact
+            url: /integrations/marketing/constant-contact
+          - title: Oracle Eloqua
+            url: /integrations/marketing/eloqua
+          - title: MailChimp
+            url: /integrations/marketing/mailchimp
+          - title: Marketo
+            url: /integrations/marketing/marketo
+          - title: Sailthru
+            url: /integrations/marketing/sailthru
+          - title: Salesforce
+            url: /integrations/marketing/export-user-data-salesforce
+          - title: Salesforce Marketing Cloud
+            url: /integrations/marketing/salesforce-marketing-cloud
+          - title: Watson Campaign Automation
+            url: /integrations/marketing/watson-campaign-automation
+  - title: Monitor
+    url: /monitor-auth0
+    children:
+      - title: Check Auth0 Status
+        url: /monitor-auth0/check-auth0-status
+      - title: Check External Services Status
+        url: /monitor-auth0/check-external-services-status
+      - title: Monitor Applications
+        url: /monitor-auth0/monitor-applications
+      - title: Monitor Using SCOM
+        url: /monitor-auth0/monitor-using-scom
+      - title: Logs
+        url: /logs
         children:
-          - title: "Step-up Authentication for Web Apps"
-            url: "/multifactor-authentication/developer/step-up-authentication/step-up-for-web-apps"
-            hidden: true
-          
-          - title: "Step-up Authentication for APIs"
-            url: "/multifactor-authentication/developer/step-up-authentication/step-up-for-apis"
+          - title: PII in Logs
+            url: /logs/pii-in-logs
+          - title: Log Data Retention
+            url: /logs/log-data-retention
+          - title: View Log Events
+            url: /logs/view-log-events
+          - title: Retrieve Log Events
+            url: /logs/retrieve-log-events-using-mgmt-api
+          - title: Log Event Filters
+            url: /logs/log-event-filters
+          - title: Log Event Type Codes
+            url: /logs/log-event-type-codes
+          - title: Log Search Query Syntax
+            url: /logs/log-search-query-syntax
+            children:
+              - title: Migrate to Tenant Log Search v3
+                url: /product-lifecycle/deprecations-and-migrations/migrate-to-tenant-log-search-v3
+                hidden: true
+          - title: Export Log Events with Extensions
+            url: /logs/export-log-events-with-extensions
+          - title: Export Log Events with Rules
+            url: /logs/export-log-events-with-rules
             hidden: true
-
-      - title: "API"
-        url: "/multifactor-authentication/api"
-        hidden: true
+      - title: Streams
+        url: /monitor-auth0/streams
         children:
-          - title: "Manual Challenge"
-            url: "/multifactor-authentication/api/challenges"
+          - title: AWS EventBridge
+            url: /monitor-auth0/streams/stream-logs-to-amazon-eventbridge
             hidden: true
-          - title: "One-Time Password Challenge"
-            url: "/multifactor-authentication/api/otp"
+          - title: Azure Event Grid
+            url: /monitor-auth0/streams/stream-logs-to-azure-event-grid
             hidden: true
-          - title: "SMS Message Challenge"
-            url: "/multifactor-authentication/api/oob"
+          - title: Datadog
+            url: /monitor-auth0/streams/stream-logs-to-datadog
             hidden: true
-          - title: "Manage Authenticators"
-            url: "/multifactor-authentication/api/manage"
+            children:
+              - title: Datadog Dashboard Templates
+                url: /monitor-auth0/streams/datadog-dashboard-templates
+                hidden: true
+          - title: Splunk
+            url: /monitor-auth0/streams/stream-logs-to-splunk
             hidden: true
-          - title: "FAQ"
-            url: "/multifactor-authentication/api/faq"
+            children:
+              - title: Auth0 App for Splunk
+                url: /monitor-auth0/streams/splunk-dashboard
+                hidden: true
+          - title: Sumo Logic
+            url: /monitor-auth0/streams/stream-logs-to-sumo-logic
             hidden: true
-
-  - title: "Security"
-    url: "/security"
+            children:
+              - title: Auth0 App for Sumo Logic
+                url: /monitor-auth0/streams/sumo-logic-dashboard
+                hidden: true
+          - title: Create Custom Log Streams
+            url: /monitor-auth0/streams/custom-log-streams
+            children:
+            - title: Stream Logs to Slack Using Webhooks
+              url: /monitor-auth0/streams/stream-log-events-to-slack
+              hidden: true
+          - title: Check Log Stream Health
+            url: /monitor-auth0/streams/check-log-stream-health
+          - title: Log Stream Filters
+            url: /monitor-auth0/streams/event-filters
+  - title: Troubleshoot
+    url: /troubleshoot
     children:
-
-      - title: "Bulletins"
-        url: "/security/bulletins"
+      - title: Basic Issues
+        url: /troubleshoot/troubleshoot-basic
         children:
-          - title: "CVE 2018-6874"
-            url: "/security/bulletins/cve-2018-6874"
-            hidden: true
-            
-          - title: "CVE 2018-6873"
-            url: "/security/bulletins/cve-2018-6873"
-            hidden: true
-            
-          - title: "CVE 2018-7307"
-            url: "/security/bulletins/cve-2018-7307"
-            hidden: true
-            
-          - title: "CVE 2017-16897"
-            url: "/security/bulletins/cve-2017-16897"
-            hidden: true
-            
-          - title: "CVE 2017-17068"
-            url: "/security/bulletins/cve-2017-17068"
-            hidden: true
-      - title: "Where to Store Tokens"
-        url: "/security/store-tokens"
-        hidden: true
-      
-      - title: "Common Threats"
-        url: "/security/common-threats"
-        hidden: true
-      
-      - title: "Blacklist User Attributes"
-        url: "/security/blacklisting-attributes"
-        hidden: true
-
-  - title: "Anomaly Detection"
-    url: "/anomaly-detection"
-    children:
-
-      - title: "Overview"
-        url: "/anomaly-detection"
-
-      - title: "Breached Passwords"
-        url: "/anomaly-detection/breached-passwords"
-
-  - title: "Analytics"
-    url: "/analytics/integrations"
+          - title: Verify Platform
+            url: /troubleshoot/troubleshoot-basic/verify-platform
+          - title: Verify Connections
+            url: /troubleshoot/troubleshoot-basic/verify-connections
+          - title: Verify Domain
+            url: /troubleshoot/troubleshoot-basic/verify-domain
+          - title: Verify Rules
+            url: /troubleshoot/troubleshoot-basic/verify-rules
+          - title: Check Error Messages
+            url: /troubleshoot/troubleshoot-basic/check-error-messages
+          - title: Invalid Token Errors
+            url: /troubleshoot/troubleshoot-basic/invalid-token-errors
+          - title: Deprecation Errors
+            url: /troubleshoot/troubleshoot-basic/check-deprecation-errors
+      - title: Authentication Issues
+        url: /troubleshoot/troubleshoot-authentication
+        children:
+          - title: API Calls
+            url: /troubleshoot/troubleshoot-authentication/check-api-calls
+          - title: Login and Logout Issues
+            url: /troubleshoot/troubleshoot-authentication/check-login-and-logout-issues
+          - title: User Profiles
+            url: /troubleshoot/troubleshoot-authentication/check-user-profiles
+          - title: RBAC and Authorization
+            url: /troubleshoot/troubleshoot-authentication/troubleshoot-rbac-authorization
+          - title: MFA Issues
+            url: /mfa/troubleshoot-mfa-issues
+          - title: SAML Configurations
+            url: /troubleshoot/troubleshoot-authentication/troubleshoot-saml-configurations
+          - title: SAML Errors
+            url: /troubleshoot/troubleshoot-authentication/saml-errors
+          - title: Self Change Password Errors
+            url: /troubleshoot/troubleshoot-authentication/self-change-password-errors
+          - title: Authorization Extension Issues
+            url: /extensions/authorization-extension/troubleshoot-authorization-extension
+      - title: Integration and Extensibility Issues
+        url: /troubleshoot/troubleshoot-integration-and-extensibility
+        children:
+          - title: Test Partner Connections
+            url: /connections/how-to-test-partner-connection
+          - title: Sign in With Apple
+            url: /connections/apple-siwa/troubleshooting
+          - title: Custom Databases
+            url: /connections/database/custom-db/error-handling
+          - title: Active Directory/LDAP Connector
+            url: /extensions/ad-ldap-connector
+          - title: Extensions
+            url: /extensions/troubleshoot-extensions
+          - title: Auth0 PHP SDK
+            url: /libraries/auth0-php/troubleshoot-auth0-php-library
+      - title: Tools
+        url: /troubleshoot/tools
+        children:
+          - title: Generate and Analyze HAR Files
+            url: /troubleshoot/tools/generate-and-analyze-har-files
+          - title: Authentication API Debugger
+            url: /extensions/authentication-api-debugger-extension
+  - title: Product Lifecycle
+    url: /product-lifecycle
     children:
-
-      - title: "Facebook Analytics"
-        url: "/analytics/integrations/facebook-analytics"
-
-      - title: "Google Analytics"
-        url: "/analytics/integrations/google-analytics"
-
-  - title: "Integrations"
-    url: "/integrations"
+      - title: Product Release Stages
+        url: /product-lifecycle/product-release-stages
+      - title: Deprecations and Migrations
+        url: /product-lifecycle/deprecations-and-migrations
+      - title: Migration Process
+        url: /product-lifecycle/migration-process
+      - title: Past Migrations
+        url: /product-lifecycle/deprecations-and-migrations/past-migrations
+  - title: Security
+    url: /security
     children:
-
-      - title: "Marketing"
-        url: "/integrations/marketing"
-        children:
-
-          - title: "Adobe Campaign"
-            url: "/integrations/marketing/adobe-campaign"
-
-          - title: "Alterian"
-            url: "/integrations/marketing/alterian"
-
-          - title: "Constant Contact"
-            url: "/integrations/marketing/constant-contact"
-
-          - title: "Oracle Eloqua"
-            url: "/integrations/marketing/eloqua"
-
-          - title: "MailChimp"
-            url: "/integrations/marketing/mailchimp"
-
-          - title: "Marketo"
-            url: "/integrations/marketing/marketo"
-
-          - title: "Sailthru"
-            url: "/integrations/marketing/sailthru"
-
-          - title: "Salesforce"
-            url: "/integrations/marketing/salesforce"
-
-          - title: "Salesforce Marketing Cloud"
-            url: "/integrations/marketing/salesforce-marketing-cloud"
-
-          - title: "Watson Campaign Automation"
-            url: "/integrations/marketing/watson-campaign-automation"
-
-      - title: "Single Sign On"
-        url: "/integrations/sso"
+      - title: General Security Tips
+        url: /security/tips
+      - title: Security Bulletins
+        url: /security/security-bulletins
         children:
-
-          - title: "Active Directory RMS"
-            url: "/integrations/sso/ad-rms"
+          - title: CVE 2018-6874
+            url: /security/security-bulletins/cve-2018-6874
             hidden: true
-
-          - title: "Box"
-            url: "/integrations/sso/box"
+          - title: CVE 2018-6873
+            url: /security/security-bulletins/cve-2018-6873
             hidden: true
-
-          - title: "CloudBees"
-            url: "/integrations/sso/cloudbees"
+          - title: CVE 2018-7307
+            url: /security/security-bulletins/cve-2018-7307
             hidden: true
-
-          - title: "Concur"
-            url: "/integrations/sso/concur"
+          - title: CVE 2017-16897
+            url: /security/security-bulletins/cve-2017-16897
             hidden: true
-
-          - title: "Disqus"
-            url: "/integrations/sso/disqus"
+          - title: CVE 2017-17068
+            url: /security/security-bulletins/cve-2017-17068
             hidden: true
-
-          - title: "Dropbox"
-            url: "/integrations/sso/dropbox"
-            hidden: true
-
-          - title: "Microsoft Dynamics CRM"
-            url: "/integrations/sso/dynamics-crm"
+      - title: Data Security
+        url: /security/data-security
+        children:
+          - title: Add User Attributes to Deny List
+            url: /security/data-security/denylist
+          - title: Auth0 IP Addresses for Allow Lists
+            url: /security/data-security/allowlist
+          - title: User Data Storage
+            url: /security/data-security/user-data-storage
+          - title: Token Storage
+            url: /security/data-security/token-storage
+      - title: Prevent Common Threats
+        url: /security/prevent-threats
+      - title: Tokens
+        url: /tokens
+        children:
+          - title: ID Tokens
+            url: /tokens/id-tokens
+            children:
+              - title: Get ID Tokens
+                url: /tokens/id-tokens/get-id-tokens
+                hidden: true
+              - title: Validate ID Tokens
+                url: /tokens/id-tokens/validate-id-tokens
+                hidden: true
+              - title: ID Token Structure
+                url: /tokens/id-tokens/id-token-structure
+                hidden: true
+          - title: Access Tokens
+            url: /tokens/access-tokens
+            children:
+              - title: IDP Access Tokens
+                url: /tokens/identity-provider-access-tokens
+                hidden: true
+              - title: Get Access Tokens
+                url: /tokens/access-tokens/get-access-tokens
+                hidden: true
+              - title: Use Access Tokens
+                url: /tokens/access-tokens/use-access-tokens
+                hidden: true
+              - title: Validate Access Tokens
+                url: /tokens/access-tokens/validate-access-tokens
+                hidden: true
+          - title: Refresh Tokens
+            url: /tokens/refresh-tokens
+            children:
+              - title: Get Refresh Tokens
+                url: /tokens/refresh-tokens/get-refresh-tokens
+                hidden: true
+              - title: Use Refresh Tokens
+                url: /tokens/refresh-tokens/use-refresh-tokens
+                hidden: true
+              - title: Revoke Refresh Tokens
+                url: /tokens/refresh-tokens/revoke-refresh-tokens
+                hidden: true
+          - title: Refresh Token Rotation
+            url: /tokens/refresh-tokens/refresh-token-rotation
+            children:
+              - title: Configure Refresh Token Rotation
+                url: /tokens/refresh-tokens/configure-refresh-token-rotation
+                hidden: true
+              - title: Use Refresh Token Rotation
+                url: /tokens/refresh-tokens/refresh-token-rotation/use-refresh-token-rotation
+                hidden: true
+              - title: Disable Refresh Token Rotation
+                url: /tokens/refresh-tokens/disable-refresh-token-rotation
+                hidden: true
+          - title: Refresh Token Expiration
+            url: /tokens/refresh-tokens/configure-refresh-token-expiration
+          - title: Delegation Tokens
+            url: /tokens/delegation-tokens
             hidden: true
-
-          - title: "EchoSign"
-            url: "/integrations/sso/echosign"
+          - title: JSON Web Tokens
+            url: /tokens/json-web-tokens
             hidden: true
-
-          - title: "Egnyte"
-            url: "/integrations/sso/egnyte"
+            children:
+              - title: Validate JSON Web Tokens
+                url: /tokens/json-web-tokens/validate-json-web-tokens
+                hidden: true
+              - title: JSON Web Key Sets
+                url: /tokens/json-web-tokens/json-web-key-sets
+                hidden: true
+                children:
+                  - title: Locate JSON Web Key Sets
+                    url: /tokens/json-web-tokens/json-web-key-sets/locate-json-web-key-sets
+                    hidden: true
+                  - title: JSON Web Key Set Properties
+                    url: /tokens/json-web-tokens/json-web-key-set-properties
+                    hidden: true
+              - title: JSON Web Token Claims
+                url: /tokens/json-web-tokens/json-web-token-claims
+                hidden: true
+                children:
+                  - title: Create Namespaced Custom Claims
+                    url: /tokens/create-namespaced-custom-claims
+                    hidden: true
+              - title: Signing Algorithms
+                hidden: true
+              - title: JSON Web Token Structure
+                url: /tokens/json-web-tokens/json-web-token-structure
+                hidden: true
+          - title: Revoke Tokens
+            url: /tokens/revoke-tokens
+      - title: Cookies
+        url: /sessions/cookies
+        children:
+          - title: Authenticate SPAs with Cookies
+            url: /sessions/cookies/spa-authenticate-with-cookies
             hidden: true
-
-          - title: "New Relic"
-            url: "/integrations/sso/new-relic"
+  - title: Data Privacy and Compliance
+    url: /compliance
+    children:
+      - title: GDPR
+        url: /compliance/gdpr
+        children:
+          - title: Conditions for Consent
+            url: /compliance/gdpr/gdpr-conditions-for-consent
             hidden: true
-
-          - title: "Microsoft Office 365"
-            url: "/integrations/sso/office-365"
+          - title: Right to Access, Correct, and Erase Data
+            url: /compliance/gdpr/gdpr-right-to-access-correct-and-erase-data
             hidden: true
-
-          - title: "Salesforce"
-            url: "/integrations/sso/salesforce"
+          - title: Data Minimization
+            url: /compliance/gdpr/gdpr-data-minimization
             hidden: true
-
-          - title: "Microsoft SharePoint"
-            url: "/integrations/sso/sharepoint"
+          - title: Data Portability
+            url: /compliance/gdpr/gdpr-data-portability
             hidden: true
-
-          - title: "Slack"
-            url: "/integrations/sso/slack"
+          - title: Protect and Secure User Data
+            url: /compliance/gdpr/gdpr-protect-and-secure-user-data
             hidden: true
-
-          - title: "SpringCM"
-            url: "/integrations/sso/springcm"
+          - title: Redirect Users to Consent Form
+            url: /compliance/gdpr/gdpr-redirect-users-consent-form-hosted-webtask
             hidden: true
-
-          - title: "Zendesk"
-            url: "/integrations/sso/zendesk"
+          - title: Track Consent with Custom UI
+            url: /compliance/gdpr/gdpr-track-consent-with-custom-ui
             hidden: true
-
-          - title: "Zoom"
-            url: "/integrations/sso/zoom"
+          - title: Track Consent with Lock
+            url: /compliance/gdpr/gdpr-track-consent-with-lock
             hidden: true
-
-  - title: "Protocols"
-    url: "/protocols"
+      - title: Data Processing
+        url: /compliance/data-processing
+  - title: Best Practices
+    url: /best-practices
     children:
-
-      - title: "OAuth 2.0"
-        url: "/protocols/oauth2"
+      - title: General Usage and Operations
+        url: /best-practices/general-usage-and-operations-best-practices
+      - title: Deployment
+        url: /best-practices/deployment-best-practices
+      - title: Performance
+        url: /best-practices/performance-best-practices
+        hidden: true 
+      - title: Debugging
+        url: /best-practices/debugging-best-practices
+        hidden: true 
+      - title: Error Handling
+        url: /best-practices/error-handling-best-practices
+      - title: Multi-Tenant Applications
+        url: /best-practices/multi-tenant-apps-best-practices
+      - title: Mobile Device Login Flow
+        url: /best-practices/mobile-device-login-flow-best-practices
+      - title: Connection Settings
+        url: /best-practices/connection-settings-best-practices
+      - title: Custom Databases and Scripts
+        url: /best-practices/custom-database-connections-scripts
         children:
-
-        - title: "The State Parameter"
-          url: "/protocols/oauth2/oauth-state"
-          hidden: true
-          
-      - title: "OpenID Connect"
-        url: "/protocols/oidc"
-
-      - title: "SAML"
-        url: "/protocols/saml"
-
-      - title: "WS-Fed"
-        url: "/protocols/ws-fed"
-        
-      - title: "LDAP"
-        url: "/protocols/ldap"
-        
-  - title: "Addons/Third-Party Apps"
-    url: "/addons"
-    children:
-
-      - title: "Overview"
-        url: "/addons"
-
-  - title: "Auth0 Migrations"
-    url: "/migrations"
+          - title: Connection Anatomy
+            url: /best-practices/custom-database-connections-scripts/anatomy
+          - title: Script Environment
+            url: /best-practices/custom-database-connections-scripts/environment
+          - title: Script Execution
+            url: /best-practices/custom-database-connections-scripts/execution
+          - title: Database Security
+            url: /best-practices/custom-database-connections-scripts/connection-security
+      - title: Passwordless Login Connections
+        url: /connections/passwordless/best-practices
+      - title: Rules
+        url: /best-practices/rules-best-practices
+        children:
+          - title: Rules Anatomy
+            url: /best-practices/rules-best-practices/rules-anatomy-best-practices
+          - title: Rules Environment
+            url: /best-practices/rules-best-practices/rules-environment-best-practices
+          - title: Rules Execution
+            url: /best-practices/rules-best-practices/rules-execution-best-practices
+          - title: Rules Security
+            url: /best-practices/rules-best-practices/rules-security-best-practices
+          - title: Rules Testing
+            url: /best-practices/rules-best-practices/rules-testing-best-practices
+      - title: Tokens
+        url: /best-practices/token-best-practices
+      - title: User Search
+        url: /best-practices/user-search-best-practices
+  - title: Support
+    url: /support
     children:
-
-      - title: "Past Migrations"
-        url: "/migrations/past-migrations"
-        hidden: true
-
-      - title: "Management API and ID Tokens"
-        url: "/migrations/guides/calling-api-with-idtokens"
-        hidden: true
-      
-      - title: "Extensibility and Node.js v8"
-        url: "/migrations/guides/extensibility-node8"
-        hidden: true
-        
-  - title: "Data Privacy"
-    url: "/compliance"
-    children:   
-      - title: "GDPR"
-        url: "/compliance/gdpr"
-        children:        
-          - title: "Terminology"
-            hidden: true
-            url: "/compliance/gdpr/definitions"
-            
-          - title: "Summary"
-            hidden: true
-            url: "/compliance/gdpr/gdpr-summary"
-             
-          - title: "Roles and Responsibilities"
-            hidden: true
-            url: "/compliance/gdpr/roles-responsibilities"
-          
-          - title: "Auth0 Data Processing"
-            hidden: true
-            url: "/compliance/gdpr/data-processing"
-
-          - title: "How Auth0 can help"
-            url: "/compliance/gdpr/features-aiding-compliance"
+      - title: Support Plans
+        url: /support/support-plans
+      - title: Support Channels
+        url: /support/support-channels
+      - title: Support Procedures
+        url: /support/support-procedures
+      - title: Support Hours and Languages
+        url: /support/support-hours-and-languages
+      - title: Whitehat Security Support Tickets
+        url: /support/whitehat-security-support-tickets
+      - title: Product Support Matrix
+        url: /support/product-support-matrix
+      - title: Service Levels
+        url: /support/sla
+      - title: Support Tickets
+        url: /support/open-and-manage-support-tickets
+      - title: Support Center Users
+        url: /support/support-center-users
+      - title: Manage Subscriptions
+        url: /support/manage-subscriptions
+      - title: Software Updates
+        url: /support/software-updates
+      - title: Operational Policies
+        url: /policies
+        children:
+          - title: Billing
+            url: /policies/billing-policy
+          - title: Data Export and Transfer
+            url: /policies/data-export-and-transfer-policy
+          - title: Endpoints
+            url: /security/public-cloud-service-endpoints
+          - title: Load Testing
+            url: /policies/load-testing-policy
+          - title: Penetration Testing
+            url: /policies/penetration-testing-policy
+          - title: Rate Limits
+            url: /policies/rate-limit-policy
             children:
-          
-              - title: "User Consent"
+              - title: Managment API Endpoint Rate Limits
+                url: /policies/rate-limit-policy/management-api-endpoint-rate-limits
                 hidden: true
-                url: "/compliance/gdpr/features-aiding-compliance/user-consent"
-                children:
-              
-                  - title: "Track Consent with Lock"
-                    hidden: true
-                    url: "/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock"
-                  
-                  - title: "Track Consent with custom UI"
-                    hidden: true
-                    url: "/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui"
-
-              - title: "Access, correct, and erase data"
+              - title: Authentication API Endpoint Rate Limits
+                url: /policies/rate-limit-policy/management-api-endpoint-rate-limits
                 hidden: true
-                url: "/compliance/gdpr/features-aiding-compliance/right-to-access-data"
-
-              - title: "Data Minimization"
+              - title: User/Password Authentication Rate Limits
+                url: /policies/rate-limit-policy/database-connections-rate-limits
                 hidden: true
-                url: "/compliance/gdpr/features-aiding-compliance/data-minimization"
-
-              - title: "Data Portability"
-                hidden: true
-                url: "/compliance/gdpr/features-aiding-compliance/data-portability"
-
-              - title: "Protect and secure user data"
-                hidden: true
-                url: "/compliance/gdpr/features-aiding-compliance/protect-user-data"
-              
-          - title: "Security Advice"
-            hidden: true
-            url: "/compliance/gdpr/security-advice-for-customers"
-      
-  - title: "Support"
-    url: "/support"
+          - title: Entity Limits
+            url: /policies/entity-limit-policy 
+      - title: Changelog
+        external: true 
+        forceFullReload: true 
+        url: 'https://auth0.com/changelog'
+  - title: Professional Services
+    url: /professional-services
     children:
-      - title: "Support Options"
-        url: "/support"
-
-      - title: "Support Matrix"
-        url: "/support/matrix"
-
-      - title: "SLA"
-        url: "/support/sla"
-
-      - title: "Tickets"
-        url: "/support/tickets"
-
-      - title: "Manage Subscription"
-        url: "/support/subscription"
-
-      - title: "Operational Policies"
-        url: "/policies"
-    
-  - title: "Pre-Deployment"
-    url: "/pre-deployment"
-    children:
-      - title: Useful Tips
-        url: /pre-deployment/prelaunch-tips
-      
-      - title: Run Tests
-        url: /pre-deployment/how-to-run-test
-
-  - title: "Professional Services"
-    url: "/services"
-    children:
-      - title: "Overview"
-        url: "/services"
-
-      - title: "Architectural Design Sessions"
-        url: "/services/architectural-design"
-      
-      - title: "Performance and Scalability"
-        url: "/services/performance-scalability"
-
-      - title: "Scenario guidance"
-        url: "/services/scenario-guidance"
-
-      - title: "Code Review"
-        url: "/services/code-review"
-
-      - title: "Pair Programming"
-        url: "/services/pair-programming"
-      
-      - title: "Private SaaS reconfiguration"
-        url: "/services/private-saas-configuration"
-
-      - title: "Auth0 Introduction"
-        url: "/services/auth0-introduction"
-
-      - title: "Auth0 Advanced Topics"
-        url: "/services/auth0-advanced"
-
-      - title: "Private SaaS Management Workshop"
-        url: "/services/private-saas-management"
-
-      - title: "Jumpstart"
-        url: "/services/jumpstart"
-
+      - title: Discover and Design
+        url: /professional-services/discover-design
+      - title: Implement
+        url: /professional-services/implement
+      - title: Maintain and Improve
+        url: /professional-services/maintain-improve
+      - title: Packages
+        url: /professional-services/packages
+  - title: Auth0 Marketplace
+    external: true
+    forceFullReload: true
+    url: 'https://marketplace.auth0.com/'
+  - title: Auth0 Community
+    external: true
+    forceFullReload: true
+    url: 'https://community.auth0.com/'
+  - title: Auth0 Blog
+    external: true
+    forceFullReload: true
+    url: 'https://auth0.com/blog/'
 apis:
-
-  - title: "Overview"
-    url: "/api/info"
-
-  - title: "Testing with Postman"
-    url: "/api/postman"
-
-  - title: Authentication API
-    url: "/api/authentication"
+  - title: overview
+    url: /api
+  - title: testingWithPostman
+    url: /api/use-auth0-apis-with-postman-collections
+    hidden: true 
+  - title: authenticationApi
+    url: /api/authentication
     external: true
     forceFullReload: true
-
-  - title: Management API
-    url: "/api/management/v2/tokens"
+  - title: changesInManagementApiV2
+    url: /api/management-api-changes-v1-to-v2
     forceFullReload: true
-    expanded: 1
-    children:
-
-      - title: API Tokens
-        url: "/api/management/v2/tokens"
-        forceFullReload: true
-        children:
-        - title: Changes
-          url: "/api/management/v2/tokens-flows"
-
-      - title: Changes in v2
-        url: "/api/management/v2/changes"
-        forceFullReload: true
-
-      - title: API Explorer
-        url: "/api/management/v2/"
-        forceFullReload: true
-        external: true
-
+    hidden: true 
+  - title: managementApiExplorer
+    url: /api/management/v2/
+    forceFullReload: true
+    external: true
+  - title: myAccountApiExplorer
+    url: /api/myaccount
+    forceFullReload: true
+    external: true
 libraries:
-
-  - title: "Overview"
-    url: "/libraries"
-
-  - title: "Lock for Web"
-    url: "/libraries/lock/v11"
+  - title: Overview
+    url: /libraries
+  - title: Auth0 Single Page App SDK
+    url: /libraries/auth0-single-page-app-sdk
     children:
-
-      - title: "Overview"
-        url: "/libraries/lock/v11"
-
-      - title: "Configuration Options"
-        url: "/libraries/lock/v11/configuration"
-
-      - title: "API Reference"
-        url: "/libraries/lock/v11/api"
-
-      - title: "UI Customization"
-        url: "/libraries/lock/v11/ui-customization"
-
-      - title: "Migration Guide"
-        url: "/libraries/lock/v11/migration-guide"
-
-      - title: "Internationalization"
-        url: "/libraries/lock/v11/i18n"
-
-      - title: "Customizing Errors"
-        url: "/libraries/lock/v11/customizing-error-messages"
-
-      - title: "Lock with auth0.js"
-        url: "/libraries/lock/v11/auth0js"
-
-      - title: "Authentication Modes"
-        url: "/libraries/lock/v11/authentication-modes"
-
-  - title: "Lock for iOS"
-    url: "/libraries/lock-ios/v2"
+      - title: Migrate from auth0.js
+        url: /libraries/auth0-single-page-app-sdk/migrate-from-auth0-js-to-the-auth0-single-page-app-sdk
+        hidden: true
+  - title: Auth0 React SDK
+    url: /libraries/auth0-react
+  - title: Auth0 Angular SPA SDK
+    url: /libraries/auth0-angular-spa
+  - title: Lock for Web
+    url: /libraries/lock
     children:
-
-      - title: "Overview"
-        url: "/libraries/lock-ios/v2"
-
-      - title: "Styles Customization"
-        url: "/libraries/lock-ios/v2/customization"
-
-      - title: "Behavior Configuration"
-        url: "/libraries/lock-ios/v2/configuration"
-
-      - title: "Custom Fields"
-        url: "/libraries/lock-ios/v2/custom-fields"
-
-      - title: "Internationalization"
-        url: "/libraries/lock-ios/v2/internationalization"
-
-      - title: "Passwordless"
-        url: "/libraries/lock-ios/v2/passwordless"
-
-      - title: "Migration Guide"
-        url: "/libraries/lock-ios/v2/migration"
-
-  - title: "Lock for Android"
-    url: "/libraries/lock-android/v2"
+      - title: Overview
+        url: /libraries/lock
+      - title: Configuration Options
+        url: /libraries/lock/lock-configuration
+      - title: API Reference
+        url: /libraries/lock/lock-api-reference
+      - title: UI Customization
+        url: /libraries/lock/lock-ui-customization
+      - title: Internationalization
+        url: /libraries/lock/lock-internationalization
+      - title: Customizing Errors
+        url: /libraries/lock/customize-lock-error-messages
+      - title: Authentication Modes
+        url: /libraries/lock/lock-authentication-modes
+  - title: Lock for iOS
+    url: /libraries/lock-swift
     children:
-
-      - title: "Overview"
-        url: "/libraries/lock-android/v2"
-
-      - title: "Configuration Options"
-        url: "/libraries/lock-android/v2/configuration"
-
-      - title: "Custom Auth Providers"
-        url: "/libraries/lock-android/v2/custom-authentication-providers"
-
-      - title: "Android Dev Keystores"
-        url: "/libraries/lock-android/v2/keystore"
-
-      - title: "Custom Signup Fields"
-        url: "/libraries/lock-android/v2/custom-fields"
-
-      - title: "Custom Theming"
-        url: "/libraries/lock-android/v2/custom-theming"
-
-      - title: "Migration v1 to v2"
-        url: "/libraries/lock-android/v2/migration-guide"
-
-      - title: "Passwordless Auth"
-        url: "/libraries/lock-android/v2/passwordless"
-
-      - title: "Internationalization"
-        url: "/libraries/lock-android/v2/internationalization"
-
-  - title: "Lock vs. Custom UI"
-    url: "/libraries/when-to-use-lock"
-
-  - title: "Auth0 SDK for Web"
-    url: "/libraries/auth0js/v9"
+      - title: Overview
+        url: /libraries/lock-swift
+      - title: Styles Customization
+        url: /libraries/lock-swift/lock-swift-customization
+      - title: Behavior Configuration
+        url: /libraries/lock-swift/lock-swift-configuration-options
+      - title: Custom Fields
+        url: /libraries/lock-swift/lock-swift-custom-fields-at-signup
+      - title: Internationalization
+        url: /libraries/lock-swift/lock-swift-internationalization
+  - title: Lock for Android
+    url: /libraries/lock-android
     children:
-
-      - title: "Auth0.js"
-        url: "/libraries/auth0js/v9"
-
-      - title: "Migration Guide"
-        url: "/libraries/auth0js/v9/migration-guide"
-
-  - title: "Auth0 SDK for iOS"
-    url: "/libraries/auth0-swift"
+      - title: Overview
+        url: /libraries/lock-android
+      - title: Configuration Options
+        url: /libraries/lock-android/lock-android-configuration
+      - title: Custom Auth Providers
+        url: /libraries/lock-android/lock-android-custom-authentication-providers
+      - title: Android Dev Keystores
+        url: /libraries/auth0-android/android-development-keystores-hashes
+      - title: Custom Signup Fields
+        url: /libraries/lock-android/lock-android-custom-fields-at-signup
+      - title: Custom Theming
+        url: /libraries/lock-android/lock-android-custom-theming
+      - title: Internationalization
+        url: /libraries/lock-android/lock-android-internationalization
+      - title: Passwordless
+        url: /libraries/lock-android/lock-android-passwordless
+      - title: Passwordless with Magic Link
+        url: /libraries/lock-android/lock-android-passwordless-with-magic-link
+  - title: Lock vs. Custom UI
+    url: /universal-login/universal-login-page-customization
+  - title: Auth0 SDK for Web
+    url: /libraries/auth0js-v9-reference
+  - title: Auth0 SDK for iOS
+    url: /libraries/auth0-swift
     children:
-
-      - title: "Overview"
-        url: "/libraries/auth0-swift"
-
-      - title: "Database Authentication"
-        url: "/libraries/auth0-swift/database-authentication"
-
-      - title: "User Management"
-        url: "/libraries/auth0-swift/user-management"
-
-      - title: "Passwordless Authentication"
-        url: "/libraries/auth0-swift/passwordless"
-
-      - title: "Refresh Tokens"
-        url: "/libraries/auth0-swift/save-and-refresh-jwt-tokens"
-
-      - title: "TouchID"
-        url: "/libraries/auth0-swift/touchid-authentication"
-
-  - title: "Auth0 SDK for Android"
-    url: "/libraries/auth0-android"
+      - title: Overview
+        url: /libraries/auth0-swift
+      - title: Database Authentication
+        url: /libraries/auth0-swift/auth0-swift-database-connections
+      - title: User Management
+        url: /libraries/auth0-swift/auth0-swift-user-management
+      - title: Refresh Tokens
+        url: /libraries/auth0-swift/auth0-swift-save-and-renew-tokens
+      - title: Touch ID / Face ID
+        url: /libraries/auth0-swift/auth0-swift-touchid-faceid
+  - title: Auth0 SDK for Android
+    url: /libraries/auth0-android
     children:
-
-      - title: "Overview"
-        url: "/libraries/auth0-android"
-
-      - title: "Configuration"
-        url: "/libraries/auth0-android/configuration"
-
-      - title: "Database Authentication"
-        url: "/libraries/auth0-android/database-authentication"
-
-      - title: "User Management"
-        url: "/libraries/auth0-android/user-management"
-
-      - title: "Passwordless"
-        url: "/libraries/auth0-android/passwordless"
-
-      - title: "Refresh Tokens"
-        url: "/libraries/auth0-android/save-and-refresh-tokens"
-
-appliance:
-
-  - title: "Introduction"
-    url: "/appliance"
-
-  - title: "Support"
-    url: "/appliance/critical-issue"
-    expanded: 1
+      - title: Overview
+        url: /libraries/auth0-android
+      - title: Login, Logout, and User Profiles
+        url: /libraries/auth0-android/auth0-android-login-logout-and-user-profiles
+      - title: Configuration
+        url: /libraries/auth0-android/auth0-android-configuration
+      - title: Database Authentication
+        url: /libraries/auth0-android/auth0-android-database-authentication
+      - title: Passwordless Authentication
+        url: /libraries/auth0-android/auth0-android-passwordless
+      - title: User Management
+        url: /libraries/auth0-android/auth0-android-user-management
+      - title: Refresh Tokens
+        url: /libraries/auth0-android/auth0-android-save-and-renew-tokens
+      - title: Custom Networking Client
+        url: /libraries/auth0-android/auth0-android-custom-networking-client
+      - title: V2 Migration Guide
+        url: /libraries/auth0-android/auth0-android-v2-migration-guide
+videos:
+  - title: Learn Identity
+    url: /videos/learn-identity-series
     children:
-      - title: Critical Issue
-        url: /appliance/critical-issue
-      - title: Enterprise Support
-        url: /onboarding/enterprise-support
-
-  - title: PSaaS Appliance Planning
-    url: /appliance/appliance-overview
-    expanded: 1
+      - title: Introduction to Identity
+        url: /videos/learn-identity-series/introduction-to-identity
+      - title: OpenID Connect and OAuth2
+        url: /videos/learn-identity-series/openid-connect-and-oauth2
+      - title: Web Sign-In
+        url: /videos/learn-identity-series/web-sign-in
+      - title: Calling an API
+        url: /videos/learn-identity-series/calling-an-api
+      - title: Desktop and Mobile Apps
+        url: /videos/learn-identity-series/desktop-and-mobile-apps
+      - title: Single Page Apps
+        url: /videos/learn-identity-series/single-page-apps
+  - title: Get Started
+    url: /videos/get-started-series
     children:
-      - title: Overview
-        url: /appliance/appliance-overview
-
-      - title: Geographic High-Availability
-        url: /appliance/geo-ha
-        children:
-          - title: Disaster Recovery
-            url: /appliance/geo-ha/disaster-recovery
-
-      - title: Infrastructure Requirements
-        url: /appliance/infrastructure
-        children:
-          - title: Installation Process
-            url: /appliance/infrastructure/installation
-          - title: Infrastructure Overview
-            url: /appliance/infrastructure/infrastructure-overview
-          - title: Webtasks and Web Extensions
-            url: /appliance/infrastructure/extensions
-
-          - title: Requirements
-            category: true
-          - title: Virtual Machines
-            url: /appliance/infrastructure/virtual-machines
-          - title: Network
-            url: /appliance/infrastructure/network
-          - title: IP/Domain and Port List
-            url: /appliance/infrastructure/ip-domain-port-list
-          - title: Security and Access
-            url: /appliance/infrastructure/security
-
-      - title: Roles and Responsibilities
-        url: /appliance/raci
-
-      - title: Customer Onboarding
-        url: /onboarding/appliance-sprint
-
-      - title: Private Cloud Requirements
-        url: /appliance/private-cloud-requirements
-
-  - title: "PSaaS Appliance Administration"
-    url: "/appliance/admin"
-    expanded: 1
+      - title: 'Architect: Your Tenant'
+        url: /videos/get-started-series/architect-your-tenant
+      - title: 'Provision: User Stores'
+        url: /videos/get-started-series/provision-user-stores
+      - title: 'Provision: Import Users'
+        url: /videos/get-started-series/provision-import-users
+      - title: 'Authenticate: How It Works'
+        url: /videos/get-started-series/authenticate-how-it-works
+      - title: 'Authenticate: SPA Example'
+        url: /videos/get-started-series/authenticate-spa-example
+      - title: 'Authorize: ID Tokens and Access Control'
+        url: /videos/get-started-series/authorize-id-tokens-and-access-control
+      - title: 'Authorize: Get and Validate ID Tokens'
+        url: /videos/get-started-series/authorize-get-and-validate-id-tokens
+      - title: User Profiles
+        url: /videos/get-started-series/learn-user-profiles
+      - title: 'Brand: How It Works'
+        url: /videos/get-started-series/brand-how-it-works
+      - title: 'Brand: Sign Up and Login Pages'
+        url: /videos/get-started-series/brand-signup-and-login-pages
+      - title: 'Brand: Emails and Error Pages'
+        url: /videos/get-started-series/brand-emails-and-error-pages
+      - title: Logout
+        url: /videos/get-started-series/learn-logout
+identity-labs:
+  - title: Digital Identity Labs
+    url: /identity-labs
     children:
-      - title: Administrator's Manual
-        url: /appliance/admin
+      - title: 'Lab 1: Web Sign-In'
+        url: /identity-labs/lab-1-web-sign-in
         children:
-          - title: Managing the Dashboard
-            url: /appliance/admin/managing-the-dashboard
-          - title: Disabling Sign-ups
-            url: /appliance/admin/disabling-sign-ups
-          - title: Inviting Co-Administrators
-            url: /appliance/admin/inviting-coadmins
-          - title: Appliance Backups
-            url: /appliance/admin/backing-up-the-appliance-instances
-          - title: Monitoring
-            url: /appliance/admin/monitoring
-          - title: Limiting SSH Access
-            url: /appliance/admin/limiting-ssh-access
-          - title: Updating
-            url: /appliance/admin/updating-the-appliance
-
-      - title: Dashboard/Configuration Area
-        url: /appliance/dashboard
+          - title: Exercise 1
+            url: /identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-1
+          - title: Exercise 2
+            url: /identity-labs/lab-1-web-sign-in/identity-lab-1-exercise-2
+      - title: 'Lab 2: Calling an API'
+        url: /identity-labs/identity-lab-2-calling-api
         children:
-          - title: Troubleshoot
-            url: /appliance/dashboard/troubleshoot
-        
-      - title: Monitoring Tools
-        url: /appliance/monitoring
+          - title: Exercise 1
+            url: /identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-1
+          - title: Exercise 2
+            url: /identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-2
+          - title: Exercise 3
+            url: /identity-labs/identity-lab-2-calling-api/identity-lab-2-exercise-3
+      - title: 'Lab 3: Mobile Native App'
+        url: /identity-labs/lab-3-mobile-native-app
         children:
-          - title: Instrumentation
-            url: /appliance/instrumentation
-          - title: Testall endpoint
-            url: /appliance/monitoring/testall
-          - title: Authenticated testing endpoints
-            url: /appliance/monitoring/authenticated-endpoints
-        
-      - title: Command-Line Interface Tools
-        url: /appliance/cli
-      - title: Automatic Tenant Creation
-        url: /appliance/admin/creating-tenants
-      - title: Node Module Availibility
-        url: /appliance/modules
-      - title: Webtasks
-        url: /appliance/webtasks
-      - title: Extensions
-        url: /appliance/extensions
-      - title: Disaster Recovery
-        url: /appliance/disaster-recovery
+          - title: Exercise 1
+            url: /identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-1
+          - title: Exercise 2
+            url: /identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-2
+          - title: Exercise 3
+            url: /identity-labs/lab-3-mobile-native-app/identity-lab-3-exercise-3
+      - title: 'Lab 4: Single Page App'
+        url: /identity-labs/lab-4-single-page-app
         children:
-          - title: Roles and Responsibilities
-            url: /appliance/disaster-recovery-raci
-
-      - title: Release Notes
-        url: https://auth0.com/changelog/appliance
-        external: true
-        forceFullReload: true
+          - title: Exercise 1
+            url: /identity-labs/lab-4-single-page-app/identity-lab-4-exercise-1
+          - title: Exercise 2
+            url: /identity-labs/lab-4-single-page-app/identity-lab-4-exercise-2
diff --git a/config/vars.yml b/config/vars.yml
index 0b75543074..513dd8a13a 100644
--- a/config/vars.yml
+++ b/config/vars.yml
@@ -1,9 +1,11 @@
-lock_url: 'https://cdn.auth0.com/js/lock/11.6.1/lock.min.js'
+lock_url: 'https://cdn.auth0.com/js/lock/11.14/lock.min.js'
 lock_urlv10: 'https://cdn.auth0.com/js/lock/10.24.3/lock.min.js'
-lock_urlv11: 'https://cdn.auth0.com/js/lock/11.6.1/lock.min.js'
-lock_passwordless_url: 'https://cdn.auth0.com/js/lock-passwordless-2.2.min.js'
-auth0js_url: 'https://cdn.auth0.com/js/auth0/9.5.1/auth0.min.js'
-auth0js_urlv9: 'https://cdn.auth0.com/js/auth0/9.5.1/auth0.min.js'
+lock_urlv11: 'https://cdn.auth0.com/js/lock/11.14/lock.min.js'
+auth0js_url: 'https://cdn.auth0.com/js/auth0/9.11/auth0.min.js'
+auth0js_urlv9: 'https://cdn.auth0.com/js/auth0/9.10/auth0.min.js'
 auth0js_urlv8: 'https://cdn.auth0.com/js/auth0/8.12.3/auth0.min.js'
 auth0js_urlv7: 'https://cdn.auth0.com/w2/auth0-7.6.1.min.js'
+auth0spajs_url: 'https://cdn.auth0.com/js/auth0-spa-js/1.20/auth0-spa-js.production.js'
+auth0spajs_urlv2: 'https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js'
+auth0react_url: 'https://cdn.auth0.com/js/auth0-react/1.0/auth0-react.min.js'
 auth0_community: 'https://community.auth0.com/'
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
+    
+  
        
+  
          
+    
          
+      
        • 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/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
        
+    
          
+      <% requirements.forEach(req => { %>
+      
        • ${req}
          • 
+      <% }); %>
+    
        
+  
        
+  
        
+    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 @@
+
          
+<% _.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/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/articles/applications/application-settings/_adv-settings-pt2.md b/fr-ca/articles/libraries/lock-ios/_includes/_roadmap.md
similarity index 100%
rename from articles/applications/application-settings/_adv-settings-pt2.md
rename to fr-ca/articles/libraries/lock-ios/_includes/_roadmap.md
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/ApiController.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.md
new file mode 100644
index 0000000000..9f8b83b336
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.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/HasScopeHandler.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.md
new file mode 100644
index 0000000000..f67f1b2cd1
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.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/HasScopeRequirement.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.md
new file mode 100644
index 0000000000..fe73104225
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.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/files/Program.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/Program.md
new file mode 100644
index 0000000000..7b30acec02
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/Program.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/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..d9419a5dd9
--- /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..6b83318668
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/interactive.md
@@ -0,0 +1,613 @@
+---
+title: Ajouter une autorisation à votre application API ASP.NET Core Web
+description: Ce tutoriel explique comment ajouter une autorisation à une application API ASP.NET Core Web en utilisant le logiciel médiateur JWT standard.
+interactive:  true
+files:
+ - files/appsettings
+ - files/Program
+ - files/HasScopeHandler
+ - files/HasScopeRequirement
+ - files/ApiController
+github:
+  path: Quickstart/01-Authorization
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application API ASP.NET Core Web
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et d’accéder aux informations relatives au profil de l’utilisateur dans presque tous les types d’applications. Ce guide explique comment intégrer Auth0 à n’importe quelle application API ASP.NET Web, nouvelle ou existante, à l’aide du package Microsoft.AspNetCore.Authentication.JwtBearer .
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration.
        Vous pouvez également consulter notre guide de démarrage, qui vous aidera à configurer votre première API via Auth0 Dashboard.
        Notez que chaque API dans Auth0 est configurée à l’aide d’un identifiant d’API; votre code d’application utilisera l’identifiant d’API comme Public pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0 ? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et accorder un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard. L’exemple suivant utilise la permission read:messages.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        
+
+## Installer les dépendances
+
+
+
        Pour permettre à votre application de valider les jetons d’accès, ajoutez une référence au package NuGet Microsoft.AspNetCore.Authentication.JwtBearer :
        Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
+
+
        
+
+
        
+
+## Configurer le logiciel médiateur {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        Configurez le logiciel médiateur d’authentification dans le fichier Program.cs de votre application :
        1. Enregistrez les services d’authentification en appelant la méthode AddAuthentication. Configurez JwtBearerDefaults.AuthenticationScheme comme schéma par défaut.
        2. Enregistrez le schéma d’authentification du porteur JWT en faisant un appel à la méthode AddJwtBearer. Configurez votre domaine Auth0 comme autorité et votre identifiant API Auth0 comme public, et assurez-vous que votre domaine Auth0 et votre identifiant API sont définis dans le fichier appsettings.json de votre application.
+
+
          Dans certains cas, le jeton d’accès n’aura pas de sub demande; dans ce cas, le nom User.Identity.Name sera null. Si vous souhaitez mapper une demande différente à User.Identity.Name, ajoutez-la aux options.TokenValidationParameters dans l’appel AddJwtBearer().
          .
        3. Ajoutez l’authentification et l’autorisation de le logiciel médiateur au pipeline du logiciel médiateur en ajoutant des appels aux méthodes UseAuthentication  et UseAuthorization  sous la méthode var app = builder.Build(); .
        
+
+## Valider les permissions {{{ data-action="code" data-code="HasScopeHandler.cs" }}}
+
+
+
        Pour s’assurer qu’un jeton d’accès contient les permissions adéquates, utilisez Policy-Based Authorization (Autorisation basée sur une politique) dans ASP.NET Core :
        1. Créez une nouvelle exigence d’autorisation appelée HasScopeRequirement, qui vérifiera si la demande de scope émise par votre locataire Auth0 est présente et, le cas échéant, vérifiera que la demande contient la permission demandée.
        2. Dans la méthode var builder = WebApplication.CreateBuilder(args);  du fichier Program.cs, ajoutez un appel à la méthode app.AddAuthorization.
        3. Ajoutez des politiques pour les permissions en appelant AddPolicy  pour chaque permission.
        4. Enregistrez un singleton pour la classe HasScopeHandler.
        
+
+## Protéger les points de terminaison des API {{{ data-action="code" data-code="ApiController.cs" }}}
+
+
+
        Le logiciel médiateur JWT s’intègre aux mécanismes d’authentification et d’autorisation standard de ASP.NET Core.
        Pour sécuriser un point de terminaison, ajoutez l’attribut [Authorize] à votre action de contrôleur (ou à tout le contrôleur si vous souhaitez protéger toutes ses actions).
        Lors de la sécurisation des points de terminaison qui nécessitent des permissions particulières, assurez-vous que la bonne permission est présente dans access_token. Pour ce faire, ajoutez l’attribut Authorize à l’action Scoped et passez read:messages comme paramètre de la policy.
        
+
+## Appeler votre API
+
+
+
        La façon dont vous appelez votre API dépend du type d’application que vous développez et du cadre que vous utilisez. Pour en savoir plus, lire le Guide rapide de l’application concernée :
        Obtenir un jeton d’accès
        Quel que soit le type d’application que vous développez ou le cadre que vous utilisez, vous aurez besoin d’un jeton d’accès pour appeler votre API.
        Si vous appelez votre API à partir d’une application à page unique (SPA) ou native, vous recevrez un jeton d’accès une fois l’autorisation obtenue.
        Si vous appelez l’API à partir d’un outil de ligne de commande ou d’un autre service sans identifiants utilisateur, utilisez le Flux des identifiants client d’OAuth. Pour ce faire, enregistrez une Application de communication entre machines et incluez les valeurs suivantes à votre requête :
        • ID client comme paramètre client_id.
        • Secret client comme paramètre client_secret.
        • Identifiant API (la même valeur utilisée pour configurer l’intergiciel plus tôt dans ce guide rapide) comme paramètre audience.
        Pour en savoir plus sur l’obtention de l’identificateur client et du secret client pour votre application de communication entre machines, lisez la section Paramètres de l’application.
        Exemple de demande
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/token");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/token"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/token")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/token',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/token"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/token",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/token", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/token")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/token")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Appeler un point de terminaison sécurisé
        Maintenant que vous avez un jeton d’accès, vous pouvez l’utiliser pour appeler des points de terminaison API sécurisés. Lorsque vous appelez un point de terminaison sécurisé, vous devez inclure le jeton d’accès en tant que jeton de porteur dans l’en-tête Authorization de la requête. Par exemple, vous pouvez faire une requête au point de terminaison /api/private :
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http://localhost:3010/api/private \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN'
        var client = new RestClient("http://localhost:3010/api/private");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http://localhost:3010/api/private"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http://localhost:3010/api/private")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http://localhost:3010/api/private',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://localhost:3010/api/private"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_PORT => "3010",
+
+  CURLOPT_URL => "http://localhost:3010/api/private",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("localhost:3010")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN" }
+
+
+
+conn.request("get", "/api/private", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http://localhost:3010/api/private")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http://localhost:3010/api/private")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Appelez le point de terminaison /api/private-scoped de manière similaire, mais assurez-vous que les autorisations API sont configurées correctement et que le jeton d’accès inclut la permission read:messages.
        Guide rapide ASP.NET API - Étape 6 - Point de contrôle 
        Vous devriez maintenant pouvoir appeler les points de terminaison /api/private et /api/private-scoped.
        Exécutez votre application et vérifiez que :
        • GET /api/private est disponible pour les demandes authentifiées.
        • GET /api/private-scoped est disponible pour les demandes authentifiées contenant un jeton d’accès avec la permission read:messages.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que ValidIssuer et ValidAudience sont correctement configurés
        • assurez-vous que le jeton est ajouté en tant qu’en-tête de l'authorisation
        • vérifiez que le jeton a les permissions adéquates (vous pouvez utiliser jwt.io pour vérifier)
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou la page de notre communauté.
        
+
+  
        
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/apiexample/urls.md b/fr-ca/articles/quickstart/backend/django/files/apiexample/urls.md
new file mode 100644
index 0000000000..dd7c571d81
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/django/files/apiexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/apiexample/validator.md b/fr-ca/articles/quickstart/backend/django/files/apiexample/validator.md
new file mode 100644
index 0000000000..16b55b40c3
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/django/files/apiexample/validator.md
@@ -0,0 +1,28 @@
+---
+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/apiexample/views.md b/fr-ca/articles/quickstart/backend/django/files/apiexample/views.md
new file mode 100644
index 0000000000..e9f3f9f404
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/django/files/apiexample/views.md
@@ -0,0 +1,37 @@
+---
+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/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..d664a74e3e
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/django/interactive.md
@@ -0,0 +1,316 @@
+---
+title: Ajouter une autorisation à votre application API Django
+description: Ce tutoriel explique comment ajouter une autorisation à une API Python développée avec Django.
+interactive:  true
+files:
+ - files/apiexample/validator
+ - files/apiexample/views
+ - files/apiexample/urls
+github:
+  path: 01-Authorization
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application API Django
+
+
+
        Ce guide explique comment intégrer Auth0 à n’importe quelle API Python, nouvelle ou ancienne, développée avec Django.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante qui représente le projet avec lequel vous souhaitez vous intégrer.
        Vous pouvez également lire notre guide de démarrage, qui vous aidera à configurer votre première API via Auth0 Dashboard.
        Toute API dans Auth0 est configurée à l’aide d’un identifiant d’API que votre code d’application utilisera comme Audience pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0 ? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et accorder un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API du Auth0 Dashboard. L’exemple suivant utilise la permission read:messages.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        
+
+## Configurer Django pour utiliser Auth0
+
+
+
        Installez des dépendances
        1. Ajoutez les dépendances suivantes à votre requirements.txt :
+
+
        2. Exécutez pip install -r requirements.txt
        Créez une application Django
        
+
+## Créer le validateur JWT {{{ data-action="code" data-code="apiexample/validator.py" }}}
+
+
+
        Vous utiliserez une bibliothèque appelée Authlib pour créer un ResourceProtector, qui est un type de Django view decorator (Décorateur de vue Django) qui protège vos ressources (vues API) avec un validateur donné.
        Le validateur vérifiera le jeton d’accès que vous passez à la ressource en vérifiant qu’il a une signature et des demandes valides.
        Vous pouvez utiliser le validateur JWTBearerTokenValidator d’AuthLib avec quelques ajustements pour vous assurer qu’il est conforme à nos exigences de validation des jetons d’accès.
        Pour créer votre Auth0JWTBearerTokenValidator, vous devez le passer à votre domaine et à votre public (Identificateur API). Il obtiendra alors la clé publique nécessaire pour vérifier la signature du jeton et la passera à la classe JWTBearerTokenValidator.
        Vous remplacerez ensuite les claims_options de la classe pour vous assurer que les demandes expiry, audience et issue du jeton sont validées selon nos exigences.
        Créez le fichier apiexample/validator.py en utilisant le code du panneau interactif.
        
+
+## Créer les vues API {{{ data-action="code" data-code="apiexample/views.py" }}}
+
+
+
        Ensuite, vous allez créer trois vues API dans apiexample/views.py :
        • /api/public : point de terminaison public qui ne nécessite aucune authentification.
        • /api/private : point de terminaison privé qui nécessite un JWT de jeton d’accès valide.
        • /api/private-scoped : termpoint de terminaison inal privé qui nécessite un JWT de jeton d’accès valide contenant la scope donnée.
        Les routes protégées auront un "decorator" require_auth, qui est un ResourceProtector qui utilise le Auth0JWTBearerTokenValidator que vous avez créé précédemment.
        Pour créer le Auth0JWTBearerTokenValidator, vous devez le transmettre au domaine de votre locataire et à l’identificateur de l’API que vous avez créé précédemment.
        Le decorator require_auth sur la route private_scoped prend en charge un argument supplémentaire "read:messages" qui vérifie la permission du jeton d’accès que vous avez créé précédemment.
        
+
+## Ajouter des mappages d’URL {{{ data-action="code" data-code="apiexample/urls.py#8:10" }}}
+
+
+
        Dans les étapes précédentes, vous avez ajouté des méthodes au fichier views.py . Mappez à présent ces méthodes aux URL en utilisant le URL Dispatcher (Répartiteur d’URL) de Django, qui vous permet de mapper les modèles d’URL aux vues.
        Ajoutez les modèles d’URL à votre fichier apiexample/urls.py.
        Faites un appel à votre API
        Pour appeler votre API, vous aurez besoin d’un jeton d’accès. Vous pouvez récupérer un jeton d’accès à des fins de test dans la vue Test dans vos API Settings (Paramètres API).
        Auth0 Dashboard> Applications > API > [API specifique] > Onglet Test
        Fournissez le jeton d’accès comme en-tête Authorization dans vos requêtes.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}.com/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}.com/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}.com/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}.com/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}.com/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}.com/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}.com/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}.com/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}.com/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}.com/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
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..9e2ba946b6
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/golang/files/main.md
@@ -0,0 +1,67 @@
+---
+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/files/middleware/jwt.md b/fr-ca/articles/quickstart/backend/golang/files/middleware/jwt.md
new file mode 100644
index 0000000000..0149818d66
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/golang/files/middleware/jwt.md
@@ -0,0 +1,88 @@
+---
+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/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..7b7d02c8ba
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/golang/interactive.md
@@ -0,0 +1,359 @@
+---
+title: Ajouter une autorisation à votre application Go
+description: Ce tutoriel explique comment ajouter une autorisation à une API Go.
+interactive:  true
+files:
+ - files/middleware/jwt
+ - files/main
+github:
+  path: 01-Authorization-RS256
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application Go
+
+
+
        Ce guide explique comment intégrer Auth0 à n’importe quelle application API Go, nouvelle ou ancienne, en utilisant le package go-jwt-middleware.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante pour votre projet.
        Pour configurer votre première API via Auth0 Dashboard, consultez notre guide de démarrage.
        Chaque API Auth0 utilise l’identificateur API, dont votre application a besoin pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0 ? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard. L’exemple suivant utilise la permission read:messages.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        
+
+## Installer les dépendances
+
+
+
        Ajoutez un fichier go.mod pour répertorier toutes les dépendances nécessaires.
        // 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
+
+)
+
+
        
+
+
        Téléchargez les dépendances en exécutant la commande shell suivante :
        go mod download
+
+
        
+
+
        
+
+## Configuration de votre application
+
+
+
        Créez un fichier .env à la racine de votre répertoire de projet pour stocker la configuration de l’application. Renseignez ensuite les variables d’environnement :
        # 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}'
+
+
        
+
+
        
+
+## Créer un logiciel médiateur pour valider les jetons d’accès {{{ data-action="code" data-code="middleware/jwt.go" }}}
+
+
+
        La fonction de logiciel médiateur EnsureValidToken valide le jeton d’accès. Vous pouvez appliquer cette fonction à tous les points de terminaison que vous souhaitez protéger. Si le jeton est valide, le point de terminaison libère les ressources. Si le jeton n’est pas valide, l’API renvoie une erreur 401 Authorization (Autorisation 401).
        Configurez le logiciel médiateur go-jwt-middleware pour vérifier les jetons d’accès des demandes entrantes.
        Par défaut, votre API sera configurée pour utiliser RS256 comme algorithme de signature des jetons. Puisque RS256 fonctionne en utilisant une paire de clés privée/publique, les jetons peuvent être vérifiés par rapport à la clé publique pour votre compte Auth0. Cette clé publique est accessible à https://{yourDomain}/.well-known/jwks.json.
        Inclure un mécanisme pour vérifier que le jeton a une scope (permission) suffisante pour accéder aux ressources demandées.
        Créer une fonction HasScope pour vérifier et s’assurer que le jeton d’accès a la bonne permission avant de renvoyer une réponse réussie.
        
+
+## Protéger les points de terminaison des API {{{ data-action="code" data-code="main.go" }}}
+
+
+
        Dans cet exemple, vous allez créer un point de terminaison /api/public qui n’utilise pas le logiciel médiateur EnsureToken car il est accessible aux requêtes non authentifiées.
        Créez un point de terminaison /api/private qui nécessite le logiciel médiateur EnsureToken car il n’est disponible que pour les requêtes authentifiées contenant un jeton d’accès, sans permission supplémentaire.
        Créez un point de terminaison /api/private qui nécessite le logiciel médiateur EnsureToken et HasScope car il n’est disponible que pour les requêtes authentifiées contenant un jeton d’accès dont la permission read:messages est accordée.
        Seule la portée read:messages est vérifiée par la fonction HasScope. Vous pouvez l’étendre ou en faire un logiciel médiateur autonome qui accepte plusieurs permissions pour s’adapter à votre cas d’utilisation.
        Faire un appel à votre API
        Pour appeler votre API, vous avez besoin d’un jeton d’accès. Vous pouvez obtenir un jeton d’accès à des fins de test dans la vue Test dans vos API settings (Paramètres API).
        Auth0 Dashboard> Applications > API > [API specifique] > Onglet Test
        Fournissez le Jeton d’accès comme un en-tête Authorization (Autorisation) dans vos requêtes.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Démarrage rapide Go API - Étape 5 - Point de contrôle 
        Maintenant que vous avez configuré votre application, lancez votre application et vérifiez que :
        • GET /api/public est disponible pour les demandes non authentifiées.
        • GET /api/private est disponible pour les demandes authentifiées.
        • GET /api/private-scoped est disponible pour les demandes authentifiées contenant un jeton d’accès avec la permission read:messages.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré :
        • Vérifiez que vous avez ajouté le jeton en tant qu’en-tête d'autorisation
        • Assurez-vous que le jeton est doté des permissions appropriées. Vérifiez avec jwt.io.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/APIController.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/APIController.md
new file mode 100644
index 0000000000..6f04ff5496
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/APIController.md
@@ -0,0 +1,35 @@
+---
+name: APIController.java
+language: powershell
+---
+    
+```powershell
+    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");
+}
+    }
+```
diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
new file mode 100644
index 0000000000..5c6788d8a4
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
@@ -0,0 +1,41 @@
+---
+name: SecurityConfig.java
+language: powershell
+---
+    
+```powershell
+    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();
+}
+    }
+```
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..b94691c69a
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/application.md
@@ -0,0 +1,13 @@
+---
+name: application.yml
+language: 
+---
+    
+```
+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}
+```
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..fc1823b480
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/message.md
@@ -0,0 +1,11 @@
+---
+name: Message.java
+language: powershell
+---
+    
+```powershell
+    /**
+     * Simple domain object for our API to return a message.
+     */
+    public record Message(String message) {}
+```
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..ee55577b5b
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/java-spring-security5/interactive.md
@@ -0,0 +1,129 @@
+---
+title: Ajouter l’autorisation à votre application Spring Boot
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application Spring Boot, nouvelle ou ancienne.
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/Message
+ - files/APIController
+github:
+  path: 01-Authorization-MVC
+locale: fr-CA
+---
+
+# Ajouter l’autorisation à votre application Spring Boot
+
+
+
        Auth0 vous permet d’ajouter rapidement une autorisation à votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application Spring Boot, nouvelle ou ancienne.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante qui représente le projet avec lequel vous souhaitez vous intégrer.
        Consultez notre guide de démarrage pour configurer votre première API via Auth0 Dashboard.
        Chaque API Auth0 utilise l’identificateur API, dont votre application a besoin pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        Cet exemple utilise la permission read:messages.
        
+
+## Configurer l’exemple de projet {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        L’exemple de projet utilise un fichier /src/main/resources/application.yml, qui le configure pour utiliser le domaine et l’identificateur API Auth0 corrects pour votre API. Si vous téléchargez le code à partir de cette page, il sera automatiquement configuré. En revanche, si vous clonez l’exemple à partir de GitHub, vous devrez le remplir manuellement.
        
+
+## Installer les dépendances {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        Si vous utilisez Gradle, vous pouvez ajouter les dépendances nécessaires en utilisant le plugiciel Gradle de Spring Boot et le plugiciel de gestion des dépendances pour résoudre les problèmes de versions de dépendances :
        // 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'
+
+    }
+
+
        
+
+
        Si vous utilisez Maven, ajoutez les dépendances Spring à votre fichier pom.xml :
        // pom.xml
+
+
+
+<parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.5</version>
+
+ <relativePath/>
+
+</parent>
+
+<dependencies>
+
+ <dependency>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+ <groupId>com.okta.spring</groupId>
+
+ <artifactId>okta-spring-boot-starter</artifactId>
+
+ <version>3.0.5</version>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## Configurer le serveur de ressources {{{ data-action="code" data-code="SecurityConfig.java" }}}
+
+
+
        Pour configurer l’application en tant que serveur de ressources et valider les JWT, créez une classe qui fournira une instance SecurityFilterChain et ajoutez l’annotation @Configuration.
        Protéger les points de terminaison des API
        Les routes ci-dessous sont disponibles pour les demandes suivantes :
        • GET /api/public : disponible pour les demandes non authentifiées
        • GET /api/private : disponible pour les demandes authentifiées contenant un jeton d’accès sans permission supplémentaire
        • GET /api/private-scoped : disponible pour les demandes authentifiées contenant un jeton d’accès dont la permission read:messages est accordée
        L’exemple ci-dessous montre comment sécuriser les méthodes de l’API à l’aide de l’objet HttpSecurity fourni dans la méthode filterChain() de la classe SecurityConfig. Les adaptateurs de routes limitent l’accès en fonction du niveau d’autorisation requis.
        Par défaut, Spring Security crée une GrantedAuthority pour chaque permission dans la demande scope du JWT. Cette permission permet d’utiliser la méthode hasAuthority("SCOPE_read:messages") pour restreindre l’accès à un JWT valide qui contient la permission read:messages.
        
+
+## Créer l’objet de domaine {{{ data-action="code" data-code="Message.java#1:4" }}}
+
+
+
        Pour que votre point de terminaison renvoie un objet JSON, utilisez un enregistrement Java. Les variables membres de cet objet sont sérialisées dans la valeur clé de votre objet JSON. Créez un nouvel enregistrement appelé Message comme exemple d’objet de domaine à renvoyer lors des appels à l’API.
        
+
+## Créer le contrôleur d’API {{{ data-action="code" data-code="APIController.java" }}}
+
+
+
        Créez une nouvelle classe appelée APIController pour gérer les demandes vers les points de terminaison. L’APIController possède trois routes définies dans la section Protéger les points de terminaison des API. Dans cet exemple, toutes les origines sont autorisées par l’annotation @CrossOrigin. Les applications réelles doivent configurer CORS en fonction de leur cas d’utilisation.
        
+
+## Exécuter l’application {{{ data-action="code" data-code="APIController.java" }}}
+
+
+
        Pour développer et exécuter le projet exemple, exécutez la tâche Gradle bootRun.
        Linux ou macOS :
        ./gradlew bootRun
        Windows :
        gradlew.bat bootRun
        Si vous configurez votre propre application en utilisant Maven et le plugiciel Spring Boot Maven Plugin, vous pouvez exécuter l’objectif spring-boot:run.
        Linux ou macOS :
        mvn spring-boot:run
        Windows :
        mvn.cmd spring-boot:run
        API Spring Boot - Étape 7 - Point de contrôle 
        L’exemple d’application sera accessible à l’adresse http://localhost:3010/. Pour en savoir plus sur la manière de tester et d’utiliser votre API, consultez Utiliser votre API.
        
+
+  
        
+
+  
        Si votre application n’a pas été lancée avec succès :
        • Utilisez la section Dépannage pour vérifier votre configuration.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/files/routes/api.md b/fr-ca/articles/quickstart/backend/laravel/files/routes/api.md
new file mode 100644
index 0000000000..a966bef3c4
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/laravel/files/routes/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..f909fe764e
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/laravel/interactive.md
@@ -0,0 +1,225 @@
+---
+title: Ajouter l’autorisation à votre application Laravel
+description: Ce guide explique comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 ou 10.
+interactive:  true
+files:
+ - files/routes/api
+github:
+  path: sample
+locale: fr-CA
+---
+
+# Ajouter l’autorisation à votre application Laravel
+
+
+
        La trousse SDK Laravel d’Auth0 vous permet d’ajouter rapidement une autorisation basée sur un jeton et un contrôle d’accès au routage à votre application Laravel. Ce guide explique comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 ou 10.
        Les applications dorsales diffèrent des applications Web traditionnelles en ce sens qu’elles ne gèrent pas l’authentification des utilisateurs et n’ont pas d’interface utilisateur. Elles fournissent une API avec laquelle d’autres applications peuvent interagir. Elles acceptent les jetons d’accès des en-têtes Authorization dans les requêtes pour contrôler l’accès aux routes.
        Des applications frontales distinctes sont généralement créées pour interagir avec ces types d’applications dorsales. Il peut s’agir d’applications à page unique ou d’applications natives ou mobiles (pour lesquelles Auth0 fournit également des trousses SDK).
        Pour interagir avec votre application dorsale, les utilisateurs doivent d’abord s’authentifier auprès d’Auth0 à l’aide de l’application frontale. L’application frontale récupère ensuite un jeton d’accès auprès d’Auth0, qu’elle peut utiliser pour adresser des demandes à votre application dorsale au nom de l’utilisateur.
        Comme leur nom l’indique, les jetons d’accès sont conçus pour traiter les questions de contrôle d’accès (autorisation) et ne contiennent pas d’informations sur l’utilisateur. Les applications dorsales fonctionnent exclusivement avec des jetons d’accès. Vous pouvez récupérer des informations sur l’utilisateur créateur du jeton à l’aide de la Management API, que nous présenterons plus loin.
        
+
+## Installation de Laravel
+
+
+
        Si vous n’avez pas déjà configuré une application Laravel, ouvrez un shell dans un répertoire approprié pour un nouveau projet et exécutez la commande suivante :
        composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0
+
+
        
+
+
        Toutes les commandes de ce guide supposent que vous les exécutez à partir de la racine de votre projet Laravel, donc vous devez bous placer cd dans le nouveau répertoire du projet :
        cd auth0-laravel-api
+
+
        
+
+
        
+
+## Installation de la trousse SDK
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse SDK Laravel Auth0 :
        composer require auth0/login:^7.8 --update-with-all-dependencies
+
+
        
+
+
        Générez ensuite un fichier de configuration de la trousse SDK pour votre application :
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## Configuration SDK
+
+
+
        Exécuter la commande suivante à partir du répertoire de votre projet pour télécharger le Interface de ligne de commande (CLI) Auth0 :
        curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+
+
        
+
+
        Authentifiez ensuite la CLI avec votre compte Auth0 en choisissant « as a user (en tant qu’utilisateur) » lorsque vous y êtes invité :
        ./auth0 login
+
+
        
+
+
        Puis créez une nouvelle application avec Auth0 :
        ./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
+
+
        
+
+
        Vous devez également créer une nouvelle API :
        ./auth0 apis create \
+
+--name "My Laravel Backend API" \
+
+--identifier "https://github.com/auth0/laravel-auth0" \
+
+--offline-access \
+
+--no-input \
+
+--json > .auth0.api.json
+
+
        
+
+
        Cela produit deux fichiers qui configurent la trousse SDK dans votre répertoire de projet.
        Comme ces fichiers contiennent des renseignements personnels, il est important de les traiter comme étant sensibles. Vous devez vous assurer de ne pas les soumettre au contrôle de version. Si vous utilisez Git, vous devez les ajouter à votre fichier .gitignore :
        echo ".auth0.*.json" >> .gitignore
+
+
        
+
+
        
+
+## Contrôle d’accès {{{ data-action="code" data-code="routes/api.php#6:16" }}}
+
+
+
        La trousse SDK enregistre automatiquement son gardien d’autorisation avec votre application Laravel pour l’utiliser avec le logiciel médiateur api, que Laravel applique par défaut à toutes les routes dans le fichier routes/api.php de votre application.
        Pour que la trousse SDK fonctionne comme prévu sans configuration supplémentaire, vous devez définir vos routes dans lefichierroutes/api.php.
        Vous pouvez utiliser la protection d’autorisation de la trousse SDK Auth0 pour restreindre l’accès aux routes de votre application.
        Pour rejeter les demandes qui ne contiennent pas de jeton d’accès valide dans l’en-tête Authorization, vous pouvez utiliser le logiciel médiateur auth de Laravel :
        Route::get('/private', function () {
+
+ return response()->json([
+
+ 'message' \=> 'Your token is valid; you are authorized.',
+
+ ]);
+
+})->middleware('auth');
+
+
        
+
+
        Vous pouvez également exiger que le jeton fourni dispose des permissions spécifiques en le combinant avec le logiciel médiateur can de Laravel :
        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');
+
+
        
+
+
        
+
+## Informations de jeton {{{ data-action="code" data-code="routes/api.php#18:30" }}}
+
+
+
        Les informations sur le jeton d’accès fourni sont disponibles via la façade Auth de Laravel, ou la fonction d’assistance auth().
        Par exemple, pour récupérer l’identificateur et l’adresse courriel de l’utilisateur :
        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(),
+
+ ]);
+
+});
+
+
        
+
+
        
+
+## Récupérer des informations sur l’utilisateur {{{ data-action="code" data-code="routes/api.php#32:51" }}}
+
+
+
        Vous pouvez récupérer des informations sur l’utilisateur créateur du jeton d’accès à partir d’Auth0 en utilisant Auth0 Management API. La trousse SDK fournit une enveloppe pratique pour cette API, accessible par le biais de la méthode management() de la trousse SDK.
        Avant de faire des appels à la Management API, vous devez permettre à votre application de communiquer avec Management API. Cela peut être fait à partir de la page API d’Auth0 Dashboard, en choisissant Auth0 Management API et en sélectionnant l’onglet Machine to Machine Applications (Communication entre machines). Autorisez votre application Laravel, puis cliquez sur la flèche vers le bas pour choisir les permissions que vous souhaitez accorder.
        Dans l’exemple suivant, vous devez accorder la permission read:users. Une liste des points de terminaison API et les permissions requises peuvent être trouvées dans la documentation de Management API.
        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');
+
+
        
+
+
        Vous devez mettre en cache les informations relatives aux utilisateurs dans votre application pendant de brèves périodes. Cela réduit le nombre de requêtes que votre application adresse à Auth0 et améliore les performances. Vous devez éviter de stocker des informations sur les utilisateurs dans votre application pendant de longues périodes, car cela peut conduire à des données obsolètes. Vous devez également éviter de stocker dans des bases de données persistantes des informations autres que l’identifiant de l’utilisateur.
        
+
+## Exécuter l’application
+
+
+
        Vous êtes maintenant prêt à lancer votre application Laravel, de sorte qu’elle puisse accepter les demandes :
        php artisan serve
+
+
        
+
+
        
+
+## Récupérer un jeton de test
+
+
+
        Pour en savoir plus sur la récupération des jetons d’accès, cliquez ici. Pour ce démarrage rapide, vous pouvez simplement utiliser un jeton d’accès à partir de l’affichage « test » des paramètres de votre API.
        La route /me que nous avons créée ci-dessus ne fonctionnera pas avec un jeton de test car aucun utilisateur réel n’y est associé.
        Démarrage rapide Laravel – Étape 8 – Point de contrôle 
        Ouvrez un shell et essayez d’envoyer des requêtes à votre application.
        Commencez par demander la route publique :
        curl --request GET \ --url http://localhost:8000/api \ --header ’Accept: application/json’
        Ensuite, utilisez votre jeton d’accès dans un en-tête Authorization pour demander une route protégée :
        curl --request GET \ --url http://localhost:8000/api/private \ --header ’Accept: application/json’ \ --header ’Authorization : Bearer YOUR_ACCESS_TOKEN’
        Enfin, essayez de demander la route protégée par des permissions, qui n’aboutira que si le jeton d’accès dispose de la permission read:messages :
        curl --request GET \ --url http://localhost:8000/api/scope \ --header ’Accept: application/json’ \ --header ’Authorization : Bearer YOUR_ACCESS_TOKEN’
        
+
+  
        
+
+  
        Essayez ce qui suit :
        • Exécutez php artisan optimize:clear pour vider le cache Laravel.
        • Assurez-vous que vos fichiers .auth0.app.json et .auth0.api.json se trouvent à la racine de votre projet.
        • Assurez-vous d’avoir activé votre application Laravel en tant qu’application de communication entre machines et de lui avoir accordé toutes les permissions nécessaires pour Auth0 Management API à partir de Auth0 Dashboard.
        Vous rencontrez des problèmes? Consultez la documentation de la trousse SDK ou notre centre de documentation. N’hésitez pas à consulter la communauté où notre équipe et d’autres membres pourront répondre à vos questions.
        
+
+  
        Lecture supplémentaire
        • Référentiels et modèles d’utilisateurs étend la trousse SDK Laravel Auth0 et permet d’utiliser des modèles d’utilisateurs personnalisés et de stocker et de récupérer des utilisateurs à partir d’une base de données.
        • Événements d’appels explique comment détecter les événements soulevés par la trousse SDK Laravel Auth0, pour personnaliser pleinement le comportement de votre intégration.
        • Le soutien de Management API est intégré à la trousse SDK Laravel Auth0, vous permettant d’interagir avec Management API à partir de votre application Laravel.
        
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..4f8b8f5734
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/nodejs/files/server.md
@@ -0,0 +1,43 @@
+---
+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..bb5c616179
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,317 @@
+---
+title: Ajouter une autorisation à votre application API Express.js
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application API Express.js, nouvelle ou existante, en utilisant le package express-oauth2-jwt-bearer.
+interactive:  true
+files:
+ - files/server
+github:
+  path: 01-Authorization-RS256
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application API Express.js
+
+
+
        Ce guide explique comment intégrer Auth0 à n’importe quelle application API Express.js, nouvelle ou existante, en utilisant le package express-oauth2-jwt-bearer.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, utilisez le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante pour votre projet.
        Pour configurer votre première API via Auth0 Dashboard, consultez notre guide de démarrage. Chaque API Auth0 utilise l’identificateur API, dont votre application a besoin pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard.
        null
        Cet exemple utilise la permission read:messages.
        
+
+## Installer les dépendances
+
+
+
        Tout d’abord, installez la trousse SDK avec npm.
        npm install --save express-oauth2-jwt-bearer
+
+
        
+
+
        
+
+## Configurer l’intergiciel {{{ data-action="code" data-code="server.js#1:10" }}}
+
+
+
        Configurez express-oauth2-jwt-bearer avec votre domaine et votre identificateur API.
        L’intergiciel checkJwt présenté à droite vérifie si le jeton d’accès de l’utilisateur inclus dans la demande est valide. Si le jeton n’est pas valide, l’utilisateur reçoit une erreur « 401 Authorization » (Autorisation 401) lorsqu’il tente d’accéder aux points de terminaison.
        L’intergiciel ne vérifie pas si le jeton dispose d’une permission suffisante pour accéder aux ressources demandées.
        
+
+## Protéger les points de terminaison des API {{{ data-action="code" data-code="server.js#12:32" }}}
+
+
+
        Pour protéger une route individuelle en exigeant un JWT valide, configurez la route avec le logiciel médiateur checkJwt développé à partir de express-oauth2-jwt-bearer.
        Vous pouvez configurer des routes individuelles pour qu’elles recherchent une permission particulière. Pour ce faire, configurez un autre logiciel médiateur avec la méthode requiresScope. Fournissez les permissions requises et appliquez le logiciel médiateur à toutes les routes auxquelles vous souhaitez ajouter une autorisation.
        Transmettez les logiciels médiateurs checkJwt et requiredScopes à la route que vous souhaitez protéger.
        Dans cette configuration, seuls les jetons d’accès avec la permission read:messages peuvent accéder au point de terminaison.
        Faire un appel à votre API
        Pour appeler votre API, vous avez besoin d’un jeton d’accès. Vous pouvez obtenir un jeton d’accès à des fins de test dans la vue Test dans vos API settings (Paramètres API).
        null
        Fournir le Jeton d’accès comme un en-tête Authorization dans vos demandes.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http:///%7ByourDomain%7D/api_path \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///%7ByourDomain%7D/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///%7ByourDomain%7D/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///%7ByourDomain%7D/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///%7ByourDomain%7D/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///%7ByourDomain%7D/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///%7ByourDomain%7D/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "%7ByourDomain%7D/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///%7ByourDomain%7D/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///%7ByourDomain%7D/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        API Node JS - Étape 4 - Point de contrôle 
        Maintenant que vous avez configuré votre application, exécutez-la pour vérifier que :
        • GET /api/public est disponible pour les demandes non authentifiées.
        • GET /api/private est disponible pour les demandes authentifiées.
        • GET /api/private-scoped est disponible pour les demandes authentifiées contenant un jeton d’accès avec la permission read:messages.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré avec succès :
        • Vérifiez que vous avez ajouté le jeton en tant qu’en-tête d'autorisation
        • Assurez-vous que le jeton est doté des permissions appropriées. Vérifiez avec jwt.io.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..5a0ab723f3
--- /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..73c5831f3c
--- /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..ff549c5a65
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/php/interactive.md
@@ -0,0 +1,66 @@
+---
+title: Ajouter une autorisation à votre application PHP
+description: Ce guide explique comment intégrer Auth0, ajouter une autorisation basée sur un jeton et protéger les routes de l’application en utilisant la trousse SDK Auth0 PHP.
+interactive:  true
+files:
+ - files/index
+ - files/router
+github:
+  path: app
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application PHP
+
+
+
        Auth0 vous permet d’ajouter rapidement une autorisation de point de terminaison basée sur un jeton à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter une autorisation basée sur un jeton et protéger les routes de l’application en utilisant la trousse SDK Auth0 PHP.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Avoir un projet PHP fonctionnel que vous souhaitez intégrer à Auth0. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application enregistrée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous configurez le fonctionnement de l’authentification pour votre projet.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionnez une application existante qui représente le projet que vous souhaitez intégrer. Dans Auth0, il est attribué à chaque application un identificateur client unique alphanumérique que votre code d’application utilise pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer une API
        De même, vous devez créer une nouvelle API Auth0 ou utiliser une API existante qui représente le projet que vous intégrez à partir du Dashboard. Choisissez un identificateur unique pour l’API et notez-le. Cet identificateur vous sera nécessaire pour configurer votre application ci-dessous.
        
+
+## Installer la trousse SDK PHP Auth0 {{{ data-action="code" data-code="index.php" }}}
+
+
+
        Auth0 fournit une trousse SDK PHP (Auth0-PHP) pour simplifier le processus de mise en œuvre de l’authentification et de l’autorisation Auth0 dans les applications PHP.
        La trousse SDK PHP Auth0 nécessite l’installation des bibliothèques HTTP compatibles PSR-17 et PSR-18 pour la gestion des requêtes réseau. Si vous ne disposez pas de bibliothèques disponibles, vous pouvez installer des choix fiables en exécutant les commandes suivantes dans votre terminal :
        cd <your-project-directory>
+
+    composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        Installez maintenant la trousse SDK PHP Auth0 en exécutant la commande suivante dans votre terminal :
        composer require auth0/auth0-php
+
+
        
+
+
        Configurer la trousse SDK Auth0
        Pour que la trousse SDK fonctionne correctement, vous devez définir les propriétés suivantes dans la trousse SDK Auth0 lors de l’initialisation :
        • strategy : La stratégie aide à orienter le comportement du SDK en ce qui concerne l’utilisation de votre application. Dans ce cas, vous souhaitez la définir sur la constante
          Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API
        • domain : Le domaine de votre locataire Auth0. En général, vous le trouverez dans Auth0 Dashboard dans Application Settings (Paramètres d’application) dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • clientId : L’identifiant de l’application Auth0 que vous avez configurée précédemment dans le démarrage rapide. Vous pouvez le trouver dans Auth0 Dashboard, dans la rubrique des paramètres de votre application, dans le champ Client ID (ID client).
        • clientSecret : Le secret de l’application Auth0 que vous avez créée plus tôt dans le démarrage rapide. Le secret client se trouve dans Auth0 Dashboard, dans Application Settings (Paramètres d’application) dans le champ Client Secret (Secret client).
        • public : L’identificateur de l’API Auth0 que vous avez enregistré ci-dessus. Il doit être fourni sous la forme d’un tableau.
        API PHP - Étape 2 - Point de contrôle 
        Votre trousse SDK Auth0 est maintenant correctement configurée. Exécutez votre application pour vérifier que :
        • la trousse SDK s’initialise correctement,
        • votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Assurez-vous que la bonne application est sélectionnée
        • Avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • Assurez-vous que le domaine et l’identifiant client ont été importés correctement.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Détecter les jetons du porteur {{{ data-action="code" data-code="index.php#20:23" }}}
+
+
+
        Développez ensuite votre application pour récupérer et traiter les jetons de porteur. Les jetons de porteur sont des jetons d’accès fournis à votre API avec des demandes de clients au nom d’un utilisateur. Les jetons d’accès approuvent ou refusent l’accès aux routes de votre application. C’est ce que l’on appelle l’autorisation de point de terminaison.
        La méthode la plus simple pour récupérer les jetons d’accès à partir d’une requête est la méthode getBearerToken() de la trousse SDK PHP. Cette méthode récupère les jetons à partir des paramètres GET, des corps POST, des en-têtes de requête et d’autres sources. Dans ce cas, la trousse SDK PHP traite les jetons transmis par les requêtes GET dans le paramètre token ou dans l’en-tête HTTP Authorization.
        
+
+## Créer et configurer des routes {{{ data-action="code" data-code="router.php" }}}
+
+
+
        Maintenant, installez une bibliothèque de routage pour aider à diriger les requêtes entrantes vers votre application. Cette étape n’est pas obligatoire, mais elle simplifie la structure de l’application pour les besoins de ce guide rapide.
        composer require steampixel/simple-php-router
+
+
        
+
+
        Créez un nouveau fichier dans votre application appelé router.php pour définir les routes. Copiez le code du panneau interactif à droite sous l’onglet router.php.
        
+
+## Configurer l’autorisation des points de terminaison {{{ data-action="code" data-code="router.php#21:31" }}}
+
+
+
        Maintenant que vous avez configuré votre application Auth0, la trousse SDK PHP Auth0, et que votre application récupère les jetons de porteur des requêtes, l’étape suivante est de configurer l’autorisation des points de terminaison pour votre projet. La méthode getBearerToken() que vous avez mise en œuvre ci-dessus renvoie une classe Token qui contient des informations sur l’accès à la requête.
        Étant donné que la méthode getBearerToken() valide et vérifie automatiquement la requête entrante, votre application détermine les détails du jeton d’accès en évaluant la réponse de la méthode. Si la réponse est nulle, c’est qu’aucun jeton valide n’a été fourni. Dans le cas contraire, inspectez le contenu de la réponse pour en savoir plus sur la demande.
        Dans le panneau interactif à droite, une validation de la réponse (null ou non) permet de filtrer l’accès à la route /api/private.
        
+
+## Autoriser avec des permissions {{{ data-action="code" data-code="router.php#33:48" }}}
+
+
+
        Dans certains cas, vous pouvez souhaiter filtrer l’accès à une route particulière en fonction des permissions demandées dans un jeton d’accès. Comme le montre le panneau interactif de droite, évaluez le contenu de la propriété ’scope’ de la réponse de la méthode getBearerToken() pour vérifier les permissions accordées par le jeton d’accès.
        
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..7d7c5c8bc9
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/python/files/server.md
@@ -0,0 +1,55 @@
+---
+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..bda3edb8ca
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/python/files/validator.md
@@ -0,0 +1,28 @@
+---
+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..d05b8a78a6
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,318 @@
+---
+title: Ajouter une autorisation à votre application API Flask
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle API Python, nouvelle ou ancienne, développée avec Flask.
+interactive:  true
+files:
+ - files/validator
+ - files/server
+github:
+  path: 00-Starter-Seed
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application API Flask
+
+
+
        Ce guide explique comment intégrer Auth0 à n’importe quelle API Python, nouvelle ou ancienne, développée avec Flask.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante qui représente le projet avec lequel vous souhaitez vous intégrer.
        Vous pouvez également lire notre guide de démarrage qui vous aide à configurer votre première API via Auth0 Dashboard.
        Toute API dans Auth0 est configurée à l’aide d’un identificateur d’API que votre code d’application utilisera comme Audience (Public) pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès en particulier. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section APIs (API) d'Auth0 Dashboard.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        Cet exemple utilise la permission read:messages.
        
+
+## Installer des dépendances
+
+
+
        Ajoutez les dépendances suivantes à votre fichier requirements.txt :
        # /requirements.txt
+
+
+
+    flask
+
+    Authlib
+
+
        
+
+
        
+
+## Créer le validateur JWT {{{ data-action="code" data-code="validator.py" }}}
+
+
+
        Nous allons utiliser une bibliothèque appelée Authlib pour créer un ResourceProtector, qui est un type de Flask decorator qui protège nos ressources (routes API) avec un validateur donné.
        Le validateur validera le jeton d’accès que nous transmettons à la ressource en vérifiant qu’il a une signature et des demandes valides.
        Nous pouvons utiliser le validateur JWTBearerTokenValidator d’AuthLib avec quelques ajustements pour nous assurer qu’il est conforme à nos exigences de validation des jetons d’accès.
        Pour créer notre Auth0JWTBearerTokenValidator, nous devons lui transmettre notre domain et notre audience (Identificateur API). Il obtiendra alors la clé publique nécessaire pour vérifier la signature du jeton et la transmettra à la classe JWTBearerTokenValidator.
        Nous remplacerons ensuite les claims_options de la classe pour nous assurer que les demandes d’échéance, de public et d’émission du jeton sont validées selon nos exigences.
        
+
+## Créer une application Flask {{{ data-action="code" data-code="server.py" }}}
+
+
+
        Ensuite, nous allons créer une application Flask avec 3 routes API :
        • /api/public Un point de terminaison public qui ne nécessite aucune authentification.
        • /api/private Un point de terminaison privé qui nécessite un jeton d’accès JWT valide.
        • /api/private-scoped Un point de terminaison privé qui nécessite un jeton d’accès JWT valide contenant la scope donnée.
        Les routes protégées auront un décorateur require_auth, qui est un ResourceProtector qui utilise le Auth0JWTBearerTokenValidator que nous avons créé précédemment.
        Pour créer Auth0JWTBearerTokenValidator, nous devons lui transmettre le domaine de notre locataire et l’identificateur de l’API que nous avons créée précédemment.
        Le decorator require_auth sur la route private_scoped prend en charge un argument supplémentaire "read:messages", qui vérifie la permission du jeton d’accès que nous avons créé précédemment.
        Faire un appel à votre API
        Pour appeler votre API, vous avez besoin d’un jeton d’accès. Vous pouvez obtenir un jeton d’accès à des fins de test dans la vue Test dans vos API settings (Paramètres API).
        Auth0 Dashboard> Applications > API > [API specifique] > Onglet Test
        Fournir le jeton d’accès comme un en-tête Authorization dans vos demandes.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
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/app/controllers/application_controller.md b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
new file mode 100644
index 0000000000..75520386ba
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
@@ -0,0 +1,12 @@
+---
+name: app/controllers/application_controller.rb
+language: powershell
+---
+    
+```powershell
+    # frozen_string_literal: true
+
+    class ApplicationController < ActionController::API
+      include Secured
+    end
+```
diff --git a/fr-ca/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
new file mode 100644
index 0000000000..c6529ef19b
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
@@ -0,0 +1,67 @@
+---
+name: app/controllers/concerns/secured.rb
+language: powershell
+---
+    
+```powershell
+    # 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/files/app/controllers/private_controller.md b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
new file mode 100644
index 0000000000..336740f6cd
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/private_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/app/controllers/public_controller.md b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
new file mode 100644
index 0000000000..f8a6db5aff
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/public_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/app/lib/auth0_client.md b/fr-ca/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
new file mode 100644
index 0000000000..079089b4d9
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
@@ -0,0 +1,66 @@
+---
+name: app/lib/auth0_client.rb
+language: powershell
+---
+    
+```powershell
+    # 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
+```
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..cb3202986b
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,338 @@
+---
+title: Ajouter une autorisation à votre API Ruby on Rails
+description: Ce tutoriel effectue la validation des jetons d’accès en utilisant le gem jwt dans une classe Auth0Client personnalisée.
+interactive:  true
+files:
+ - files/app/controllers/application_controller
+ - files/app/lib/auth0_client
+ - files/app/controllers/concerns/secured
+ - files/app/controllers/public_controller
+ - files/app/controllers/private_controller
+github:
+  path: 01-Authentication-RS256
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre API Ruby on Rails
+
+
+
        Ce tutoriel effectue la validation des jetons d’accès en utilisant le gem jwt dans une classe Auth0Client personnalisée. Un concern appelé Secured est utilisé pour autoriser les points de terminaison qui nécessitent une authentification par le biais d’un jeton d’accès entrant.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante pour votre projet.
        Pour configurer votre première API via Auth0 Dashboard, consultez notre guide de démarrage.
        Chaque API Auth0 utilise l’identificateur API, dont votre application a besoin pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        Cet exemple utilise la permission read:messages.
        
+
+## Installer les dépendances
+
+
+
        Installer le gem jwt.
        gem 'jwt'
+
+    bundle install
+
+
        
+
+
        
+
+## Créer une classe Auth0Client {{{ data-action="code" data-code="app/controllers/concerns/secured.rb" }}}
+
+
+
        Créez une classe appelée Auth0Client. Cette classe décode et vérifie le jeton d’accès entrant provenant de l’en-tête Authorization  de la requête.
        La classe Auth0Client récupère la clé publique de votre locataire Auth0 et l’utilise pour vérifier la signature du jeton d’accès. La structure Token définit une méthode validate_permissions pour rechercher une scope particulière dans un jeton d’accès en fournissant un tableau des permissions requises et en vérifiant si elles sont présentes dans la charge utile du jeton.
        
+
+## Définir un concern Secured {{{ data-action="code" data-code="app/controllers/concerns/secured.rb" }}}
+
+
+
        Créez un concern appelé Secured qui recherche le jeton d’accès dans l’en-tête Authorization d’une requête entrante.
        Si le jeton est présent, Auth0Client.validate_token utilisera le gem jwt pour vérifier la signature du jeton et valider les demandes du jeton.
        Outre la vérification de la validité du jeton d’accès, concern possède un mécanisme permettant de confirmer que le jeton dispose d’une permission suffisante pour accéder aux ressources demandées. Dans cet exemple, nous définissons une méthode validate_permissions qui reçoit un bloc et vérifie les autorisations en appelant la méthode Token.validate_permissions de la classe Auth0Client.
        Pour la route /private-scoped, les permissions définies seront croisées avec les permissions provenant de la charge utile, afin de déterminer si elle contient un ou plusieurs éléments de l’autre tableau.
        
+
+## Inclure la préoccupation Secure dans votre ApplicationController {{{ data-action="code" data-code="app/controllers/application_controller.rb" }}}
+
+
+
        En ajoutant la préoccupation Secure à votre contrôleur d’application, vous n’aurez plus qu’à utiliser un filtre before_action dans le contrôleur qui requiert une autorisation.
        
+
+## Créer le point de terminaison public {{{ data-action="code" data-code="app/controllers/public_controller.rb" }}}
+
+
+
        Créez un contrôleur pour gérer le point de terminaison public /api/public.
        Le point de terminaison /public ne requiert aucune autorisation et aucune before_action n’est donc nécessaire.
        
+
+## Créer les points de terminaison privés {{{ data-action="code" data-code="app/controllers/private_controller.rb" }}}
+
+
+
        Créez un contrôleur pour traiter les points de terminaison privés : /api/private et /api/private-scoped.
        /api/private est disponible pour les requêtes authentifiées contenant un jeton d’accès sans permission supplémentaire.
        /api/private-scoped est disponible pour les requêtes authentifiées contenant un jeton d’accès dont la permission read:messages est accordée.
        Les points de terminaison protégés doivent appeler la méthode authorize du concern Secured; vous devez pour cela utiliser before_action :authorize, ce qui assure que la méthode Secured.authorize est appelée avant chaque action dans le PrivateController.
        Faire un appel à votre API
        Pour appeler votre API, vous avez besoin d’un jeton d’accès. Vous pouvez obtenir un jeton d’accès à des fins de test dans la vue Test dans vos API settings (Paramètres API).
        Auth0 Dashboard> Applications > API > [API specifique] > Onglet Test
        Fournissez le jeton d’accès comme un en-tête Authorization dans vos demandes.
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Ruby on Rails - Étape 7- Point de contrôle 
        Maintenant que vous avez configuré votre application, exécutez-la pour vérifier que :
        • GET /api/public est disponible pour les demandes non authentifiées.
        • GET /api/private est disponible pour les demandes authentifiées.
        • GET /api/private-scoped est disponible pour les demandes authentifiées contenant un jeton d’accès avec la permission read:messages.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré avec succès :
        • Vérifiez que vous avez ajouté le jeton en tant qu’en-tête d'autorisation
        • Assurez-vous que le jeton est doté des permissions appropriées. Vérifiez avec jwt.io.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/ApiController.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/ApiController.md
new file mode 100644
index 0000000000..f2c2cd153e
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/ApiController.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."
+        });
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md
new file mode 100644
index 0000000000..f15111e01b
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.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) };
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md
new file mode 100644
index 0000000000..6d78b4041a
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.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);
+    }
+}
+```
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..015db9db1d
--- /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);
+}
+```
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..f971d46fe9
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/webapi-owin/interactive.md
@@ -0,0 +1,58 @@
+---
+title: Ajouter une autorisation à votre application API ASP.NET OWIN Web
+description: Ce tutoriel explique comment ajouter une autorisation à une API ASP.NET OWIN en utilisant le logiciel médiateur JWT standard.
+interactive:  true
+files:
+ - files/Startup
+ - files/OpenIdConnectSigningKeyResolver
+ - files/ScopeAuthorizeAttribute
+ - files/ApiController
+github:
+  path: Quickstart/Sample
+locale: fr-CA
+---
+
+# Ajouter une autorisation à votre application API ASP.NET OWIN Web
+
+
+
        Auth0 vous permet d’ajouter une autorisation à n’importe quel type d’application. Ce guide explique comment intégrer Auth0 à n’importe quelle application API ASP.NET Owin Web, nouvelle ou ancienne, à l’aide du package Microsoft.Owin.Security.Jwt.
        Si vous n’avez pas encore créé d’API dans votre Auth0 Dashboard, vous pouvez utiliser le sélecteur interactif pour créer une nouvelle API Auth0 ou sélectionner une API existante pour votre projet.
        Pour configurer votre première API via Auth0 Dashboard, consultez notre guide de démarrage.
        Chaque API Auth0 utilise l’identificateur API, dont votre application a besoin pour valider le jeton d’accès.
        Vous ne connaissez pas Auth0 ? Découvrez Auth0 et l’implémentation de l’authentification et de l’autorisation d’API en utilisant le cadre d’applications OAuth 2.0.
        
+
+## Définir les autorisations
+
+
+
        Les autorisations vous permettent de définir comment les ressources peuvent être accessibles au nom de l’utilisateur avec un jeton d’accès donné. Par exemple, vous pouvez choisir d’accorder un accès en lecture à la ressource messages si les utilisateurs ont le niveau d’accès gestionnaire et un accès en écriture à cette ressource s’ils ont le niveau d’accès administrateur.
        Vous pouvez définir les autorisations autorisées dans la vue Permissions (Autorisations) de la section API d’Auth0 Dashboard. L’exemple suivant utilise la permission read:messages.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        
+
+## Installer les dépendances
+
+
+
        Installez le NuGetPackage Microsoft.Owin.Security.Jwt. Ce package contient l’intergiciel OWIN JWT nécessaire pour utiliser les jetons d’accès Auth0 dans l’API Web ASP.NET Owin.
        Install-Package Microsoft.Owin.Security.Jwt
+
+
        
+
+
        
+
+## Configurer l’intergiciel {{{ data-action="code" data-code="Startup.cs" }}}
+
+
+
        Allez dans la méthode de Configuration de votre classe Startup et ajoutez un appel à UseJwtBearerAuthentication passant dans les JwtBearerAuthenticationOptions configurées.
        JwtBearerAuthenticationOptions doit indiquer votre identificateur API Auth0 dans la propriété ValidAudience et le chemin complet vers votre domaine Auth0 en tant que ValidIssuer. Vous devrez configurer l’instance IssuerSigningKeyResolver pour utiliser l’instance OpenIdConnectSigningKeyResolver afin de résoudre la clé de connexion.
        N’oubliez pas la barre oblique finale.
        Assurez-vous que l’URL précisée pour ValidIssuer contient une barre oblique (/) finale. Cela doit correspondre exactement à la demande de l’émetteur JWT. Les appels d’API ne s’authentifieront pas correctement si vous avez mal configuré cette valeur.
        
+
+## Vérifier la signature du jeton {{{ data-action="code" data-code="OpenIdConnectSigningKeyResolver.cs" }}}
+
+
+
        Le logiciel médiateur OWIN JWT n’utilise pas Open ID Connect Discovery par défaut, vous devez donc fournir un IssuerSigningKeyResolver personnalisé.
        Créez la classe OpenIdConnectSigningKeyResolver et assurez-vous de retourner la bonne SecurityKey en implémentant GetSigningKey. Cette classe est ensuite utilisée comme TokenValidationParameters.IssuerSigningKeyResolver lors de la configuration du logiciel médiateur dans Startup.cs.
        
+
+## Valider les permissions {{{ data-action="code" data-code="ScopeAuthorizeAttribute.cs" }}}
+
+
+
        Le logiciel médiateur JWT vérifie que le jeton d’accès inclus dans la requête est valide; cependant, il n’inclut pas encore de mécanisme pour vérifier que le jeton a une scope (permission) suffisante pour accéder aux ressources demandées.
        Créez une classe appelée ScopeAuthorizeAttribute qui hérite de System.Web.Http.AuthorizeAttribute. Cet attribut vérifiera que la demande de scope émise par votre locataire Auth0 est présente, et si oui, il assurera que la demande de scope  contient la permission demandée.
        
+
+## Protéger les points de terminaison des API {{{ data-action="code" data-code="ApiController.cs" }}}
+
+
+
        Les routes ci-dessous sont disponibles pour les demandes suivantes :
        • GET /api/public : Disponible pour les demandes non authentifiées.
        • GET /api/private : Disponible pour les demandes authentifiées contenant un jeton d’accès sans permission supplémentaire.
        • GET /api/private-scoped : Disponible pour les demandes authentifiées contenant un jeton d’accès dont la permission read:messages est accordée.
        L’intergiciel JWT s’intègre aux mécanismes d’authentification et d’autorisation standard d’ASP.NET, vous n’avez donc qu’à décorer votre action de contrôleur avec l’attribut [Authorize] pour obtenir un point de terminaison.
        Mettez à jour l’action avec l’attribut ScopeAuthorize et passez le nom de la scope requise dans le paramètre scope. Cela garantit que la permission adéquate est disponible pour appeler un point de terminaison d’API donné.
        Guide rapide ASP.NET API OWIN - Étape 6 - Point de contrôle 
        Maintenant que vous avez configuré votre application, lancez votre application et vérifiez que :
        • GET /api/public est disponible pour les demandes non authentifiées.
        • GET /api/private est disponible pour les demandes authentifiées.
        • GET /api/private-scoped est disponible pour les demandes authentifiées contenant un jeton d’accès avec la permission read:messages.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré avec succès :
        • Assurez-vous que les valeurs ValidIssuer et ValidAudience sont correctement configurées
        • Vérifiez que vous avez ajouté le jeton en tant qu’en-tête d'autorisation
        • Assurez-vous que le jeton est doté des permissions appropriées. Vérifiez avec jwt.io.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/snippets/application-platforms/emberjs/dependencies.md b/fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
similarity index 100%
rename from snippets/application-platforms/emberjs/dependencies.md
rename to fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
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/files/exchangeTokens.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
new file mode 100644
index 0000000000..c2593142a7
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
@@ -0,0 +1,26 @@
+---
+name: exchangeTokens
+language: kotlin
+---
+    
+```kotlin
+private fun exchangeTokens(
+        sessionToken: String,
+        userProfile: String,
+        callback: SimpleCallback
+    ) {
+        val params = mapOf("user_profile" to userProfile)
+        apiClient.loginWithNativeSocialToken(sessionToken, FACEBOOK_SUBJECT_TOKEN_TYPE)
+            .setScope(AUTH0_SCOPE)
+            .addParameters(params)
+            .start(object : Callback {
+                override fun onFailure(error: AuthenticationException) {
+                    callback.onError(error)
+                }
+
+                override fun onSuccess(result: Credentials) {
+                    callback.onResult(result)
+                }
+            })
+    }
+```
diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
new file mode 100644
index 0000000000..24232d1f4c
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
@@ -0,0 +1,35 @@
+---
+name: fetchSessionToken
+language: kotlin
+---
+    
+```kotlin
+private fun fetchSessionToken(token: String, callback: SimpleCallback) {
+        val params = Bundle().apply {
+            putString("grant_type", "fb_attenuate_token")
+            putString("fb_exchange_token", token)
+            putString("client_id", getString(R.string.facebook_app_id))
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = "oauth/access_token"
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            if (response.error != null) {
+                callback.onError(response.error?.exception!!)
+                return@Callback
+            }
+
+            try {
+                val fbSessionToken = response.jsonObject!!.getString("access_token")
+                callback.onResult(fbSessionToken)
+            } catch (jsonException: JSONException) {
+                //Failed to parse session token
+                callback.onError(jsonException)
+            }
+        }
+        request.executeAsync()
+    }
+```
diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
new file mode 100644
index 0000000000..d54981f1d4
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
@@ -0,0 +1,32 @@
+---
+name: fetchUserProfile
+language: kotlin
+---
+    
+```kotlin
+private fun fetchUserProfile(token: String, userId: String, callback: SimpleCallback) {
+
+        val params = Bundle().apply {
+            putString("access_token", token)
+            putString("fields", "first_name,last_name,email")
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = userId
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            val error = response.error
+            if (error != null) {
+                //Failed to fetch user profile
+                callback.onError(error.exception!!)
+                return@Callback
+            }
+            //Handle back the profile as received
+            callback.onResult(response.rawResponse!!)
+        }
+
+        request.executeAsync()
+    }
+```
diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/files/onCreate.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/onCreate.md
new file mode 100644
index 0000000000..1102e17fb5
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/onCreate.md
@@ -0,0 +1,41 @@
+---
+name: onCreate
+language: kotlin
+---
+    
+```kotlin
+override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+
+        FacebookSdk.setClientToken(getString(R.string.facebook_client_token))
+        FacebookSdk.sdkInitialize(this)
+
+        setContentView(R.layout.activity_login)
+
+        val auth0 =
+            Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain))
+        apiClient = AuthenticationAPIClient(auth0)
+
+        fbCallbackManager = CallbackManager.Factory.create()
+
+        val loginButton = findViewById(R.id.login_button).apply {
+            setPermissions(*FACEBOOK_PERMISSIONS)
+        }
+
+        loginButton.registerCallback(fbCallbackManager, object : FacebookCallback {
+            override fun onSuccess(result: LoginResult) {
+
+                val accessToken = result.accessToken
+                performLogin(accessToken)
+            }
+
+            override fun onCancel() {
+                Log.i(TAG, "Facebook sign-in cancelled")
+            }
+
+            override fun onError(error: FacebookException) {
+                Log.e(TAG, "Error {error.message}")
+            }
+        })
+    }
+```
diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md
new file mode 100644
index 0000000000..6645fdf0d8
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md	
@@ -0,0 +1,12 @@
+---
+name: performLogin + SimpleCallback
+language: kotlin
+---
+    
+```kotlin
+private interface SimpleCallback {
+  fun onResult(result: T)
+
+  fun onError(cause: Throwable)
+}
+```
diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin.md b/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin.md
new file mode 100644
index 0000000000..84a6251bd1
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/files/performLogin.md
@@ -0,0 +1,41 @@
+---
+name: performLogin
+language: kotlin
+---
+    
+```kotlin
+private fun performLogin(accessToken: AccessToken) {
+        val token = accessToken.token
+        fetchSessionToken(token, object : SimpleCallback {
+            override fun onResult(sessionToken: String) {
+                //2. Obtained the Facebook session token
+                fetchUserProfile(token, accessToken.userId, object : SimpleCallback {
+                    override fun onResult(userProfile: String) {
+                        //3. Obtained the user profile
+                        exchangeTokens(
+                            sessionToken,
+                            userProfile,
+                            object : SimpleCallback {
+                                override fun onResult(credentials: Credentials) {
+                                    //4. Exchanged the tokens
+                                    Log.i(TAG, "Logged in to Auth0")
+                                }
+
+                                override fun onError(cause: Throwable) {
+                                    Log.e(TAG, "Error exchanging tokens", cause)
+                                }
+                            })
+                    }
+
+                    override fun onError(cause: Throwable) {
+                        Log.e(TAG, "Error fetching the profile", cause)
+                    }
+                })
+            }
+
+            override fun onError(cause: Throwable) {
+                Log.e(TAG, "Error fetching the session token", cause)
+            }
+        })
+    }
+```
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..c4db748f26
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/index.yml
@@ -0,0 +1,55 @@
+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
+hidden_articles:
+  - interactive
+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-facebook-login/interactive.md b/fr-ca/articles/quickstart/native/android-facebook-login/interactive.md
new file mode 100644
index 0000000000..a61a7c178b
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android-facebook-login/interactive.md
@@ -0,0 +1,129 @@
+---
+title: Android – Connexion Facebook
+description: Ce tutoriel explique comment ajouter la connexion utilisateur à une application Android à l’aide de la méthode native Connexion Facebook.
+interactive:  true
+files:
+ - files/performLogin + SimpleCallback
+ - files/onCreate
+ - files/fetchSessionToken
+ - files/fetchUserProfile
+ - files/exchangeTokens
+ - files/performLogin
+github:
+  path: 00-login-facebook
+locale: fr-CA
+---
+
+# Android – Connexion Facebook
+
+
+
        Ce tutoriel explique comment ajouter la connexion utilisateur à une application Android à l’aide de la méthode native Connexion Facebook. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.
        Configurations requise
        • Android Studio 3.6.1
        • Trousse SDK Android 25
        • Émulateur - Nexus 5X - Android 6.0
        Ce tutoriel décrit comment mettre en œuvre la connexion avec la trousse SDK Facebook.
        Avant de commencer
        • Installez et configurez la trousse SDK Connexion Facebook. Vous découvrirez également le processus de création d’une application Facebook sur https://developers.facebook.com. À la fin de cette étape, vous devriez avoir une application mobile fonctionnant avec la fonction de connexion Facebook intégrée.
        Configurez votre application Auth0 dans le Dashboard pour utiliser la fonction Connexion Facebook en mode natif. Voir Ajouter une connexion Facebook aux applications natives. À la fin de cette étape, votre application sera en mesure d’implémenter la fonction Connexion Facebook en mode natif.
        
+
+## Demande d’autorisations Facebook
+
+
+
        Votre application est déjà capable de se connecter à Facebook. Cependant, pour garantir un profil utilisateur riche, vous devez mettre à jour les autorisations avec lesquelles le bouton de connexion Facebook a été configuré.
        Définissez les autorisations demandées sur public_profile et email. De cette manière, l’adresse courriel de l’utilisateur sera également incluse dans la réponse, à condition que la demande d’accès soit acceptée par l’utilisateur.
        loginButton.setPermissions(Arrays.asList("public_profile", "email"));
        
+
+## Créer la méthode performLogin {{{ data-action="code" data-code="performLogin + SimpleCallback" }}}
+
+
+
        Maintenant, pour lancer le processus d’authentification avec Auth0, créez une nouvelle méthode où vous préparerez la charge utile à envoyer.
        Vous utiliserez une interface simple pour gérer nos rappels internes.
        Dans l’exemple, la méthode s’appelle performLogin et l’interface SimpleCallback. Ajoutez les deux.
        
+
+## Appeler la méthode performLogin {{{ data-action="code" data-code="onCreate" }}}
+
+
+
        Maintenant, appelez la méthode de la méthode onSuccess de rappel (Callback) de connexion Facebook.
        
+
+## Intégrer Facebook
+
+
+
        Lorsque vous vous connectez à Facebook avec Auth0, le système dorsal effectue des vérifications en arrière-plan pour s’assurer que l’utilisateur est bien celui qu’il prétend être. Pour ce faire, il faut lui fournir un jeton d’accès à la session.
        En outre, si un utilisateur doit être créé sur Auth0 pour représenter cet utilisateur Facebook, le système dorsal aura besoin de certaines de ses informations, comme le nom, le nom de famille et l’adresse électronique. L’adresse électronique, si elle est fournie, sera signalée comme non vérifiée dans le profil utilisateur Auth0.
        Pour obtenir le jeton d’accès de session et le profil utilisateur, deux requêtes supplémentaires doivent être effectuées auprès de l’API Facebook.
        
+
+## Récupérer le jeton d’accès à la session Facebook {{{ data-action="code" data-code="fetchSessionToken" }}}
+
+
+
        Effectuez une nouvelle requête GET vers le point de terminaison /oauth/access_token de l’API Facebook. Utilisez les paramètres de requête suivants :
        • grant_type : fb_attenuate_token.
        • fb_exchange_token : le jeton d’accès reçu lors de la connexion.
        • client_id : l’identifiant de votre application. Cette valeur provient du tableau de bord du développeur Facebook et devrait déjà être utilisée dans votre application si vous avez réussi à intégrer la connexion Facebook.
        Placez la logique de cette étape dans sa propre méthode. Vous effectuerez cet appel plus tard, à partir de la méthode ajoutée précédemment.
        L’exemple utilise la classe GraphRequest de la trousse SDK Facebook pour effectuer cette demande.
        
+
+## Récupérer le profil utilisateur Facebook {{{ data-action="code" data-code="fetchUserProfile" }}}
+
+
+
        Effectuez à présent une autre demande GET, comme dans l’étape précédente. Le chemin du point de terminaison correspondra à la valeur de l’identificateur de l’utilisateur figurant dans le résultat de la connexion Facebook (p. ex., /904636746222815). Utilisez les paramètres suivants :
        • access_token : le jeton d’accès reçu lors de la connexion.
        • fields : les champs du profil utilisateur que vous souhaitez récupérer dans la réponse. Ces champs sont directement liés aux autorisations du bouton de connexion Facebook qui ont été configurées au début. Lorsqu’une autorisation est facultative, l’utilisateur doit d’abord consentir à y donner accès. Pour inscrire un utilisateur à Auth0, le nom complet et l’adresse électronique suffisent.
        
+
+## Intégrer Auth0
+
+
+
        Maintenant que les artefacts requis ont été obtenus, vous êtes prêt à les échanger contre les identifiants utilisateur Auth0, comme l’identifiant et les jetons d’accès. Mais d’abord, vous devez configurer la trousse SDK Auth0 pour qu’il effectue cette dernière demande.
        Obtenir les clés de votre application
        1. Allez dans la section Applications de Auth0 Dashboard et sélectionnez l’application existante dans laquelle vous avez activé la fonction Sign in with Facebook (Se connecter avec Facebook). Si vous avez besoin d’aide pour cette étape, veuillez consulter la section des exigences en haut de cet article.
        2. Copiez les valeurs Domaine et Identifiant client de la page des paramètres de l’application. Ces valeurs sont requises par la trousse SDK.
        3. Créez deux nouvelles ressources dans le fichier strings.xml de votre application Android pour les stocker. Les noms des clés doivent correspondre à ceux utilisés ci-dessous :
+
+
          <resources>
+
+    <string name="com_auth0_domain">${account.namespace}</string>
+
+    <string name="com_auth0_client_id">${account.clientId}</string>
+
+</resources>
+
+
          
+
+
        Installer la trousse SDK Auth0
        Dans votre application Android, ajoutez cette ligne au fichier app/build.gradle :
        dependencies {
+
+    implementation 'com.auth0.android:auth0:1.+'
+
+}
+
+
        
+
+
        Il est maintenant temps d’exécuter la tâche Gradle Sync pour actualiser le projet et ses dépendances.
        Mise à jour du manifeste pour l’authentification Web
        Si votre application ne prévoit pas d’utiliser le module d’authentification Web fourni par la trousse SDK, vous devrez supprimer l’activité inutilisée du fichier AndroidManifest.xml pour éviter les problèmes liés au placeholder du manifeste. Pour ce faire, il suffit d’ajouter une déclaration d’activité et de l’annoter avec tools:node="remove".
        <application>
+
+  <!-- Add the activity declaration line below -->
+
+   <activity
+
+    android:name="com.auth0.android.provider.AuthenticationActivity"
+
+    tools:node="remove" />
+
+
+
+</application>
+
+
        
+
+
        Toutefois, si vous envisagez de prendre en charge l’authentification Web, rendez-vous ici pour savoir comment déclarer les placeholder du manifeste.
        
+
+## Échanger les données reçues contre des jetons Auth0 {{{ data-action="code" data-code="exchangeTokens" }}}
+
+
+
        Vous devez instancier la trousse SDK avant de l’utiliser. Définissez un champ au niveau de la classe et initialisez-le dans la méthode onCreate. Remarque : Les identifiants définis à l’étape précédente sont transmis au développeur Auth0 et une nouvelle instance de AuthenticationAPIClient est créée avec lui.
        private AuthenticationAPIClient auth0Client;
+
+
+
+@Override
+
+public void onCreate(Bundle savedInstanceState) {
+
+    super.onCreate(savedInstanceState);
+
+
+
+    setContentView(R.layout.activity_login);
+
+
+
+    Auth0 account = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+
+    auth0Client = new AuthenticationAPIClient(account);
+
+
+
+    //...
+
+}
+
+
        
+
+
        Créez la méthode qui contiendra la logique d’échange des deux artefacts obtenus contre les identifiants de l’utilisateur Auth0. Dans l’exemple, cette méthode s’appelle exchangeTokens.
        Le client de l’API déclare la méthode loginWithNativeSocialToken qui reçoit un jeton et un type de sujet. Le premier correspond au jeton de session et le second indique le type de connexion avec lequel le système dorsal tentera de s’authentifier.
        Pour la fonction native Connexion Facebook, vous devez utiliser la valeur suivante : "http://auth0.com/oauth/token-type/facebook-info-session-access-token"
        Les autres valeurs à configurer sont le profil utilisateur (en utilisant la clé user_profile) et la permission que vous demandez aux jetons Auth0 de contenir.
        Nous recommandons de conserver toutes les valeurs immuables en tant que constantes au début de la classe. L’exemple utilise des constantes pour le type de jeton sujet, les permissions Facebook et les permissions Auth0. Pour en savoir plus sur les permissions Auth0, lisez cet article.
        
+
+## Mettre à jour la méthode performLogin {{{ data-action="code" data-code="performLogin" }}}
+
+
+
        Maintenant que chaque étape est définie dans sa propre méthode, il est temps de tout regrouper dans la méthode performLogin.
        Si tout a bien fonctionné, vous devriez maintenant être en mesure de vous authentifier de manière native avec la trousse SDK de connexion à Facebook. Cela signifie que si l’application Facebook est installée sur l’appareil, l’authentification sera gérée par l’application et non par une application de navigateur.
        
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/MainActivity.md b/fr-ca/articles/quickstart/native/android/files/MainActivity.md
new file mode 100644
index 0000000000..2e476f1606
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android/files/MainActivity.md
@@ -0,0 +1,78 @@
+---
+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
+        }
+      })
+  }
+}
+```
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..949546a282
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android/files/build.md
@@ -0,0 +1,26 @@
+---
+name: build.gradle
+language: javascript
+---
+    
+```javascript
+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.+'
+}
+```
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..b83b0540e1
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android/files/strings.md
@@ -0,0 +1,11 @@
+---
+name: strings.xml
+language: 
+---
+    
+```
+
+    "${account.namespace}"
+    "${account.clientId}"
+
+```
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..e6755bc034
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/android/interactive.md
@@ -0,0 +1,78 @@
+---
+title: Ajouter une connexion à votre application Android
+description: Ce guide explique comment intégrer Auth0 à une application Android en utilisant la trousse SDK Auth0 Android.
+interactive:  true
+files:
+ - files/build
+ - files/strings
+ - files/MainActivity
+github:
+  path: 00-Login-Kt
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Android
+
+
+
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer l’authentification pour votre projet.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est l’URL de l’application vers laquelle Auth0 dirigera vos utilisateurs une fois qu’ils se seront authentifiés. Si vous ne définissez pas cette valeur, Auth0 ne renverra pas les utilisateurs vers votre application après leur connexion.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur demo://{yourDomain}/android/YOUR_APP_PACKAGE_NAME/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est l’URL de l’application vers laquelle Auth0 redirigera vos utilisateurs une fois qu’ils se seront déconnectés. Si vous ne définissez pas cette valeur, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur demo://{yourDomain}/android/YOUR_APP_PACKAGE_NAME/callback
        
+
+## Installer la trousse SDK Android Auth0 {{{ data-action="code" data-code="build.gradle#18:18" }}}
+
+
+
        Ajoutez la trousse SDK Android Auth0 à votre projet. La bibliothèque adressera des demandes aux Authentication et Management API d’Auth0.
        Dans la section dépendances du build.gradle de votre application, ajoutez ce qui suit :
        implementation 'com.auth0.android:auth0:2. '
+
+
        
+
+
        Veillez à cibler le code Java 8+ pour les plugiciels Android et Kotlin respectivement.
        
+
+## Ajouter des paramètres fictifs dans le manifeste {{{ data-action="code" data-code="build.gradle#10:12" }}}
+
+
+
        La trousse SDK nécessite des paramètres fictifs dans le manifeste. Auth0 utilise des paramètres fictifs en interne pour définir un intent-filter, qui capture l’URL de rappel pour l’authentification. Vous devez définir le domaine du locataire Auth0 et le schéma de l’URL de rappel.
        Vous n’avez pas besoin de déclarer un intent-filter spécifique pour votre activité car vous avez défini les paramètres fictifs dans le manifeste avec vos valeurs Auth0 Domaine et Schéma et la bibliothèque traitera la redirection pour vous.
        Nous avons utilisé la valeur demo pour auth0Scheme ici, afin qu’un schéma d’URL personnalisé puisse être utilisé pour l’URL vers laquelle Auth0 redirige après la connexion. L’alternative est https si vous voulez utiliser des liens vers les applications Android. Vous pouvez en savoir plus sur la définition de cette valeur dans le SDK README d’Auth0.Android.
        
+
+## Configuration de votre application {{{ data-action="code" data-code="strings.xml#2:3" }}}
+
+
+
        Pour que la trousse SDK fonctionne correctement, définissez les propriétés suivantes dans strings.xml :
        • com_auth0_domain : Le domaine de votre locataire Auth0. En général, vous le trouvez dans Auth0 Dashboard sous vos paramètres d’application dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • com_auth0_client_id : l’identificateur de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous pouvez le trouver dans Auth0 Dashboard, dans les paramètres de votre application, dans le champ Client ID (ID client).
        Assurez-vous que le fichier AndroidManifest.xml spécifie l’autorisation android.permissions.INTERNET :
        <uses-permission android:name="android.permission.INTERNET" />
+
+
        
+
+
        Exécutez Sync Project with Gradle Files dans Android Studio ou exécutez ./gradlew clean assembleDebug à partir de la ligne de commande.
        Pour en savoir plus sur l’utilisation de Gradle, consultez la documentation officielle de Gradle.
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="MainActivity.kt#6:38" }}}
+
+
+
        La connexion universelle est le moyen le plus simple de mettre en place l’authentification dans votre application. Nous recommandons de l’utiliser pour une meilleure expérience, une meilleure sécurité et un plus grand nombre de fonctionnalités.
        Dans la méthode onCreate, créez une nouvelle instance de la classe Auth0 qui contiendra les informations d’identification de l’utilisateur.
        Créez une méthode loginWithBrowser et utilisez la classe WebAuthProvider pour vous authentifier avec n’importe quelle connexion que vous avez activée sur votre application dans Auth0 Dashboard. Ici, vous pouvez passer la valeur du schéma qui a été utilisée dans le paramètre fictif du manifeste auth0Scheme dans le cadre de la configuration initiale.
        Après avoir appelé la fonction WebAuthProvider#start, le navigateur se lance et affiche la page de connexion. Une fois l’utilisateur authentifié, l’URL de rappel est appelée. L’URL de rappel contient le résultat final du processus d’authentification.
        Démarrage rapide Android – Étape 5 – Point de contrôle 
        Ajoutez un bouton à votre application qui appelle loginWithBrowser. Lorsque vous cliquez dessus, vérifiez que votre application Next.js vous redirige vers la page Connexion universelle Auth0 et que vous pouvez maintenant vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe ou un fournisseur social.
        Une fois l’opération terminée, vérifiez qu’Auth0 vous redirige vers votre application.
        
+
+  
        
+
+  
        Si le lancement de votre application a échoué :
        • Assurez-vous que les URL de rappel autorisées sont correctes
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        • Assurez-vous que les valeurs de domaine et d’identifiant client ont été importées correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="MainActivity.kt#40:52" }}}
+
+
+
        Utilisez WebAuthProvider pour supprimer le témoin défini par le navigateur au moment de l’authentification, de sorte que les utilisateurs soient obligés de saisir à nouveau leurs identifiants la prochaine fois qu’ils essaient de s’authentifier.
        Ajoutez une méthode logout à votre application pour supprimer la session de l’utilisateur et le déconnecter de l’application. Ici, vous pouvez passer la valeur du schéma qui a été utilisée dans le placeholder du manifeste auth0Scheme dans le cadre de la configuration initiale.
        Utilisez la classe WebAuthProvider pour mettre en œuvre la déconnexion. Cet appel ouvre le navigateur et dirige l’utilisateur vers le point de terminaison de déconnexion. Si l’utilisateur annule la déconnexion, envisagez de le rediriger vers l’URL précédente.
        Démarrage rapide Android - Étape 6 - Point de contrôle 
        Ajoutez un bouton à votre application qui appelle logout et déconnecte l’utilisateur de votre application. Lorsque vous cliquez sur ce bouton, vérifiez que votre application Android vous redirige vers la page de déconnexion et vous renvoie, et que vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Si votre application n’a pas réussi à se déconnecter :
        • Assurez-vous que les URL de déconnexion autorisées sont correctement définies
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="MainActivity.kt#54:70" }}}
+
+
+
        Utilisez la classe AuthenticationAPIClient pour récupérer le profil utilisateur auprès de Auth0. Pour ce faire, les éléments suivants sont nécessaires :
        • Le jeton d’accès renvoyé par la phase de connexion
        • Le WebAuthProvider.login  doit contenir la permission profile
        Vous devez spécifier la permission email si vous avez besoin de récupérer l’adresse courriel de l’utilisateur.
        Ce guide rapide définit par défaut les permissions openid profile email lors de l’étape de connexion ci-dessus.
        L’exemple suivant démontre une fonction qui peut être utilisée pour récupérer le profil utilisateur et l’afficher à l’écran :
        Guide rapide Android - Étape 7 - Point de contrôle 
        Appelez la fonction showUserProfile après la connexion. Vérifiez que le rappel onSuccess renvoie les informations du profil utilisateur.
        
+
+  
        
+
+  
        Si votre application n’a pas renvoyé d’informations sur le profil utilisateur :
        • Vérifiez la validité du jeton d’accès
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..172b69189f
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/device/index.yml
@@ -0,0 +1,26 @@
+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
+hidden_articles:
+  - "interactive"
+show_steps: false
diff --git a/fr-ca/articles/quickstart/native/device/interactive.md b/fr-ca/articles/quickstart/native/device/interactive.md
new file mode 100644
index 0000000000..3f15738133
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/device/interactive.md
@@ -0,0 +1,559 @@
+---
+title: Flux d’autorisation d’appareil
+description: Ce tutoriel explique comment appeler votre API à partir d’un appareil dont les entrées sont limitées, à l’aide du flux d’autorisation d’appareil.
+interactive:  true
+
+locale: fr-CA
+---
+
+# Flux d’autorisation d’appareil
+
+
+
        Ce tutoriel explique comment appeler votre API à partir d’un appareil dont les entrées sont limitées, à l’aide du flux d’autorisation d’appareil. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.
        Pour une expérience interactive, vous pouvez utiliser Terrain de jeu du flux d’appareil.
        Conditions requises
        
+
+## Recevoir le code de l’appareil
+
+
+
        Lorsque l’utilisateur démarre l’application de l’appareil et souhaite l’autoriser, votre application doit demander un code d’appareil à Auth0 Authentication API pour l’associer à la session de l’utilisateur.
        Pour obtenir le code de l’appareil, votre application doit appeler le Authorize endpoint (Point de terminaison d’autorisation) d’Authentication API du flux d’autorisation de l’appareil :
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/device/code' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/device/code");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/device/code"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/device/code")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/device/code',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/device/code"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/device/code",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/device/code", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/device/code")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/device/code")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
+
+## Recevoir le code de l’appareil
+
+
+
        L’application de l’appareil devrait recevoir une réponse HTTP 200 et une charge utile similaire à celle-ci :
        {
+
+  "device_code": "GmRh...k9eS",
+
+  "user_code": "WDJB-MJHT",
+
+  "verification_uri": "https://my-tenant.auth0.com/device",
+
+  "verification_uri_complete": "https://my-tenant.auth0.com/device?user_code=WDJB-MJHT",
+
+  "expires_in": 900,
+
+  "interval": 5
+
+}
+
+
        
+
+
        
+
+## Demande d’activation de l’appareil
+
+
+
        Après avoir reçu le device_code et le user_code, votre application doit demander à l’utilisateur de se rendre au verification_uri et de saisir le user_code.
        null
        Le device_code n’est pas destiné directement à l’utilisateur et ne doit pas être affiché pendant l’interaction afin de ne pas créer de confusion chez l’utilisateur.
        Lorsque vous créez une CLI, vous pouvez ignorer cette étape et ouvrir directement le navigateur avec verification_uri_complete.
        
+
+## Interrogation du point de terminaison du jeton
+
+
+
        Pendant que votre application attend que l’utilisateur l’active, elle doit appeler le point de terminaison POST /oauth/token d’Authentication API de manière intermittente et traiter la réponse de manière appropriée.
        Assurez-vous que votre application attend la durée de interval (en secondes) ou jusqu’à ce qu’elle reçoive une réponse positive, la durée la plus longue étant retenue, afin d’éviter les problèmes de latence du réseau.
        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:device_code \ 
+
+--data device_code=__AUTH0_SCOPES__ \ 
+
+--data 'client_id=${account.clientId}'
+
+
        
+
+
        
+
+## Autorisation de l’utilisateur
+
+
+
        L’utilisateur peut soit balayer le code QR, soit ouvrir la page d’activation et saisir le code d’utilisateur :
        null
        Une page de confirmation s’affiche pour que l’utilisateur confirme qu’il s’agit du bon appareil :
        null
        L’utilisateur terminera la transaction en se connectant. Cette étape peut comprendre un ou plusieurs des procédés suivant :
        • Authentifier l’utilisateur
        • Redirection de l’utilisateur vers un fournisseur d’identité pour gérer l’authentification
        • Vérification des sessions actives d’authentification unique (SSO)
        • Obtenir le consentement de l’utilisateur pour l’appareil, à moins qu’il n’ait été donné au préalable
        null
        Une fois l’authentification et le consentement obtenus, la demande de confirmation s’affiche :
        null
        À ce stade, l’utilisateur s’est authentifié et l’appareil a été autorisé.
        
+
+## Recevoir les jetons
+
+
+
        Une fois que l’utilisateur a autorisé l’application, celle-ci reçoit une réponse HTTP 200 et la charge utile suivante :
        {
+
+  "access_token": "eyJz93a...k4laUWw",
+
+  "refresh_token": "GEbRxBN...edjnXbL",
+
+  "id_token": "eyJ0XAi...4faeEoQ",
+
+  "token_type": "Bearer",
+
+  "expires_in": 86400
+
+}
+
+
        
+
+
        Vous devez valider vos jetons avant de les enregistrer. Pour en savoir plus, consultez Valider les jetons d’accès et Valider les jetons d’ID.
        Les jetons d’accès sont utilisés pour appeler le point de terminaison Get User Info de Authentication API (si l’application de votre appareil a demandé la permission openid) ou l’API définie par le paramètre audience. Si vous appelez votre propre API, votre application doit vérifier le jeton d’accès avant de l’utiliser.
        Les jetons d’ID contiennent des informations sur l’utilisateur qui doivent être décodées et extraites. Authentication API ne renvoie un id_token que si l’application de votre appareil a demandé la permission openid.
        Les jetons d’actualisation sont utilisés pour obtenir un nouveau jeton d’accès ou un nouveau jeton d’ID après l’expiration du précédent. Authentication API ne renvoie un refresh_token que si le paramètre Autoriser l’accès hors ligne est activé pour l’API indiquée par le paramètre public et que l’application de votre appareil a demandé la permission offline_access.
        
+
+## Appeler votre API
+
+
+
        Pour appeler votre API, votre application doit transmettre le jeton d’accès en tant que jeton de porteur dans l’en-tête Authorization de votre requête HTTP.
        curl --request GET \
+
+  --url https://myapi.com/api \
+
+  --header 'authorization: Bearer __AUTH0_API_ACCESS_TOKEN__' \
+
+  --header 'content-type: application/json'
+
+
        
+
+
        
+
+## Jetons d’actualisation
+
+
+
        Pour obtenir un nouveau jeton d’accès pour un utilisateur, l’application de votre appareil peut appeler le point de terminaison POST /oauth/token de l’API d’authentication avec le paramètre refresh_token.
        curl --request POST \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded' \
+
+  --data grant_type=refresh_token \
+
+  --data 'client_id=${account.clientId}' \
+
+  --data 'client_secret=${account.clientSecret}' \
+
+  --data refresh_token=__AUTH0_REFRESH_TOKEN__
+
+
        
+
+
        Si la requête a réussi, l’application de votre appareil reçoit une réponse HTTP 200 avec la charge utile suivante :
        {
+
+  "access_token": "eyJ...MoQ",
+
+  "expires_in": 86400,
+
+  "scope": "openid offline_access",
+
+  "id_token": "eyJ...0NE",
+
+  "token_type": "Bearer"
+
+}
+
+
        
+
+
        Pour en savoir plus sur les jetons d’actualisation, veuillez consulter Jetons d’actualisation.
        
+
+## Dépannage
+
+
+
        Les journaux de locataires sont créés pour toutes les interactions qui ont lieu et peuvent être utilisés pour résoudre les problèmes.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **Code****Nom****Description**
        fdeazÉchec de la demande d’autorisation de l’appareil
        fdeacÉchec de l’activation de l’appareil
        fdeccL’utilisateur a annulé la confirmation de l’appareil
        fedeÉchec de l’échangeCode d’appareil contre un jeton d’accès
        sedeÉchange réussicode d’appareil contre un jeton d’accès
        Réponses des jetons
        Il est possible de recevoir plusieurs réponses HTTP 4xx différentes pendant que vous attendez que l’utilisateur autorise l’appareil.
        Autorisation en attente
        Vous verrez cette erreur pendant que vous attendez que l’utilisateur agisse. Poursuivez l’interrogation en utilisant interval suggéré dans l’étape précédente de ce tutoriel.
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "authorization_pending", 
+
+  "error_description": "..." 
+
+}
+
+
        
+
+
        Ralentissement
        L’interrogation est trop rapide. Ralentissez et utilisez l’intervalle suggéré dans l’étape précédente de ce tutoriel. Pour éviter de recevoir cette erreur en raison de la latence du réseau, vous devez commencer à compter chaque intervalle après la réception de la réponse de la dernière demande d’interrogation.
        `HTTP 429`
+
+
+
+{
+
+  "error": "slow_down",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        Jeton expiré
        L’utilisateur n’a pas autorisé l’appareil assez rapidement, par conséquent le device_code a expiré. Votre application doit avertir l’utilisateur que le flux a expiré et l’inviter à le réinitialiser.
        Le expired_token n’est renvoyé qu’une seule fois. Ensuite, le point de terminaison renvoie l’erreur invalid_grant.
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "expired_token",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        Accès refusé
        Si l’accès est refusé, vous recevez :
        `HTTP 403`
+
+
+
+{
+
+  "error": "access_denied",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        Cela peut se produire pour diverses raisons, notamment :
        • l’utilisateur a refusé d’autoriser l’appareil,
        • le serveur d’autorisation a refusé la transaction.
        • Une Action configurée a refusé l’accès.
        
+
+## Exemples de mises en œuvre
+
+
+
        Consultez les exemples ci-dessous pour savoir comment mettre en œuvre ce flux dans des applications réelles.
        • Terrain de jeu du flux de l’appareil
        • AppleTV (Swift) : application simple qui montre comment Auth0 peut être utilisé avec le flux d’autorisation d’un appareil AppleTV.
        • CLI (Node.js) : exemple de mise en œuvre d’une CLI qui utilise le flux d’autorisation de l’appareil au lieu du flux du code d’autorisation. La principale différence est que votre CLI n’a pas besoin d’héberger un serveur Web et d’écouter sur un port.
        
+
+## Limites
+
+
+
        Pour utiliser le flux d’autorisation de l’appareil, l’application de l’appareil doit :
        En outre, le flux d’autorisation de l’appareil ne permet pas :
        
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/app/build.md b/fr-ca/articles/quickstart/native/flutter/files/app/build.md
new file mode 100644
index 0000000000..c696fb8793
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/flutter/files/app/build.md
@@ -0,0 +1,21 @@
+---
+name: app/build.gradle
+language: 
+---
+    
+```
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion flutter.targetSdkVersion
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders += [auth0Domain: "auth0-dsepaid.auth0.com", auth0Scheme: "https"]
+        // <---
+    }
+}
+```
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/main_view.md b/fr-ca/articles/quickstart/native/flutter/files/main_view.md
new file mode 100644
index 0000000000..7ad3aa9879
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/flutter/files/main_view.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('auth0-dsepaid.auth0.com', 'OywWcFnHsbz50TfbRLWK0YTzrpxkwQL5');
+  }
+
+  @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/files/profile_view.md b/fr-ca/articles/quickstart/native/flutter/files/profile_view.md
new file mode 100644
index 0000000000..3dedf5c4b3
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/flutter/files/profile_view.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..1adde93134
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/flutter/interactive.md
@@ -0,0 +1,76 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Flutter
+description: Ce guide explique comment intégrer Auth0 à une application Flutter à l’aide de la trousse SDK Flutter Auth0.
+interactive:  true
+files:
+ - files/app/build
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Flutter
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et d’accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à une application Flutter à l’aide de la trousse SDK Flutter Auth0.
        La trousse SDK Flutter ne prend actuellement en charge que les applications Flutter pour Android, iOS et macOS.
        Ce guide de démarrage rapide suppose que vous avez déjà une application Flutter installée et active. Si ce n’est pas le cas, consultez les guides « Getting started » (Premiers pas) de Flutter pour commencer avec une application simple.
        Vous devez également être familiarisé avec Outil de ligne de commande Flutter.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour votre projet.
        Configurer une application Auth0.
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application Auth0 Native existante. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel et les URL de déconnexion
        Les Callback URL et les URL de déconnexion sont des URL qu’invoque Auth0 pour rediriger vers votre application. Auth0 invoque l’URL de rappel après avoir authentifié l’utilisateur, et l’URL de déconnexion après avoir supprimé le témoin de session. Si les Callback URL et les URL de déconnexion ne sont pas définies, les utilisateurs ne pourront pas se connecter ou se déconnecter de l’application et recevront un message d’erreur.
        Définissez les Callback URL et les URL de déconnexion sur les valeurs suivantes, en fonction de votre plateforme.
        Sur Android, la valeur du paramètre fictif SCHEME peut être https ou un autre schéma personnalisé. Les schémas https nécessitent l’activation des liens d’application Android.
        Sur iOS 17.4+ et macOS 14.4+, il est possible d’utiliser des liens universels (https) comme URL Callback et de déconnexion. Lorsqu’activé, la trousse SDK reviendra à l’utilisation d’un schéma d’URL personnalisé sur les anciennes versions iOS/MacOS – l’identificateur de bundlede votre application. Cette fonctionnalité nécessite un Xcode 15.3+ et un compte Apple Developer payant.
        Android
        SCHEME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        iOS
        https://{yourDomain}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://{yourDomain}/ios/YOUR_BUNDLE_IDENTIFIER/callback
        macOS
        https://{yourDomain}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://{yourDomain}/macos/YOUR_BUNDLE_IDENTIFIER/callback
        Par exemple, si l’identifiant de votre bundle iOS était com.example.MyApp et votre domaine Auth0 était example.us.auth0.com, alors cette valeur serait :
        https://example.us.auth0.com/ios/com.example.MyApp/callback,
+
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
        
+
+## Installer la trousse SDK Flutter Auth0
+
+
+
        Ajoutez la trousse SDK Flutter Auth0 au projet :
        flutter pub add auth0_flutter
        
+
+## Configurer Android
+
+
+
        Si vous ne développez pas pour la plateforme Android, ignorez cette étape.
        La trousse SDK nécessite des placeholder dans le manifeste. Auth0 utilise des placeholder en interne pour définir un intent-filter, qui capture l’URL de rappel d’authentification. Vous devez définir le domaine du locataire Auth0 et le schéma de l’URL de rappel.
        L’exemple utilise les placeholder suivants :
        • auth0Domain : Le domaine de votre locataire Auth0. En général, vous le trouverez dans Auth0 Dashboard sous vos Application Settings (Paramètres d’application) dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, indiquez dans ce champ votre domaine personnalisé.
        • auth0Scheme : Le schéma à utiliser. Peut être un schéma personnalisé, ou https si vous souhaitez utiliser les liens d’application Android. Vous pouvez en savoir plus sur la définition de cette valeur dans le SDK README d’Auth0.Android.
        Vous n’avez pas besoin de déclarer un intent-filter spécifique pour votre activité car vous avez défini les paramètres fictifs dans le manifeste avec vos valeurs Auth0 Domain et Scheme. La bibliothèque gère la redirection pour vous.
        Exécutez Sync Project with Gradle Files dans Android Studio pour appliquer vos modifications.
        
+
+## Configurer iOS/macOS
+
+
+
        Si vous ne développez pas pour les plateformes iOS ou macOS, ignorez cette étape.
        Cette étape nécessite un compte Apple Developer payant. Il est nécessaire d’utiliser des liens universels comme URL Callback et de déconnexion. Ignorez cette étape pour utiliser plutôt un schéma d’URL personnalisé.
        Configurer Team ID et l’identifiant du bundle
        Allez à la page des paramètres de votre application Auth0, faites défiler jusqu’en bas, et ouvrez Advanced Settings (Paramètres avancés) > Device Settings (Paramètres de l’appareil). Dans la section iOS, définissez Team ID sur votre Apple Team ID et App ID sur l’identificateur du bundle de votre application.
        null
        Cette action ajoutera votre application au fichier apple-app-site-association de votre locataire Auth0.
        Ajouter la capacité de domaine associé
        Ouvrez votre application dans Xcode en exécutant open ios/Runner.xcworkspace (ou open macos/Runner.xcworkspace pour macOS). Allez à l’ongletSigning and Capabilities (Signature et capacités) des paramètres de la cible de l’exécuteur, puis appuyez sur le bouton + Capability (Capabilité). Puis sélectionnez Associated Domains (Domaines associés).
        null
        Ensuite, ajoutez l’entrée suivante sous Associated Domains (Domaines associés) :
        webcredentials:{yourDomain}
        Si vous avez un domaine personnalisé, utilisez-le à la place du domaine Auth0 de la page des paramètres.
        Pour que le domaine associé fonctionne, votre application doit être signée avec votre certificat d’équipe même lors du développement pour le simulateur iOS. Assurez-vous d’utiliser Apple Team dont la Team ID (ID d’équipe) est configurée dans la page des paramètres de votre application Auth0.
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="main_view.dart#29:40" }}}
+
+
+
        La connexion universelle est le moyen le plus simple de mettre en place l’authentification dans votre application. Nous recommandons de l’utiliser pour une meilleure expérience, une meilleure sécurité et un plus grand nombre de fonctionnalités.
        Intégrez la connexion universelle Auth0 dans votre application Flutter en utilisant la classe Auth0. Redirigez vos utilisateurs vers la page de connexion universelle Auth0 en utilisant webAuthentication().login(). Il s’agit d’une fonctionnalité Future pour que vous récupériez les jetons de l’utilisateur.
        Android : si vous utilisez un schéma personnalisé, passez ce schéma à la méthode de connexion afin que le SDK puisse assurer un aller-retour vers la page de connexion :
        await auth0.webAuthentication(scheme: ’YOUR CUSTOM SCHEME’).login();
        Lorsqu’un utilisateur se connecte, il est redirigé vers votre application. Puis, vous pouvez accéder à l’identifiant et aux jetons d’accès de cet utilisateur.
        Flutter – Étape 5 – Ajouter une fonctionnalité de connexion à votre application 
        Ajoutez un bouton à votre application qui appelle webAuthentication().login() et déconnecte l’utilisateur de votre application. Vérifiez que vous êtes redirigé vers Auth0 pour l’authentification, puis renvoyé vers votre application.
        Vérifiez que vous pouvez accéder aux jetons sur le résultat de l’appel login.
        
+
+  
        
+
+  
        Si le lancement de votre application a échoué :
        • Assurez-vous que les URL de rappel autorisées sont correctement définies
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        • Assurez-vous que les valeurs de domaine et d’identifiant client sont importées correctement
        • Si vous utilisez Android, assurez-vous que les paramètres fictifs du manifeste ont été correctement configurés, sinon la redirection vers votre application risque de ne pas fonctionner
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="main_view.dart#45:55" }}}
+
+
+
        Pour déconnecter les utilisateurs, redirigez-les vers le point de terminaison Auth0 pour effacer leur session de connexion en appelant la trousse SDK Flutter Auth0 webAuthentication().logout(). En savoir plus sur la déconnexion d’Auth0.
        Android : si vous utilisez un schéma personnalisé, passez ce schéma à la méthode de déconnexion afin que la trousse SDK puisse renvoyer correctement vers votre application :
        await auth0.webAuthentication(scheme: ’YOUR CUSTOM SCHEME’).logout();
        Flutter - Étape 6 - Ajouter une fonctionnalité de connexion à votre application 
        Ajoutez un bouton à votre application qui appelle webAuthentication().logout() et déconnecte l’utilisateur de votre application. Lorsque vous le sélectionnez, vérifiez que votre application Flutter vous redirige vers le point de terminaison de déconnexion et vice-versa. Vous ne devriez pas être connecté à votre application.
        
+
+  
        
+
+  
        Si votre application ne s’est pas déconnectée avec succès :
        • Assurez-vous que les URL de déconnexion autorisées sont correctement définies
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
        Le profil utilisateur récupère automatiquement les propriétés du profil utilisateur pour vous lorsque vous appelez webAuthentication().login(). L’objet retourné à partir de l’étape de connexion contient une propriété user avec toutes les propriétés du profil utilisateur, qui est renseigné en décodant le jeton d’ID.
        Flutter - Étape 7 - Afficher les informations du profil utilisateur 
        Connectez-vous et inspectez la propriété user par rapport au résultat. Vérifiez les informations de profil utilisateur actuel, telles que son email ou name.
        
+
+  
        
+
+  
        Si votre application n’a pas renvoyé d’informations sur le profil utilisateur :
        • Vérifiez la validité du jeton d’accès
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/app.component.md b/fr-ca/articles/quickstart/native/ionic-angular/files/app.component.md
new file mode 100644
index 0000000000..0b54654bab
--- /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();
+          }
+        }
+      });
+    });
+  }
+}
+```
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..987cc68c0d
--- /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],
+})
+```
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..7821093b94
--- /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();
+  }
+}
+```
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..32da066dac
--- /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();
+  }
+}
+```
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..01fea0f83d
--- /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) {}
+}
+```
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..46d19d59ee
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-angular/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Ajouter la connexion à votre application Ionic Angular avec Capacitor
+description: Ce guide explique comment intégrer Auth0 avec une application Ionic (Angular) et Capacitor en utilisant la trousse SDK Angular Auth0.
+interactive:  true
+files:
+ - files/app.module
+ - files/app.component
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: angular
+locale: fr-CA
+---
+
+# Ajouter la connexion à votre application Ionic Angular avec Capacitor
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et d’accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 avec une application Ionic (Angular) & Capacitor en utilisant la trousse SDK Angular Auth0.
        
+
+## Démarrage
+
+
+
        Ce guide de démarrage rapide suppose que vous avez déjà une application Ionic en cours d’exécution avec Capacitor. Si ce n’est pas le cas, consultez Using Capacitor with Ionic Framework guide (Utiliser Capacitor avec le cadre d’applications Ionic)  pour commencer avec une application simple ou clonez nos our sample apps (exemples d’applications).
        Vous devez également être familiarisé avec Capacitor development workflow (le flux de production de développement Capacitor).
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour votre projet.
        Tout au long de cet article, YOUR_PACKAGE_ID est l’identifiant du package de votre application. Ceci peut être trouvé et configuré dans le champ appId de votre fichier capacitor.config.ts . Voir Capacitor’s Config schema (Schéma de configuration du Capacitor) pour plus d’informations.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur :
        YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur :
        YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback
        Configurer les origines autorisées
        Pour pouvoir faire des requêtes à partir de votre application d’origine vers Auth0, définissez les origines autorisées dans vos Application Settings (Paramètres d’application).
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur capacitor://localhost, http://localhost pour iOS et Android respectivement.
        Enfin, assurez-vous que le type d’application pour votre application est défini sur Native dans les Application Settings (Paramètres d’application).
        
+
+## Installer la trousse SDK React Auth0
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse SDK Angular Auth0 :
        npm install @auth0/auth0-angular
        La trousse SDK expose plusieurs types qui vous aident à intégrer Auth0 avec votre application Angular, y compris un module et un service d’authentification.
        Installer les plugiciels Capacitor
        Ce guide rapide et cet exemple utilisent certains des plugiciels officiels Capacitor. Installez-les dans votre application à l’aide de la commande suivante :
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser : Vous permet d’interagir avec le navigateur de système de l’appareil, et est utilisé pour ouvrir l’URL vers le point de terminaison d’autorisation d’Auth0.
        • @capacitor/app : Vous permet de vous abonner à des événements d’application de haut niveau, utiles pour la gestion des Callbacks depuis Auth0.
        Le plugiciel de navigateur de Capacitor sur iOS utilise SFSafariViewController, qui sur iOS 11+ ne partage pas les témoins avec Safari sur l’appareil. Cela signifie que SSO ne fonctionnera pas sur ces appareils. Si vous avez besoin de SSO, veuillez utiliser un plugiciel compatible qui utilise ASWebAuthenticationSession.
        
+
+## Enregistrer et configurer le module d’authentification {{{ data-action="code" data-code="app.module.ts" }}}
+
+
+
        La trousse SDK exporte AuthModule, un module qui contient tous les services nécessaires au fonctionnement de la trousse SDK. Ce module doit être enregistré avec votre application et être configuré avec votre domaine Auth0 et votre identifiant client.
        La fonction AuthModule.forRoot prend la configuration suivante :
        • domain : La valeur domain présente dans les paramètres de l’application que vous avez créée dans Auth0 Dashboard, ou votre domaine personnalisé si vous utilisez la fonctionnalité Domaines personnalisés d’Auth0.
        • clientId : La valeur de l’identifiant du client présente dans les paramètres de l’application que vous avez créée dans Auth0 Dashboard.
        • useRefreshTokens : Pour utiliser auth0-angular avec Ionic sur Android et iOS, il est nécessaire d’activer les jetons d’actualisation.
        • useRefreshTokensFallback : Pour utiliser auth0-angular avec Ionic sur Android et iOS, il est nécessaire de désactiver le iframe de substitution.
        • authorizationParams.redirect_uri : L’URL pour rediriger vos utilisateurs après qu’ils se sont authentifiés avec Auth0.
        Pour conserver l’authentification après la fermeture et la réouverture de l’application, vous pouvez définir cacheLocation sur localstorage lors de la configuration du SDK, mais soyez conscient des risques liés au stockage de jetons dans localstorage. De plus, localstorage devrait être traité comme transitoire dans l’application Capacitor car les données pourraient être récupérées de façon inattendue dans certaines circonstances. Veuillez lire les directives sur le stockage dans la documentation Capacitor.
        En outre, le SDK a la capacité d’utiliser une implémentation de cache personnalisée pour stocker des jetons, si vous avez une exigence d’utiliser un mécanisme de stockage plus sûr et persistant.
        Notez que nous recommandons de ne pas utiliser le plugiciel Capacitor pour stocker les jetons, car cela est soutenu par UserDefaults et SharedPreferences sur iOS et Android respectivement. Les données stockées à l’aide de ces API ne sont pas cryptées, non sécurisées et peuvent également être synchronisées dans le nuage.
        Ionic & Capacitor (Angular) - Étape 4 - Enregistrer et configurer le module d’authentification 
        Maintenant que vous avez configuré votre application avec la trousse SDK Angular Auth0, exécutez votre application pour vérifier que la trousse SDK est initialisée sans erreur et que votre application s’exécute comme auparavant.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client ont été importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou visitez la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login-button.ts" }}}
+
+
+
        Dans une application Capacitor, le plugiciel de navigateur Capacitor effectue une redirection vers la page de connexion universelle Auth0. Définissez le paramètre openUrl sur la fonction loginWithRedirect pour utiliser Browser.open de sorte que l’URL soit ouverte à l’aide du composant navigateur du système de l’appareil (SFSafariViewController sur iOS et les Onglets Personnalisés Chrome sur Android).
        Par défaut, la méthode loginWithRedirect de la trousse SDK utilise window.location.href pour accéder à la page de connexion dans l’application de navigateur par défaut sur l’appareil de l’utilisateur plutôt que dans le composant de navigateur système approprié pour la plate-forme. L’utilisateur quitterait votre application pour s’authentifier et pourrait rendre l’expérience utilisateur sous-optimale.
        Ionic & Capacitor (Angular) - Étape 5 - Ajouter la connexion à votre application 
        La fonction loginWithRedirect indique à la trousse SDK d’initier le flux de connexion, en utilisant la fonction Browser.open pour ouvrir l’URL de connexion avec le composant navigateur du système de la plateforme en définissant le paramètre openUrl. Cela permet à votre utilisateur de se connecter à votre application. Les utilisateurs sont redirigés vers la page de connexion à Auth0 et ne reçoivent aucune erreur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous qu’il n’y a pas d’erreurs dans la fenêtre de la console du navigateur au point de connexion
        • assurez-vous que le domaine et l’identifiant client sont corrects selon votre application Auth0 dans le tableau de bord
        • si vous êtes redirigé vers Auth0 et recevez une page d’erreur, vérifiez la section des « détails techniques » en bas de la page pour connaître la raison de l’échec
        
+
+  
        
+
+## Gérer la callback de connexion {{{ data-action="code" data-code="app.component.ts" }}}
+
+
+
        Une fois que les utilisateurs sont connectés avec la page de connexion universelle, ils sont redirigés vers votre application via une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être géré depuis votre application. Vous pouvez appeler la méthode handleRedirectCallback depuis la trousse SDK Auth0 pour initier l’état de l’authentification.
        Vous pouvez utiliser cette méthode uniquement sur une redirection depuis Auth0. Pour vérifier le succès, vérifiez la présence du code et des paramètres state dans l’URL.
        La méthode Browser.close() devrait fermer le navigateur lorsque cet événement est déclenché.
        Notez que la callback de l’événement appUrlOpen est enveloppé dans ngZone.run. Les modifications aux observables survenant lorsque handleRedirectCallback est exécuté sont détectées par l’application Angular. Pour en savoir plus sur cette fonctionnalité, veuillez consulter Utiliser Angular avec Capacitator. Sinon, l’écran ne se met pas à jour pour afficher l’état authentifié après la connexion.
        Cet article suppose que vous utiliserez des schémas d’URL personnalisés pour gérer le rappel dans votre application. Pour ce faire, enregistrez votre YOUR_PACKAGE_ID comme schéma d’URL pour la plateforme de votre choix. Pour en savoir plus, lire Defining a Custom URL Scheme (Définition d’un schéma d’URL personnalisé) pour iOS ou Create Deep Links to App Content (Création de liens profonds vers le contenu des applications) pour Android.
        Ionic & Capacitor (Angular) - Étape 6 - Gérer le rappel de connexion 
        Ajoutez appUrlOpen au composant App de votre application et connectez-vous. La fenêtre du navigateur devrait se fermer une fois que l’utilisateur s’authentifie et se connecte à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout-button.ts" }}}
+
+
+
        Maintenant que les utilisateurs peuvent se connecter, vous devez configurer une façon de se déconnecter. Les utilisateurs doivent être redirigés vers le point de terminaison de déconnexion Auth0 dans le navigateur pour effacer leur session de navigation. Encore une fois, le plugiciel du navigateur de Capacitor doit effectuer cette redirection afin que l’utilisateur ne quitte pas votre application et ne vive pas une expérience frustrante.
        Pour y parvenir avec Ionic et Capacitor en conjonction avec le SDK Auth0 :
        • Créez l’URL de votre application vers laquelle Auth0 doit rediriger après la déconnexion. Il s’agit d’une URL qui utilise votre schéma personnalisé enregistré et le domaine Auth0. Ajoutez-la à votre configuration URL de déconnexions autorisées dans Auth0 Dashboard
        • Déconnectez-vous de la trousse SDK en appelant logout et transmettez votre URL de redirection comme paramètre logoutParams.returnTo.
        • Définissez le paramètre openUrl sur un callback qui utilise le plugiciel de navigateur Capacitor pour ouvrir l’URL à l’aide de Browser.open.
        De la même manière que pour l’étape de connexion, si vous ne définissez pas openUrl lors de l’appel de logout, le SDK redirige l’utilisateur vers l’URL de déconnexion à l’aide de l’application de navigateur par défaut sur l’appareil, ce qui offre une expérience utilisateur sous-optimale.
        Ionic & Capacitor (Angular) - Étape 7 - Ajouter la déconnexion à votre application 
        Fournir un moyen pour vos utilisateurs de se déconnecter de votre application. Vérifiez la redirection vers Auth0, puis vers l’adresse que vous avez spécifiée dans le paramètre returnTo. Assurez-vous que les utilisateurs ne sont plus connectés à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vérifiez que l’URL que vous avez fournie dans le paramètre returnTo est enregistrée comme URL de rappel autorisée dans votre Tableau de bord Auth0
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
        La trousse SDK Auth0 récupère les informations de profil associées aux utilisateurs connectés dans n’importe quel composant dont vous avez besoin, comme leur nom ou leur image de profil, pour personnaliser l’interface utilisateur. Les informations de profil sont disponibles via la propriété user$ exposée par AuthService.
        Ionic & Capacitor (Angular) - Étape 8 - Afficher le profil utilisateur 
        Fournir un moyen pour que vos utilisateurs puissent voir leurs détails de profil utilisateur dans l’application et vérifiez que vous êtes en mesure de récupérer et d’afficher les informations de votre profil à l’écran une fois que vous avez ouvert une session.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous de lire uniquement le profil utilisateur lorsque isLoading est false
        • assurez-vous que user résout un objet et n’est pas 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..f41566cdb1
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-react/files/app.md
@@ -0,0 +1,58 @@
+---
+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]);
+
+  // ..
+};// 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]);
+
+  // ..
+};
+```
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..ab848413f9
--- /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(
+  
+    
+  
+);
+```
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..20dc0072e2
--- /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;
+```
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..87d163ec18
--- /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;
+```
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..8d811b0020
--- /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;
+```
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..721bfb3921
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-react/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Ajouter la connexion à votre application Ionic React avec l’application Capacitor
+description: Ce guide explique comment intégrer Auth0 avec une application Ionic (React) & Capacitor en utilisant la trousse SDK React Auth0.
+interactive:  true
+files:
+ - files/index
+ - files/login-button
+ - files/logout-button
+ - files/app
+ - files/user-profile
+github:
+  path: react
+locale: fr-CA
+---
+
+# Ajouter la connexion à votre application Ionic React avec l’application Capacitor
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 avec une application Ionic (React) & Capacitor en utilisant la trousse SDK Auth0 React.
        
+
+## Démarrage
+
+
+
        Ce guide de démarrage rapide suppose que vous avez déjà une application Ionic en cours d’exécution avec Capacitor. Si ce n’est pas le cas, consultez Using Capacitor with Ionic Framework guide (Utiliser Capacitor avec le cadre d’applications Ionic)  pour commencer avec une application simple ou clonez nos our sample apps (exemples d’applications).
        Vous devez également être familiarisé avec Capacitor development workflow (le flux de production de développement Capacitor).
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour votre projet.
        Tout au long de cet article, YOUR_PACKAGE_ID est l’identifiant du package de votre application. Ceci peut être trouvé et configuré dans le champ appId de votre fichier capacitor.config.ts . Voir Capacitor’s Config schema (Schéma de configuration du Capacitor) pour plus d’informations.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur :
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/capacitor/YOUR_PACKAGE_ID/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur :
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/capacitor/YOUR_PACKAGE_ID/callback.
        Configurer les origines autorisées
        Pour pouvoir faire des requêtes à partir de votre application d’origine vers Auth0, définissez les origines autorisées dans vos Application Settings (Paramètres d’application).
        Si vous suivez notre projet faisant office d’exemple, définissez ceci sur capacitor://localhost, http://localhost pour iOS et Android respectivement.
        Enfin, assurez-vous que le type d’application pour votre application est défini sur Native dans les Application Settings (Paramètres d’application).
        
+
+## Installer la trousse SDK React Auth0
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse SDK React Auth0 :
        npm install @auth0/auth0-react
        La trousse SDK expose des méthodes et variables qui vous aident à intégrer Auth0 avec votre application React en utilisant les Crochets React ou les Composants d’ordre supérieur.
        Installer les plugiciels Capacitor
        Ce guide rapide et cet exemple utilisent certains des plugiciels officiels Capacitor. Installez-les dans votre application à l’aide de la commande suivante :
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser : Vous permet d’interagir avec le navigateur de système de l’appareil, et est utilisé pour ouvrir l’URL vers le point de terminaison d’autorisation d’Auth0.
        • @capacitor/app : Vous permet de vous abonner à des événements d’application de haut niveau, utiles pour la gestion des Callbacks depuis Auth0.
        Le plugiciel de navigateur de Capacitor sur iOS utilise SFSafariViewController, qui sur iOS 11+ ne partage pas les témoins avec Safari sur l’appareil. Cela signifie que SSO ne fonctionnera pas sur ces appareils. Si vous avez besoin de SSO, veuillez utiliser un plugiciel compatible qui utilise ASWebAuthenticationSession.
        
+
+## Configurer le composant Auth0Provider {{{ data-action="code" data-code="index.tsx" }}}
+
+
+
        Au cours de son fonctionnement, la trousse SDK React Auth0 utilise React Context pour gérer l’état d’authentification de vos utilisateurs. Une façon d’intégrer Auth0 avec votre application React est d’envelopper votre composant racine avec un Auth0Provider que vous pouvez importer à partir de la trousse SDK.
        Le composant Auth0Provider prend les props suivants :
        • domain : La valeur du domain présente dans les paramètres de l’application que vous avez créée dans votre Auth0 Dashboard, ou votre domaine personnalisé si vous utilisez la fonctionnalité Domaines personnalisés d’Auth0.
        • clientId : La valeur de l’identifiant du client présente dans les paramètres de l’application que vous avez créée dans votre Auth0 Dashboard.
        • useRefreshTokens : Pour utiliser auth0-react avec Ionic sur Android et iOS, il est nécessaire d’activer les jetons d’actualisation.
        • useRefreshTokensFallback : Pour utiliser auth0-react avec Ionic sur Android et iOS, il est nécessaire de désactiver le iframe de substitution.
        • authorizationParams.redirect_uri : L’URL vers laquelle vous souhaitez rediriger vos utilisateurs après qu’ils se soient authentifiés avec Auth0.
        Pour conserver l’authentification après la fermeture et la réouverture de l’application, vous pouvez définir cacheLocation sur localstorage lors de la configuration du SDK, mais soyez conscient des risques liés au stockage de jetons dans localstorage. De plus, localstorage devrait être traité comme transitoire dans l’application Capacitor car les données pourraient être récupérées de façon inattendue dans certaines circonstances. Veuillez lire les directives sur le stockage dans la documentation Capacitor.
        En outre, le SDK a la capacité d’utiliser une implémentation de cache personnalisée pour stocker des jetons, si vous avez une exigence d’utiliser un mécanisme de stockage plus sûr et persistant.
        Notez que nous recommandons de ne pas utiliser le plugiciel Capacitor pour stocker les jetons, car cela est soutenu par UserDefaults et SharedPreferences sur iOS et Android respectivement. Les données stockées à l’aide de ces API ne sont pas cryptées, non sécurisées et peuvent également être synchronisées dans le nuage.
        Ionic & Capacitor (React) - Étape 4 - Configurer le composant Auth0Provider 
        Ajoutez le composant Auth0Provider d’une manière qui enveloppe votre composant App, puis exécutez votre application pour vérifier que le SDK est initialisé correctement et que votre application ne lance pas d’erreurs liées à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client ont été importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login-button.tsx" }}}
+
+
+
        Dans une application Capacitor, le plugiciel Capacitor’s Browser effectue une redirection vers la Universal Login Page (page de connexion universelle) d’Auth0 Auth0. Définissez le paramètre openUrl sur la fonction loginWithRedirect pour utiliser Browser.open afin que l’URL soit ouverte à l’aide du composant de navigateur système de l’appareil (SFSafariViewController sur iOS et Chrome Custom Tabs [Onglets personnalisés Chrome] sur Android).
        Par défaut, la méthode loginWithRedirect de la trousse SDK utilise window.location.href pour accéder à la page de connexion dans l’application de navigateur par défaut sur l’appareil de l’utilisateur plutôt que dans le composant de navigateur système approprié pour la plate-forme. L’utilisateur quitterait votre application pour s’authentifier et pourrait rendre l’expérience utilisateur sous-optimale.
        Ionic & Capacitor (React) - Étape 5 - Ajouter une connexion à votre application 
        La fonction loginWithRedirect indique à la trousse SDK d’initier le flux de connexion, en utilisant la fonction Browser.open pour ouvrir l’URL de connexion avec le composant navigateur du système de la plateforme en définissant le paramètre openUrl. Cela permet à votre utilisateur de se connecter à votre application. Les utilisateurs sont redirigés vers la page de connexion à Auth0 et ne reçoivent aucune erreur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous qu’il n’y a pas d’erreurs dans la fenêtre de la console du navigateur au point de connexion
        • assurez-vous que le domaine et l’identifiant client sont corrects selon votre application Auth0 dans le tableau de bord
        • si vous êtes redirigé vers Auth0 et recevez une page d’erreur, consultez la section « détails techniques » en bas pour connaître la raison de l’échec
        
+
+  
        
+
+## Gérer le rappel de connexion {{{ data-action="code" data-code="app.tsx" }}}
+
+
+
        Une fois que les utilisateurs sont connectés avec la page de connexion universelle, ils sont redirigés vers votre application au moyen d’une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être traité au sein de votre application. Vous pouvez appeler la méthode handleRedirectCallback à partir de la trousse SDK Auth0 pour initialiser l’état d’authentification.
        Vous pouvez utiliser cette méthode uniquement sur une redirection depuis Auth0. Vérifiez que les paramètres code et state sont présents dans l’URL.
        La méthode Browser.close() devrait fermer le navigateur lorsque cet événement est déclenché.
        Cet article suppose que vous utiliserez des schémas d’URL personnalisés pour gérer le rappel dans votre application. Pour ce faire, enregistrez votre YOUR_PACKAGE_ID comme schéma d’URL pour la plateforme de votre choix. Pour en savoir plus, lire Defining a Custom URL Scheme (Définition d’un schéma d’URL personnalisé) pour iOS ou Create Deep Links to App Content (Création de liens profonds vers le contenu des applications) pour Android.
        Ionic & Capacitor (React) - Étape 6 - Gérer le rappel de connexion 
        Ajoutez appUrlOpen au composant App de votre application et connectez-vous. La fenêtre du navigateur devrait se fermer une fois que l’utilisateur s’authentifie et se connecte à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout-button.tsx" }}}
+
+
+
        Maintenant que les utilisateurs peuvent se connecter, vous devez configurer une façon de se déconnecter. Les utilisateurs doivent être redirigés vers le point de terminaison de déconnexion Auth0 dans le navigateur pour effacer leur session de navigation. Encore une fois, le plugiciel du navigateur de Capacitor doit effectuer cette redirection afin que l’utilisateur ne quitte pas votre application et ne vive pas une expérience frustrante.
        Pour y parvenir avec Ionic et Capacitor en conjonction avec le SDK Auth0 :
        • Créez l’URL de votre application vers laquelle Auth0 doit rediriger après la déconnexion. Il s’agit d’une URL qui utilise votre schéma personnalisé enregistré et le domaine Auth0. Ajoutez-la à votre configuration URL de déconnexions autorisées dans Auth0 Dashboard
        • Déconnectez-vous de la trousse SDK en appelant logout et transmettez votre URL de redirection comme paramètre logoutParams.returnTo.
        • Définissez le paramètre openUrl sur un callback qui utilise le plugiciel de navigateur Capacitor pour ouvrir l’URL à l’aide de Browser.open.
        De la même manière que pour l’étape de connexion, si vous ne définissez pas openUrl lors de l’appel de logout, le SDK redirige l’utilisateur vers l’URL de déconnexion à l’aide de l’application de navigateur par défaut sur l’appareil, ce qui offre une expérience utilisateur sous-optimale.
        Ionic & Capacitor (React) - Étape 7 - Ajouter une déconnexion à votre application 
        Fournir un moyen pour vos utilisateurs de se déconnecter de votre application. Vérifiez que vous redirigez vers Auth0, puis vers l’adresse spécifiée dans le paramètre returnTo. Vérifiez que vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="user-profile.tsx" }}}
+
+
+
        La trousse SDK React Auth0 récupère le user’s profile (profil utilisateur) associé aux utilisateurs connectés dans n’importe quel composant dont vous avez besoin, comme leur nom ou leur image de profil, pour personnaliser l’interface utilisateur. Les informations de profil sont accessibles via la propriété user exposée par l’appel useAuth0().
        L’initialisation de la trousse SDK est asynchrone, et vous devez protéger le profil utilisateur en activant les propriétés isLoading et user. Une fois que isLoading est false et que user a une valeur, le profil utilisateur peut être utilisé.
        Ionic & Capacitor (React) - Étape 8 - Afficher le profil utilisateur 
        Fournir un moyen pour que vos utilisateurs puissent voir leurs détails de profil utilisateur dans l’application et vérifiez que vous êtes en mesure de récupérer et d’afficher les informations de votre profil à l’écran une fois que vous avez ouvert une session.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vérifiez que vous lisez uniquement le profil utilisateur lorsque isLoading est false
        • vérifiez que user résout un objet et n’est pas 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/LoginButton.md b/fr-ca/articles/quickstart/native/ionic-vue/files/LoginButton.md
new file mode 100644
index 0000000000..ceb58fc255
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/files/LoginButton.md
@@ -0,0 +1,41 @@
+---
+name: LoginButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+
+```
diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/LogoutButton.md b/fr-ca/articles/quickstart/native/ionic-vue/files/LogoutButton.md
new file mode 100644
index 0000000000..6ebfb8809e
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/files/LogoutButton.md
@@ -0,0 +1,44 @@
+---
+name: LogoutButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/UserProfile.md b/fr-ca/articles/quickstart/native/ionic-vue/files/UserProfile.md
new file mode 100644
index 0000000000..0366a88cc4
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/files/UserProfile.md
@@ -0,0 +1,35 @@
+---
+name: UserProfile.vue
+language: 
+---
+    
+```
+
+
+
+```
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..1f9bee09d5
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/files/app.md
@@ -0,0 +1,45 @@
+---
+name: App.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
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..38d763e101
--- /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");
+});
+```
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..2202e5d0b6
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Ajouter la connexion à votre application Ionic Vue avec l’application Capacitor
+description: Ce guide montre comment intégrer Auth0 avec une application Ionic (Vue) et Capacitor en utilisant la trousse SDK Vue Auth0.
+interactive:  true
+files:
+ - files/main
+ - files/LoginButton
+ - files/LogoutButton
+ - files/App
+ - files/UserProfile
+github:
+  path: vue
+locale: fr-CA
+---
+
+# Ajouter la connexion à votre application Ionic Vue avec l’application Capacitor
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide montre comment intégrer Auth0 avec une application Ionic (Vue) et Capacitor en utilisant la trousse SDK Vue Auth0.
        
+
+## Démarrage
+
+
+
        Ce guide de démarrage rapide suppose que vous avez déjà une application Ionic en cours d’exécution avec Capacitor. Si ce n’est pas le cas, consultez Utiliser Capacitor avec Ionic Framework pour commencer avec une application simple ou clonez nos our sample apps (exemples d’applications).
        Vous devez également être familiarisé avec Capacitor development workflow (le flux de production de développement Capacitor).
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour votre projet.
        Tout au long de cet article, YOUR_PACKAGE_ID est l’identificateur du package de votre application. Il peut être trouvé et configuré dans le champ appId de votre fichier capacitor.config.ts. Voir Schéma de configuration de Capacitor pour plus d’informations.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback.
        Configurer les origines autorisées
        Pour pouvoir faire des requêtes à partir de votre application d’origine vers Auth0, définissez les origines autorisées dans vos Application Settings (Paramètres d’application).
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur capacitor://localhost, http://localhost pour iOS et Android respectivement.
        Enfin, assurez-vous que le type d’application pour votre application est défini sur Native dans les Application Settings (Paramètres d’application).
        
+
+## Installer la trousse SDK Vue Auth0
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse SDK Vue Auth0 :
        npm install @auth0/auth0-vue
        La trousse SDK expose plusieurs types qui vous aident à intégrer Auth0 avec votre application Vue, y compris un module et un service d’authentification.
        Installer les plugiciels Capacitor
        Ce guide rapide et cet exemple utilisent certains des plugiciels officiels Capacitor. Installez-les dans votre application à l’aide de la commande suivante :
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser : vous permet d’interagir avec le navigateur de système de l’appareil et est utilisé pour ouvrir l’URL vers le point de terminaison d’autorisation de Auth0
        • @capacitor/app : vous permet de souscrire à des événements d’application de haut niveau, utiles pour la gestion des Callbacks depuis Auth0
        Le plugiciel de navigateur de Capacitor sur iOS utilise SFSafariViewController, qui sur iOS 11+ ne partage pas les témoins avec Safari sur l’appareil. Cela signifie que SSO ne fonctionnera pas sur ces appareils. Si vous avez besoin de SSO, veuillez utiliser un plugiciel compatible qui utilise ASWebAuthenticationSession.
        
+
+## Configurer le plugiciel CreateAuht0 {{{ data-action="code" data-code="main.ts" }}}
+
+
+
        La trousse SDK exporte createAuth0, un composable qui contient tous les services nécessaires au fonctionnement du SDK. Ce composable doit être enregistré avec votre application et être configuré avec votre domaine Auth0 et votre ID client.
        Le composable createAuth0 prend la configuration suivante :
        • domain : La valeur domain présente dans les Settings (Paramètres) de l’application que vous avez créée dans le Auth0 Dashboard, ou votre domaine personnalisé si vous utilisez la fonctionnalité de domaines personnalisés d’Auth0.
        • clientId : La valeur de l’identificateur client présente dans les Settings (Paramètres) de l’application que vous avez créée dans l’Auth0 Dashboard.
        • useRefreshTokens : Pour utiliser auth0-vue avec Ionic sur Android et iOS, il est nécessaire d’activer les jetons d’actualisation.
        • useRefreshTokensFallback : Pour utiliser auth0-vue avec Ionic sur Android et iOS, il est nécessaire de désactiver le iframe de substitution.
        • authorizationParams.redirect_uri : URL pour rediriger vos utilisateurs après qu’ils se sont authentifiés avec Auth0.
        Pour conserver l’authentification après la fermeture et la réouverture de l’application, vous pouvez définir cacheLocation sur localstorage lors de la configuration de la trousse SDK, mais soyez conscient des risques liés au stockage de jetons dans localstorage. De plus, localstorage devrait être traité comme transitoire dans l’application Capacitor car les données pourraient être récupérées de façon inattendue dans certaines circonstances. Veuillez lire les directives sur le stockage dans la documentation Capacitor.
        En outre, la trousse SDK a la capacité d’utiliser une implémentation de cache personnalisée pour stocker des jetons, si vous avez une exigence d’utiliser un mécanisme de stockage plus sûr et persistant.
        Notez que nous recommandons de ne pas utiliser le plugiciel Capacitor pour stocker les jetons, car cela est soutenu par UserDefaults et SharedPreferences sur iOS et Android respectivement. Les données stockées à l’aide de ces API ne sont pas chiffrées, non sécurisées et peuvent également être synchronisées dans le nuage.
        Démarrage rapide Ionic - Étape 4 - Point de contrôle 
        Maintenant que vous avez configuré votre application avec la trousse SDK Vue Auth0, exécutez votre application pour vérifier que la trousse SDK est initialisée sans erreur et que votre application s’exécute comme auparavant.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client ont été importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="LoginButton.vue" }}}
+
+
+
        Dans une application Capacitor, le plugicielCapacitor’s Browser effectue une redirection vers la Universal Login Page (page de connexion universelle) Auth0. Définissez le paramètre openUrl sur la fonction loginWithRedirect pour utiliser Browser.open afin que l’URL soit ouverte à l’aide du composant de navigateur système de l’appareil (SFSafariViewController sur iOS et Chrome Custom Tabs [Onglets personnalisés Chrome] sur Android).
        Par défaut, la méthode loginWithRedirect de la trousse SDK utilise window.location.href pour accéder à la page de connexion dans l’application de navigateur par défaut sur l’appareil de l’utilisateur plutôt que dans le composant de navigateur système approprié pour la plateforme. L’utilisateur quitterait votre application pour s’authentifier et pourrait rendre l’expérience utilisateur frustrante.
        Ionic – Étape 5 – Point de contrôle 
        La fonction loginWithRedirect indique à la trousse SDK d’initier le flux de connexion, en utilisant la fonction Browser.open pour ouvrir l’URL de connexion avec le composant navigateur du système de la plateforme en définissant le paramètre openUrl. Cela permet à votre utilisateur de se connecter à votre application. Les utilisateurs sont redirigés vers la page de connexion à Auth0 et ne reçoivent aucune erreur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous qu’il n’y a pas d’erreurs dans la fenêtre de la console du navigateur au point de connexion
        • assurez-vous que le domaine et l’identifiant client sont corrects selon votre application Auth0 dans le tableau de bord
        • si vous êtes redirigé vers Auth0 et recevez une page d’erreur, vérifiez la section des « détails techniques » en bas de la page pour connaître la raison de l’échec
        
+
+  
        
+
+## Gérer le rappel de connexion {{{ data-action="code" data-code="App.vue" }}}
+
+
+
        Une fois que les utilisateurs sont connectés avec la page de connexion universelle, ils sont redirigés vers votre application au moyen d’une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être traité au sein de votre application. Vous pouvez appeler la méthode handleRedirectCallback à partir de la trousse SDK Auth0 pour initialiser l’état d’authentification.
        Vous pouvez utiliser cette méthode uniquement sur une redirection depuis Auth0. Vérifiez que les paramètres code et state sont présents dans l’URL.
        La méthode Browser.close() devrait fermer le navigateur lorsque cet événement est déclenché.
        Cet article suppose que vous utiliserez des schémas d’URL personnalisés pour gérer le callback dans votre application. Pour ce faire, enregistrez votre YOUR_PACKAGE_ID comme schéma d’URL pour la plateforme de votre choix. Pour en savoir plus, lisez Définition d’un schéma d’URL personnalisé pour iOS ou Création de liens profonds vers le contenu des applications  pour Android.
        Ionic - Étape 6 - Point de contrôle 
        Ajoutez appUrlOpen au composant App de votre application et connectez-vous. La fenêtre du navigateur devrait se fermer une fois que l’utilisateur s’authentifie et se connecte à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="LogoutButton.vue" }}}
+
+
+
        Maintenant que les utilisateurs peuvent se connecter, vous devez configurer une façon de se déconnecter. Les utilisateurs doivent être redirigés vers le point de terminaison de déconnexion Auth0 dans le navigateur pour effacer leur session de navigation. Encore une fois, le plugiciel du navigateur de Capacitor doit effectuer cette redirection afin que l’utilisateur ne quitte pas votre application et ne vive pas une expérience frustrante.
        Pour y parvenir avec Ionic et Capacitor en conjonction avec le SDK Auth0 :
        • Créez l’URL de votre application vers laquelle Auth0 doit rediriger après la déconnexion. Il s’agit d’une URL qui utilise votre schéma personnalisé enregistré et le domaine Auth0. Ajoutez-la à votre configuration URL de déconnexions autorisées dans Auth0 Dashboard
        • Déconnectez-vous de la trousse SDK en appelant logout et transmettez votre URL de redirection comme paramètre logoutParams.returnTo.
        • Définissez le paramètre openUrl sur un callback qui utilise le plugiciel de navigateur Capacitor pour ouvrir l’URL à l’aide de Browser.open.
        De la même manière que pour l’étape de connexion, si vous ne définissez pas openUrl lors de l’appel de logout, la trousse SDK redirige l’utilisateur vers l’URL de déconnexion à l’aide de l’application de navigateur par défaut sur l’appareil, ce qui offre une expérience utilisateur sous-optimale.
        Ionic - Étape 7 - Point de contrôle 
        Fournir un moyen pour vos utilisateurs de se déconnecter de votre application. Vérifiez que vous redirigez vers Auth0, puis vers l’adresse spécifiée dans le paramètre returnTo. Vérifiez que vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vérifiez que l’URL que vous avez fournie dans le paramètre returnTo est enregistrée comme URL de rappel autorisée dans votre Tableau de bord Auth0
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="UserProfile.vue" }}}
+
+
+
        La trousse SDK Vue Auth0 récupère le profil utilisateur associé aux utilisateurs connectés dans n’importe quel composant dont vous avez besoin, comme leur nom ou leur image de profil, pour personnaliser l’interface utilisateur. Les informations de profil sont accessibles à partir de la propriété user exposée par la fonction composable useAuth0().
        L’initialisation de la trousse SDK est asynchrone, et vous devez protéger le profil utilisateur en activant les propriétés isLoading et user. Une fois que isLoading est false et que user a une valeur, le profil utilisateur peut être utilisé.
        Ionic - Étape 8 - Point de contrôle 
        Assurez-vous que vos utilisateurs ont un moyen de consulter leurs informations de profil dans l’application et vérifiez que vous êtes en mesure de récupérer et d’afficher les informations de votre profil à l’écran une fois que vous vous êtes connecté.
        
+
+  
        
+
+  
        
+
+  
        
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..06a0a42d16
--- /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..c7dd749fe5
--- /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..cd896b9fe0
--- /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..ac70c8d6b6
--- /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..873bf12474
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ios-swift/interactive.md
@@ -0,0 +1,106 @@
+---
+title: Ajouter une connexion à votre application iOS ou macOS
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application iOS/macOS à l’aide du SDK Auth0.swift.
+interactive:  true
+files:
+ - files/Auth0
+ - files/MainView
+ - files/ProfileView
+ - files/User
+github:
+  path: Sample-01
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application iOS ou macOS
+
+
+
        Ce guide explique comment ajouter l’authentification et accéder aux informations du profil utilisateur dans n’importe quelle application iOS/macOS à l’aide du SDK Auth0.swift.
        Pour utiliser ce guide rapide, vous devez :
        • vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • avoir une application iOS/macOS existante que vous souhaitez intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application configurée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour l’application que vous développez.
        Configurer une application Auth0
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionnez une application Auth0 native existante. Auth0 attribue à chaque application un ID client unique alphanumérique que votre application utilise pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce démarrage rapide met automatiquement à jour votre application Auth0 dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Consultez un exemple d’application si vous préférez explorer une configuration complète.
        Configuration des Callback URL et des URL de déconnexion.
        Auth0 fait appel aux Callback URL et aux URL de déconnexion pour rediriger les utilisateurs vers votre application. Auth0 fait appel à une URL de rappel après avoir authentifié l’utilisateur et à une URL de déconnexion après avoir supprimé le témoin de session. Si vous ne définissez pas les Callback URL et les URL de déconnexion, les utilisateurs ne pourront pas se connecter et se déconnecter de l’application, et votre application produira une erreur.
        Sur iOS 17.4+ et macOS 14.4+, il est possible d’utiliser des liens universels comme callback URL et URL de déconnexion. Lorsqu’activé, Auth0.swift reviendra à l’utilisation d’un schéma d’URL personnalisé sur les anciennes versions iOS/MacOS.
        Cette fonctionnalité nécessite un Xcode 15.3+ et un compte Apple Developer payant.
        Ajoutez les URL suivantes aux URL de rappel et URL de déconnexion, selon la plateforme de votre app. Si vous avez un domaine personnalisé, utilisez-le à la place du domaine de votre locataire Auth0.
        iOS
        https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+
+
        
+
+
        macOS
        https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+
+
        
+
+
        Par exemple, si l’identifiant de votre ensemble iOS est com.example.MyApp et votre domaine Auth0 est example.us.auth0.com, cette valeur sera alors :
        https://example.us.auth0.com/ios/com.example.MyApp/callback,
+
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+
+
        
+
+
        Configurer le domaine associé
        Cette étape nécessite un compte Apple Developer payant. Il est nécessaire d’utiliser des liens universels comme callback URL et URL de déconnexion. Ignorez cette étape pour utiliser plutôt un schéma d’URL personnalisé.
        Configurer l’ID Team et l’identifiant de l’ensemble
        Allez à la page des paramètres de votre application Auth0, faites défiler jusqu’en bas, et ouvrez Advanced Settings (Paramètres avancés) > (Paramètres de l’appareil). Dans la section iOS, définissez Team ID sur votre Apple Apple Team ID et App ID sur l’identifiant de l’ensemble de votre application.
        Auth0 Dashboard> Applications > Applications > [Native App] > Settings tab (Onglet des paramètres) > Advanced Settings (Paramètres avancés) > Device Settings tab (Onglet des paramètres de l’appareil)
        Cette action ajoutera votre application au fichier apple-app-site-association de votre locataire Auth0.
        Ajouter la capacité de domaine associé
        Dans Xcode, allez à l’ongletSigning and Capabilities (Signature et capacités) des paramètres cibles de votre application, puis appuyez sur le bouton + Capability (Capacité). Sélectionnez ensuite Associated Domains (Domaines associés).
        Xcode> Onglet Signing and Capabilities (Signature et capacités) > Add New (Ajouter nouveau) > Associated Domains (Domaines associés)
        Ajoutez l’entry suivante sous Associated Domains (Domaines associés) :
        webcredentials:labs-fundtraining.us.auth0.com
+
+
        
+
+
        Si vous avez un domaine personnalisé, utilisez-le à la place du domaine de votre locataire Auth0.
        Pour que le domaine associé fonctionne, votre application doit être signée avec votre certificat d’équipe même lors de la construction du simulateur iOS. Assurez-vous d’utiliser l’équipe Apple dont l’ID d’équipe est configuré dans la page des paramètres de votre application Auth0.
        
+
+## Installer la trousse SDK
+
+
+
        Utilisation du gestionnaire de packages Swift
        Ouvrez l’élément de menu suivant dans Xcode :
        File (Fichier) > Add Package Dependencies (Ajouter des dépendances de package)...
        Dans la zone de recherche Search or Enter Package URL (Rechercher ou saisir l’URL du package) entrez cette URL :
        https://github.com/auth0/Auth0.swift
+
+
        
+
+
        Ensuite, sélectionnez la règle de dépendance et appuyez sur Add Package (Ajouter le package).
        Pour plus d’informations sur SPM consultez la  documentation officielle.
        Utilisation de Cocoapods
        Ajoutez la ligne suivante à votre Podfile :
        pod 'Auth0', '~> 2.0'
+
+
        
+
+
        Ensuite, exécutez pod install.
        Pour plus d’informations sur CocoaPods, consultez la documentation officielle.
        Utilisation de Carthage
        Ajoutez la ligne suivante à votre Cartfile :
        github "auth0/Auth0.swift" ~> 2.0
+
+
        
+
+
        Ensuite, exécutez carthage bootstrap --use-xcframeworks.
        Pour en savoir plus sur Carthage, consultez la documentation officielle.
        
+
+## Configuration de la trousse SDK {{{ data-action="code" data-code="Auth0.plist" }}}
+
+
+
        La trousse SDK Auth0.swift a besoin de votre domain (domaine) Auth0 et de votre Client ID (Identifiant client). Ces valeurs se trouvent dans la page des paramètres de votre application Auth0.
        • domain (domaine) : Le domaine de votre locataire Auth0. Si vous avez un domaine personnalisé, utilisez-le à la place du domaine de votre locataire Auth0.
        • Client ID (Identifiant client) L’identifiant alphanumérique unique de l’application Auth0 que vous avez configuré précédemment dans ce démarrage rapide.
        Créez un fichier plist nommé Auth0.plist dans votre ensemble d’application contenant les valeurs du domaine Auth0 et de l’identifiant client.
        Vous pouvez également configurer la trousse SDK de manière programmatique. Consultez README pour en savoir plus.
        Démarrage rapide iOS Swift - Étape 3 - Point de contrôle 
        Vous avez configuré la trousse SDK Auth0.swift. Exécutez votre application afin de vérifier qu’elle ne produit pas d’erreurs liées à la trousse SDK.
        
+
+  
        
+
+  
        Si votre application génère des erreurs liées à la trousse SDK :
        • Assurez-vous d’avoir sélectionné la bonne application Auth0
        • Vérifiez que vous avez enregistré vos mises à jour d’URL
        • Assurez-vous d’avoir défini correctement le domaine Auth0 et l’identifiant client
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="MainView.swift#20:31" }}}
+
+
+
        Importez le module Auth0 dans le fichier où vous souhaitez présenter la page de connexion. Ensuite, présentez la page Universal Login (Connexion universelle) dans l’action de votre bouton Login (Connexion).
        Vous pouvez utiliser async/await ou Combine au lieu de l’API basée sur les rappels. Consultez README pour en savoir plus.
        Un exemple d’écran de connexion universelle pour une application iOS.
        Démarrage rapide iOS Swift – Étape 4 – Point de contrôle 
        Appuyez sur le bouton Login (Connexion) et vérifiez que :
        • Une boîte d’alerte s’affiche demandant le consentement.
        • Sélectionner Continue (Continuer) ouvre la page de connexion universelle dans un modal Safari.
        • Vous pouvez vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe ou un fournisseur social.
        • Le modal Safari se ferme automatiquement par la suite.
        
+
+  
        
+
+  
        Si la connexion échoue ou génère des erreurs :
        • Vérifiez que vous avez saisi la bonne URL de rappel
        • Assurez-vous de définir correctement le domaine Auth0 et l’identifiant client
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="MainView.swift#34:45" }}}
+
+
+
        Maintenant que vous pouvez vous connecter à votre application, vous avez besoin d’un moyen de vous déconnecter. Dans l’action de votre bouton Logout (Déconnexion), faites usage de la méthode clearSession() pour effacer le témoin de session de la connexion universelle.
        Démarrage rapide iOS Swift - Étape 5 - Point de contrôle 
        Appuyez sur le bouton Logout (Déconnexion) et vérifiez que :
        • Une boîte d’alerte s’affiche demandant le consentement.
        • Choisir Continue (Poursuivre) ouvre une page dans une boîte de dialogue modale Safari.
        • La boîte de dialogue modale Safari se ferme automatiquement par la suite.
        
+
+  
        
+
+  
        Si la déconnexion échoue ou génère des erreurs :
        • Vérifiez que vous avez saisi la bonne URL de rappel
        • Assurez-vous de définir correctement le domaine Auth0 et l’identifiant client
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Accéder aux informations du profil utilisateur {{{ data-action="code" data-code="User.swift#11:14" }}}
+
+
+
        L’instance Credentials que vous avez obtenue après vous être connecté inclut un jeton d’ID. Le jeton d’ID contient les informations de profil associées à l’utilisateur connecté, telles que son courriel et sa photo de profil. Vous pouvez utiliser ces informations pour personnaliser l’interface utilisateur de votre application.
        La trousse SDK Auth0.swift inclut un utilitaire pour décoder les JWT, comme le jeton d’ID. Commencez par importer le module JWTDecode dans le fichier où vous souhaitez accéder aux informations du profil utilisateur. Ensuite, utilisez la méthode decode(jwt:) pour décoder le jeton d’ID et accéder aux demandes qu’il contient.
        Vous pouvez récupérer les dernières informations utilisateur avec la méthode userInfo(withAccessToken:). Consultez les EXAMPLES (EXEMPLES) pour en savoir plus.
        Démarrage rapide iOS Swift - Étape 6 - Point de contrôle 
        Vérifiez que vous pouvez accéder à email, picture, ou à toute autre demande après vous être connecté.
        
+
+  
        
+
+  
        Si vous ne pouvez pas accéder aux informations de l’utilisateur :
        • Vérifiez que vous avez importé le module JWTDecode dans lequel vous appelez la méthode decode(jwt:)
        • Vérifiez l’orthographe de vos requêtes.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou visitez nos forums communautaires pour obtenir de l’aide.
        
+
+  
        
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/MainPage.xaml.md b/fr-ca/articles/quickstart/native/maui/files/MainPage.xaml.md
new file mode 100644
index 0000000000..010c5970f8
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/maui/files/MainPage.xaml.md
@@ -0,0 +1,73 @@
+---
+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 = "";
+    }
+}
+```
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..4e568a4bc0
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,158 @@
+---
+title: Ajouter une connexion à votre application MAUI
+description: Ce tutoriel explique comment ajouter une connexion utilisateur avec Auth0 à une application .NET MAUI.
+interactive:  true
+files:
+ - files/MainPage.xaml
+github:
+  path: Sample
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application MAUI
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application .NET MAUI à l’aide des SDK Auth0 de MAUI.
        La trousse SDK MAUI prend en charge Android, iOS, macOS et Windows. Poursuivez la lecture pour en savoir plus sur la configuration propre à chaque plateforme.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple, définissez cette URL comme suit : myapp://callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple, définissez cette URL comme suit : myapp://callback.
        
+
+## Installer la trousse SDK Auth0
+
+
+
        Auth0 propose une trousse SDK MAUI pour simplifier le processus de mise en œuvre de l’authentification Auth0 dans les applications MAUI.
        Utilisez le gestionnaire de paquet NuGet (Outils -> Gestionnaire de paquets de la bibliothèque -> Console du gestionnaire de paquets) pour installer le paquet Auth0.OidcClient.MAUI.
        Vous pouvez aussi utiliser la Console du gestionnaire de paquets NuGet (Install-Package) ou le dotnet interface de ligne de commande (CLI) (dotnet add).
        Install-Package Auth0.OidcClient.MAUI
+
+
        
+
+
        dotnet add package Auth0.OidcClient.MAUI
+
+
        
+
+
        
+
+## Configuration propre à la plateforme
+
+
+
        Une configuration propre à la plateforme est nécessaire pour utiliser la trousse SDK avec Android et Windows.
        Android
        Créez une nouvelle activité qui étend WebAuthenticatorCallbackActivity :
        [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";
+
+}
+
+
        
+
+
        L’activité ci-dessus garantira que l’application peut gérer l’URL myapp://callback lorsque Auth0 redirige de nouveau vers l’application Android après la connexion.
        Windows
        Pour garantir la réactivation correcte de votre application après la redirection vers Auth0, vous devez faire deux choses :
        • Ajouter le protocole correspondant au Package.appxmanifest. Dans ce cas, il est défini sur myapp, mais vous pouvez le changer à votre guise (veillez également à mettre à jour toutes les URL Auth0 correspondantes).
        <Applications>
+
+ <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="$targetentrypoint$">
+
+ <Extensions>
+
+ <uap:Extension Category="windows.protocol">
+
+ <uap:Protocol Name="myapp"/>
+
+ </uap:Extension>
+
+ </Extensions>
+
+ </Application>
+
+</Applications>
+
+
        
+
+
        • Appelez Activator.Default.CheckRedirectionActivation() dans le fichier propre à App.xaml.cs.
        public App()
+
+{
+
+ if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation())
+
+ return;
+
+
+
+ this.InitializeComponent();
+
+}
+
+
        
+
+
        
+
+## Instancier Auth0Client. {{{ data-action="code" data-code="MainPage.xaml.cs#3:10" }}}
+
+
+
        Pour intégrer Auth0 dans votre application, instanciez une instance de la classe Auth0Client en passant une instance de Auth0ClientOptions qui contient votre domaine Auth0, votre identifiant client et les permissions requises. De plus, vous devez également configurer RedirectUri et PostLogoutRedirectUri pour garantir qu’Auth0 peut rediriger vers l’application en utilisant les URL configurées.
        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"
+
+ });
+
+
        
+
+
        En règle générale, la trousse SDK emploiera les onglets personnalisés de Chrome pour Android, ASWebAuthenticationSession pour iOS et macOS, et le navigateur par défaut de votre système sur Windows.
        Démarrage rapide MAUI - Étape 4 - Point de contrôle 
        Votre Auth0Client devrait maintenant être correctement instancié. Exécutez votre application pour vérifier que :
        • l’Auth0Client est correctement instancié dans la MainPage,
        • votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="MainPage.xaml.cs#25:25" }}}
+
+
+
        À présent que vous avez configuré votre application Auth0 et la trousse SDK Auth0, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode LoginAsync() de la trousse SDK pour créer un bouton de connexion qui redirige les utilisateurs vers la page de connexion universelle Auth0.
        var loginResult = await client.LoginAsync();
+
+
        
+
+
        S’il n’y a pas d’erreur, vous pouvez accéder à User, IdentityToken, AccessToken et RefreshToken dans le LoginResult renvoyé par LoginAsync().
        Démarrage rapide MAUI – Étape 5 – Point de contrôle 
        Vous devez désormais pouvoir vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe.
        Appuyez sur le bouton de connexion et vérifiez que :
        • Votre application vous redirige vers la page Connexion universelle Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez appelé LoginAsync comme prévu
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajoutez une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="MainPage.xaml.cs#32:32" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. Créez un bouton de déconnexion en utilisant la méthode LogoutAsync() de la trousse SDK. Lorsque les utilisateurs se déconnectent, ils seront redirigés vers votre point de terminaison de déconnexion Auth0, qui par la suite les redirigera immédiatement vers l’URL de déconnexion que vous avez configurée précédemment dans ce démarrage rapide.
        await client.LogoutAsync();
+
+
        
+
+
        Démarrage rapide MAUI – Étape 6 – Point de contrôle 
        Exécutez votre application et cliquez sur le bouton de déconnexion, vérifiez que :
        • Votre application vous redirige vers l’adresse que vous avez précisée comme l’une des URL de déconnexion autorisées dans les paramètres de votre application.
        • Vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez configuré la bonne URL de déconnexion
        • vous avez appelé LogoutAsync comme prévu
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="MainPage.xaml.cs#55:58" }}}
+
+
+
        Maintenant que vos utilisateurs peuvent se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les profile information (informations de profil) associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir afficher le nom ou la photo de profil d’un utilisateur connecté dans votre projet.
        La trousse SDK Auth0 de MAUI fournit des informations sur l’utilisateur par l’intermédiaire de la propriété LoginResult.User.
        
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/AppDelegate.md b/fr-ca/articles/quickstart/native/net-android-ios/files/AppDelegate.md
new file mode 100644
index 0000000000..0efcf0d8ce
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/net-android-ios/files/AppDelegate.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;
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/native/net-android-ios/files/MainActivity.md b/fr-ca/articles/quickstart/native/net-android-ios/files/MainActivity.md
new file mode 100644
index 0000000000..dcf30e59af
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/net-android-ios/files/MainActivity.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 = "${account.namespace}",
+    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();
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/native/net-android-ios/files/MyViewController.md b/fr-ca/articles/quickstart/native/net-android-ios/files/MyViewController.md
new file mode 100644
index 0000000000..99821cc2bd
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/net-android-ios/files/MyViewController.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();
+    }
+}
+```
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..06b11d8815
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/net-android-ios/interactive.md
@@ -0,0 +1,163 @@
+---
+title: Ajouter une connexion à votre application .NET Android ou iOS
+description: Ce tutoriel explique comment ajouter une connexion utilisateur avec Auth0 à une application .NET Android ou iOS
+interactive:  true
+files:
+ - files/MainActivity
+ - files/AppDelegate
+ - files/MyViewController
+github:
+  path: Quickstart/01-Login
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application .NET Android ou iOS
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application .NET Android et iOS à l’aide des SDK Auth0 pour Android et iOS.
        Ce guide de démarrage couvre .NET Android et iOS, les futures générations de Xamarin.Android et de Xamarin.iOS. Si vous utilisez encore Xamarin.Android et Xamarin.iOS, vous pouvez suivre ce guide, car l’intégration est identique et les SDK sont compatibles.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Avoir un projet Android ou iOS fonctionnel utilisant .NET 6 (ou une version ultérieure) avec lequel vous souhaitez vous intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour votre projet.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application « Application native », ou sélectionnez une application existante qui représente le projet avec lequel vous souhaitez vous intégrer. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce démarrage rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez l’une des URL suivantes selon votre plateforme :
        • Android : YOUR_PACKAGE_NAME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS : YOUR_BUNDLE_ID://{yourDomain}/ios/YOUR_BUNDLE_ID/callback
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez l’une des URL suivantes selon votre plateforme :
        • Android : YOUR_PACKAGE_NAME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS : YOUR_BUNDLE_ID://{yourDomain}/ios/YOUR_BUNDLE_ID/callback
        Enfin, assurez-vous que le type d’application pour votre application est défini sur Native dans les Application Settings (Paramètres d’application).
        
+
+## Installer la trousse SDK Auth0
+
+
+
        Auth0 propose une trousse SDK Android et iOS pour simplifier le processus d’implémentation de l’authentification Auth0 dans les applications .NET Android et iOS.
        Utilisez le gestionnaire de packages NuGet (Tools (Outils) -> Library Package Manager (Gestionnaire de packages de bibliothèque) -> Package Manager Console (Console du gestionnaire de packages)) pour installer le package Auth0.OidcClient.AndroidX ou Auth0.OidcClient.iOS, pour développer une application Android ou iOS.
        Sinon, vous pouvez utiliser la Console du gestionnaire de packages NuGet (Install-Package) ou le dotnet CLI (dotnet add).
        Install-Package Auth0.OidcClient.AndroidX
+
+Install-Package Auth0.OidcClient.iOS
+
+
        
+
+
        dotnet add Auth0.OidcClient.AndroidX
+
+dotnet add Auth0.OidcClient.iOS
+
+
        
+
+
        
+
+## Instancier Auth0Client
+
+
+
        Pour intégrer Auth0 dans votre application, instanciez une instance de la classe Auth0Client en passant une instance de Auth0ClientOptions qui contient votre domaine Auth0 et votre identificateur client.
        using Auth0.OidcClient;
+
+
+
+var client = new Auth0Client(new Auth0ClientOptions {
+
+  Domain = "${account.namespace}",
+
+  ClientId = "${account.clientId}"
+
+}, this);
+
+
        
+
+
        Par défaut, la trousse SDK utilisera les onglets personnalisés Chrome pour Android et ASWebAuthenticationSession pour iOS.
        Démarrage rapide .NET Android/iOS - Étape 3 - Point de contrôle 
        Votre Auth0Client devrait maintenant être correctement instancié. Exécutez votre application pour vérifier que :
        • l’Auth0Client est instancié correctement dans Activity (Android) ou UIViewController (iOS) ;
        • votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Configurer Android {{{ data-action="code" data-code="MainActivity.cs#2:9" }}}
+
+
+
        Une fois un utilisateur authentifié avec succès, il est redirigé vers l’URL de rappel que vous avez configurée précédemment dans ce guide rapide.
        Pour gérer la fonction Callback sur les appareils Android, vous devez enregistrer une intention qui gère cette URL de rappel. Une façon simple de le faire est d’enregistrer l’intention sur la même activité à partir de laquelle vous avez appelé la méthode LoginAsync pour instancier le flux d’authentification.
        Assurez-vous de remplacer YOUR_ANDROID_PACKAGE_NAME dans l’exemple de code par le nom réel du package de votre application, comme com.mycompany.myapplication, et de vous assurer que tout le texte des champs DataScheme, DataHostet et DataPathPrefix est en majuscules. De plus, définissez LaunchMode = LaunchMode.SingleTask pour l’activité; sinon, le système créera une nouvelle instance de l’activité chaque fois que l’URL de rappel est appelée.
        De plus, vous devez gérer l’intention dans l’événement OnNewIntent dans votre classe Activity. Vous devez notifier le client OIDC Auth0 pour terminer le flux d’authentification en appelant la méthode Send du singleton ActivityMediator, en transmettant l’URL qui a été envoyée.
        protected override void OnNewIntent(Intent intent)
+
+    {
+
+        base.OnNewIntent(intent);
+
+        ActivityMediator.Instance.Send(intent.DataString);
+
+    }
+
+
        
+
+
        
+
+## Configurer iOS {{{ data-action="code" data-code="AppDelegate.cs#6:11" }}}
+
+
+
        Une fois un utilisateur authentifié avec succès, il est redirigé vers l’URL de rappel que vous avez configurée précédemment dans ce guide rapide.
        Pour gérer la callback sur les appareils iOS :
        1. Ouvrez le fichier Info.plist de votre application dans Visual Studio, puis accédez à l’onglet Advanced (Avancé).
        2. Sous URL Types (Types d’URL), cliquez sur le bouton Add URL Type (Ajouter le type d’URL).
        3. Définissez Identifier (Identificateur) sur Auth0, les URL Schemes (Schémas d’URL) identiques à Bundle IdentifierRole (Rôle)
        Voici un exemple de la représentation XML de votre fichier Info.plist après avoir ajouté le type d’URL :
        <key>CFBundleURLTypes</key>
+
+<array>
+
+ <dict>
+
+ <key>CFBundleTypeRole</key>
+
+ <string>None</string>
+
+ <key>CFBundleURLName</key>
+
+ <string>Auth0</string>
+
+ <key>CFBundleURLSchemes</key>
+
+ <array>
+
+ <string>YOUR_BUNDLE_IDENTIFIER</string>
+
+ </array>
+
+ </dict>
+
+</array>
+
+
        
+
+
        De plus, vous devez gérer l’URL de rappel dans l’événement OpenUrl dans votre classe AppDelegate. Vous devez notifier le client OIDC Auth0 pour terminer le flux d’authentification en appelant la méthode Send du singleton ActivityMediator, en transmettant l’URL qui a été envoyée.
        
+
+## Ajouter une fonctionnalité de connexion à votre application
+
+
+
        À présent que vous avez configuré votre application Auth0 et la trousse SDK Auth0, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode LoginAsync() de la trousse SDK pour créer un bouton de connexion qui redirige les utilisateurs vers la page de connexion universelle Auth0.
        var loginResult = await client.LoginAsync();
+
+
        
+
+
        S’il n’y a pas d’erreur, vous pouvez accéder à User, IdentityToken, AccessToken et RefreshToken dans le LoginResult renvoyé par LoginAsync().
        Démarrage rapide .NET Android/iOS – Étape 6 – Point de contrôle 
        Vous devez désormais pouvoir vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe.
        Appuyez sur le bouton de connexion et vérifiez que :
        • Votre application Android ou iOS vous redirige vers la page de connexion universelle Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez appelé LoginAsync comme prévu
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. Créez un bouton de déconnexion en utilisant la méthode LogoutAsync() de la trousse SDK. Lorsque les utilisateurs se déconnectent, ils seront redirigés vers votre point de terminaison de déconnexion Auth0, qui par la suite les redirigera immédiatement vers l’URL de déconnexion que vous avez configurée précédemment dans ce démarrage rapide.
        await client.LogoutAsync();
+
+
        
+
+
        Guide rapide .NET Android/iOS - Étape 7 - Point de contrôle 
        Exécutez votre application et cliquez sur le bouton de déconnexion. Veuillez vérifiez que :
        • Votre application Android ou iOS vous redirige vers l’adresse que vous avez spécifiée comme l’une des URL de déconnexion autorisées dans les paramètres de votre application.
        • Vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez configuré la bonne URL de déconnexion
        • vous avez appelé LogoutAsync comme prévu
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur
+
+
+
        Vu que vos utilisateurs peuvent désormais se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être afficher le nom ou la photo de profil d’un utilisateur connecté dans votre projet.
        La trousse SDK Auth0 pour Android et iOS fournit des informations sur l’utilisateur via la propriété LoginResult.User.
        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-button.md b/fr-ca/articles/quickstart/spa/angular/files/login-button.md
new file mode 100644
index 0000000000..e23ae11430
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/angular/files/login-button.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();
+  }
+}
+```
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-button.md b/fr-ca/articles/quickstart/spa/angular/files/logout-button.md
new file mode 100644
index 0000000000..15c515882b
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/angular/files/logout-button.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 
+      }
+    });
+  }
+}
+```
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/main.md b/fr-ca/articles/quickstart/spa/angular/files/main.md
new file mode 100644
index 0000000000..75912e62eb
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/angular/files/main.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
+      }
+    }),
+  ]
+});
+```
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/files/user-profile.md b/fr-ca/articles/quickstart/spa/angular/files/user-profile.md
new file mode 100644
index 0000000000..711e1577df
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/angular/files/user-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) {}
+}
+```
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..07dc3a2c12
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/angular/interactive.md
@@ -0,0 +1,66 @@
+---
+title: Ajouter une connexion à votre application Angular
+description: Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application Angular à l’aide de la trousse SDK Angular Auth0.
+interactive:  true
+files:
+ - files/main
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: Sample-01
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Angular
+
+
+
        Consultez le guide Angular Authentication By Example pour un examen approfondi de l’implémentation de l’authentification des utilisateurs dans Angular. Ce guide fournit des détails supplémentaires sur la façon de créer un bouton d’inscription, d’ajouter des protections de routage et d’appeler une API protégée à partir de Angular.
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application Angular à l’aide de la trousse SDK Angular Auth0.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Disposer d’un projet Angular fonctionnel avec lequel vous souhaitez vous intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:4200.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:4200.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:4200.
        
+
+## Installer la trousse SDK React Auth0
+
+
+
        Auth0 propose une trousse SDK Angular pour simplifier le processus de mise en œuvre de l’authentification et de l’autorisation Auth0 dans les applications Angular.
        Installez la trousse SDK Angular Auth0 en exécutant les commandes suivantes dans votre terminal :
        npm install @auth0/auth0-angular
        La trousse SDK expose plusieurs types qui aident à intégrer Auth0 dans une application Angular, y compris un module et un service d’authentification.
        
+
+## Enregistrer et fournir Auth0 {{{ data-action="code" data-code="main.ts#7:13" }}}
+
+
+
        La trousse SDK exporte provideAuth0, qui est une fonction provide contenant tous les services nécessaires au fonctionnement de la trousse SDK. Pour l’enregistrer dans votre application :
        1. Ouvrez le fichier main.ts.
        2. Importez la fonction provideAuth0 du package @auth0/auth0-angular.
        3. Ajoutez provideAuth0 à l’application en l’ajoutant aux providers dans bootstrapApplication.
        4. Injectez AuthService dans AppComponent.
        La fonction provideAuth0 prend les propriétés domain et clientId; les valeurs de ces propriétés correspondent aux valeurs Domain et Client ID que vous pouvez trouver sous Settings (Paramètres) dans la Single-Page Application (Application à page unique) que vous avez enregistrée avec Auth0. En outre, nous configurons authorizationParams.redirect_uri, qui permet à Auth0 de rediriger l’utilisateur vers l’URL spécifique après une authentification réussie.
        Si vous utilisez un domaine personnalisé avec Auth0, la valeur de la propriété de domaine est la valeur de votre domaine personnalisé au lieu de la valeur indiquée dans l’onglet « Settings (Paramètres) ».
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login-button.ts#11:13" }}}
+
+
+
        À présent que vous avez configuré votre application Auth0 et la trousse SDK Angular Auth0, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode loginWithRedirect() de la classe AuthService dans la trousse SDK pour rediriger les utilisateurs vers la page de connexion universelle Auth0 où Auth0 peut les authentifier. Après qu’un utilisateur se soit authentifié avec succès, il sera redirigé vers votre application et vers l’URL de rappel que vous avez configurée plus tôt dans ce guide.
        Créez un bouton de connexion dans votre application qui appelle loginWithRedirect() lorsqu’il est sélectionné.
        Angular - Étape 4 - Point de contrôle 
        Vous devriez maintenant pouvoir vous connecter à votre application.
        Exécutez votre application et sélectionnez le bouton de connexion. Vérifiez que :
        • Vous pouvez vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe.
        • Votre application vous redirige vers la page Connexion universelle Auth0.
        • Vous êtes redirigé vers Auth0 pour l’authentification.
        • Auth0 redirige bien vers votre application après l’authentification.
        • Vous ne recevez aucun message d’erreur dans la console lié à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous d’avoir configuré le bon authorizationParams.redirect_uri
        • assurez-vous d’avoir ajouté le boutonLoginButtonComponent aux déclarations du module
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou la page de notre communauté.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout-button.ts#19:25" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. La trousse SDK fournit une méthode logout() sur la classe AuthService que vous pouvez utiliser pour déconnecter un utilisateur de votre application. Lorsque les utilisateurs se déconnectent, ils seront redirigés vers votre point de terminaison de déconnexion Auth0, qui par la suite les redirigera immédiatement vers votre application et l’URL de déconnexion que vous avez configurée précédemment dans ce démarrage rapide.
        Créez un bouton de déconnexion dans votre application qui appelle logout() lorsqu’il est sélectionné.
        La trousse SDK expose un observable isAuthenticated$ sur la classe AuthService qui vous permet de vérifier si un utilisateur est authentifié ou non. Vous pouvez produire les boutons de connexion et de déconnexion de manière conditionnelle en fonction de la valeur de l’observable isAuthenticated$. Vous pouvez également utiliser un seul bouton pour combiner les boutons de connexion et de déconnexion ainsi que leur rendu conditionnel.
        Angular - Étape 5 - Point de contrôle 
        Vous devriez maintenant pouvoir vous connecter à votre application.
        Exécutez votre application, connectez-vous et sélectionnez le bouton de déconnexion. Vérifiez que :
        • vous êtes redirigé vers le point de terminaison de déconnexion Auth0.
        • Auth0 redirige bien vers votre application et l’URL de déconnexion correcte.
        • vous n’êtes plus connecté à votre application.
        • Vous ne recevez aucun message d’erreur dans la console lié à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous d’avoir configuré l’URL de déconnexion comme l’une des URL de déconnexion autorisées dans les paramètres de votre application
        • vérifiez que vous avez ajouté le LogoutButtonComponent aux déclarations du module
        • cherchez d’autres erreurs éventuelles dans les journaux de l’application
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou la page de notre communauté.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
        Étant donné que vos utilisateurs peuvent désormais se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir personnaliser l’interface utilisateur en affichant le nom ou la photo de profil d’un utilisateur connecté.
        La trousse SDK Angular Auth0 fournit des informations sur les utilisateurs par l’intermédiaire de l’observable user$ exposé par la classe AuthService. L’observable user$ contenant des informations et des artefacts sensibles liés à l’identité de l’utilisateur, sa disponibilité dépend de l’état d’authentification de l’utilisateur. Heureusement, l’observable user$ est configuré pour émettre des valeurs uniquement lorsque l’observable isAuthenticated$ est défini sur vrai, de sorte qu’il n’est pas nécessaire de vérifier manuellement l’état de l’authentification avant d’accéder aux données du profil utilisateur.
        La trousse SDK expose également un observable isAuthenticated$ sur la classe AuthService qui vous permet de vérifier si un utilisateur est authentifié ou non, ce qui vous aide à décider s’il faut afficher ou masquer des éléments de l’interface utilisateur, par exemple.
        Examinez le code UserProfileComponent dans le panneau interactif pour voir des exemples d’utilisation de ces fonctions.
        Angular - Étape 6 - Point de contrôle 
        Vous devriez maintenant être en mesure d’afficher les informations relatives au profil utilisateur.
        Exécutez votre application et vérifiez que :
        • Les informations sur l’utilisateur s’affichent correctement après la connexion.
        • Les informations sur l’utilisateur ne s’affichent pas après la déconnexion.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous d’être connecté
        • assurez-vous que vous essayez d’accéder à une propriété existante telle que user.name
        • assurez-vous d’avoir ajouté le composant UserProfileComponent aux déclarations du module adéquat
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/main_view.md b/fr-ca/articles/quickstart/spa/flutter/files/main_view.md
new file mode 100644
index 0000000000..3d1a6f111c
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/flutter/files/main_view.md
@@ -0,0 +1,58 @@
+---
+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/files/profile_view.md b/fr-ca/articles/quickstart/spa/flutter/files/profile_view.md
new file mode 100644
index 0000000000..34ada342a4
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/flutter/files/profile_view.md
@@ -0,0 +1,26 @@
+---
+name: profile_view.dart
+language: javascript
+---
+    
+```javascript
+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..146c8025a1
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/flutter/interactive.md
@@ -0,0 +1,77 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Flutter
+description: Ce guide explique comment intégrer Auth0 à une application Flutter à l’aide de la trousse SDK Auth0 Flutter.
+interactive:  true
+files:
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Flutter
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et d’accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à une application Flutter à l’aide de la trousse SDK Auth0 Flutter.
        La trousse SDK Flutter ne prend actuellement en charge que les applications Flutter s’exécutant sur les plateformes Android, iOS ou Web.
        Ce guide rapide suppose que vous avez déjà une application Flutter installée et active. Si ce n’est pas le cas, consultez les guides de démarrage de Flutter pour commencer l’utilisation d’une application simple.
        Vous devez également être familiarisé avec l’outil de ligne de commande Flutter.
        
+
+## Configuration d’Auth0
+
+
+
        Lorsque vous vous êtes inscrit à Auth0, une nouvelle application a été créée pour vous, ou vous auriez pu en créer une nouvelle. Vous aurez besoin de quelques informations à propos de cette application pour communiquer avec Auth0. Vous pouvez obtenir ces informations dans la section Paramètres d’application d’Auth0 Dashboard.
        null
        Si vous utilisez l’application par défaut avec une application native ou une application à page unique, veillez à mettre à jour la méthode d’authentification du point de terminaison des jetons en la réglant sur None et à définir le type d’application sur SPA ou Native.
        Les informations suivantes sont nécessaires :
        • Domaine
        • Identifiant client
        Si vous téléchargez l’exemple en haut de cette page, les détails sont renseignés pour vous.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle Auth0 redirige l’utilisateur après qu’il s’est authentifié. L’URL de rappel de votre application doit être ajoutée au champ URL de rappel autorisées dans les Paramètres d’application. Si ce champ n’est pas défini, les utilisateurs ne pourront pas se connecter à l’application et obtiendront un message d’erreur.
        Si vous suivez l’exemple de projet que vous avez téléchargé en haut de cette page, vous devez définir l’URL de rappel autorisée sur http://localhost:3000.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle Auth0 peut se rediriger une fois que l’utilisateur a été déconnecté du serveur d’autorisations. Cette URL est spécifiée dans le paramètre de requête returnTo. L’URL de déconnexion de votre application doit être ajoutée au champ URL de déconnexions autorisées dans les Application Settings (Paramètres d’application). Si ce champ n’est pas défini, les utilisateurs ne pourront pas se déconnecter de l’application et obtiendront un message d’erreur.
        Si vous suivez l’exemple de projet que vous avez téléchargé en haut de cette page, l’URL de déconnexion que vous devez ajouter au champ URL de déconnexions autorisées est http://localhost:3000.
        Configurer les origines Web autorisées
        Vous devez ajouter l’URL de votre application au champ Origines Web autorisées dans vos Application Settings (Paramètres d’application). Si vous n’enregistrez pas l’URL de votre application ici, l’application ne pourra pas actualiser silencieusement les jetons d’authentification et vos utilisateurs seront déconnectés la prochaine fois qu’ils visiteront l’application ou qu’ils actualiseront la page.
        Si vous suivez l’exemple de projet que vous avez téléchargé en haut de cette page, vous devez définir l’option Origines Web autorisées sur http://localhost:3000.
        
+
+## Installer la trousse SDK Flutter Auth0
+
+
+
        Ajoutez la trousse SDK Flutter Auth0 au projet :
        flutter pub add auth0_flutter
+
+
        
+
+
        Ajoutez l’étiquette de script suivante à votre page index.html :
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js" defer></script>
+
+
        
+
+
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="main_view.dart" }}}
+
+
+
        La connexion universelle est le moyen le plus simple de mettre en place l’authentification dans votre application. Nous recommandons de l’utiliser pour une meilleure expérience, une meilleure sécurité et un plus grand nombre de fonctionnalités.
        Intégrez la connexion universelle Auth0 dans votre application Flutter (Web) en utilisant la classe Auth0Web. Redirigez vos utilisateurs vers la page de connexion universelle Auth0 en utilisant loginWithRedirect().
        Vous devrez normalement définir le paramètre redirectUrl sur loginWithRedirect. Si ce paramètre n’est pas spécifié, Auth0 utilisera la route de connexion par défaut, qui n’est pas configurée par défaut.
        Lorsqu’un utilisateur se connecte, il est redirigé vers votre application. Vous pouvez alors accéder à l’identificateur et aux jetons d’accès de cet utilisateur en appelant onLoad lors du démarrage et en gérant les informations d’identification qui vous sont communiquées :
        auth0.onLoad().then((final credentials) => setState(() {
+
+    // Handle or store credentials here
+
+    _credentials = credentials;
+
+  }));
+
+
        
+
+
        Flutter Web – Étape 3 – Point de contrôle 
        Ajoutez un bouton à votre application qui appelle loginWithRedirect() et déconnecte l’utilisateur de votre application. Vérifiez que vous êtes redirigé vers Auth0 pour l’authentification, puis renvoyé vers votre application.
        Vérifiez que vous pouvez accéder aux credentials après avoir appelé onLoad et que vous pouvez accéder à l’identifiant et aux jetons d’accès.
        
+
+  
        
+
+  
        Si votre application n’a pas été lancée avec succès :
        • Assurez-vous que les URL de rappel autorisées sont correctement définies
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        • Assurez-vous que les valeurs de domaine et d’identifiant client sont importées correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application
+
+
+
        Pour déconnecter les utilisateurs, redirigez-les vers le point de terminaison Auth0 pour effacer leur session de connexion en appelant la trousse SDK Flutter Auth0 logout(). En savoir plus sur la déconnexion d’Auth0.
        Vous devez normalement spécifier returnToUrl lorsque vous appelez logout, sinon Auth0 utilisera par défaut la première URL de la liste URL de déconnexion autorisées.
        Flutter (Web) - Étape 4 - Point de contrôle 
        Ajoutez un bouton à votre application qui appelle logout() et déconnecte l’utilisateur de votre application. Lorsque vous le sélectionnez, vérifiez que votre application Flutter vous redirige vers le point de terminaison de déconnexion et vice-versa. Vous ne devriez pas être connecté à votre application.
        
+
+  
        
+
+  
        Si votre application n’a pas réussi à se déconnecter :
        • Assurez-vous que les URL de déconnexion autorisées sont correctement définies
        • Vérifiez que vous avez enregistré vos modifications après avoir saisi vos URL
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
        Le profil utilisateur récupère automatiquement les propriétés du profil utilisateur lors du chargement de la page. Il est possible d’y accéder et de les stocker en appelant onLoad lors du démarrage de l’application. L’objet retourné à partir de onLoad contient une propriété user avec toutes les propriétés du profil utilisateur. Cette propriété est alimentée en interne par le décodage du jeton d’ID.
        Flutter (Web) - Étape - Point de contrôle 
        Connectez-vous et inspectez la propriété user par rapport au résultat. Vérifiez les informations de profil utilisateur actuel, telles que son email ou name.
        
+
+  
        
+
+  
        Si votre application n’a pas renvoyé d’informations sur le profil utilisateur :
        • Vérifiez la validité du jeton d’ID
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..2efeee2d47
--- /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(
+
+    
+  ,
+);
+```
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..f490be840d
--- /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;
+```
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..466de32532
--- /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;
+```
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..032891f7bb
--- /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;
+```
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..3302b745da
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/react/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application React
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application React, nouvelle ou ancienne, à l’aide du SDK React Auth0.
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: Sample-01
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application React
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application React à l’aide du SDK React Auth0.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Disposer d’un projet React fonctionnel avec lequel vous souhaitez vous intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        Consultez le guide React Authentication By Example (Authentification React par l’exemple) pour un examen approfondi de l’implémentation de l’authentification des utilisateurs dans React. Ce guide fournit des détails supplémentaires sur la façon de créer un bouton d’inscription, d’ajouter des protections de routage en utilisant React Router, et d’appeler une API protégée à partir de React.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Installer la trousse SDK Auth0 React {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Auth0 propose une trousse SDK React (auth0-react.js) pour simplifier le processus de mise en œuvre de l’authentification et de l’autorisation Auth0 dans les applications React.
        Installez la trousse SDK React Auth0 en exécutant les commandes suivantes dans votre terminal :
        cd <your-project-directory>
+
+npm install @auth0/auth0-react
+
+
        
+
+
        Configurer le composant Auth0Provider
        Pour que la trousse SDK fonctionne adéquatement, définissez les propriétés suivantes dans le composant Auth0Provider :
        • domain: Le domaine de votre locataire Auth0. En général, il figure dans Auth0 Dashboard dans vos paramètres d’application dans le champ Domaine. Si vous utilisez un domaine personnalisé, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • clientId: L’identifiant de l’application Auth0 que vous avez configuré précédemment dans ce guide rapide. Il se trouve sur Auth0 Dashboard, dans la section Paramètres de l’application, dans le champ Identifiant client.
        • authorizationParams.redirect_uri: L’URL dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Cela correspond à l’URL de rappel que vous avez configurée précédemment dans ce guide de démarrage rapide. Cette valeur se trouve également dans Auth0 Dashboard, dans les paramètres de votre application, dans le champ URL de rappel. Assurez-vous que les informations que vous saisissez dans votre code correspondent à celles qui ont été configurées précédemment. Dans le cas contraire, vos utilisateurs verront un message d’erreur.
        Démarrage rapide React - Étape 2 - Point de contrôle 
        Votre composant Auth0Provider devrait maintenant être correctement configuré. Exécutez votre application pour vérifier que :
        • la trousse SDK s’initialise correctement,
        • votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client ont été importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login.js" }}}
+
+
+
        À présent que vous avez configuré votre application Auth0 et la trousse SDK Auth0 React, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode loginWithRedirect() de la trousse SDK pour créer un bouton de connexion qui redirige les utilisateurs vers la page de connexion universelle Auth0. Une fois un utilisateur authentifié avec succès, il est redirigé vers l’URL de rappel que vous avez configurée précédemment dans ce Démarrage rapide.
        Ce guide se concentre sur l’utilisation du hook React personnalisé useAuth0(). Si vous utilisez des composants de classe, consultez le composant de niveau supérieurwithAuth0().
        Créez un nouveau fichier dans votre application appelé login.js pour le composant du bouton de connexion, et copiez le code du panneau interactif à droite, qui contient la logique nécessaire à la connexion. Ensuite, mettez à jour votre fichier index.js pour y intégrer le nouveau bouton de connexion.
        Démarrage rapide React – Étape 3 – Point de contrôle 
        Vous devez désormais pouvoir vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe.
        Appuyez sur le bouton de connexion et vérifiez que :
        • Votre application React vous redirige vers la page de connexion universelle Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre application en utilisant la valeur authorizationParams.redirect_uri  que vous avez utilisée pour configurer Auth0Provider..
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez configuré le bon authorizationParams.redirect_uri
        • vous avez ajouté le bouton Connexion au fichier index.js.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout.js" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. Créez un bouton de déconnexion en utilisant la méthode Logout() de la trousse SDK. Lorsque les utilisateurs se déconnecteront, ils seront redirigés vers votre point de terminaison Auth0 logout qui par la suite les redirigera immédiatement vers l’URL de déconnexion que vous avez configurée précédemment dans ce guide de démarrage rapide.
        Créez un nouveau fichier dans votre application appelé logout.js pour le composant du bouton de déconnexion, et copiez le code du panneau interactif, qui contient la logique nécessaire à la déconnexion. Ensuite, mettez à jour votre fichier index.js pour y intégrer le nouveau bouton de déconnexion.
        Démarrage rapide React – Étape 4 – Point de contrôle 
        Exécutez votre application et cliquez sur le bouton de déconnexion, vérifiez que :
        • Votre application React vous redirige vers l’adresse que vous avez précisée comme l’une des URL de déconnexion autorisées dans les paramètres de votre application.
        • Vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez configuré la bonne URL de déconnexion
        • vous avez ajouté le bouton Déconnexion au fichier index.js
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        Vu que vos utilisateurs peuvent désormais se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir afficher le nom ou la photo de profil d’un utilisateur connecté dans votre projet.
        La trousse SDK React Auth0 fournit des informations sur l’utilisateur par l’intermédiaire de la propriété user. Examinez le code profile.js dans le panneau interactif pour voir un exemple de la façon de l’utiliser.
        Étant donné que la propriété user contient des informations sensibles liées à l’identité de l’utilisateur, sa disponibilité dépend de l’état d’authentification de l’utilisateur. Pour éviter les erreurs de rendu, vous devez toujours :
        • Utilisez la propriété isAuthenticated pour déterminer si Auth0 a authentifié l’utilisateur avant que React ne rende un composant qui consomme la propriété user.
        • Assurez-vous que la trousse SDK a fini de se charger en vérifiant que isLoading est faux avant d’accéder à la propriété isAuthenticated.
        null
        Démarrage rapide React - Étape 5 - Point de contrôle 
        Vérifiez que :
        • Vous pouvez afficher user.name ou toute autre propriété de l’utilisateur dans un composant correctement, après vous être connecté.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vous avez ajouté la vérification isLoading avant d’accéder à la propriété isAuthenticated
        • vous avez ajouté le composant Profile au fichier index.js
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..52be06a92e
--- /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..897afdacdf
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/interactive.md
@@ -0,0 +1,78 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application JavaScript
+description: Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans une application à page unique (SPA) qui utilise du simple JavaScript, en utilisant la trousse SDK Auth0 SPA.
+interactive:  true
+files:
+ - files/app
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application JavaScript
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans une application à page unique (SPA) qui utilise du simple JavaScript, en utilisant la trousse SDK Auth0 SPA.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Disposer d’un projet fonctionnel avec lequel vous souhaitez vous intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        Ce guide rapide suppose que vous ajoutez Auth0 à une application simple JavaScript, par opposition à l’utilisation d’un cadre d’applications comme React ou Angular.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Ajouter la trousse SDK Auth0 SPA
+
+
+
        Auth0 propose une trousse SDK SPA (auth0-spa-js) pour simplifier le processus de mise en œuvre de l’authentification et de l’autorisation Auth0 dans les applications JavaScript. Vous pouvez installer la trousse SDK Auth0 SPA en tant que paquet NPM ou à partir du CDN. Pour les besoins de ce démarrage rapide, nous utiliserons le CDN. Incluez cette balise de script dans votre page HTML :
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js"></script>
+
+
        
+
+
        
+
+## Créer le client Auth0 {{{ data-action="code" data-code="app.js#1:7" }}}
+
+
+
        Créez une nouvelle instance du client Auth0 fourni par la trousse SDK Auth0 SPA et fournissez les détails de l’application Auth0 que vous avez créée plus tôt dans ce guide rapide.
        Si un utilisateur s’est déjà connecté, le client actualisera l’état d’authentification lors du chargement de la page; l’utilisateur restera connecté après l’actualisation de la page.
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="app.js#8:14" }}}
+
+
+
        À présent que vous avez configuré votre application Auth0, ajouté la trousse SDK Auth0 SPA et créé le client Auth0, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode loginWithRedirect() de la trousse SDK pour rediriger les utilisateurs vers la page de connexion universelle Auth0 où Auth0 peut les authentifier. Une fois un utilisateur authentifié avec succès, il est redirigé vers l’URL de rappel que vous avez configurée précédemment dans ce démarrage rapide.
        Créez un bouton de connexion dans votre application qui appelle loginWithRedirect() lorsqu’il est sélectionné.
        Guide rapide Javascript - Étape 4 - Point de contrôle 
        Vous devriez maintenant pouvoir vous connecter à votre application.
        Exécutez votre application et sélectionnez le bouton de connexion. Vérifiez que :
        • Vous pouvez vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe
        • Votre application vous redirige vers la page Connexion universelle Auth0.
        • Vous êtes redirigé vers Auth0 pour l’authentification
        • Auth0 redirige bien vers votre application après l’authentification
        • Vous ne recevez aucun message d’erreur dans la console lié à Auth0
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • assurez-vous d'effectuer un enregistrement après avoir saisi vos URL
        • assurez-vous que le client Auth0 a été correctement configuré avec votre domaine Auth0 et votre identifiant client
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou la page de notre communauté.
        
+
+  
        
+
+## Gérer le rappel de Auth0 {{{ data-action="code" data-code="app.js#16:21" }}}
+
+
+
        Lorsque le navigateur est redirigé vers votre processus d’application, votre application doit appeler la fonction handleRedirectCallback() sur le client Auth0 uniquement lorsqu’elle détecte un rappel provenant d’Auth0. Une façon de procéder consiste à appeler handleRedirectCallback() uniquement lorsque des paramètres de requête code et state sont détectés.
        Si la gestion du rappel a réussi, les paramètres doivent être supprimés de l’URL afin d’éviter que le gestionnaire du rappel ne soit déclenché lors du prochain chargement de la page.
        Démarrage rapide Javascript - Étape 5 - Point de contrôle 
        Votre rappel provenant d’Auth0 devrait maintenant être correctement traité.
        Exécutez votre application et sélectionnez le bouton de connexion. Veuillez vérifiez que :
        • Auth0 redirige avec succès vers votre application après l’authentification.
        • les paramètres de requête sont supprimés de l’URL.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vérifiez que l’option redirect_uri a été configurée sur l’URL de votre application
        • si vous avez un paramètre de requête error, inspectez-le pour connaître la cause de l’erreur
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="app.js#23:29" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin de a way to log out (un moyen de se déconnecter). Le client Auth0 fournit une méthode logout() que vous pouvez utiliser pour déconnecter un utilisateur de votre application. Lorsque les utilisateurs se déconnectent, ils seront redirigés vers votre Auth0 logout endpoint (Point de terminaison de déconnexion Auth0), qui par la suite les redirigera immédiatement vers votre application et l’URL de déconnexion que vous avez configurée précédemment dans ce démarrage rapide.
        Créez un bouton de déconnexion dans votre application qui appelle logout() lorsqu’il est sélectionné.
        La trousse SDK présente une fonction isAuthenticated() qui permet de vérifier si un utilisateur est authentifié ou non. Vous pouvez produire les boutons de connexion et de déconnexion de manière conditionnelle en fonction de la valeur de la fonction isAuthenticated(). Vous pouvez également utiliser un seul bouton pour combiner les boutons de connexion et de déconnexion ainsi que leur rendu conditionnel.
        Guide rapide Javascript - Étape 6 - Point de contrôle 
        Vous devriez maintenant pouvoir vous connecter à votre application.
        Exécutez votre application, connectez-vous et sélectionnez le bouton de déconnexion. Vérifiez que :
        • vous êtes redirigé vers le point de terminaison de déconnexion Auth0.
        • Auth0 redirige bien vers votre application et l’URL de déconnexion correcte.
        • vous n’êtes plus connecté à votre application.
        • Vous ne recevez aucun message d’erreur dans la console lié à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous d’avoir configuré l’URL de déconnexion comme l’une des URL de déconnexion autorisées dans les Paramètres de votre application
        • inspectez les journaux de l’application pour y trouver d’autres erreurs éventuelles
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou visitez la page de notre communauté.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="app.js#31:45" }}}
+
+
+
        Vu que vos utilisateurs peuvent désormais se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir personnaliser l’interface utilisateur en affichant le nom ou la photo de profil d’un utilisateur connecté.
        La trousse SDK Auth0 SPA fournit des informations sur les utilisateurs par l’intermédiaire de la fonction getUser() exposée par le client Auth0. Le client Auth0 expose également une fonction isAuthenticated() qui vous permet de vérifier si un utilisateur est authentifié ou non, ce qui vous permet de déterminer s’il faut afficher ou masquer des éléments de l’interface utilisateur, par exemple. Examinez le code dans le panneau interactif pour voir des exemples d’utilisation de ces fonctions.
        Démarrage rapide JavaScript - Étape 7 - Point de contrôle 
        Vous devriez maintenant être en mesure d’afficher les informations relatives au profil utilisateur.
        Exécutez votre application et vérifiez que :
        • Les informations sur l’utilisateur s’affichent correctement après la connexion.
        • Les informations sur l’utilisateur ne s’affichent pas après la déconnexion.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que toutes les étapes précédentes fonctionnent sans problème
        • vérifiez votre code qui gère l’interface utilisateur en réponse à l’état d’authentification
        • inspectez les journaux de l’application pour y chercher d’autres erreurs liées à l’authentification silencieuse
        Vous rencontrez toujours des problèmes? Pour obtenir de l’aide, consultez notre documentation ou la page de notre communauté.
        
+
+  
        
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..7f2f476128
--- /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');
+```
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..21ef76110f
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/login.md
@@ -0,0 +1,37 @@
+---
+name: login.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..6e0420788f
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..97966a2320
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/profile.md
@@ -0,0 +1,50 @@
+---
+name: profile.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..e07e69499e
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Ajouter une connexion à votre application Vue
+description: Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application Vue à l’aide de la trousse SDK Vue Auth0.
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Vue
+
+
+
        Auth0 vous permet d’ajouter l’authentification à presque tous les types d’applications. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application Vue à l’aide de la trousse SDK Vue Auth0.
        Ce guide rapide est conçu pour l’utilisation de Vue Auth0 avec des applications Vue 3. Si vous utilisez Vue 2, veuillez plutôt consulter le tutoriel Vue 2 avec la trousse SDK Auth0 SPA ou le guide Vue.js Authentication 2 By Example.
        Pour utiliser ce guide rapide, vous aurez besoin de :
        • Un compte Auth0 gratuit ou une connexion à Auth0.
        • Un projet Vue fonctionnel avec lequel vous souhaitez vous intégrer OU vous pouvez télécharger un exemple d’application après vous être connecté.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Installer la trousse SDK Auth0 Vue {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Auth0 propose une trousse SDK Vue pour simplifier le processus d’implémentation de l’authentification et de l’autorisation Auth0 dans les applications Vue 3.
        Installez la trousse SDK Auth0 Vue en exécutant les commandes suivantes dans votre terminal :
        cd <your-project-directory>
+
+npm install @auth0/auth0-vue
+
+
        
+
+
        Enregistrer le plugiciel
        Pour que la trousse SDK fonctionne, vous devez enregistrer le plugiciel dans votre application Vue à l’aide des propriétés suivantes :
        • domain : Le domaine de votre locataire Auth0. Cette valeur se trouve dans Auth0 Dashboard dans les Settings (Paramètres) de votre application dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • clientId : L’identifiant de l’application Auth0 que vous avez configurée précédemment dans le démarrage rapide. Vous le trouverez dans Auth0 Dashboard sous les paramètres de votre application dans le champ Client ID (Identifiant client).
        • authorizationParams.redirect_uri : L’URL dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Cela correspond à l’URL de rappel que vous avez configurée précédemment dans ce démarrage rapide. Cette valeur se trouve dans Auth0 Dashboard, dans les Paramètres de votre application, dans le champ URL de rappel. Assurez-vous que ce que vous saisissez dans votre code correspond à ce que vous avez configuré précédemment, au cas contraire, vos utilisateurs verront une erreur.
        Le plugiciel enregistrera la trousse SDK en utilisant à la fois provide et app.config.globalProperties. Cela permet d’activer à la fois l’API de composition et l’API d’options.
        Démarrage rapide Vue - Étape 2 - Point de contrôle 
        Le plugiciel est maintenant configuré. Exécutez votre application pour vérifier que :
        • la trousse SDK est correctement initialisée,
        • votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré :
        • Vérifiez que vous avez sélectionné la bonne application
        • Enregistrez vos modifications après avoir saisi vos URL
        • Vérifiez que le domaine et l’identifiant client ont été importés correctement
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login.js" }}}
+
+
+
        Vous allez ensuite configurer une connexion pour votre projet. Vous utiliserez la fonction loginWithRedirect de la trousse SDK exposée à la valeur de retour de useAuth0, à laquelle vous pouvez accéder dans la fonction de configuration de votre composant. Elle redirigera les utilisateurs vers la page de connexion universelle Auth0 et, après l’authentification de l’utilisateur, elle le redirigera vers l’URL de rappel que vous avez configurée plus tôt dans ce guide rapide.
        Utilisation d’Options API
        Si vous utilisez Options API, vous pouvez utiliser la même méthode loginWithRedirect à partir de la propriété globale $auth0 via l’accesseur this.
        Démarrage rapide Vue – Étape 3 – Point de contrôle 
        Vous devriez maintenant être en mesure de vous connecter en utilisant la connexion universelle Auth0.
        Appuyez sur le bouton de connexion et vérifiez que :
        • Votre application Vue vous redirige vers la page de connexion universelle Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre application en utilisant la valeur authorizationParams.redirect_uri  que vous avez utilisée pour configurer le plugiciel.
        
+
+  
        
+
+  
        Si vous n’avez pas pu vous connecter à l’aide de la connexion universelle Auth0 :
        • Vérifiez que vous avez configuré le bon authorizationParams.redirect_uri
        • Vérifiez que le domaine et l’identifiant client sont correctement définis
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout.js" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. Quand les utilisateurs se déconnectent, votre application les redirige vers votre point de terminaison Déconnexion Auth0, qui les redirige ensuite vers le paramètre logoutParams.returnTo indiqué.
        Utilisez la fonction logout exposée sur la valeur de retour useAuth0, à laquelle vous pouvez accéder dans la fonction setup de votre composant, pour déconnecter l’utilisateur de votre application.
        Utilisation d’Options API
        Avec l’Options API, vous pouvez utiliser la même méthode logout à partir de la propriété globale $auth0 via l’accesseur this.
        Démarrage rapide Vue - Étape 4 - Point de contrôle 
        Exécutez votre application et cliquez sur le bouton de déconnexion, vérifiez que :
        • votre application Vue vous redirige vers l’adresse logoutParams.returnTo ,
        • vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Si vous ne parvenez pas à vous déconnecter :
        • Vérifiez que vous avez précisé une valeur pour logoutParams.returnTo lors de l’appel de logout
        • Vérifiez que les URL de déconnexion autorisées dans les paramètres de votre application contiennent la valeur returnTo.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        Vous allez ensuite configurer la manière de récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir afficher le nom ou la photo de profil d’un utilisateur connecté dans votre projet. Une fois l’utilisateur authentifié, la trousse SDK extrait les informations du profil utilisateur et les stocke en mémoire. L’application peut accéder au profil utilisateur à l’aide de la propriété réactive user. Pour accéder à cette propriété, examinez la fonction setup de votre composant et trouvez la valeur de retour de userAuth0.
        La propriété user contient des informations sensibles relatives à l’identité de l’utilisateur. Elle n’est disponible qu’en fonction de l’état d’authentification de l’utilisateur. Pour éviter les erreurs de rendu, vous devez toujours :
        • utiliser la propriété isAuthenticated pour déterminer si Auth0 a authentifié l’utilisateur avant que Vue ne rende un composant qui consomme la propriété user.
        • vous assurer que la trousse SDK a fini de se charger en vérifiant que isLoading est false avant d’accéder à la propriété isAuthenticated.
        Utilisation de l’API Options
        Pour l’API Options, utilisez les mêmes propriétés réactives user, isLoading et isAuthenticated de la propriété globale $auth0 via l’accesseur this.
        Vue - Étape 5 - Point de contrôle 
        Vérifiez que :
        • vous pouvez afficher user ou l’une des propriétés de l’utilisateur correctement dans un composant, après vous être connecté.
        
+
+  
        
+
+  
        Si vous rencontrez des problèmes avec les propriétés user :
        • Vérifiez que vous avez ajouté la vérification isLoading avant d’accéder à la propriété isAuthenticated
        • Vérifiez que vous avez ajouté la vérification isAuthenticated avant d’accéder à la propriété user
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/files/auth_openidc.md b/fr-ca/articles/quickstart/webapp/apache/files/auth_openidc.md
new file mode 100644
index 0000000000..44d311ab8e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/files/auth_openidc.md
@@ -0,0 +1,23 @@
+---
+name: auth_openidc.conf
+language: 
+---
+    
+```
+OIDCProviderMetadataURL https://${account.namespace}/.well-known/openid-configuration OIDCClientID ${account.clientId} 
+OIDCClientSecret ${account.clientSecret}
+OIDCScope "openid name email" 
+OIDCRedirectURI https://your_apache_server/your_path/redirect_uri/ OIDCCryptoPassphrase  
+
+ 
+   AuthType openid-connect 
+   Require valid-user 
+   LogLevel debug 
+
+
+ 
+   AuthType openid-connect 
+   #Require valid-user 
+   Require claim folder:admin 
+
+```
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..d90cb29e77
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/index.yml
@@ -0,0 +1,20 @@
+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
+hidden_articles:
+  - "interactive"
+contentType: tutorial
+useCase: quickstart
diff --git a/fr-ca/articles/quickstart/webapp/apache/interactive.md b/fr-ca/articles/quickstart/webapp/apache/interactive.md
new file mode 100644
index 0000000000..66f91f7cf9
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,49 @@
+---
+title: Apache
+description: Ce tutoriel montre comment configurer Apache pour ajouter l’authentification et l’autorisation à votre application web.
+interactive:  true
+files:
+ - files/auth_openidc
+locale: fr-CA
+---
+
+# Apache
+
+
+
        Ce tutoriel montre comment configurer Apache pour ajouter l’authentification et l’autorisation à votre application web. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.
        Configuration requise
        Ce tutoriel et le projet d’exemple ont été testés avec les éléments suivants :
        • Apache 2.4
        
+
+## Installer et activer le module mod_auth_openidc
+
+
+
        Tout d’abord, installez le module mod_auth_openidc pour Apache.
        Vous pouvez obtenir les binaires sur GitHub et les installer pour votre système d’exploitation. Si votre système d’exploitation n’est pas compatible avec les binaires, vous pouvez toujours le build it from source (construire à partir de la source).
        Une fois le module installé, activez-le pour Apache avec la commande a2enmod. Pour en savoir plus, veuillez consulter la page a2enmod on Ubuntu Manpage :
        a2enmod auth_openidc
        Pour Windows, vous pouvez utiliser ce script Powershell pour faire fonctionner a2enmod sur votre système.
        
+
+## Configurer le module avec les informations de votre compte Auth0 {{{ data-action="code" data-code="auth_openidc.conf#1:12" }}}
+
+
+
        Mettez à jour votre nouveau fichier de configuration (auth_openidc.conf), présent dans le dossier /etc/apache2/mods-available.
        Pour Windows, vous devez utiliser le fichier /apache/conf/httpd.conf.
        
+
+## Configuration d’Auth0
+
+
+
        Dans Auth0 Dashboard :
        1. Accédez à Applications > Applications, puis sélectionnez votre application dans la liste.
        2. Passez à l’affichage Settings (Paramètres), puis localisez la section Application URIs (URI d’application).
        3. Ajoutez la valeur de OIDCRedirectURIà URL de rappel autorisées.
        4. Localisez Advanced Settings (Paramètres avancés) au bas de la page.
        5. Passez à l’affichage OAuth.
        6. Définissez Algorithme de signature du jeton Web JSON (JWT) sur RS256.
        
+
+## Autorisation {{{ data-action="code" data-code="auth_openidc.conf#14:18" }}}
+
+
+
        Vous pouvez configurer Apache pour protéger un emplacement spécifique en fonction de la valeur d’une revendication dans le jeton d’ID de l’utilisateur en ajoutant un bloc Location à votre fichier auth_openidc.conf.
        Par exemple, vous pouvez créer une Action qui lit les rôles de l’utilisateur, puis ajoute une revendication qui accorde l’accès à un emplacement protégé :
        exports.onExecutePostLogin = async (event, api) => {
+
+  const roles = event.authorization.roles; // ['user', 'admin']
+
+
+
+  if (roles.includes('admin')) {
+
+    api.idToken.setCustomClaim('folder', 'admin');
+
+  }
+
+};
+
+
        
+
+
        
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/Login.cshtml.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.md
new file mode 100644
index 0000000000..bc1fc7b36d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.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);
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md
new file mode 100644
index 0000000000..9e54f3d16d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.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);
+    }
+}
+```
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..b20d6763a5
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
@@ -0,0 +1,37 @@
+---
+name: Profile.razor
+language: 
+---
+    
+```
+@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();
+    }
+}
+```
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..80c23e3cb0
--- /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();
+```
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..21ad3a02b7
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
@@ -0,0 +1,61 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Blazor Server
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application Blazor Server, nouvelle ou existante, à l’aide de la trousse SDK Auth0.AspNetCore.Authentication.
+interactive:  true
+files:
+ - files/Login.cshtml
+ - files/Logout.cshtml
+ - files/Profile
+ - files/Program
+github:
+  path: Quickstart/Sample
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Blazor Server
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application Blazor Server, nouvelle ou existante, à l’aide de la trousse SDK Auth0.AspNetCore.Authentication.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce démarrage rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos Applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Installer et configurer la trousse SDK {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        Installer à partir de Nuget
        Pour intégrer Auth0 à Blazor Server vous pouvez utiliser notre trousse SDK en installant le package NugetAuth0.AspNetCore.Authenticationdans votre application.
        Configurer le logiciel médiateur
        Pour activer l’authentification dans votre application Blazor Server, utilisez le logiciel médiateur fourni par la trousse SDK. Allez dans le fichier Program.cs et appelez builder.Services.AddAuth0WebAppAuthentication() pour enregistrer le logiciel médiateur de la trousse SDK.
        Assurez-vous de configurer Domain et ClientId, car ce sont des champs requis pour garantir que la trousse SDK sache quel locataire Auth0 et quelle application utiliser.
        Assurez-vous d’avoir activé l’authentification et l’autorisation dans votre fichier Program.cs.
        
+
+## Connexion {{{ data-action="code" data-code="Login.cshtml.cs" }}}
+
+
+
        Pour permettre aux utilisateurs de se connecter à votre application Blazor Server, ajoutez un LoginModel à votre répertoire Pages.
        Dans le cadre de la méthode OnGet de LoginModel, appelez HTTPContext.ChallengeAsync() et passez Auth0Constants.AuthenticationScheme comme schéma d’authentification. Cela fera appel au gestionnaire d’authentification OIDC que notre trousse SDK enregistre en interne. Assurez-vous également d’indiquer les authenticationProperties correspondantes, que vous pouvez construire en utilisant LoginAuthenticationPropertiesBuilder.
        Après avoir appelé avec succès HttpContext.ChallengeAsync(), l’utilisateur est redirigé vers Auth0 et est connecté à la fois au logiciel médiateur OIDC et au logiciel médiateur de témoin après avoir été redirigé vers votre application. Cela permettra aux utilisateurs d’être authentifiés lors des requêtes suivantes.
        ASP.NET Core Blazor Server - Étape 3 - Point de contrôle 
        Maintenant que vous avez configuré la fonction de connexion, lancez votre application pour vérifier que :
        • naviguer vers votre page Login vous redirigera vers Auth0,
        • saisir vos identifiants vous redirigera vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="Profile.razor" }}}
+
+
+
        Une fois que le logiciel médiateur a réussi à récupérer les jetons auprès d’Auth0, il extrait les informations et les demandes de l’utilisateur du jeton d’ID et les met à disposition via AuthenticationState, que vous pouvez ajouter en tant que CascadingParameter.
        Vous pouvez créer une page de profil utilisateur personnalisée pour afficher le nom de l’utilisateur, ainsi que des demandes supplémentaires (comme le courriel et la photo), en récupérant les informations correspondantes à partir de la propriété User de AuthenticationState et en les visualisant à partir du code Blazor.
        ASP.NET Core Blazor Server - Étape 4 - Point de contrôle 
        Maintenant que vous avez effectué la configuration pour afficher le profil utilisateur, lancez votre application pour vérifier que :
        • la navigation vers le point de terminaison contenant le profil après une connexion réussie permet d’afficher le profil utilisateur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Déconnexion {{{ data-action="code" data-code="Logout.cshtml.cs" }}}
+
+
+
        Déconnecter l’utilisateur de votre propre application peut se faire en appelant HttpContext.SignOutAsync avec le schéma d’authentification CookieAuthenticationDefaults.AuthenticationScheme à partir de la méthode OnGetde LogoutModel.
        En outre, si vous souhaitez également déconnecter l’utilisateur d’Auth0 (cette action peut également le déconnecter d’autres applications qui utilisent l’authentification unique), appelez HttpContext.SignOutAsync avec le schéma d’authentification Auth0Constants.AuthenticationScheme ainsi que l’authenticationProperties approprié qui peut être construit en utilisant LogoutAuthenticationPropertiesBuilder.
        ASP.NET Core Blazor Server – Étape 5 – Point de contrôle 
        Maintenant que vous avez configuré la fonction de déconnexion, exécutez votre application pour vérifier que :
        • Naviguer vers votre page Logout garantira que l’utilisateur est déconnecté.
        • Lorsque vous vous déconnectez également d’Auth0, vous devriez être redirigé vers Auth0, puis immédiatement renvoyé vers votre propre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/AccountController.md b/fr-ca/articles/quickstart/webapp/aspnet-core/files/AccountController.md
new file mode 100644
index 0000000000..52bd2b6799
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/files/AccountController.md
@@ -0,0 +1,62 @@
+---
+name: AccountController.cs
+language: javascript
+---
+    
+```javascript
+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
+    );
+  }
+}
+```
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..8e344581e6
--- /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}"
+  }
+}
+```
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..9383bb20e1
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: javascript
+---
+    
+```javascript
+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();
+```
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..7fbc71fc7f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/interactive.md
@@ -0,0 +1,60 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application ASP.NET MVC
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application ASP.NET MVC, nouvelle ou existante, à l’aide de la trousse SDK Auth0.AspNetCore.Authentication.
+interactive:  true
+files:
+ - files/Program
+ - files/appsettings
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application ASP.NET MVC
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application ASP.NET MVC, nouvelle ou existante, à l’aide de la trousse SDK Auth0.AspNetCore.Authentication.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Installer et configurer la trousse SDK {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        Installer à partir de Nuget
        Pour intégrer Auth0 à ASP.NET Core, vous pouvez utiliser notre trousse SDK en installant le package NugetAuth0.AspNetCore.Authenticationdans votre application.
        Configurer le logiciel médiateur
        Pour activer l’authentification dans votre application ASP.NET Core, utilisez le logiciel médiateur fourni par la trousse SDK. Allez dans le fichier Program.cs et appelez builder.Services.AddAuth0WebAppAuthentication() pour enregistrer le logiciel médiateur de la trousse SDK.
        Assurez-vous de configurer Domain et ClientId, car ce sont des champs requis pour garantir que la trousse SDK sache quel locataire Auth0 et quelle application utiliser.
        Assurez-vous d’avoir activé l’authentification et l’autorisation dans votre fichier Program.cs.
        
+
+## Connexion {{{ data-action="code" data-code="AccountController.cs" }}}
+
+
+
        Pour permettre aux utilisateurs de se connecter à votre application ASP.NET MVC, ajoutez une action Login à votre contrôleur.
        Appelez HTTPContext.ChallengeAsync() et transmettez Auth0Constants.AuthenticationScheme comme schéma d’authentification. Cela fera appel au gestionnaire d’authentification OIDC que notre trousse SDK enregistre en interne. Assurez-vous également d’indiquer les authenticationProperties correspondantes, que vous pouvez construire en utilisant LoginAuthenticationPropertiesBuilder.
        Après avoir appelé avec succès HTTPContext.ChallengeAsync(), l’utilisateur est redirigé vers Auth0 et est connecté à la fois au logiciel médiateur OIDC et au logiciel médiateur de témoin après avoir été redirigé vers votre application. Cela permettra aux utilisateurs d’être authentifiés lors des requêtes suivantes.
        ASP.NET MWC - Étape 3 - Point de contrôle 
        Maintenant que vous avez configuré la fonction de connexion, lancez votre application pour vérifier que :
        • naviguer vers votre action Login vous redirigera vers Auth0,
        • saisir vos identifiants vous redirigera vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher le profil utilisateur
+
+
+
        Une fois que l’intergiciel a réussi à récupérer les jetons auprès d’Auth0, il extrait les informations et les demandes de l’utilisateur du jeton d’ID et les met à disposition en tant que propriété User.Claims sur le contrôleur.
        Vous pouvez créer une page de profil utilisateur personnalisée pour afficher le nom, l’adresse courriel et l’image de profil d’un utilisateur, en récupérant les informations correspondantes de User et en les visualisant à partir de votre contrôleur.
        ASP.NET MWC - Étape 4 - Point de contrôle 
        Maintenant que vous avez configuré votre action pour afficher le profil de l’utilisateur, lancez votre application pour vérifier que :
        • naviguer vers votre action Profile après vous être connecté avec succès affiche le profil de l’utilisateur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Déconnexion
+
+
+
        Déconnecter l’utilisateur de votre propre application peut se faire en appelant HttpContext.SignOutAsync avec le schéma d’authentification CookieAuthenticationDefaults.AuthenticationScheme à partir de l’action de votre contrôleur.
        En outre, si vous souhaitez également déconnecter l’utilisateur d’Auth0 (cette action peut également le déconnecter d’autres applications qui utilisent l’authentification unique), appelez HttpContext.SignOutAsync avec le schéma d’authentification Auth0Constants.AuthenticationScheme ainsi que les authenticationProperties appropriées qui peuvent être développées en utilisant LogoutAuthenticationPropertiesBuilder.
        ASP.NET MWC – Étape 5 – Point de contrôle 
        Maintenant que vous avez configuré la fonction de déconnexion, exécutez votre application pour vérifier que :
        • Naviguer vers votre action Logout garantit que l’utilisateur est déconnecté.
        • Lorsque vous vous déconnectez également d’Auth0, vous devriez être redirigé vers Auth0, puis immédiatement renvoyé vers votre propre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/AccountController.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
new file mode 100644
index 0000000000..0f87e854e3
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
@@ -0,0 +1,47 @@
+---
+name: AccountController.cs
+language: csharp
+---
+    
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+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/Web.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/Web.md
new file mode 100644
index 0000000000..c88062828f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/Web.md
@@ -0,0 +1,14 @@
+---
+name: Web.config
+language: 
+---
+    
+```
+
+
+  
+    
+    
+  
+
+```
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..d1fbe54773
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/startup.md
@@ -0,0 +1,82 @@
+---
+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);
+            }
+        }
+    });
+}
+```
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..b2fcc99237
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/interactive.md
@@ -0,0 +1,71 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application ASP.NET OWIN
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application ASP.NET OWIN, nouvelle ou ancienne, à l’aide du package NuGet Microsoft.Owin.Security.OpenIdConnect.
+interactive:  true
+files:
+ - files/Web
+ - files/Startup
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application ASP.NET OWIN
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application ASP.NET OWIN, nouvelle ou ancienne, en utilisant le package Nuget Microsoft.Owin.Security.OpenIdConnect.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce démarrage rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos Applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Configurer le projet {{{ data-action="code" data-code="Web.config" }}}
+
+
+
        Installer à partir de Nuget
        Pour intégrer Auth0 avec ASP.NET OWIN, vous pouvez utiliser les packages Nuget Microsoft.Owin.Security.OpenIdConnect et Microsoft.Owin.Security.Cookies.
        Install-Package Microsoft.Owin.Security.OpenIdConnect
+
+Install-Package Microsoft.Owin.Security.Cookies
+
+
        
+
+
        Des problèmes surviennent lorsque vous configurez l’intergiciel de témoin OWIN et les témoins System.Web en même temps. Pour en savoir plus, consultez la documentation sur les problèmes d’intégration des témoins System.Web afin d’atténuer ces problèmes.
        Configurer les identifiants
        Pour que la trousse SDK fonctionne correctement, définissez les propriétés suivantes dans Web.config :
        • auth0:Domain : Le domaine de votre locataire Auth0. Celui-ci figure dans Auth0 Dashboard, dans les Settings (Paramètres) de votre application dans le champ Domaine. Si vous utilisez un domaine personnalisé, définissez ceci plutôt sur la valeur de votre domaine personnalisé.
        • auth0:ClientId : L’identifiant de l’application Auth0 que vous avez créée dans Auth0 Dashboard. Celui-ci figure dans Auth0 Dashboard, dans les Settings (Paramètres) de votre application dans le champ Identifiant client.
        
+
+## Configurer le logiciel médiateur {{{ data-action="code" data-code="Startup.cs#18:74" }}}
+
+
+
        Pour activer l’authentification dans votre application ASP.NET OWIN, reportez-vous à la méthode de configuration de votre classe de démarrage et configurez le témoin, ainsi que le logiciel médiateur OIDC.
        Il est essentiel d’enregistrer à la fois le logiciel médiateur de témoin et le logiciel médiateur OpenID Connect, car les deux sont nécessaires (dans cet ordre) pour que l’authentification fonctionne. le logiciel médiateur OpenID Connect gère l’authentification avec Auth0. Une fois que les utilisateurs se sont authentifiés, leur identité est sauvegardée dans le logiciel médiateur de témoin.
        Dans l’extrait de code, AuthenticationType est défini sur Auth0. Utilisez AuthenticationType dans la section suivante pour lancer un défi au logiciel médiateur OpenID Connect et commencer le flux d’authentification. L’événement de notification RedirectToIdentityProvider génère la bonne Logout URL (URL de déconnexion).
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="AccountController.cs#7:16" }}}
+
+
+
        Pour permettre aux utilisateurs de se connecter à votre application ASP.NET OWIN, ajoutez une action Loginà votre contrôleur.
        Appelez HttpContext.GetOwinContext().Authentication.Challenge et passez Auth0 comme schéma d’authentification. Cette action fait appel au gestionnaire d’authentification OIDC qui a été enregistré plus tôt. Veillez à préciser les AuthenticationProperties, y compris un RedirectUrii.
        Après avoir appelé avec succès HttpContext.GetOwinContext().Authentication.Challenge, l’utilisateur est redirigé vers Auth0 et est connecté à la fois au logiciel médiateur OIDC et au logiciel médiateur de témoin après avoir été redirigé vers votre application. Cela permettra aux utilisateurs d’être authentifiés lors des requêtes suivantes.
        ASP.NET (OWIN) - Étape 4 - Point de contrôle 
        Maintenant que vous avez configuré la fonction de connexion, lancez votre application pour vérifier que :
        • naviguer vers votre action Login vous redirigera vers Auth0,
        • saisir vos identifiants vous redirigera vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="AccountController.cs#34:39" }}}
+
+
+
        À partir de l’action de votre contrôleur, appelez HttpContext.GetOwinContext().Authentication.SignOut avec le schéma d’authentification CookieAuthenticationDefaults.AuthenticationType pour déconnecter l’utilisateur de votre application.
        De plus, si vous souhaitez déconnecter l’utilisateur d’Auth0 (cette action pourrait également le déconnecter d’autres applications qui dépendent de l’authentification unique), appelez HttpContext.GetOwinContext().Authentication.SignOut avec le schéma d’authentification "Auth0".
        ASP.NET (OWIN) – Étape 5 – Point de contrôle 
        Maintenant que vous avez configuré la fonction de déconnexion, exécutez votre application pour vérifier que :
        • Naviguer vers votre action Logout garantit que l’utilisateur est déconnecté.
        • Lors de la déconnexion, vous êtes redirigé vers Auth0 puis immédiatement renvoyé vers votre application pendant la déconnexion.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="AccountController.cs#18:32" }}}
+
+
+
        Après que l’intergiciel a réussi à récupérer les jetons d’Auth0, il extraira les informations et les demandes de l’utilisateur à partir du jeton d’ID et les met à disposition en tant que ClaimsIdentity. Accédez aux informations extraites en utilisant la propriété User dans le contrôleur.
        Pour créer un profil utilisateur, récupérez le nom, l’adresse courriel et l’image de profil de l’utilisateur à partir de User et visualisez-les à partir de votre contrôleur.
        ASP.NET (OWIN) - Étape 6 - Point de contrôle 
        Maintenant que vous avez configuré votre action pour afficher le profil de l’utilisateur, lancez votre application pour vérifier que :
        • naviguer vers votre action Profile après vous être connecté avec succès affiche le profil de l’utilisateur.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • assurez-vous que la bonne application est sélectionnée
        • assurez-vous que le domaine et l’identifiant client sont correctement configurés
        • Avez-vous défini openid profile email comme permission?
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/files/webappexample/settings.md b/fr-ca/articles/quickstart/webapp/django/files/webappexample/settings.md
new file mode 100644
index 0000000000..28f748dd86
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/webappexample/settings.md
@@ -0,0 +1,35 @@
+---
+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/webappexample/templates/index.md b/fr-ca/articles/quickstart/webapp/django/files/webappexample/templates/index.md
new file mode 100644
index 0000000000..a1c6426ea1
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/webappexample/templates/index.md
@@ -0,0 +1,23 @@
+---
+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/webappexample/urls.md b/fr-ca/articles/quickstart/webapp/django/files/webappexample/urls.md
new file mode 100644
index 0000000000..6a3c8bda44
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/webappexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/webappexample/views.md b/fr-ca/articles/quickstart/webapp/django/files/webappexample/views.md
new file mode 100644
index 0000000000..f141c8ea43
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/webappexample/views.md
@@ -0,0 +1,59 @@
+---
+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..5cb56d1c9c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/interactive.md
@@ -0,0 +1,98 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Django
+description: Ce guide explique comment intégrer Auth0 à une application Python Django, à l’aide de la trousse SDK Authlib.
+interactive:  true
+files:
+ - files/webappexample/templates/index
+ - files/webappexample/settings
+ - files/webappexample/urls
+ - files/webappexample/views
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Django
+
+
+
        Auth0 vous permet d’ajouter l’authentification et de pouvoir accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à une application Python Django, à l’aide de la trousse SDK Authlib.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Installer les dépendances
+
+
+
        Pour cette intégration, vous ajouterez plusieurs dépendances de bibliothèque, telles qu’Authlib. Créez un fichier requirements.txt dans votre répertoire de projet et incluez ce qui suit :
        authlib ~= 1.0
+
+django ~= 4.0
+
+python-dotenv ~= 0.19
+
+requests ~= 2.27
+
+
        
+
+
        Exécutez la commande suivante depuis votre interface système pour accéder à ces dépendances :
        pip install -r requirements.txt
        
+
+## Configurez votre fichier .env.
+
+
+
        Ensuite, créez un fichier .env dans votre répertoire de projet. Ce fichier contiendra les clés de vos clients et d’autres détails de configuration.
        AUTH0_CLIENT_ID=${account.clientId}
+
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+AUTH0_DOMAIN=${account.namespace}
+
+
        
+
+
        
+
+## Création d’une application
+
+
+
        Si vous avez déjà une application Django installée, passez à l’étape suivante. Pour un nouveau projet d’application, exécutez la commande suivante :
        django-admin startproject webappexample
        Placez-vous dans le nouveau dossier du projet :
        cd webappexample
        
+
+## Mettre à jour settings.py {{{ data-action="code" data-code="webappexample/settings.py" }}}
+
+
+
        Ouvrez le fichier webappexample/settings.py pour examiner les valeurs .env.
        En haut du fichier, ajoutez les importations os et dotenv.
        Ensuite, sous la définition BASE_DIR, ajoutez la variable TEMPLATE_DIR.
        Ensuite, trouvez la variable TEMPLATES et mettez à jour la valeur DIRS pour y ajouter notre chaîne TEMPLATE_DIR. Cette action détermine le chemin des fichiers modèles, que vous créerez à une étape future. Ne modifiez aucun autre élément de ce tableau.
        À la fin de ce fichier, ajoutez le code pour charger la configuration d’Auth0.
        
+
+## Configurez votre application {{{ data-action="code" data-code="webappexample/views.py#1:18" }}}
+
+
+
        Pour commencer à créer votre application, ouvrez le fichier webappexample/views.py dans votre IDE.
        Importez toutes les bibliothèques nécessaires à votre application.
        Vous pouvez maintenant configurer Authlib pour gérer l’authentification de votre application avec Auth0.
        Découvrez les options de configuration possibles pour la méthode Authlib’s OAuth register() à partir de leur documentation.
        
+
+## Configurer vos gestionnaires de route {{{ data-action="code" data-code="webappexample/views.py#20:52" }}}
+
+
+
        Dans cet exemple, vous allez ajouter quatre routes pour votre application : connexion, callback, déconnexion et index.
        • login – Lorsque les visiteurs de votre application se rendent sur la route /login ils seront redirigés vers Auth0 pour commencer le processus d’authentification.
        • callback – Après la connexion de vos utilisateurs à Auth0, ceux-ci reviendront à votre application à la route /callback. Cette route enregistre la session de l’utilisateur et permet de ne plus avoir à se reconnecter lorsqu’il revient.
        • logout – La route /logout permet aux utilisateurs de se déconnecter de votre application. Cette route efface la session de l’utilisateur dans votre application et redirige vers le point de terminaison de déconnexion d’Auth0 pour s’assurer que la session n’est plus enregistrée. Ensuite, l’application redirige l’utilisateur vers votre route d’accueil.
        • index – La route d’accueil affichera les détails de l’utilisateur authentifié ou permettra aux visiteurs de se connecter.
        
+
+## Enregistrer vos routes {{{ data-action="code" data-code="webappexample/urls.py" }}}
+
+
+
        Remplacez le contenu de votre fichier webappexample/urls.py par le code à droite pour vous connecter à ces nouvelles routes.
        Cela dirigera les routes /login, /callback, /logout et / vers les gestionnaires appropriés.
        
+
+## Ajouter des modèles {{{ data-action="code" data-code="webappexample/templates/index.html" }}}
+
+
+
        Vous allez ensuite créer un fichier modèle utilisé dans la route de la page d’accueil.
        Créez un nouveau sous-répertoire dans le dossier webappexample nommé templates, et créez un fichier index.html.
        Le fichier index.html contiendra un code modèle pour afficher les informations de l’utilisateur s’il est connecté, ou pour lui présenter un bouton de connexion s’il ne l’est pas.
        
+
+## Exécuter votre application
+
+
+
        Vous êtes prêts à exécuter votre application! À partir de votre Directory de projet, ouvrez un interface et utilisez :
        python3 manage.py migrate
+
+python3 manage.py runserver 3000
+
+
        
+
+
        Votre application devrait maintenant être prête à s’ouvrir à partir de votre navigateur à l’adresse http://localhost:3000.
        Django - Étape 10 - Exécuter votre application - Point de contrôle 
        Visitez http://localhost:3000 pour des raisons de vérification. Un bouton de connexion devrait vous permettre de vous connecter à Auth0, puis de revenir à votre application pour consulter les informations relatives à votre profil.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré avec succès :
        • Vérifiez les erreurs éventuelles dans la console.
        • Vérifiez que le domaine et l’identifiant client ont été importés correctement.
        • Vérifiez la configuration de votre locataire.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..ed5b9ef117
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/files/server.md
@@ -0,0 +1,39 @@
+---
+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..02c1f27b03
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,48 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Express
+description: Ce guide explique comment intégrer Auth0, ajouter la connexion utilisateur, la déconnexion et un profil à une application Node.js Express en utilisant la trousse SDK Express OpenID Connect.
+interactive:  true
+files:
+ - files/server
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Express
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter la connexion utilisateur, la déconnexion et un profil à une application Node.js Express en utilisant la trousse SDK Express OpenID Connect.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/logout.
        
+
+## Installer la trousse SDK Express OpenID Connect {{{ data-action="code" data-code="server.js#2:16" }}}
+
+
+
        Votre application aura besoin du package express-openid-connect, qui est une trousse SDK conforme à l’OIDC maintenue par Auth0 pour Express.
        Installez la trousse SDK Express OpenID Connect en exécutant les commandes suivantes dans votre terminal :
        cd <your-project-directory>
+
+npm install express-openid-connect
+
+
        
+
+
        Configurer le routeur
        La bibliothèque Express OpenID Connect fournit le routeur auth afin de joindre des routes d’authentification à votre application. Vous devez configurer le routeur avec les clés de configuration suivantes :
        • authRequired - Vérifie si l’authentification est requise pour toutes les routes.
        • auth0Logout - Utilise la fonctionnalité de déconnexion d’Auth0.
        • baseURL - L’URL où l’application est hébergée.
        • secret - Une chaîne longue et aléatoire.
        • issuerBaseURL - Le domaine sous forme d’URL sécurisée trouvé dans vos Paramètres d’application.
        • clientID - L’ID client trouvé dans vos Paramètres d’application.
        Pour des options de configuration supplémentaires, consultez la documentation API.
        Vous pouvez générer une chaîne appropriée pourLONG_RANDOM_STRING en utilisant openssl rand -hex 32 dans la ligne de commande.
        Express - Étape 2 - Installer la trousse SDK Express OpenID Connect 
        Un utilisateur peut désormais se connecter à votre application en visitant la route /login fournie par la bibliothèque. Si vous exécutez votre projet sur localhost:3000, ce lien sera http://localhost:3000/login.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Vérifiez les détails de l’erreur sur la page de connexion Auth0 pour vous assurer que vous avez correctement saisi l’URL de rappel.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="server.js#25:28" }}}
+
+
+
        Pour afficher le profil utilisateur, votre application doit fournir une route protégée.
        Ajoutez le logiciel médiateur requiresAuth pour les routes qui nécessitent une authentification. Toute route utilisant ce logiciel médiateur vérifiera s’il existe une session utilisateur valide et, si ce n’est pas le cas, redirigera l’utilisateur vers la page de connexion.
        Express - Étape 3 - Afficher le profil utilisateur - Point de contrôle 
        Un utilisateur peut se déconnecter de votre application en visitant la route /logout fournie par la bibliothèque. Si vous exécutez votre projet sur localhost:3000, ce lien sera http://localhost:3000/logout.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..bd316c62dc
--- /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..c0abe39ef0
--- /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..e777b2df02
--- /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/go.md b/fr-ca/articles/quickstart/webapp/golang/files/go.md
new file mode 100644
index 0000000000..ccdace1ba9
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/go.md
@@ -0,0 +1,20 @@
+---
+name: go.mod
+language: go
+---
+    
+```go
+// 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..9613366e02
--- /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..67dc5740d9
--- /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..a239d207be
--- /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..5dcf244bcd
--- /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..bcb15eb5ff
--- /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..9976a1a8a3
--- /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..4de9bd1144
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,79 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Go
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application Web Go, nouvelle ou existante.
+interactive:  true
+files:
+ - files/auth
+ - files/callback
+ - files/env
+ - files/go
+ - files/isAuthenticated
+ - files/login
+ - files/logout
+ - files/main
+ - files/router
+ - files/user
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Go
+
+
+
        Auth0 vous permet d’ajouter l’authentification et de pouvoir accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application Web Go, nouvelle ou existante.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Installer les dépendances {{{ data-action="code" data-code="go.mod" }}}
+
+
+
        Créez un fichier go.mod pour lister toutes les dépendances de votre application.
        Pour intégrer Auth0 dans une application Go, ajoutez les packages coreos/go-oidc/v3 et x/oauth2.
        En plus des packages OIDC et OAuth2, ajoutez joho/godotenv, gin-gonic/gin, et gin-contrib/sessions.
        Cet exemple utilise gin pour le routage, mais vous pouvez utiliser le routeur de votre choix.
        Enregistrez le fichier go.mod avec les dépendances nécessaires et installez-les en utilisant la commande suivante dans votre terminal :
        go mod download
        
+
+## Configurer les variables d’environnement {{{ data-action="code" data-code=".env" }}}
+
+
+
        Vous devez définir les variables d’environnement suivantes dans .env à la racine de votre répertoire de projet :
        • AUTH0_DOMAIN : Le domaine de votre locataire Auth0. Trouvez votre domaine Auth0 dans Auth0 Dashboard sous les paramètres de votre application dans le champ Domain (Domaine). Pour les domaines personnalisés, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • AUTH0_CLIENT_ID : L’identificateur de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous le trouverez dans Auth0 Dashboard sous les paramètres de votre application dans le champ Client ID (Identificateur client).
        • AUTH0_CLIENT_SECRET : Le secret de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous le trouverez dans Auth0 Dashboard, sous les paramètres de votre application dans le champ Client Secret (Secret client).
        • AUTH0_CALLBACK_URL : L’URL utilisée par Auth0 pour rediriger l’utilisateur après une authentification réussie.
        
+
+## Configurez les packages OAuth2 et OpenID Connect {{{ data-action="code" data-code="auth.go" }}}
+
+
+
        Ensuite, configurez les packages OAuth2 et OpenID Connect
        Créez un fichier nommé auth.go dans le dossier platform/authenticator. Dans ce package, créez une méthode pour configurer et renvoyer les clients OAuth2 et OIDC, et une autre pour vérifier un jeton d’ID.
        
+
+## Configurer vos routes d’application {{{ data-action="code" data-code="router.go" }}}
+
+
+
        Créez un fichier nommé router.go dans le dossier platform/router. Dans ce package, créez une méthode pour configurer et renvoyer nos routes en utilisant github.com/gin-gonic/gin. Vous passerez une instance de Authenticator à la méthode pour l’utiliser avec les gestionnaires login (connexion) et callback (rappel).
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login.go" }}}
+
+
+
        Pour que l’utilisateur s’authentifie, nous devons créer une fonction gestionnaire pour traiter la route/login.
        Créez un fichier nommé login.go dans le dossier web/app/login et ajoutez une fonction Handler. Lors de l’exécution du gestionnaire, l’utilisateur sera redirigé vers Auth0 où il pourra saisir ses identifiants.
        Pour appeler la route /login ajoutez un lien vers /login dans le modèle home.html situé dans le directory web/template.
        
+
+## Gérer le rappel d’authentification {{{ data-action="code" data-code="callback.go" }}}
+
+
+
        Une fois que les utilisateurs se sont authentifiés en utilisant la page de connexion universelle d’Auth0, ils reviendront à l’application à la route /callback.
        Créez un fichier nommé callback.go dans le dossier web/app/callback et ajoutez une fonction Handler.
        Ce gestionnaire prendra la chaîne de requête code fournie par Auth0 et l’échangera contre un jeton d’ID et un jeton d’accès.
        Si le jeton d’ID est valide, il stockera les informations de profil et le jeton d’accès dans la session. Les informations de profil sont basées sur les demandes contenues dans le jeton d’ID. Le stockage de session permet à l’application d’accéder à ces informations selon les besoins.
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="user.go" }}}
+
+
+
        Maintenant que vos utilisateurs peuvent se connecter, vous voulez probablement pouvoir récupérer et utiliser les informations de profil associées aux utilisateurs authentifiés.
        Vous pouvez accéder à ces informations de profil, telles que leur pseudonyme ou leur photo de profil, à partir du profile qui a été sauvegardé dans la session précédemment.
        Créez un gestionnaire pour le point de terminaison /user dans web/app/user/user.go et renvoyez le fichier HTML correspondant. Comme le profile passe à ctx.HTML(), vous pouvez accéder aux informations de profil, telles que picture et nickname à l’intérieur de ce même fichier HTML.
        Un exemple de fichier HTML de ce type pourrait ressembler à l’exemple ci-dessous, mais vous pouvez récupérer n’importe quelle information de profil, y compris des demandes personnalisées.
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout.go" }}}
+
+
+
        Pour déconnecter l’utilisateur, effacez les données de la session et redirigez l’utilisateur vers le point de terminaison de déconnexion Auth0. Vous trouverez plus d’informations à ce sujet dans la documentation sur la déconnexion.
        Créez un fichier nommé logout.go dans le dossier web/app/logout, et ajoutez la fonction Handler pour rediriger l’utilisateur vers le point de terminaison de déconnexion Auth0.
        L’URL returnTo doit figurer dans la liste des URL de déconnexion autorisées de la section des paramètres de l’application. Pour plus d’informations, consultez Rediriger les utilisateurs après la déconnexion.
        Créez un fichier nommé user.js dans le dossier web/static/js, et ajoutez le code pour supprimer le témoin d’un utilisateur connecté.
        
+
+## Protéger les routes {{{ data-action="code" data-code="isAuthenticated.go" }}}
+
+
+
        La pratique recommandée veut que certaines routes ne soient accessibles qu’aux utilisateurs authentifiés. Lorsque des utilisateurs non authentifiés essaient d’accéder à des routes protégées, votre application devrait les rediriger.
        Dans ce cas, vous devez mettre en œuvre un intergiciel pour accéder à la requête HTTP. La fonction d’intergiciel détermine si la requête doit être dirigée vers le gestionnaire de point de terminaison ou si elle doit être bloquée.
        Créez un fichier nommé isAuthenticated.go dans platform/middleware et ajoutez une fonction qui vérifie si l’utilisateur est authentifié ou non, en fonction de la clé de session de profile. Si l’utilisateur n’est pas authentifié, l’intergiciel le redirigera vers la racine de l’application.
        L’intergiciel créé, nous pouvons le configurer pour toute route nécessitant une authentification en l’ajoutant au routeur.
        
+
+## Lancer votre application {{{ data-action="code" data-code="main.go" }}}
+
+
+
        L’authentificateur et le routeur configurés, nous pouvons connecter les éléments à l’aide du point d’entrée de notre application. Dans main.go, créez une instance de l’authentificateur et du routeur, qui reçoit l’instance de l’authentificateur.
        Si vous utilisez un fichier .env , vous devez appeler godotenv.Load() au tout début de la fonction main().
        Lancez votre application en utilisant la commande suivante dans votre terminal :
        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/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
new file mode 100644
index 0000000000..29a24545b4
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
@@ -0,0 +1,52 @@
+---
+name: src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java
+language: javascript
+---
+    
+```javascript
+// 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;
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
new file mode 100644
index 0000000000..ed6667e7e3
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
@@ -0,0 +1,23 @@
+---
+name: src/main/java/com/auth0/example/web/HomeServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
new file mode 100644
index 0000000000..c818e9a8b0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
@@ -0,0 +1,38 @@
+---
+name: src/main/java/com/auth0/example/web/LoginServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
new file mode 100644
index 0000000000..929dd24742
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
@@ -0,0 +1,54 @@
+---
+name: src/main/java/com/auth0/example/web/LogoutServlet.java
+language: 
+---
+    
+```
+// 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://${account.namespace}/v2/logout?client_id=${account.clientId}&returnTo=http://localhost:3000/
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                config.getDomain(),
+                config.getClientId(),
+                returnUrl
+        );
+
+        return logoutUrl;
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
new file mode 100644
index 0000000000..58f32a0fdc
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
@@ -0,0 +1,30 @@
+---
+name: src/main/webapp/WEB-INF/web.xml
+language: powershell
+---
+    
+```powershell
+
+
+
+    auth0.domain
+    java.lang.String
+    ${account.namespace}
+
+
+    auth0.clientId
+    java.lang.String
+    ${account.clientId}
+
+
+    auth0.clientSecret
+    java.lang.String
+    ${account.clientSecret}
+
+
+    auth0.scope
+    java.lang.String
+    openid profile email
+
+
+```
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..3b54b03c6a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/index.yml
@@ -0,0 +1,52 @@
+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
+hidden_articles:
+  - "interactive"
+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-ee/interactive.md b/fr-ca/articles/quickstart/webapp/java-ee/interactive.md
new file mode 100644
index 0000000000..8f3ac15cae
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/interactive.md
@@ -0,0 +1,408 @@
+---
+title: Ajouter une connexion à votre application web Java EE
+description: Ce tutoriel montre comment ajouter une connexion utilisateur à une application web Java EE.
+interactive:  true
+files:
+ - files/src/main/webapp/WEB-INF/web
+ - files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig
+ - files/src/main/java/com/auth0/example/web/LoginServlet
+ - files/src/main/java/com/auth0/example/web/HomeServlet
+ - files/src/main/java/com/auth0/example/web/LogoutServlet
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application web Java EE
+
+
+
        Ce tutoriel montre comment ajouter une connexion utilisateur à une application web Java EE. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.
        Configuration requise
        Ce tutoriel et le projet d’exemple ont été testés avec les éléments suivants :
        • Java 11
        
+
+## Configuration d’Auth0
+
+
+
        Obtenez vos clés d’application
        Après votre inscription à Auth0, une nouvelle application a été créée pour vous, ou vous avez pu en créer une. Vous aurez besoin de quelques informations sur cette application pour communiquer avec Auth0. Vous pouvez obtenir ces détails dans la section Paramètres de l’application d’Auth0 Dashboard.
        Les informations suivantes sont nécessaires :
        • Domain (Domaine)
        • Client ID (Identifiant client)
        • Client Secret (Secret client)
        En téléchargeant l’exemple en haut de cette page, les détails vous seront automatiquement fournis.
        Configurer les URL de rappel
        Une URL de rappel est une URL dans votre application où Auth0 redirige l’utilisateur après qu’il se soit authentifié. La callbackc URL de votre application doit être ajoutée au champ URL de rappel autorisées dansples Paramètres de l’application. Si ce champ n’est pas défini, les utilisateurs ne pourront pas se connecter à l’application et obtiendront un message d’erreur.
        Si vous suivez l’exemple de projet que vous avez téléchargé à partir du haut de cette page, l’URL de rappel que vous devez ajouter au champ URL de rappel autorisées est http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL de votre application à laquelle Auth0 peut retourner après la déconnexion de l’utilisateur du serveur d’autorisation. Elle est indiquée dans le paramètre de requête returnTo. L’URL de déconnexion de votre application doit être ajoutée au champ URL de déconnexion autorisées dans les paramètres de l’application. Si ce champ n’est pas défini, les utilisateurs ne pourront pas se déconnecter de l’application et obtiendront un message d’erreur.
        Si vous suivez l’exemple de projet que vous avez téléchargé à partir du haut de cette page, l’URL de déconnexion que vous devez ajouter au champ URL de déconnexion autorisées est http://localhost:3000/.
        
+
+## Configurer Java EE pour utiliser Auth0 {{{ data-action="code" data-code="src/main/webapp/WEB-INF/web.xml" }}}
+
+
+
        Configurez les dépendances
        Pour intégrer votre application Java EE avec Auth0, ajoutez les dépendances suivantes :
        • javax.javaee-api : L’API Java EE 8 est nécessaire pour écrire des applications à l’aide de Java EE 8. L’implémentation réelle est fournie par le conteneur d’application : elle n’a donc pas besoin d’être incluse dans le fichier WAR.
        • javax.security.entreprise : L’API de sécurité Java EE 8 permet de gérer les problèmes de sécurité dans une application EE. Comme la dépendance javax.javaee-api, l’implémentation est fournie par le conteneur d’application : elle n’est donc pas incluse dans le fichier WAR.
        • auth0-java-mvc-commons : Le Kit de développement logiciel (SDK) Java MVC Auth0 vous permet d’utiliser Auth0 avec Java pour les applications Web MVC côté serveur. Il génère l’URL d’autorisation que votre application doit appeler pour authentifier un utilisateur à l’aide d’Auth0.
        Si vous utilisez Maven, ajoutez les dépendances à votre pom.xml :
        <!-- pom.xml -->
+
+<dependency>
+
+ <groupId>com.auth0</groupId>
+
+ <artifactId>mvc-auth-commons</artifactId>
+
+ <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax</groupId>
+
+ <artifactId>javaee-api</artifactId>
+
+ <version>8.0.1</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax.security.enterprise</groupId>
+
+ <artifactId>javax.security.enterprise-api</artifactId>
+
+ <version>1.0</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+
        
+
+
        Si vous utilisez Gradle, ajoutez-les à votre build.gradle :
        // 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. '
+
+
        
+
+
        Configurez votre application Java EE 
        L’exemple qui accompagne ce tutoriel est écrit en JSP et testé avec le serveur d’application WildFly. Il se peut que vous deviez adapter certaines des étapes si vous travaillez avec un conteneur d’application ou des technologies différents.
        Votre application Java EE a besoin de certaines informations pour authentifier les utilisateurs avec votre application Auth0. Le fichier descripteur de déploiement web.xml  peut être utilisé pour stocker ces informations, bien que vous puissiez les stocker dans un autre emplacement sécurisé.
        Ces informations seront utilisées pour configurer la bibliothèque auth0-java-mvc-commons afin de permettre aux utilisateurs de se connecter à votre application. Pour en savoir plus sur la bibliothèque, y compris ses différentes options de configuration, consultez le fichier README de la bibliothèque.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **Vérifier les attributs remplis**
        Si vous avez téléchargé cet exemple en utilisant le bouton **Download Sample**, les attributs domain, clientId et clientSecret seront remplis pour vous. Vous devez vérifier que les valeurs sont correctes, surtout si vous avez plusieurs applications Auth0 dans votre compte.
        
+
+## Configurer la sécurité Java EE {{{ data-action="code" data-code="src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java" }}}
+
+
+
        L’API de Java EE 8 Security a introduit l’interface HttpAuthenticationMechanism pour permettre aux applications d’obtenir les identifiants d’un utilisateur. Des implémentations par défaut existent pour l’authentification de base et l’authentification basée sur le formulaire, et il est facile de configurer une stratégie d’authentification personnalisée.
        Pour s’authentifier avec Auth0, il faut fournir des implémentations personnalisées des interfaces suivantes :
        • HttpAuthenticationMechanism : responsable de la gestion du flux d’authentification pour les utilisateurs qui reviennent d’Auth0. (JavaDoc).
        • IdentityStore : responsable de la validation des identifiants de l’utilisateur (JavaDoc).
        • CallerPrincipal : représente le principal de l’appelant de la requête HTTP en cours (JavaDoc).
        • Credential : représente l’identifiant que l’appelant utilisera pour s’authentifier (JavaDoc).
        Tout d’abord, mettez vos paramètres Auth0 à la disposition de l’application en créant un bean @ApplicationScoped pour récupérer les valeurs du contexte Web et les rendre disponibles via des getters (accesseurs).
        Ensuite, créez un CallerPrincipal personnalisé qui représente l’appelant de la requête en cours :
        // 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;
+
+    }
+
+}
+
+
        
+
+
        Vous pouvez maintenant mettre en œuvre un Credential personnalisé qui sera utilisé pour représenter les identifiants de l’utilisateur. Il contiendra des informations sur le principal :
        // 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;
+
+    }
+
+}
+
+
        
+
+
        Vous avez maintenant défini les classes qui représentent le principal et l’identifiant d’un appelant. Ensuite, créez une implémentation personnalisée de IdentityStore. Cette classe sera chargée de valider les identifiants de l’utilisateur :
        // 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;
+
+    }
+
+}
+
+
        
+
+
        Si le credential est un Auth0Credential, l’utilisateur appelant est authentifié et valide, et un CredentialValidationResult créé avec le credential est renvoyé pour indiquer le succès. S’il ne s’agit pas d’un Auth0Credential, un CredentialValidationResult.NOT_VALIDATED_RESULT est renvoyé.
        Avant d’implémenter l’interface HttpAuthenticationMechanism qui utilisera tous ces collaborateurs, créez un bean qui fournira une instance configurée du AuthenticationController de la trousse SDK Auth0 Java MVC. Le AuthenticationController est utilisé pour construire l’URL d’autorisation où les utilisateurs se connecteront, et gérer l’échange de jetons pour authentifier les utilisateurs.
        • Si votre application Auth0 est configurée pour utiliser l’algorithme de signature RS256  (par défaut lors de la création d’une nouvelle application Auth0), vous devez configurer un JwkProvider pour récupérer la clé publique utilisée pour vérifier la signature du jeton. Voir le référentiel jwks-rsa-java pour connaître les options de configuration supplémentaires.
        • Si votre application Auth0 est configurée pour utiliser l’algorithme de signature HS256, il n’est pas nécessaire de configurer le JwkProvider.
        Pour en savoir plus sur les algorithmes de signature disponibles, consultez la documentation.
        L’exemple ci-dessous montre comment configurer le AuthenticationController pour l’utiliser avec l’algorithme de signature RS256 :
        // 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();
+
+    }
+
+}
+
+
        
+
+
        Enfin, mettez en œuvre un HttpAuthenticationMechanism personnalisé
        // 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;
+
+    }
+
+}
+
+
        
+
+
        La classe a priorité sur la méthode validateRequest, qui est appelée à chaque demande adressée à notre application et qui est chargée de notifier au conteneur l’état de l’authentification.
        Cet exemple utilise le flux de code d’autorisation pour échanger un code d’autorisation contre un jeton au cours du processus d’authentification. Si cette requête est adressée au point de terminaison /callback et contient le paramètre de requête code, elle effectue quelques opérations importantes :
        • Elle appelle la méthode handle du AuthenticationController pour échanger le code d’autorisation contre un jeton d’ID et un jeton d’accès.
        • Elle utilise le jeton d’ID pour créer un nouveau Auth0Credential.
        • Elle appelle la méthode validate de l’implémentation personnalisée IdentityStore pour obtenir le résultat de la validation.
        • Elle informe le conteneur de l’application de l’état de la connexion.
        Si la ressource demandée n’est pas /callback, elle renvoie httpMessageContext.doNothing() pour permettre la poursuite du traitement de la demande. Vous verrez bientôt comment utiliser les informations d’authentification lors du déclenchement de l’authentification et de l’affichage des vues Web.
        Enfin, notez que l’annotation @AutoApplySession a été ajoutée pour permettre au conteneur de créer une session pour l’utilisateur authentifié.
        
+
+## Déclencher l’authentification {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LoginServlet.java" }}}
+
+
+
        Pour permettre à un utilisateur de se connecter, créez un Servlet qui traitera les requêtes au chemin /login.
        Le LoginController est responsable de rediriger la requête vers l’URL d’autorisation appropriée, où l’utilisateur peut s’authentifier avec Auth0. Il utilise le AuthenticationController du SDK Auth0 Java MVC pour construire le bon URL d’autorisation, en utilisant les valeurs de configuration injectées via Auth0AuthenticationConfig. Par défaut, cet exemple demande les permissions "openid profile email" pour permettre à l’application de récupérer les informations de profil de base auprès de l’utilisateur authentifié. Vous pouvez en savoir plus sur ces permissions dans la documentation OpenID Connect Scopes.
        Une fois que l’utilisateur a entré ses identifiants et autorisé les permissions demandées, Auth0 enverra une requête au callbackUrl, incluant un paramètre de requête code qui peut être échangé contre un jeton d’ID et un jeton d’accès. Rappelons que le Auth0HttpAuthenticationMechanism créé ci-dessus gère cet échange afin qu’il puisse notifier le conteneur d’applications du statut d’authentification. Cela permet au Servlet qui gère les requêtes vers le chemin /callback de simplement transférer la requête à la ressource initialement demandée avant de se connecter, ou simplement de rediriger vers la page d’accueil :
        // 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);
+
+    }
+
+}
+
+
        
+
+
        
+
+## Afficher les informations de l’utilisateur {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/HomeServlet.java" }}}
+
+
+
        Vous pouvez utiliser Auth0JwtPrincipal pour obtenir des informations sur le profil de l’utilisateur authentifié. L’exemple de code HomeServlet.java montre comment utiliser les demandes sur le Jeton d’ID pour définir les données de profil comme attribut de requête.
        Vous pouvez ensuite utiliser ces informations de profil dans votre vue pour afficher des informations sur l’utilisateur :
        <!-- src/main/webapp/WEB-INF/jsp/fragments/navbar.jspf -->
+
+
+
+<c:choose>
+
+ <c:when test="{empty profile}">
+
+<li>
+
+ <form action="/login" method="GET">
+
+<input type="submit" value="Login"/>
+
+ </form>
+
+</li>
+
+ </c:when>
+
+ <c:otherwise>
+
+<li>
+
+ <a href="#">
+
+<!-- Profile image should be set to the profile picture from the id token -->
+
+<img src="{profile.get('picture').asString()}" alt="Profile picture"/>
+
+ </a>
+
+ <div>
+
+<!-- Show the user's full name from the id token here -->
+
+<div>"{profile.get('name').asString()}"</div>
+
+<a href="/profile">Profile</a>
+
+<a href="/logout">Log out</a>
+
+ </div>
+
+</li>
+
+ </c:otherwise>
+
+</c:choose>
+
+
        
+
+
        
+
+## Gérer la déconnexion {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LogoutServlet.java" }}}
+
+
+
        Pour déconnecter un utilisateur, vous devez effacer la session d’application et déconnecter l’utilisateur d’Auth0. Cette opération est gérée dans le LogoutServlet.
        Commencez par effacer la session en appelant request.getSession().invalidate(). Créez ensuite l’URL de déconnexion, en veillant à inclure le paramètre de requête returnTo, vers lequel l’utilisateur sera redirigé après la déconnexion. Enfin, redirigez la réponse vers l’URL de déconnexion de l’application.
        
+
+## Exécuter l’exemple
+
+
+
        Pour construire et exécuter l’exemple, exécutez l’objectif Maven wildfly:run pour démarrer un serveur d’application WildFly intégré avec cette application déployée. Voir la documentation Plugiciel WildFly Maven pour plus d’informations.
        Si vous utilisez Linux ou MacOS :
        ./mvnw clean wildfly:run
+
+
        
+
+
        Windows :
        mvnw.cmd clean wildfly:run
+
+
        
+
+
        Pointez votre navigateur sur http://localhost:3000. Suivez le lien Log In (Connexion) pour vous connecter ou vous inscrire à votre locataire Auth0.
        null
        Une fois la connexion réussie, vous verrez l’image du profil de l’utilisateur et un menu déroulant à l’endroit où se trouvait le lien Log In (Connexion). Vous pouvez alors consulter la page de profil de l’utilisateur en cliquant sur le lien Profile (Profil). Vous pouvez vous déconnecter en cliquant sur le lien Logout (Déconnexion) dans le menu déroulant.
        
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/HomeController.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
new file mode 100644
index 0000000000..4ca305ce5e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
@@ -0,0 +1,29 @@
+---
+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";
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
new file mode 100644
index 0000000000..a08d869b03
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
@@ -0,0 +1,31 @@
+---
+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();
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md
new file mode 100644
index 0000000000..d36c761126
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.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);
+            }
+        };
+    }
+}
+```
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..035001998b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/application.md
@@ -0,0 +1,12 @@
+---
+name: application.yml
+language: javascript
+---
+    
+```javascript
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: ${account.clientSecret}
+```
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..9c8255bdc8
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/index.md
@@ -0,0 +1,24 @@
+---
+name: index.html
+language: html
+---
+    
+```html
+
+
+    
+        
        
+            Log In
+        
        
+        
        
+            
        You are logged in!
        
+            " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+            
        ">
        
+            
        ">
        
+            
        
+                
        
+    
+
+```
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..0d4520695a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,196 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Spring Web
+description: Ce guide explique comment intégrer Auth0 à une application Spring Boot à l’aide de la trousse SDK Spring Boot Auth0.
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/index
+ - files/HomeController
+ - files/SecurityConfigWithLogout
+github:
+  path: mvc-login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Spring Web
+
+
+
        Vous utilisez Spring WebFlux?
        Ce tutoriel utilise Spring MVC. Si vous utilisez Spring WebFlux, les étapes pour ajouter l’authentification sont similaires, mais certains détails d’implémentation sont différents. Reportez-vous au Code d’exemple Spring Boot WebFlux pour voir comment intégrer Auth0 à votre application Spring Boot WebFlux.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur
        http://localhost:3000/login/oauth2/code/okta.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur
        http://localhost:3000.
        
+
+## Configurer l’application Sprint Boot
+
+
+
        Ajouter les dépendances Spring
        Pour intégrer votre application Spring Boot avec Auth0, incluez Okta Spring Boot Starter dans les dépendances de votre application.
        Ce guide utilise Thymeleaf et le module d’intégration Spring Security pour la couche d’affichage. Si vous utilisez une technologie d’affichage différente, la configuration et les composants de Spring Security restent les mêmes.
        Si vous utilisez Gradle, vous pouvez inclure ces dépendances comme indiqué ci-dessous.
        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'
+
+
        
+
+
        Si vous utilisez Maven :
        <parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.4</version>
+
+ <relativePath/>
+
+</parent>
+
+
+
+<dependencies>
+
+ <dependency>
+
+<groupId>com.okta</groupId>
+
+<artifactId>okta-spring-boot-starter</artifactId>
+
+<version>3.0.5</version>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-oauth2-client</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-thymeleaf</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.thymeleaf.extras</groupId>
+
+<artifactId>thymeleaf-extras-springsecurity6</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>nz.net.ultraq.thymeleaf</groupId>
+
+<artifactId>thymeleaf-layout-dialect</artifactId>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## Configurer Spring Security {{{ data-action="code" data-code="application.yml" }}}
+
+
+
        Okta Spring Boot Starter facilite la configuration de votre application avec Auth0. L’exemple ci-dessous utilise un fichier application.yml, mais vous pouvez également utiliser des fichiers de propriétés ou tout autre mécanisme d’externalisation pris en charge.
        #src/main/resources/application.yml
+
+
+
+okta:
+
+  oauth2:
+
+    issuer: https://${account.namespace}/
+
+    client-id: ${account.clientId}
+
+    client-secret: ${account.clientSecret}
+
+
+
+#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
+
+
        
+
+
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="SecurityConfig.java" }}}
+
+
+
        Pour permettre aux utilisateurs de se connecter avec Auth0, créez une classe qui enregistrera une SecurityFilterChain et ajoutez l’annotation @Configuration.
        Vous pouvez configurer l’instance HttpSecurity pour qu’elle exige une authentification sur tous les chemins ou seulement sur certains d’entre eux. Par exemple, pour exiger l’authentification sur tous les chemins à l’exception de la page d’accueil :
         http
+
+    .authorizeHttpRequests(authorize -> authorize
+
+        .requestMatchers("/").permitAll()
+
+        .anyRequest().authenticated()
+
+    );
        
+
+## Ajouter une page d’accueil {{{ data-action="code" data-code="index.html" }}}
+
+
+
        Okta Spring Boot Starter utilisera la configuration client que vous avez définie précédemment pour gérer la connexion lorsqu’un utilisateur visite le chemin //oauth2/authorization/okta de votre application. Vous pouvez l’utiliser pour créer un lien de connexion dans votre application.
        Cette page renvoie les attributs de l’utilisateur lorsque celui-ci s’authentifie. Vous utiliserez le lien /logout dans le modèle pour mettre en œuvre la fonctionnalité de déconnexion.
        
+
+## Ajouter un contrôleur {{{ data-action="code" data-code="HomeController.java" }}}
+
+
+
        Créez un contrôleur pour traiter la demande entrante. Ce contrôleur crée la page index.html. Lorsque l’utilisateur s’authentifie, l’application récupère les attributs d’information du profil utilisateur pour créer la page.
        Spring Boot - Étape 6 - Point de contrôle 
        Lorsque vous cliquez sur le lien de connexion, vérifiez que l’application vous redirige vers la page Connexion universelle Auth0 et que vous pouvez maintenant vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe, ou un réseau social.
        
+
+  
        
+
+  
        
+
+  
        null
        Auth0 active le fournisseur social Google par défaut sur les nouveaux locataires et vous offre des clés de développeur pour tester la connexion avec des fournisseurs d’identité sociale. Toutefois, ces clés de développeur présentent certaines limitations qui peuvent entraîner un comportement différent de votre application. Pour plus de détails sur ce comportement et comment le résoudre, consultez le document Tester les connexions sociales avec des clés de développeur Auth0.
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="SecurityConfigWithLogout.java" }}}
+
+
+
        Maintenant que les utilisateurs peuvent se connecter à votre application, ils ont besoin d’un moyen de se déconnecter. Par défaut, lorsque la déconnexion est activée, Spring Security déconnecte l’utilisateur de votre application et efface la session. Pour permettre une déconnexion réussie de Auth0, vous pouvez fournir un LogoutHandler pour rediriger les utilisateurs vers votre point de terminaison de déconnexion Auth0 (https://{yourDomain}/v2/logout) et ensuite les rediriger immédiatement vers votre application.
        Dans la classe SecurityConfig, fournissez un LogoutHandler qui redirige vers le point de terminaison de déconnexion Auth0, et configurez HTTPSecurity pour ajouter le gestionnaire de déconnexion.
        Spring Boot - Étape 7 - Point de contrôle 
        Lorsque vous cliquez sur le lien de déconnexion, l’application doit vous rediriger vers l’adresse que vous avez spécifiée comme l’une des « URL de déconnexion autorisées » dans les « Paramètres d’application » et vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        
+
+  
        
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/AuthenticationControllerProvider.md b/fr-ca/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
new file mode 100644
index 0000000000..badefcb759
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
@@ -0,0 +1,34 @@
+---
+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;
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java/files/CallbackServlet.md b/fr-ca/articles/quickstart/webapp/java/files/CallbackServlet.md
new file mode 100644
index 0000000000..ff5d16fdd5
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/CallbackServlet.md
@@ -0,0 +1,45 @@
+---
+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);
+        }
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java/files/HomeServlet.md b/fr-ca/articles/quickstart/webapp/java/files/HomeServlet.md
new file mode 100644
index 0000000000..edec61b849
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/HomeServlet.md
@@ -0,0 +1,22 @@
+---
+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);
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java/files/LoginServlet.md b/fr-ca/articles/quickstart/webapp/java/files/LoginServlet.md
new file mode 100644
index 0000000000..e05ba29f75
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/LoginServlet.md
@@ -0,0 +1,32 @@
+---
+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);
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/java/files/LogoutServlet.md b/fr-ca/articles/quickstart/webapp/java/files/LogoutServlet.md
new file mode 100644
index 0000000000..95dd2ed96b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/LogoutServlet.md
@@ -0,0 +1,39 @@
+---
+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);
+    }
+
+}
+```
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..1adea02008
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/web.md
@@ -0,0 +1,21 @@
+---
+name: web.xml
+language: 
+---
+    
+```
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    ${account.clientSecret}
+
+```
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..8163acb793
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,139 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre Application Java Servlet
+description: Ce guide explique comment intégrer Auth0 dans n’importe quelle application Java Servlet, nouvelle ou existante.
+interactive:  true
+files:
+ - files/web
+ - files/AuthenticationControllerProvider
+ - files/LoginServlet
+ - files/CallbackServlet
+ - files/HomeServlet
+ - files/LogoutServlet
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre Application Java Servlet
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification et de pouvoir accéder aux informations relatives au profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 dans n’importe quelle application Java Servlet, nouvelle ou existante.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/logout.
        
+
+## Intégrer Auth0 dans votre application
+
+
+
        Régler les dépendances.
        Pour intégrer votre application Java avec Auth0, ajoutez les dépendances suivantes :
        • javax.servlet-api
          : est la bibliothèque qui vous permet de créer des servlets Java. Vous devez ensuite ajouter une dépendance de serveur comme Tomcat ou Gretty, selon votre choix. Consultez notre code d’exemple pour plus d’informations.
        • auth0-java-mvc-commons : est la bibliothèque Java qui vous permet d’utiliser Auth0 avec Java pour des applications Web MVC côté serveur. Elle génère l’URL d’autorisation que vous devez appeler pour authentifier et valide le résultat reçu au retour afin d’obtenir finalement les jetons Auth0 qui identifient l’utilisateur.
        Si vous utilisez Gradle, ajoutez-les à votre build.gradle :
        // build.gradle
+
+
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+
+compile 'com.auth0:mvc-auth-commons:1.+'W
+
+
        
+
+
        Si vous utilisez Maven, ajoutez-les à votre fichier pom.xml :
        <!-- pom.xml -->
+
+
+
+<dependency>
+
+  <groupId>com.auth0</groupId>
+
+  <artifactId>mvc-auth-commons</artifactId>
+
+  <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+  <groupId>javax.servlet</groupId>
+
+  <artifactId>javax.servlet-api</artifactId>
+
+  <version>3.1.0</version>
+
+</dependency>
+
+
        
+
+
        
+
+## Configurer votre application Java {{{ data-action="code" data-code="web.xml" }}}
+
+
+
        Votre application Java a besoin de certaines informations pour s’authentifier auprès de votre compte Auth0. Les exemples lisent ces informations à partir du fichier descripteur de déploiement src/main/webapp/WEB-INF/web.xml, mais vous pouvez les stocker ailleurs.
        Ces informations seront utilisées pour configurer la bibliothèque auth0-java-mvc-commons afin de permettre aux utilisateurs de se connecter à votre application. Pour en savoir plus sur la bibliothèque, y compris ses différentes options de configuration, consultez la documentation de la bibliothèque.
        Vérifier les attributs remplis
        Si vous avez téléchargé cet exemple en utilisant le bouton Download Sample (Télécharger l’exemple), les attributs domain, clientId et clientSecret seront remplis pour vous. Vous devez vérifier que les valeurs sont correctes, surtout si vous avez plusieurs applications Auth0 dans votre compte.
        Structure du projet
        L’exemple de projet, qui peut être téléchargé en utilisant le bouton Download Sample (Télécharger l’exemple) a la structure suivante :
        - 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
+
+
        
+
+
        Le projet contient un seul JSP : home.jsp qui affichera les jetons associés à l’utilisateur après une connexion réussie et proposera l’option de déconnexion.
        Le projet contient un WebFilter : le Auth0Filter.java qui vérifiera l’existence de jetons avant de donner à l’utilisateur accès à notre chemin protégé /portal/*. Si les jetons n’existent pas, la requête sera redirigée vers LoginServlet.
        Le projet contient également quatre servlets :
        • LoginServlet.java : Appelé lorsque l’utilisateur essaie de se connecter. Le servlet utilise les paramètres client_id et domain pour créer une URL d’autorisation valide et y redirige l’utilisateur.
        • CallbackServlet.java : Le servlet enregistre les requêtes adressées à notre URL de rappel et traite les données pour obtenir les identifiants. Après une connexion réussie, les identifiants sont ensuite enregistrés dans la HttpSession de la requête.
        • HomeServlet.java : Le servlet lit les jetons précédemment enregistrés et les affiche sur la ressource home.jsp.
        • LogoutServlet.java : Appelé lorsque l’utilisateur clique sur le lien de déconnexion. Le servlet invalide la session de l’utilisateur et redirige l’utilisateur vers la page de connexion, gérée par LoginServlet.
        • AuthenticationControllerProvider.java : Responsable de la création et de la gestion d’une seule instance de AuthenticationController
        
+
+## Créer l’AuthenticationController {{{ data-action="code" data-code="AuthenticationControllerProvider.java#5:26" }}}
+
+
+
        Pour permettre aux utilisateurs de s’authentifier, créez une instance de l’AuthenticationController fournie par la trousse SDK auth0-java-mvc-commons en utilisant le domain, clientId, et clientSecret. L’exemple présente comment configurer le composant pour l’utiliser avec des jetons signés à l’aide de l’algorithme de signature asymétrique RS256, en précisant un JwkProvider pour récupérer la clé publique utilisée pour vérifier la signature du jeton. Consultez le référentiel jwks-rsa-java pour en savoir plus sur les options de configuration supplémentaires. Si vous utilisez HS256, il n’est pas nécessaire de configurer JwkProvider.
        AuthenticationController ne stocke aucun contexte et est destiné à être réutilisé. Une création inutile peut entraîner la génération de ressources supplémentaires, ce qui peut avoir une incidence sur les performances.
        
+
+## Redirection de connexion {{{ data-action="code" data-code="LoginServlet.java#21:23" }}}
+
+
+
        Pour permettre aux utilisateurs de se connecter, votre application les redirigera vers la page de Connexion universelle. En utilisant l’instance AuthenticationController , vous pouvez générer l’URL de redirection en appelant la méthode buildAuthorizeUrl(HttpServletRequest request, HttpServletResponse response, String redirectUrl). L’URL de redirection doit être celle qui a été ajoutée aux URL de rappel autorisées de votre application Auth0.
        
+
+## Gérer les jetons {{{ data-action="code" data-code="CallbackServlet.java#16:37" }}}
+
+
+
        Après que l’utilisateur s’est connecté, le résultat sera reçu dans notre CallbackServlet via une requête HTTP GET ou POST. Comme nous utilisons le flux de code d’autorisation (par défaut), une requête GET sera envoyée. Si vous avez configuré la bibliothèque pour le flux implicite, une requête POST sera plutôt envoyée.
        La requête contient le contexte d’appel que la bibliothèque a précédemment défini en générant l’URL d’autorisation avec AuthenticationController. Lorsqu’il est passé au contrôleur, vous recevez soit une instance Tokens valide soit une Exception indiquant ce qui a mal tourné. En cas d’appel réussi, vous devez enregistrer les identifiants afin de pouvoir y accéder ultérieurement. Vous pouvez utiliser HttpSession de la requête en utilisant la classe SessionsUtils comprise dans la bibliothèque.
        Il est recommandé d’enregistrer le moment où nous avons demandé les jetons ainsi que la valeur expiresIn reçue, afin que la prochaine fois que nous utiliserons le jeton, nous puissions vérifier s’il a déjà expiré ou s’il est encore valide. Pour les besoins de cet exemple, nous ignorerons cette validation.
        
+
+##  Afficher la page d’accueil {{{ data-action="code" data-code="HomeServlet.java#4:14" }}}
+
+
+
        Maintenant que l’utilisateur est authentifié (les jetons existent), Auth0Filter leur permettra d’accéder à nos ressources protégées. Dans le HomeServlet nous obtenons les jetons de la session de la requête et les définissons comme l’attribut userId afin qu’ils puissent être utilisés dans le code JSP.
        
+
+## Gérer la déconnexion {{{ data-action="code" data-code="LogoutServlet.java#13:30" }}}
+
+
+
        Pour gérer adéquatement la déconnexion, nous devons effacer la session et déconnecter l’utilisateur d’Auth0. Cette opération est gérée dans LogoutServlet de notre exemple d’application.
        Tout d’abord, nous effaçons la session en appelant request.getSession().invalidate(). Nous générons ensuite l’URL de déconnexion, en veillant à inclure le paramètre de requête returnTo qui est l’endroit où l’utilisateur sera redirigé après la déconnexion. Enfin, nous redirigeons la réponse vers notre URL de déconnexion.
        
+
+## Exécuter l’exemple
+
+
+
        Pour exécuter l’exemple à partir d’un terminal, placez-vous dans le dossier racine du projet et exécutez la ligne suivante :
        ./gradlew clean app
        Après quelques secondes, l’application sera accessible sur http://localhost:3000/. Essayez d’accéder à la ressource protégée http://localhost:3000/portal/home et notez comment vous êtes redirigé par Auth0Filter vers la page de connexion Auth0. Le gadget logiciel affiche toutes les connexions via réseaux sociaux et de bases de données que vous avez définies pour cette application dans le tableau de bord.
        null
        Vous serez en mesure de voir le contenu de la page d’accueil après une authentification réussie.
        null
        Déconnectez-vous en cliquant sur le bouton logout (déconnexion) en haut à droite de la page d’accueil.
        
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/routes/web.md b/fr-ca/articles/quickstart/webapp/laravel/files/routes/web.md
new file mode 100644
index 0000000000..3552be454c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/files/routes/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/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..a289825937
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,225 @@
+---
+title: Ajouter une connexion à votre application Laravel
+description: Ce guide montre comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 ouº10.
+interactive:  true
+files:
+ - files/routes/web
+github:
+  path: sample
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Laravel
+
+
+
        La Auth0’s Laravel SDK (trousse SDK Laravel Auth0) vous permet d’ajouter rapidement l’authentification, la gestion du profil utilisateur et le contrôle d’accès au routage à votre application Laravel. Ce guide explique comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 or 10 (Laravel 9 ou 10).
        
+
+## Installer Laravel
+
+
+
        Si vous n’avez pas déjà configuré une application Laravel, ouvrez un shell dans un répertoire approprié pour un nouveau projet et exécutez la commande suivante :
        composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
        Toutes les commandes de ce guide supposent que vous les exécutez à partir de la racine de votre projet Laravel, donc vous devez placer cd dans le nouveau répertoire du projet :
        cd auth0-laravel-app
        
+
+## Installation de la trousse SDK
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse Auth0 Laravel SDK :
        composer require auth0/login:^7.8 --update-with-all-dependencies
        Générez ensuite un fichier de configuration pour la trousse SDK pour votre application :
        php artisan vendor:publish --tag auth0
        
+
+## Configuration SDK
+
+
+
        Exécutez la commande suivante à partir du répertoire de votre projet pour télécharger l’interface de ligne de commande (CLI) Auth0 :
        curl -sSfL HTTPs://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
        Ensuite, authentifiez la CLI avec votre compte Auth0 en choisissant « as a user (en tant qu’utilisateur) » lorsque vous y êtes invité :
        ./auth0 login
        Ensuite, créez une nouvelle application avec Auth0 :
        ./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
+
+
        
+
+
        Vous devez également créer une nouvelle API :
        ./auth0 apis create \
+
+  --name "My Laravel Application's API" \
+
+  --identifier "https://github.com/auth0/laravel-auth0" \
+
+  --offline-access \
+
+  --no-input \
+
+  --json > .auth0.api.json
+
+
        
+
+
        Cela produit deux fichiers qui configurent la trousse SDK dans votre répertoire de projet.
        Comme ces fichiers contiennent des renseignements personnels, il est important de les traiter comme étant sensibles. Vous devez vous assurer de ne pas les soumettre au contrôle de version. Si vous utilisez Git, vous devez les ajouter à votre fichier .gitignore :
        echo ".auth0.*.json" >> .gitignore
        
+
+## Routes de connexion
+
+
+
        La trousse SDK enregistre automatiquement toutes les routes nécessaires pour que les utilisateurs de votre application s’authentifient.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **Routes****Objet**
        /loginInitie le flux d’authentification.
        /logoutDéconnecte l’utilisateur.
        /callbackGère le rappel de Auth0.
        Si vous avez besoin d’un plus grand contrôle sur les utilisateurs, ou s’ils entrent en conflit avec les routes existantes dans votre application, vous pouvez enregistrer manuellement les contrôleurs de la trousse SDK. Veuillez consulter le fichier de mise à jour de la trousse SDK README pour les intégrations avancées.
        
+
+## Contrôle d’accès {{{ data-action="code" data-code="routes/web.php#6:12" }}}
+
+
+
        Les installations d’authentification de Laravel utilisent des « gardes » pour définir comment les utilisateurs sont authentifiés pour chaque demande. Vous pouvez utiliser la protection d’authentification de la trousse SDK Auth0 pour restreindre l’accès aux routes de votre application.
        Pour exiger que les utilisateurs s’authentifient avant d’accéder à une route, vous pouvez utiliser l’intergiciel auth de Laravel.
        Route::get('/private', function () {
+
+  return response('Welcome! You are logged in.');
+
+})->middleware('auth');
+
+
        
+
+
        Vous pouvez également exiger que les utilisateurs authentifiés aient des autorisations spécifiques en combinant cela avec l'intergiciel can de Laravel.
        Route::get('/scope', function () {
+
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+
+})->middleware('auth')->can('read:messages');
+
+
        
+
+
        
+
+## Renseignements de l’utilisateur {{{ data-action="code" data-code="routes/web.php#14:24" }}}
+
+
+
        Les renseignements de l’utilisateur authentifié sont accessibles à partir de la Facade Auth de Laravel, ou de la fonction d’assistance auth().
        Par exemple, pour récupérer l’identificateur et l’adresse courriel de l’utilisateur :
        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}.");
+
+});;
+
+
        
+
+
        
+
+## Gestion des utilisateurs {{{ data-action="code" data-code="routes/web.php#26:43" }}}
+
+
+
        Vous pouvez mettre à jour les informations utilisateur en utilisant la Auth0 Management API. Tous les terminaux de gestion sont accessibles via la méthode management() de la trousse SDK.
        Avant de faire des appels à la Management API, vous devez permettre à votre application de communiquer avec la Management API. Cela peut être fait à partir de la page API du Auth0 Dashboard, en choisissant la Auth0 Management API et en sélectionnant l’onglet Machine to Machine Applications (Communication entre machines). Autoriser votre application Laravel, puis cliquez sur la flèche vers le bas pour choisir les permissions que vous souhaitez accorder.
        Pour l’exemple suivant, dans lequel nous allons mettre à jour les métadonnées d’un utilisateur et attribuer une couleur préférée aléatoire, vous devez accorder les permissions read:users et update:users. Une liste des points de terminaison API et les permissions requises peuvent être trouvées dans la documentation de la Management API.
        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');
+
+
        
+
+
        Un guide de référence rapide de toutes les méthodes de la Management API de la trousse SDK est disponible ici.
        
+
+## Exécuter l’application
+
+
+
        Vous êtes maintenant prêt à lancer votre application Laravel, de sorte qu’elle puisse accepter les demandes :
        php artisan serve
        Laravel – Étape 8 – Exécuter l’application – Point de contrôle 
        Ouvrez votre navigateur Web et essayez d’accéder aux routes suivantes :
        
+
+  
        
+
+  
        
+
+  
        Lecture supplémentaire
        • Référentiels et modèles d’utilisateurs étend la trousse SDK Laravel Auth0 pour utiliser des modèles d’utilisateurs personnalisés, et comment stocker et récupérer les utilisateurs à partir d’une base de données.
        • Événements d’appels explique comment écouter les événements soulevés par la trousse SDK Laravel Auth0, pour personnaliser pleinement le comportement de votre intégration.
        • Le soutien de la Management API est intégré à la trousse SDK Laravel Auth0, vous permettant d’interagir avec Management API à partir de votre application Laravel.
        
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/.env.md b/fr-ca/articles/quickstart/webapp/nextjs/files/.env.md
new file mode 100644
index 0000000000..e4de060766
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/.env.md
@@ -0,0 +1,12 @@
+---
+name: .env.local
+language: 
+---
+    
+```
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+APP_BASE_URL='http://localhost:3000'
+AUTH0_DOMAIN='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
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/files/src/app/page.md b/fr-ca/articles/quickstart/webapp/nextjs/files/src/app/page.md
new file mode 100644
index 0000000000..c623d584a1
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/src/app/page.md
@@ -0,0 +1,40 @@
+---
+name: src/app/page.tsx
+language: javascript
+---
+    
+```javascript
+import { auth0 } from "@/lib/auth0";
+import './globals.css';
+
+export default async function Home() {
+  // Fetch the user session
+  const session = await auth0.getSession();
+
+  // If no session, show sign-up and login buttons
+  if (!session) {
+    return (
+      
        
+        
+          
+        
+        
+          
+        
+      
        
+    );
+  }
+
+  // If session exists, show a welcome message and logout button
+  return (
+    
        
+      
        Welcome, {session.user.name}!
        
+      
        
+        
+          
+        
+      
        
+    
        
+  );
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md b/fr-ca/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
new file mode 100644
index 0000000000..d6a24d5995
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
@@ -0,0 +1,10 @@
+---
+name: src/lib/auth0.ts
+language: javascript
+---
+    
+```javascript
+import { Auth0Client } from "@auth0/nextjs-auth0/server";
+
+export const auth0 = new Auth0Client();
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/src/middleware.md b/fr-ca/articles/quickstart/webapp/nextjs/files/src/middleware.md
new file mode 100644
index 0000000000..cac77eaa10
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/src/middleware.md
@@ -0,0 +1,25 @@
+---
+name: src/middleware.ts
+language: javascript
+---
+    
+```javascript
+import type { NextRequest } from "next/server";
+import { auth0 } from "./lib/auth0";
+
+export async function middleware(request: NextRequest) {
+  return await auth0.middleware(request);
+}
+
+export const config = {
+  matcher: [
+    /*
+     * Match all request paths except for the ones starting with:
+     * - _next/static (static files)
+     * - _next/image (image optimization files)
+     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
+     */
+    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
+  ],
+};
+```
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..3eecb9dc9e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,71 @@
+---
+title: Ajouter une connexion à votre application Next.js
+description: Ce guide explique comment intégrer Auth0 à n’importe quelle application Next.js, nouvelle ou existante, à l’aide de la trousse SDK Next.js Auth0.
+interactive:  true
+files:
+ - files/.env
+ - files/src/lib/auth0
+ - files/src/middleware
+ - files/src/app/page
+github:
+  path: Sample-01
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Next.js
+
+
+
        Ce guide explique comment intégrer Auth0 à n’importe quelle application Next.js, nouvelle ou existante, à l’aide de la trousse SDK Next.js Auth0. Nous vous recommandons de vous connecter pour suivre ce guide de démarrage rapide avec les exemples configurés pour votre compte.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configuration des URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000/api/auth/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Installer la trousse SDK Next.js Auth0
+
+
+
        Exécutez la commande suivante dans le répertoire de votre projet pour installer la trousse SDK Next.js Auth0 :
        npm install @auth0/nextjs-auth0
        La trousse SDK expose des méthodes et des variables qui vous aident à intégrer Auth0 à votre application Next.js en utilisant les gestionnaires de route sur le système dorsal et le contexte React avec les Crochets React sur le système frontal.
        
+
+## Configuration de la trousse SDK {{{ data-action="code" data-code=".env.local" }}}
+
+
+
        Dans le répertoire racine de votre projet, ajoutez le fichier .env.local avec les variables d’environnement suivantes :
        • AUTH0_SECRET : valeur secrète longue utilisée pour chiffrer le témoin de session. Vous pouvez générer une chaîne appropriée en utilisant openssl rand -hex 32 sur la ligne de commande.
        • AUTH0_BASE_URL : URL de base de votre application.
        • AUTH0_ISSUER_BASE_URL : URL de votre domaine de locataire Auth0. Si vous utilisez un domaine personnalisé avec Auth0, utilisez la valeur de votre domaine personnalisé au lieu de la valeur indiquée dans l’onglet Settings (Paramètres).
        • AUTH0_CLIENT_ID : identifiant client de votre application Auth0.
        • AUTH0_CLIENT_SECRET : secret client de votre application Auth0.
        La trousse SDK lira ces valeurs à partir de l’environnement du processus Node.js et se configurera automatiquement.
        
+
+## Ajouter le gestionnaire de route dynamique {{{ data-action="code" data-code="src/lib/auth0.ts" }}}
+
+
+
        Ce guide rapide s’adresse au routeur d’application Next.js. Si vous utilisez le routeur Pages, consultez l’exemple dans le README de la trousse SDK.
        Créez un fichier dans app/api/auth/[auth0]/route.js. Il s’agit de votre fichier Route Handler (Gestionnaire de route) avec un Dynamic Route Segment (Segment de route dynamique).
        Ensuite, importez la méthode handleAuth de la trousse SDK et appelez-la à partir de l’exportation GET. Cette opération crée les routes suivantes :
        • /api/auth/login : la route utilisée pour se connecter avec Auth0.
        • /api/auth/logout : la route utilisée pour déconnecter l’utilisateur.
        • /api/auth/callback : la route vers laquelle Auth0 redirigera l’utilisateur après une connexion réussie.
        • /api/auth/me : la route à partir de laquelle le profil utilisateur doit être récupéré.
        
+
+## Ajouter le composant UserProvider {{{ data-action="code" data-code="src/middleware.ts" }}}
+
+
+
        Côté frontal, la trousse SDK utilise React Context pour gérer l’état d’authentification de vos utilisateurs. Pour que cet état soit accessible à toutes vos pages, vous devez remplacer le Root Layout component (composant Disposition racine) et envelopper la balise <body> avec un UserProvider dans le fichier app/layout.jsx.
        L’état d’authentification exposé par UserProvider est accessible dans n’importe quel composant client à l’aide de l’appel useUser().
        Next.js - Étape 5 - Point de contrôle 
        Maintenant que vous avez ajouté le gestionnaire de route et UserProvider, exécutez votre application pour vérifier qu’elle ne génère pas d’erreurs liées à Auth0.
        
+
+  
        
+
+  
        
+
+  
        
+
+## Ajouter une connexion à votre application {{{ data-action="code" data-code="src/app/page.tsx" }}}
+
+
+
        Les utilisateurs peuvent désormais se connecter à votre application en visitant Gestionnaire de route /api/auth/login fourni par la trousse SDK. Ajoutez un lien qui pointe vers la route de connexion à l’aide d’une balise d’ancrage. En cliquant sur ce lien, vos utilisateurs seront redirigés vers la page de connexion universelle Auth0, où Auth0 pourra les authentifier. Une fois l’authentification réussie, Auth0 redirigera vos utilisateurs vers votre application.
        Les prochaines règles de liaison pourraient suggérer d’utiliser le composant Link au lieu d’une balise d’ancrage. Le composant Link est destiné à effectuer des transitions côté client entre les pages. Comme le lien pointe vers une route API et non vers une page, vous devez le conserver en tant que balise d’ancrage.
        Next.js - Étape 6 - Point de contrôle 
        Ajoutez le lien de connexion à votre application.
        • Lorsque vous cliquez dessus, vérifiez que votre application Next.js vous redirige vers la page Connexion universelle Auth0 et que vous pouvez maintenant vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe ou un fournisseur social.
        • Une fois l’opération terminée, vérifiez qu’Auth0 vous redirige vers votre application.
        
+
+  
        
+
+  
        
+
+  
        null
        Auth0 active le fournisseur social Google par défaut sur les nouveaux locataires et vous offre des clés de développeur pour tester la connexion avec des fournisseurs d’identité sociale. Toutefois, ces clés de développeur présentent certaines limitations qui peuvent entraîner un comportement différent de votre application. Pour plus de détails sur ce comportement et comment le résoudre, consultez le document Tester les connexions sociales avec des clés de développeur Auth0.
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application
+
+
+
        Maintenant que vous pouvez vous connecter à votre application Next.js, vous avez besoin d’un moyen de vous déconnecter. Ajoutez un lien qui pointe vers la route API /api/auth/logout. En cliquant dessus, vous redirigez vos utilisateurs vers votre point de terminaison de déconnexion Auth0 (https://YOUR_DOMAIN/v2/logout), puis vous les redirigez immédiatement vers votre application.
        Next.js - Étape 7 - Point de contrôle 
         Lancez votre application.
        • Vérifiez que votre application Next.js vous redirige vers la page de connexion universelle Auth0 et que vous pouvez désormais vous connecter ou vous inscrire à l’aide d’un nom d’utilisateur et d’un mot de passe ou d’un fournisseur de réseau social.
        • Une fois cette opération terminée, vérifiez qu’Auth0 effectue une redirection vers votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • vos variables d’environnement sont-elles correctement renseignées?
        • assurez-vous que les URL de rappel autorisées sont correctement configurées dans votre locataire
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/files/frontend.md b/fr-ca/articles/quickstart/webapp/nginx-plus/files/frontend.md
new file mode 100644
index 0000000000..20c215f56b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/files/frontend.md
@@ -0,0 +1,34 @@
+---
+name: frontend.conf
+language: 
+---
+    
+```
+# auth_jwt_claim_set $claim_name https://namespace/key;
+
+server {
+    include conf.d/openid_connect.server_conf; # Authorization code flow and Relying Party processing
+    error_log /var/log/nginx/error.log debug;  # Reduce severity level as required
+
+    listen 8010; # Use SSL/TLS in production
+
+    location / {
+        # This site is protected with OpenID Connect
+        auth_jwt "" token=$session_jwt;
+        error_page 401 = @do_oidc_flow;
+
+        #auth_jwt_key_file $oidc_jwt_keyfile; # Enable when using filename
+        auth_jwt_key_request /_jwks_uri; # Enable when using URL
+
+        # Successfully authenticated users are proxied to the backend,
+        # with 'sub' claim passed as HTTP header
+        proxy_set_header username $jwt_claim_sub;
+        proxy_set_header x-email $jwt_claim_email;
+        #proxy_set_header x-custom $claim_name;             # namespaced claim
+
+        proxy_pass http://my_backend; # The backend site/app
+
+        access_log /var/log/nginx/access.log main_jwt;
+    }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/files/nginx.md b/fr-ca/articles/quickstart/webapp/nginx-plus/files/nginx.md
new file mode 100644
index 0000000000..e3f7cac534
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/files/nginx.md
@@ -0,0 +1,10 @@
+---
+name: nginx.conf
+language: 
+---
+    
+```
+...
+load_module modules/ngx_http_js_module.so;
+...
+```
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connect.md b/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
new file mode 100644
index 0000000000..3e1a926164
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
@@ -0,0 +1,22 @@
+---
+name: openid_connect.server_conf
+language: 
+---
+    
+```
+location = /_jwks_uri {
+    internal;
+    ...
+    proxy_set_header    Content-Length "";           
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+
+location = /_token {
+    internal;
+    ...
+    proxy_set_header    Content-Type "application/x-www-form-urlencoded";
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md b/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
new file mode 100644
index 0000000000..429c0e2605
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
@@ -0,0 +1,10 @@
+---
+name: openid_connection_configuration.conf
+language: 
+---
+    
+```
+map $host $oidc_logout_redirect {
+    default "https://${account.namespace}/v2/logout";
+}
+```
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..39515d2a7f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/index.yml
@@ -0,0 +1,24 @@
+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
+hidden_articles:
+  - "interactive"
+contentType: tutorial
+useCase: quickstart
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/interactive.md b/fr-ca/articles/quickstart/webapp/nginx-plus/interactive.md
new file mode 100644
index 0000000000..2e4659ff89
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,71 @@
+---
+title: NGINX Plus
+description: Ce tutoriel explique comment utiliser le module nginx-openid-connect pour ajouter une authentification et une autorisation à votre serveur NGINX.
+interactive:  true
+files:
+ - files/nginx
+ - files/openid_connection_configuration
+ - files/openid_connect
+ - files/frontend
+locale: fr-CA
+---
+
+# NGINX Plus
+
+
+
        Ce tutoriel explique comment utiliser le module nginx-openid-connect pour ajouter une authentification et une autorisation à votre serveur NGINX. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.
        Configuration requise
        Ce tutoriel et le projet initial ont été testés avec la fonctionnalité suivante :
        • NGINX Plus R24
        
+
+## Installer et activer le module nginx-plus-module-njs {{{ data-action="code" data-code="nginx.conf" }}}
+
+
+
        Vous devez d’abord installer le module nginx-plus-module-njs pour NGINX Plus.
        Suivez le guide d’installation des modules dynamiques pour installer les packages dans votre système d’exploitation hôte.
        Pour les distributions Linux qui utilisent le gestionnaire de packages yum, il est possible d’installer le module de la manière suivante :
        sudo yum install nginx-plus-module-njs jq
        Une fois le module installé, vous devez l’activer pour NGINX en ajoutant la ligne suivante au début de votre fichier /etc/nginx/nginx.conf :
        load_module modules/ngx_http_js_module.so;
        
+
+## Vérifier le référentiel de modèles nginx-openid-connect
+
+
+
        Clonez le référentiel nginx-openid-connect. Ce référentiel est accompagné d’un modèle de configuration.
        git clone https://github.com/nginxinc/nginx-openid-connect
        
+
+## Configurez NGINX avec les détails de votre application Auth0 {{{ data-action="code" data-code="openid_connection_configuration.conf" }}}
+
+
+
        Exécutez le script configure.sh dans le dossier nginx-openid-connect pour renseigner le modèle de configuration pour votre application Auth0 :
        ./configure.sh --auth_jwt_key request \
+
+  --client_id ${account.clientId} \
+
+  --pkce_enable \
+
+  https://${account.namespace}/.well-known/openid-configuration
+
+
        
+
+
        Puis, ajoutez l’URL de déconnexion de votre locataire à votre fichier openid_connect_configuration.conf.
        
+
+## Configuration de l’en-tête Accept-Encoding pour les points de terminaison du jeton et JWKS {{{ data-action="code" data-code="openid_connect.server_conf" }}}
+
+
+
        Ajoutez l’en-tête Accept-Encoding et définissez la valeur gzip dans votre fichier openid_connect.server_conf.
        
+
+## Copier les fichiers de configuration OpenID Connect
+
+
+
        Copiez vos quatre fichiers de configuration dans le dossier conf.d.
        sudo cp openid_connect.js \ 
+
+   frontend.conf \
+
+   openid_connect_configuration.conf \
+
+   openid_connect.server_conf /etc/nginx/conf.d
+
+
        
+
+
        
+
+## Configuration des paramètres de l’application Auth0
+
+
+
        Dans Auth0 Dashboard :
        1. Accédez à Applications > Applications, puis sélectionnez votre application dans la liste.
        2. Passez à l’affichage Paramètres.
        3. Dans la section  URI de l’application, ajoutez https://{yourDomain}/_codexch à URL de rappel autorisées).
        4. Passez à l’affichage Credentials (Identifiants).
        Dans la section Application Authentication (Authentification de l’application), définissez Authentication Method (Méthode d’authentification) sur « None ».
        
+
+## Transmettre les en-têtes à l’application en amont {{{ data-action="code" data-code="frontend.conf" }}}
+
+
+
        Ajoutez des en-têtes supplémentaires du jeton d’ID (JWT) à la cible en amont dans votre fichier /etc/nginx/conf.d/frontend.conf.
        
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..d6d8f81048
--- /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..da33ff8012
--- /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..cd4e6a9608
--- /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..fc2fbda6e1
--- /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..35740dafe5
--- /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..324567024b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/interactive.md
@@ -0,0 +1,88 @@
+---
+title: Ajouter une connexion à votre application PHP
+description: Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application PHP à l’aide de la trousse SDK Auth0 PHP.
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+ - files/router
+ - files/callback
+github:
+  path: app
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application PHP
+
+
+
        Auth0 vous permet d’ajouter rapidement l’authentification à presque tous les types d’application. Ce guide explique comment intégrer Auth0, ajouter l’authentification et afficher les informations de profil utilisateur dans n’importe quelle application PHP à l’aide de la trousse SDK Auth0 PHP.
        Pour utiliser ce guide rapide, vous devez :
        • Vous inscrire à un compte Auth0 gratuit ou vous connecter à Auth0.
        • Disposer d’un projet PHP fonctionnel avec lequel vous souhaitez vous intégrer. Vous pouvez également consulter ou télécharger une application faisant office d’exemple lorsque vous vous connectez.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Installer la trousse SDK Auth0 PHP {{{ data-action="code" data-code="index.php" }}}
+
+
+
        Auth0 fournit une trousse SDK PHP (Auth0-PHP) pour simplifier le processus de mise en œuvre de l’authentification et de l’autorisation Auth0 dans les applications PHP.
        La trousse SDK Auth0 PHP nécessite l’installation des bibliothèques HTTP compatibles PSR-17 et PSR-18 pour la gestion des requêtes réseau. Si vous ne disposez pas de bibliothèques, vous pouvez installer des choix fiables en exécutant les commandes suivantes dans votre terminal :
        cd <your-project-directory>
+
+composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        Installez maintenant la trousse SDK PHP Auth0 en exécutant la commande suivante dans votre terminal :
        composer require auth0/auth0-php
+
+
        
+
+
        Configurer la trousse SDK Auth0
        Créez un nouveau fichier dans votre application, appelé index.php, et copiez le code du panneau interactif à droite sous l’onglet index.php.
        Pour que la trousse SDK fonctionne correctement, vous devez définir les propriétés suivantes dans la trousse SDK Auth0 lors de l’initialisation :
        • domain : Le domaine de votre locataire Auth0. En général, vous le trouvez dans Auth0 Dashboard sous vos paramètres d’application dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • clientId : l’identificateur de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous pouvez le trouver dans Auth0 Dashboard, dans les paramètres de votre application, dans le champ Client ID (ID client).
        • clientSecret : le secret de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous pouvez le trouver dans Auth0 Dashboard, dans la rubrique des paramètres de votre application, dans le champ Client Secret (Secret client).
        • redirectUri : l’URL dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Cela correspond à l’URL de rappel que vous avez configurée précédemment dans ce guide rapide. Cette valeur se trouve également dans Auth0 Dashboard, sous les paramètres de votre application, dans le champ URL de rappel. Assurez-vous que ce que vous saisissez dans votre code correspond à ce que vous avez configuré précédemment, au cas contraire, vos utilisateurs verront une erreur.
        • cookieSecret : Valeur secrète longue utilisée pour chiffrer le témoin de session. Vous pouvez générer une chaîne appropriée en exécutant openssl rand -hex 32 dans votre terminal.
        PHP - Étape 2 - Point de contrôle 
        Votre trousse SDK Auth0 devrait maintenant être correctement configurée. Exécutez votre application pour vérifier que :
        • La trousse SDK s’initialise correctement.
        • Votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Assurez-vous que la bonne application est sélectionnée.
        • Avez-vous procédé à un enregistrement après avoir saisi vos URL?
        • Assurez-vous que le domaine et l'identifiant client ont été importés correctement.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l'aide.
        
+
+  
        
+
+## Créer des routes {{{ data-action="code" data-code="router.php" }}}
+
+
+
        Installez maintenant une bibliothèque de routage, pour aider à diriger les requêtes entrantes vers votre application. Cette étape n’est pas obligatoire, mais elle simplifie la structure de l’application pour les besoins de ce guide rapide.
        composer require steampixel/simple-php-router
+
+
        
+
+
        Créez un nouveau fichier dans votre application, appelé router.php, pour définir nos routes, et copiez le code du panneau interactif à droite.
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login.php" }}}
+
+
+
        À présent que vous avez configuré votre application Auth0 et la trousse SDK PHP Auth0, vous devez configurer la connexion pour votre projet. Pour ce faire, vous utiliserez la méthode login() de la trousse SDK pour créer un bouton de connexion qui redirige les utilisateurs vers la page de connexion universelle Auth0. Une fois un utilisateur authentifié avec succès, il est redirigé vers l’URL de rappel que vous avez configurée précédemment dans ce guide de démarrage rapide.
        Créez un nouveau fichier dans votre application, appelé login.php, pour gérer le processus de connexion, et copiez le code du panneau interactif à droite, qui contient la logique nécessaire à la connexion.
        PHP – Étape 4 – Point de contrôle 
        Vous devez désormais pouvoir vous connecter ou vous inscrire en utilisant un nom d’utilisateur et un mot de passe.
        Cliquez sur le lien de connexion et vérifiez que :
        • Votre application vous redirige vers la page de connexion universelle Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre application en utilisant la valeur de redirectUri que vous avez utilisée pour configurer la trousse SDK.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Vous avez configuré le bon redirectUri.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de déconnexion à votre application {{{ data-action="code" data-code="logout.php" }}}
+
+
+
        Les utilisateurs qui se connectent à votre projet auront également besoin d’un moyen de se déconnecter. Nous allons gérer un bouton de déconnexion à l’aide de la méthodelogout() de la trousse SDK. Lorsque les utilisateurs se déconnecteront, ils seront redirigés vers votre point de terminaison Auth0 logout qui par la suite les redirigera immédiatement vers l’URL de déconnexion que vous avez configurée précédemment dans ce guide de démarrage rapide.
        Créez un nouveau fichier dans votre application, appelé logout.php, pour gérer le processus, et copiez le code du panneau interactif, qui contient la logique nécessaire à la déconnexion. Ensuite, mettez à jour votre fichier index.php pour y intégrer le nouveau bouton de déconnexion.
        PHP - Section 5 - Point de contrôle 
        Exécutez votre application et cliquez sur le bouton de déconnexion, vérifiez que :
        • Votre application vous redirige vers l’adresse que vous avez précisée comme l’une des URL de déconnexion autorisées dans les paramètres de votre application.
        • Vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Vous avez configuré l’a bonne URL de déconnexion.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile.php" }}}
+
+
+
        Vu que vos utilisateurs peuvent désormais se connecter et se déconnecter, vous voudrez probablement pouvoir récupérer les informations de profil associées aux utilisateurs authentifiés. Par exemple, vous voudrez peut-être pouvoir afficher le nom ou la photo de profil d’un utilisateur connecté dans votre projet.
        La trousse SDK PHP Auth0 fournit des informations sur les utilisateurs via la méthode getCredentials(). Examinez le code profile.php dans le panneau interactif pour voir un exemple de la façon de l’utiliser.
        Étant donné que la méthode contient des informations sensibles liées à l’identité de l’utilisateur, sa disponibilité dépend du statut d’authentification de l’utilisateur. Pour éviter les erreurs de rendu, vous devez toujours vérifier si la méthode getCredentials() renvoie un object ou null pour déterminer si Auth0 a authentifié l’utilisateur avant que votre application ne consomme les résultats.
        PHP - Étape 6 - Point de contrôle 
        Vérifiez que :
        • vous pouvez afficher le nickname ou toute autre propriété de l’utilisateur adéquatement, après vous être connecté.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Vous avez créé le fichier profile.php et êtes connecté.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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..194c279e61
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/files/server.md
@@ -0,0 +1,67 @@
+---
+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/files/templates/home.md b/fr-ca/articles/quickstart/webapp/python/files/templates/home.md
new file mode 100644
index 0000000000..d543f58b29
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/files/templates/home.md
@@ -0,0 +1,23 @@
+---
+name: templates/home.html
+language: markup
+---
+    
+```markup
+
+
+  
+  Auth0 Example
+
+
+  {% if session %}
+      
        Welcome {{session.userinfo.name}}!
        
+      
        Logout
        
+      
        {{pretty}}
        
+  {% else %}
+    
        Welcome Guest
        
+    
        Login
        
+  {% endif %}
+
+
+```
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..2cfe2b9d31
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/interactive.md
@@ -0,0 +1,93 @@
+---
+title: Ajouter une fonctionnalité de connexion à votre application Python Flask
+description: Ce guide explique comment intégrer Auth0 à une application PythonºFlask, à l’aide de la trousse SDK Authlib.
+interactive:  true
+files:
+ - files/server
+ - files/templates/home
+github:
+  path: 01-Login
+locale: fr-CA
+---
+
+# Ajouter une fonctionnalité de connexion à votre application Python Flask
+
+
+
        Auth0 vous permet d’ajouter l’authentification et de pouvoir accéder aux informations relatives au profil de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à une application Python Flask, à l’aide de la trousse SDK Authlib.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, chaque application se voit attribuer un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide de démarrage rapide seront automatiquement mis à jour pour votre application dans le Tableau de bord, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre projet à titre d’exemple, définissez ceci sur http://localhost:3000.
        
+
+## Installer les dépendances
+
+
+
        Créez un fichier requirements.txt dans le répertoire de votre projet :
        # 📁 requirements.txt -----
+
+
+
+flask>=2.0.3
+
+python-dotenv>=0.19.2
+
+authlib>=1.0
+
+requests>=2.27.1
+
+
        
+
+
        Exécutez la commande suivante depuis votre shell pour activer les dépendances suivantes dans votre projet :
        pip install -r requirements.txt
+
+
        
+
+
        
+
+## Configurez votre fichier .env
+
+
+
        Ensuite, créez un fichier .env dans votre répertoire de projet. Ce fichier contiendra les clés de vos clients et d’autres détails de configuration.
        # 📁 .env -----
+
+
+
+AUTH0_CLIENT_ID=${account.clientId}
+
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+AUTH0_DOMAIN=${account.namespace}
+
+APP_SECRET_KEY=
+
+
        
+
+
        • Générez une chaîne pour APP_SECRET_KEY en utilisant openssl rand -hex 32 depuis votre shell.
        
+
+## Configurez votre application {{{ data-action="code" data-code="templates/home.html" }}}
+
+
+
        Ensuite, configurez votre application. Créez un fichier server.py dans le répertoire de votre projet; ce fichier contiendra la logique de votre application.
        Importez toutes les bibliothèques nécessaires à votre application.
        Chargez le fichier de configuration .env que vous avez créé à l’étape précédente.
        Configurez Authlib pour gérer l’authentification de votre application avec Auth0. Apprenez-en davantage sur les options de configuration possibles pour la méthode register() d’Authlib OAuth dans leur documentation.
        
+
+## Configurez vos routes {{{ data-action="code" data-code="server.py" }}}
+
+
+
        Dans cet exemple, vous ajouterez quatre routes à l’application : connexion, callback, déconnexion et accueil.
        Lorsque les visiteurs de votre application se rendent sur la route /login, votre application les dirige vers la page de connexion Auth0.
        Une fois vos utilisateurs connectés avec Auth0, votre application les dirige vers la route /callback. Cette route enregistre la session de l’utilisateur et permet de ne plus avoir à se reconnecter lorsqu’il revient.
        La route /logout permet aux utilisateurs de se déconnecter de votre application. Cette route efface la session de l’utilisateur dans votre application et redirige vers le point de terminaison de déconnexion d’Auth0 pour s’assurer que la session n’est plus enregistrée. Ensuite, l’application redirige l’utilisateur vers votre route d’accueil.
        Votre route /home affiche les détails d’un utilisateur authentifié ou permet aux visiteurs de s’identifier.
        
+
+## Ajouter des modèles
+
+
+
        Créez ensuite le fichier de modèle utilisé dans la route d’accueil (lors des appels render_template()).
        Créez un nouveau sous-répertoire dans le dossier de votre projet, nommé templates, et créez home.html dans ce répertoire. Collez le contenu à droite dans ce fichier.
        
+
+## Exécuter votre application
+
+
+
        Pour exécuter votre application, naviguez jusqu’à la racine du répertoire de votre projet et ouvrez un terminal. Exécutez la commande suivante :
        python3 server.py
+
+
        
+
+
        Python - Étape 7 - Point de contrôle 
        Visitez http://localhost:3000 pour des raisons de vérification. Un bouton de connexion devrait vous permettre de vous connecter à Auth0, puis de revenir à votre application pour consulter les informations relatives à votre profil.
        
+
+  
        
+
+  
        Si votre application n’a pas démarré avec succès :
        • Vérifiez les erreurs éventuelles dans la console.
        • Vérifiez que le domaine et l’identifiant client ont été importés correctement.
        • Vérifiez la configuration de votre locataire.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
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/auth0.md b/fr-ca/articles/quickstart/webapp/rails/files/auth0.md
new file mode 100644
index 0000000000..1f2fac9081
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/auth0.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
+```
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/auth0_controller.md b/fr-ca/articles/quickstart/webapp/rails/files/auth0_controller.md
new file mode 100644
index 0000000000..af8dc0c527
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/auth0_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/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/config/auth0.md b/fr-ca/articles/quickstart/webapp/rails/files/config/auth0.md
new file mode 100644
index 0000000000..35907e29d2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/config/auth0.md
@@ -0,0 +1,11 @@
+---
+name: config/auth0.yml
+language: yaml
+---
+    
+```yaml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: ${account.clientSecret}
+```
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..f4b9d7219d
--- /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
+```
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/secured.md b/fr-ca/articles/quickstart/webapp/rails/files/secured.md
new file mode 100644
index 0000000000..a1f58412c4
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/secured.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
+```
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..16d78539fe
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,132 @@
+---
+title: Ajouter une connexion à votre application Ruby on Rails
+description: Ce tutoriel explique comment ajouter la connexion utilisateur à une application Ruby on Rails.
+interactive:  true
+files:
+ - files/config/auth0
+ - files/auth0
+ - files/auth0_controller
+ - files/routes
+ - files/secured
+github:
+  path: sample
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Ruby on Rails
+
+
+
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. L’application Auth0 est l’endroit où vous allez configurer le fonctionnement de l’authentification pour le projet que vous développez.
        Configurer une application
        Utilisez le sélecteur interactif pour créer une nouvelle application Auth0 ou sélectionner une application existante qui représente le projet avec lequel vous souhaitez effectuer l’intégration. Dans Auth0, il est attribué à chaque application un identifiant client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via la trousse SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, qui est l’endroit où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez plutôt un exemple d’application.
        Configurer les URL de rappel
        Une URL de rappel est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur authentification. Si elle n’est pas définie, les utilisateurs ne seront pas redirigés vers votre application après s’être connectés.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000/auth/auth0/callback.
        Configuration des URL de déconnexion
        Une URL de déconnexion est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après leur déconnexion. Si elle n’est pas définie, les utilisateurs ne pourront pas se déconnecter de votre application et recevront un message d’erreur.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        Configurer les origines Web autorisées
        Une origine Web autorisée est une URL que vous souhaitez autoriser à accéder à votre flux d’authentification. Elle doit contenir l’URL de votre projet. Si elle n’est pas configurée adéquatement, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lorsque prochainement ils visiteront votre application ou lors de l’actualisation d’une page.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Ajouter des dépendances
+
+
+
        Utilisez omniauth-auth0, une stratégie OmniAuth personnalisée, pour gérer le flux d’authentification.
        Ajoutez les dépendances suivantes à votre Gemfile :
        gem 'omniauth-auth0', '~> 3.0'
+
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+
+
        
+
+
        Une fois vos gems ajoutés, installez-les avec la commande bundle install.
        
+
+## Configuration de la trousse SDK {{{ data-action="code" data-code="config/auth0.yml" }}}
+
+
+
        Créez un fichier de configuration ./config/auth0.yml pour préciser votre domaine Auth0, votre identifiant client et vos valeurs de secret client situées dans votre Auth0 Dashboard sous les paramètres de l’application.
        
+
+## Configurer l’intergiciel OmniAuth {{{ data-action="code" data-code="auth0.rb" }}}
+
+
+
        Créez le fichier d’initialisation suivant ./config/initializers/auth0.rb et configurez l’intergiciel OmniAuth avec le fichier de configuration que vous avez créé à l’étape précédente.
        Assurez-vous que callback_path correspond à la valeur donnée dans le paramètre des URL de rappel autorisées de votre application Auth0.
        
+
+## Ajouter un contrôleur Auth0 {{{ data-action="code" data-code="auth0_controller.rb" }}}
+
+
+
        Créez un contrôleur Auth0 pour gérer le rappel d’authentification, l’action logout et les méthodes pour créer l’URL de déconnexion.
        Exécutez la commande rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine.
        Dans la méthode de rappel, assignez le hachage des informations utilisateur, renvoyé en tant que request.env[’omniauth.auth’] à la session active.
        Pour configurer la déconnexion, effacez tous les objets stockés dans la session en appelant la méthode reset_session dans l’action logout. Ensuite, redirigez vers le point de terminaison de déconnexion Auth0. Pour en savoir plus sur reset_session, consultez Documentation relative au ActionController Ruby on Rails.
        
+
+## Configurer les routes {{{ data-action="code" data-code="routes.rb" }}}
+
+
+
        Ajoutez ces routes à votre fichier ./config/routes.rb.
        Les routes doivent être en place afin que Rails sache comment diriger les différentes URL de rappel Auth0 vers le contrôleur Auth0 que vous avez créé à l’étape précédente.
        Démarrage rapide Ruby on Rails - Étape 6 - Point de contrôle 
        Exécutez votre application pour vérifier qu’elle fonctionne toujours comme prévu et que vous ne recevez aucun message d’erreur lié à Auth0.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Veuillez vérifier que les étapes précédentes se sont déroulées sans erreur.
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application
+
+
+
        Un utilisateur peut maintenant se connecter à votre application en visitant le point de terminaison /auth/auth0.
        Pour prévenir les requêtes d’authentification falsifiées, utilisez les méthodes d’assistance link_to ou button_to avec la méthode :post.
        <!-- Place a login button anywhere on your application -->
+
+\${ "<\%= button_to 'Login', '/auth/auth0', method: :post %>" }
+
+
        
+
+
        Démarrage rapide Ruby on Rails - Étape 7 - Point de contrôle 
        Ajoutez un bouton à votre application qui redirige l’utilisateur vers le point de terminaison /auth/auth0 lorsqu’il est sélectionné. Observez si vous êtes redirigé vers Auth0 pour vous connecter, puis renvoyé vers votre application après une authentification réussie.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Assurez-vous que les bonnes URL ont été définies dans votre application Auth0 conformément à la première étape de ce démarrage rapide
        • Vérifiez que toutes les gems requis sont correctement installés
        • Vérifiez que les routes ont été configurées et que la configuration Auth0 a été définie dans votre application
        • Consultez les journaux pour y trouver d’autres erreurs ou messages qui auraient pu empêcher la connexion de fonctionner
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Ajoutez une fonctionnalité de déconnexion à votre application
+
+
+
        Maintenant que vous pouvez vous connecter à votre application Rails, vous avez besoin d’un moyen de vous déconnecter. Déconnectez un utilisateur en le redirigeant vers l’action auth/logout qui le redirige vers le point de terminaison de déconnexion d’Auth0.
        Pour tester cela après l’étape précédente, vous devez peut-être effacer votre session, puis rediriger l’utilisateur vers le point de terminaison de déconnexion d’Auth0.
        <!-- Place a logout button anywhere on your application -->
+
+\${"<%= button_to 'Logout', 'auth/logout', method: :get %>"}
+
+
        
+
+
        Démarrage rapide Ruby on Rails – Étape 8 – Point de contrôle 
        Ajoutez un bouton à votre application qui redirige l’utilisateur vers le point de terminaison /auth/logout lorsqu’il est sélectionné. Vérifiez que vous êtes redirigé vers Auth0, puis renvoyé rapidement vers votre application, et que vous n’êtes plus connecté.
        
+
+  
        
+
+  
        Nous vous prions de nous excuser pour tout inconvénient causé. Voici quelques éléments à vérifier :
        • Assurez-vous que les bonnes URL ont été définies dans votre client Auth0 conformément à la première étape de ce démarrage rapide
        • Vérifiez que les routes ont été configurées et que la configuration Auth0 a été définie dans votre application
        • Consultez les journaux pour toute autre erreur ou message qui aurait pu empêcher la connexion
        Vous rencontrez toujours des problèmes? Consultez notre documentation ou la page de notre communauté pour obtenir de l’aide.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="routes.rb" }}}
+
+
+
        Pour afficher le profil utilisateur, votre application doit fournir une route protégée. Vous pouvez utiliser une préoccupation pour contrôler l’accès aux routes qui peuvent être partagées entre plusieurs contrôleurs. La préoccupation devrait rediriger automatiquement vers Auth0 lorsque l’utilisateur n’est pas authentifié. Au cas contraire, la préoccupation  devrait renvoyer le profil utilisateur actuel.
        Une fois que vous avez une préoccupation, incluez-la dans tout contrôleur qui nécessite un utilisateur connecté. Vous pouvez ensuite accéder à l’utilisateur à partir de la session session[:userinfo] comme dans l’exemple suivant :
        class DashboardController < ApplicationController
+
+  include Secured
+
+
+
+  def show
+
+    @user = session[:userinfo]
+
+  end
+
+end
+
+
        
+
+
        Une fois que l’utilisateur a chargé la session, utilisez-la pour afficher des informations dans votre système frontal :
        <div>
+
+  <p>Normalized User Profile:\${"<%= JSON.pretty_generate(@user[:info])%>"}</p>
+
+  <p>Full User Profile:\${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}</p>
+
+</div>
+
+
        
+
+
        Démarrage rapide Ruby on Rails – Étape 9 – Point de contrôle 
        Ajoutez le concern Secured à votre application, puis incluez-le dans le contrôleur qui nécessite un utilisateur authentifié pour y accéder. Vérifiez qu’un utilisateur authentifié a accès aux actions de ce contrôleur et que les utilisateurs non authentifiés sont redirigés vers Auth0 pour l’authentification.
        
+
+  
        
+
+  
        
+
+  
        
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/snippets/application-platforms/emberjs/setup.md b/ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md
similarity index 100%
rename from snippets/application-platforms/emberjs/setup.md
rename to ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md
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/ApiController.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.md
new file mode 100644
index 0000000000..9f8b83b336
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/ApiController.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/HasScopeHandler.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.md
new file mode 100644
index 0000000000..f67f1b2cd1
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeHandler.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/HasScopeRequirement.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.md
new file mode 100644
index 0000000000..fe73104225
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/HasScopeRequirement.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/files/Program.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/Program.md
new file mode 100644
index 0000000000..7b30acec02
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/Program.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/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..d9419a5dd9
--- /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..91e43e0b95
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/interactive.md
@@ -0,0 +1,611 @@
+---
+title: ASP.NET Core Web APIアプリケーションに認可を追加する
+description: このチュートリアルは、標準のJWTミドルウェアを使ってASP.NET Core Web APIアプリケーションに認可を追加する方法を説明します。
+interactive:  true
+files:
+ - files/appsettings
+ - files/Program
+ - files/HasScopeHandler
+ - files/HasScopeRequirement
+ - files/ApiController
+github:
+  path: Quickstart/01-Authorization
+locale: ja-JP
+---
+
+# ASP.NET Core Web APIアプリケーションに認可を追加する
+
+
+
        Auth0を使用すると、アプリケーションに認証を追加して、アプリケーションの種類にかかわらず、ユーザープロファイル情報に手軽にアクセスすることができます。このガイドは、新規または既存のASP.NET Web APIアプリケーションにMicrosoft.AspNetCore.Authentication.JwtBearerパッケージを使ってAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、統合したいプロジェクトを表す既存のAPIを選択することができます。
        または、Auth0 Dashboardを使って初めてAPIをセットアップする方法を使用の開始ガイドで確認することもできます。
        Auth0にあるAPIはそれぞれAPI識別子を使って構成され、アプリケーションのコードはAPI識別子をオーディエンスとしてアクセストークンを検証します。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み取りアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［API］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。以下の例ではread:messagesスコープを使用します。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        
+
+## 依存関係をインストールする
+
+
+
        アプリケーションがアクセストークンを検証できるようにするには、Microsoft.AspNetCore.Authentication.JwtBearer NuGetパッケージへの参照を追加します。
        Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
+
+
        
+
+
        
+
+## ミドルウェアを構成する {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        アプリケーションのProgram.csファイルを構成して、認証ミドルウェアをセットアップします：
        1. AddAuthenticationメソッドを呼び出して、認証サービスを登録します。JwtBearerDefaults.AuthenticationSchemeをデフォルトのスキームとして構成します。
        2. AddJwtBearerメソッドを呼び出して、JWTベアラー認証スキームを登録します。Auth0ドメインをオーソリティ、Auth0 API識別子をオーディエンスとして構成し、Auth0ドメインとAPI識別子がアプリケーションのappsettings.jsonファイル内で設定されていることを確認します。
          場合によっては、アクセストークンにsubクレームが含まれないことがあります。この場合には、User.Identity.Nameがnullになります。別のクレームをUser.Identity.Nameにマッピングしたい場合には、それをAddJwtBearer()への呼び出しの中でoptions.TokenValidationParametersに追加します。
        3. UseAuthenticationメソッドとUseAuthorizationメソッドの呼び出しをvar app = builder.Build();メソッドの下に追加して、ミドルウェアパイプラインに認証ミドルウェアと認可ミドルウェアを追加します。
        
+
+## スコープを検証する {{{ data-action="code" data-code="HasScopeHandler.cs" }}}
+
+
+
        アクセストークンに正しいスコープが含まれていることを確認するには、ASP.NET Coreのポリシーベースの認可を使用します。
        1. HasScopeRequirementという名前の新しい認可要求を作成します。これは、Auth0テナント発行のscopeクレームが存在するかを確認し、存在する場合には、要求されたスコープがそのクレームに含まれているかを確認します。
        2. Program.csファイルにあるvar builder = WebApplication.CreateBuilder(args);メソッドの下に、app.AddAuthorizationメソッドへの呼び出しを追加します。
        3. スコープのポリシーを追加するには、各スコープにAddPolicyを呼び出します。
        4. HasScopeHandlerクラスのシングルトンを登録します。
        
+
+## APIエンドポイントを保護する {{{ data-action="code" data-code="ApiController.cs" }}}
+
+
+
        JWTミドルウェアは、ASP.NET Coreの標準の認証および認可メカニズムと統合します。
        エンドポイントのセキュリティを保護するには、[Authorize]属性をコントローラーのアクション（すべてのアクションのセキュリティを保護するには、コントローラー）に追加します。
        特定のスコープが必要なエンドポイントのセキュリティを保護するには、正しいスコープがaccess_tokenに存在することを確認します。そのためには、Authorize属性をScopedアクションに追加し、read:messagesをpolicyパラメーターとして渡します。
        
+
+## APIを呼び出す
+
+
+
        APIの呼び出し方は、開発しているアプリケーションの種類と使用しているフレームワークに依存します。詳細については、該当するアプリケーションのクイックスタートをお読みください。
        アクセストークン取得する
        開発しているアプリケーションの種類や使用しているフレームワークが何であったとしても、APIを呼び出すにはアクセストークンが必要です。
        シングルページアプリケーション（SPA）またはネイティブアプリケーションからAPIを呼び出すと、認可フローの完了後にアクセストークンを受け取ります。
        コマンドラインツールや他のサービスなど、ユーザーが資格情報を入力しないものからAPIを呼び出す際には、OAuthクライアントの資格情報フローを使用します。そのためには、マシンツーマシンアプリケーションを登録し、要求内で以下の値を渡します。
        • クライアントIDをclient_idパラメーターとして渡す。
        • クライアントシークレットをclient_secretパラメーターとして渡す。
        • API 識別子（このクイックスタートで以前にミドルウェアの構成に使用したのと同じ値）をaudienceパラメーターとして渡す。
        マシンツーマシンアプリケーションにクライアントIDとクライアントシークレットを取得する詳細については、アプリケーションの設定をお読みください。
        要求例
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/token");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/token"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/token")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/token',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/token"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/token",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/token", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/token")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/token")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        セキュリティ保護されたエンドポイントを呼び出す
        取得したアクセストークン使用すると、セキュリティ保護されたAPIエンドポイントを呼び出すことができます。セキュリティ保護されたエンドポイントを呼び出す際には、アクセストークンをベアラートークンとして要求の認可ヘッダーに含める必要があります。たとえば、/api/privateエンドポイントに要求を送信することができます：
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http://localhost:3010/api/private \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN'
        var client = new RestClient("http://localhost:3010/api/private");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http://localhost:3010/api/private"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http://localhost:3010/api/private")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http://localhost:3010/api/private',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://localhost:3010/api/private"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_PORT => "3010",
+
+  CURLOPT_URL => "http://localhost:3010/api/private",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("localhost:3010")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN" }
+
+
+
+conn.request("get", "/api/private", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http://localhost:3010/api/private")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http://localhost:3010/api/private")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        /api/private-scopedエンドポイントも同様の方法で呼び出しますが、APIのアクセス許可が正しく構成され、アクセストークンにread:messagesスコープがあることを確認してください。
        ASP.NET APIクイックスタート - 手順6「チェックポイント」 
        /api/privateと/api/private-scopedエンドポイントを呼び出すことができるはずです。
        アプリケーションを実行して次の点を確認します：
        • GET /api/privateが認証された要求に使用できる。
        • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ValidIssuerとValidAudienceが正しく構成されていることを確認します
        • トークンをAuthorizationヘッダーに含めて追加したことを確認します
        • トークンに正しいスコープがあることを確認します（確認にはjwt.ioを使用できます）
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/apiexample/urls.md b/ja-jp/articles/quickstart/backend/django/files/apiexample/urls.md
new file mode 100644
index 0000000000..dd7c571d81
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/apiexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/apiexample/validator.md b/ja-jp/articles/quickstart/backend/django/files/apiexample/validator.md
new file mode 100644
index 0000000000..16b55b40c3
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/apiexample/validator.md
@@ -0,0 +1,28 @@
+---
+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/apiexample/views.md b/ja-jp/articles/quickstart/backend/django/files/apiexample/views.md
new file mode 100644
index 0000000000..e9f3f9f404
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/apiexample/views.md
@@ -0,0 +1,37 @@
+---
+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/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..a02f195cac
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/interactive.md
@@ -0,0 +1,316 @@
+---
+title: Django APIアプリケーションに認可を追加する
+description: このチュートリアルは、Djangoを使ってビルドされたPython APIに認可を追加する方法を説明します。
+interactive:  true
+files:
+ - files/apiexample/validator
+ - files/apiexample/views
+ - files/apiexample/urls
+github:
+  path: 01-Authorization
+locale: ja-JP
+---
+
+# Django APIアプリケーションに認可を追加する
+
+
+
        このガイドは、Djangoを使ってビルドされた新規または既存のPython APIアプリケーションにAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、統合したいプロジェクトを表す既存のAPIを選択することができます。
        または、Auth0 Dashboardを使って初めてAPIをセットアップする方法を使用の開始ガイドで確認することもできます。
        Auth0にあるAPIはそれぞれAPI識別子を使って構成され、アプリケーションのコードはAPI識別子をオーディエンスとしてアクセストークンを検証します。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み取りアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［API］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。以下の例ではread:messagesスコープを使用します。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        
+
+## DjangoにAuth0の使用を構成する
+
+
+
        依存関係をインストールする
        1. requirements.txtに次の依存関係を追加します：
+
+
        2. pip install -r requirements.txtを実行する
        Djangoアプリケーションを作成する
        
+
+## JWTバリデーターを作成する {{{ data-action="code" data-code="apiexample/validator.py" }}}
+
+
+
        Authlibという名前のライブラリーを使用して、ResourceProtectorを作成します。これはDjangoビューのデコレーターの一種で、該当するバリデーターを使ってリソース（APIビュー）を保護します。
        バリデーターは、リソースに渡すアクセストークンに有効な署名とクレームがあることを確認して検証します。
        AuthLibのJWTBearerTokenValidatorバリデーターに多少の変更を加えて、アクセストークンの検証要件が満たされるようにします。
        Auth0JWTBearerTokenValidatorを作成するには、domainとaudience（API識別子）に渡すことが必要です。そうすると、トークンの署名を検証するのに必要な公開鍵が取得され、JWTBearerTokenValidatorクラスに渡されます。
        そして、クラスのclaims_optionsをオーバーライドし、トークンのexpiry、audience、issueクレームが要件を満たして有効であることを確認します。
        インタラクティブパネルからのコードを利用して、apiexample/validator.pyファイルを作成します。
        
+
+## APIビューを作成する {{{ data-action="code" data-code="apiexample/views.py" }}}
+
+
+
        次に、apiexample/views.pyに3つのAPIビューを作成します：
        • /api/public：認証を必要としないパブリックエンドポイントです。
        • /api/private：有効なJWTを必要とするプライベートエンドポイントです。
        • /api/private-scoped：与えられたscopeを含む有効なJWTを必要とするプライベートエンドポイントです。
        保護されたルートにはrequire_authデコレーターがあり、これは、以前に作成したAuth0JWTBearerTokenValidatorを使用するResourceProtectorです。
        Auth0JWTBearerTokenValidatorを作成するには、テナントのドメインと以前に作成したAPIのAPI識別子に渡します。
        private_scopedルートのrequire_authデコレーターは、追加の引数である"read:messages"を受け付けます。これは、以前に作成したアクセス許可（スコープ）について、アクセストークンをチェックします。
        
+
+## URLマッピングを追加する {{{ data-action="code" data-code="apiexample/urls.py#8:10" }}}
+
+
+
        前の手順では、views.pyファイルにメソッドを追加しました。次に、DjangoのURL dispatcherを使用して、それらのメソッドをURLへマッピングします。URL dispatcherでは、URLパターンをビューにマッピングすることができます。
        apiexample/urls.pyファイルにURLパターンを追加します。 
        APIを呼び出す
        APIを呼び出すにはアクセストークンが必要です。テスト用のアクセストークンは、APIの設定の［Test（テスト）］ビューから取得することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［API］>［Specific API（特定のAPI］>［Test（テスト）］タブ
        要求のAuthorizationヘッダーにアクセストークンを指定します。
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}.com/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}.com/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}.com/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}.com/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}.com/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}.com/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}.com/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}.com/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}.com/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}.com/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
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..9e2ba946b6
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/files/main.md
@@ -0,0 +1,67 @@
+---
+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/files/middleware/jwt.md b/ja-jp/articles/quickstart/backend/golang/files/middleware/jwt.md
new file mode 100644
index 0000000000..0149818d66
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/files/middleware/jwt.md
@@ -0,0 +1,88 @@
+---
+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/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..9c51d017c4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/interactive.md
@@ -0,0 +1,359 @@
+---
+title: Goアプリケーションに認可を追加する
+description: このチュートリアルは、Go APIに認可を追加する方法を説明します。
+interactive:  true
+files:
+ - files/middleware/jwt
+ - files/main
+github:
+  path: 01-Authorization-RS256
+locale: ja-JP
+---
+
+# Goアプリケーションに認可を追加する
+
+
+
        このガイドは、新規または既存のGo APIアプリケーションにgo-jwt-middlewareパッケージを使ってAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、プロジェクトに既存のAPIを選択することができます。
        Auth0 Dashboardを使って初めてAPIをセットアップする場合には、使用の開始ガイドを確認してください。
        それぞれのAuth0 APIにはAPI識別子があり、アプリケーションにアクセストークンの検証で使用されます。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み取りアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［API］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。以下の例ではread:messagesスコープを使用します。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        
+
+## 依存関係をインストールする
+
+
+
        go.modファイルを追加して、必要な依存関係をすべてリストします。
        // 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
+
+)
+
+
        
+
+
        次のシェルコマンドを実行して、依存関係をダウンロードします：
        go mod download
+
+
        
+
+
        
+
+## アプリケーションを構成する
+
+
+
        アプリの構成を保存するために、.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 API's Identifier.
+
+AUTH0_AUDIENCE='${apiIdentifier}'
+
+
        
+
+
        
+
+## アクセストークンを検証するミドルウェアを作成する {{{ data-action="code" data-code="middleware/jwt.go" }}}
+
+
+
        EnsureValidTokenミドルウェア関数はアクセストークンを検証します。この関数は、保護したいすべてのエンドポイントに適用することができます。トークンが有効であれば、エンドポイントがリソースを開放します。トークンが無効であれば、APIが401 Authorizationエラーを返します。
        受信する要求のアクセストークンを検証するには、go-jwt-middlewareミドルウェア をセットアップします。
        APIはデフォルトで、RS256をトークン署名アルゴリズムとしてセットアップします。RS256は秘密鍵と公開鍵のペアで機能するため、トークンはAuth0アカウントの公開鍵を使用して検証することができます。この公開鍵には、https://{yourDomain}/.well-known/jwks.jsonでアクセスすることができます。
        トークンが要求されたリソースへのアクセスに十分なスコープを持っているか確認する機能を含めてください。
        HasScope関数を作成して、応答を返す前に、アクセストークンに正しいスコープがあることを確認します。
        
+
+## APIエンドポイントを保護する {{{ data-action="code" data-code="main.go" }}}
+
+
+
        この例では、EnsureTokenミドルウェアを使用しない/api/publicエンドポイントを作成して、未認証の要求にも対応できるようにします。
        EnsureTokenミドルウェアを必要とする/api/privateエンドポイントを作成して、追加スコープのないアクセストークンを含む認証済み要求にのみ利用できるようにします。
        EnsureTokenミドルウェアとHasScopeを必要とする/api/private-scopedエンドポイントを作成して、read:messagesスコープを付与されたアクセストークンを含む認証済み要求にのみ利用できるようにします。
        read:messagesスコープのみがHasScope関数で検査されます。状況に応じて、複数のスコープを受け付けるように拡張するか、スタンドアローンのミドルウェアにすることをお勧めします。
        APIを呼び出す
        APIを呼び出すにはアクセストークンが必要です。テスト用のアクセストークンは、API設定の［Test（テスト）］ビューから取得することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［API］>［Specific API（特定のAPI］>［Test（テスト）］タブ
        要求のAuthorizationヘッダーにアクセストークンを指定します。
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Go APIクイックスタート - 手順5「チェックポイント」 
        アプリケーションの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • GET /api/publicが認証を必要としない要求に使用できる。
        • GET /api/privateが認証された要求に使用できる。
        • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • トークンをAuthorizationヘッダーに含めて追加したことを確認します。
        • トークンに正しいスコープがあることを確認します。確認にはjwt.ioを使用します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/APIController.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/APIController.md
new file mode 100644
index 0000000000..6f04ff5496
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/APIController.md
@@ -0,0 +1,35 @@
+---
+name: APIController.java
+language: powershell
+---
+    
+```powershell
+    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");
+}
+    }
+```
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
new file mode 100644
index 0000000000..5c6788d8a4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/SecurityConfig.md
@@ -0,0 +1,41 @@
+---
+name: SecurityConfig.java
+language: powershell
+---
+    
+```powershell
+    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();
+}
+    }
+```
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..b94691c69a
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/application.md
@@ -0,0 +1,13 @@
+---
+name: application.yml
+language: 
+---
+    
+```
+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}
+```
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..fc1823b480
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/message.md
@@ -0,0 +1,11 @@
+---
+name: Message.java
+language: powershell
+---
+    
+```powershell
+    /**
+     * Simple domain object for our API to return a message.
+     */
+    public record Message(String message) {}
+```
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..29e060eb54
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/interactive.md
@@ -0,0 +1,145 @@
+---
+title: Spring Bootアプリケーションに認可を追加する
+description: このガイドは、新規または既存のSpring BootアプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/Message
+ - files/APIController
+github:
+  path: 01-Authorization-MVC
+locale: ja-JP
+---
+
+# Spring Bootアプリケーションに認可を追加する
+
+
+
        Auth0を使用すると、アプリケーションにすばやく認可を追加することができます。このガイドは、新規または既存のSpring BootアプリケーションにAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、統合したいプロジェクトを表す既存のAPIを選択します。
        Auth0 Dashboardを使って初めてAPIをセットアップする場合には、使用の開始ガイドを確認してください。
        それぞれのAuth0 APIにはAPI識別子があり、アプリケーションにアクセストークンの検証で使用されます。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み出しアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［APIs］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        以下の例ではread:messagesスコープを使用します。
        
+
+## サンプルプロジェクトを構成する {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        サンプルプロジェクトは/src/main/resources/application.ymlファイルを使用し、これをAPIに対して正しいAuth0ドメインとAPI識別子を使用するように構成します。このページからコードをダウンロードすると、自動的に構成されます。GitHubから例を複製する場合は、ご自身で入力する必要があります。
        
+
+## 依存関係をインストールする {{{ data-action="code" data-code="application.yml#1:6" }}}
+
+
+
        Gradleを使用している場合、Spring Boot GradleプラグインとDependency Managementプラグインを使って必要な依存関係を追加し、依存関係のバージョンを解決することができます：
        // 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'
+
+    }
+
+
        
+
+
        Mavenを使用している場合は、Springの依存関係をpom.xmlファイルに追加します：
        // pom.xml
+
+
+
+<parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.5</version>
+
+ <relativePath/>
+
+</parent>
+
+<dependencies>
+
+ <dependency>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+ <groupId>com.okta.spring</groupId>
+
+ <artifactId>okta-spring-boot-starter</artifactId>
+
+ <version>3.0.5</version>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## リソースサーバーを構成する {{{ data-action="code" data-code="SecurityConfig.java" }}}
+
+
+
        アプリケーションをリソースサーバーとして構成し、JWTを検証するには、SecurityFilterChainのインスタンスを提供するクラスを作成し、@Configurationの注釈を追加します。
        APIエンドポイントを保護する
        以下に示されたルートは次の要求で使用することができます：
        • GET /api/public：認証を必要としない要求に使用できる
        • GET /api/private：追加スコープのないアクセストークンを含む認証された要求に使用できる
        • GET /api/private-scoped：read:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる
        以下の例は、SecurityConfigクラスのfilterChain()メソッドで指定されたHttpSecurityオブジェクトを使用して、APIメソッドのセキュリティを確保する方法を示します。ルートマッチャーは必要な認可レベルに基づいてアクセスを制限します。
        デフォルトで、Spring SecurityはJWTのscopeクレームで、クレームごとにGrantedAuthorityを作成します。このスコープでは、hasAuthority("SCOPE_read:messages")メソッドを使用して、read:messagesスコープを含む有効なJWTへのアクセスを制限することができます。
        
+
+## ドメインオブジェクトを作成する {{{ data-action="code" data-code="Message.java#1:4" }}}
+
+
+
        エンドポイントがJSONを返すには、Javaレコードを使用することができます。このオブジェクトのメンバー変数は、JSONのキー値にシリアル化されます。Messageと呼ばれる新しいレコードを、API呼び出し中に返すサンプルドメインオブジェクトとして作成します。
        
+
+## APIコントローラーを作成する {{{ data-action="code" data-code="APIController.java" }}}
+
+
+
        APIControllerという名前の新しいクラスを作成し、エンドポイントへの要求を処理します。APIControllerには、APIエンドポイントを保護するセクションで定義されるように、3つのルートがあります。たとえば、@CrossOriginの注釈からすべてのオリジンを許可します。実際のアプリケーションでは、ユースケースに対してCORSを構成する必要があります。
        
+
+## アプリケーションを実行する {{{ data-action="code" data-code="APIController.java" }}}
+
+
+
        サンプルプロジェクトを構築し実行するには、bootRun Gradleタスクを実行します。
        LinuxまたはmacOS：
        ./gradlew bootRun
+
+
        
+
+
        Windows：
        gradlew.bat bootRun
+
+
        
+
+
        MavenとSpring Boot Mavenプラグインで独自のアプリケーションを構成している場合は、spring-boot:runゴールを実行することができます。
        LinuxまたはmacOS：
        mvn spring-boot:run
+
+
        
+
+
        Windows：
        mvn.cmd spring-boot:run
+
+
        
+
+
        Spring Boot API手順7「チェックポイント」 
        サンプルアプリケーションはhttp://localhost:3010/で入手できます。「APIの使用」の記事でAPIをテストおよび使用する方法についてお読みください。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/files/routes/api.md b/ja-jp/articles/quickstart/backend/laravel/files/routes/api.md
new file mode 100644
index 0000000000..a966bef3c4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/files/routes/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..27971bf721
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/interactive.md
@@ -0,0 +1,225 @@
+---
+title: Laravelアプリケーションに認可を追加する
+description: このガイドでは、新規（または既存）のLaravel 9または10アプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/routes/api
+github:
+  path: sample
+locale: ja-JP
+---
+
+# Laravelアプリケーションに認可を追加する
+
+
+
        Auth0のLaravel SDKを使用すると、Laravelアプリケーションにトークンベースの認可とルーティングに基づくアクセスコントロールを手軽に追加できます。このガイドでは、新規（または既存）のLaravel 9または10アプリケーションにAuth0を統合する方法を説明します。
        バックエンドアプリケーションが従来のWebアプリケーションと異なるのは、前者がユーザー認証を処理しない、またはユーザーインターフェイスを持っていない点にあります。バックエンドアプリケーションには、他のアプリケーションが対話できるAPIが用意されており、ルートへのアクセス制御を行うために、要求内のAuthorizationヘッダーからのアクセストークンを受け入れます。
        別のフロントエンドアプリケーションは通常、これらのタイプのバックエンドと対話するために構築されます。これには、シングルページアプリケーションやネイティブまたはモバイルアプリ（Auth0はこれらすべてに対しSDKも提供）などさまざまな可能性があります。
        ユーザーがバックエンドアプリケーションと対話する必要がある場合、まず、フロントエンドアプリケーションを使ってAuth0と認証を行います。フロントエンドアプリケーションはAuth0からアクセストークンを取得し、これを使ってユーザーに代わって、バックエンドアプリケーションに要求することができます。
        名前が示唆するように、アクセストークンはアクセス制御（認可）の問題に対処するように設計されており、ユーザーに関する情報は含まれていません。バックエンドアプリケーションは、アクセストークンとのみ動作します。Management APIを使ってトークンを作成したユーザーに関する情報を取得することができます。これについては後で説明します。
        
+
+## Laravelをインストールする
+
+
+
        Laravelアプリケーションをまだセットアップしていない場合には、シェルを開いて、新規プロジェクトに適切なディレクトリに移動し、次のコマンドを実行します：
        composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0
+
+
        
+
+
        このガイドにあるすべてのコマンドは、Laravelプロジェクトディレクトリのルートから実行されていることを前提としています。必ず新規プロジェクトのディレクトリに移動（cd）してください：
        cd auth0-laravel-api
+
+
        
+
+
        
+
+## SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 Laravel SDKをインストールします：
        composer require auth0/login:^7.8 --update-with-all-dependencies
+
+
        
+
+
        そして、アプリケーションにSDK構成ファイルを生成します：
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## SDKを構成する
+
+
+
        プロジェクトディレクトリから次のコマンドを実行して、Auth0 CLIをダウンロードします：
        curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+
+
        
+
+
        そして、Auth0アカウントを使ってCLIを認証し、プロンプトでユーザーとしてログインすることを選択します：
        ./auth0 login
+
+
        
+
+
        次に、Auth0で新しいアプリケーションを作成します：
        ./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
+
+
        
+
+
        また、新しいAPIも作成します：
        ./auth0 apis create \
+
+--name "My Laravel Backend API" \
+
+--identifier "https://github.com/auth0/laravel-auth0" \
+
+--offline-access \
+
+--no-input \
+
+--json > .auth0.api.json
+
+
        
+
+
        これで、SDKを構成するプロジェクトディレクトリ内に2つのファイルが作成されます。
        これらのファイルには資格情報が保管されているため、機密として扱うことが重要です。必ず、バージョン管理では、これらのファイルをコミットしないようにしてください。Gitを使用している場合は、必ず.gitignoreファイルに追加します：
        echo ".auth0.*.json" >> .gitignore
+
+
        
+
+
        
+
+## アクセス制御 {{{ data-action="code" data-code="routes/api.php#6:16" }}}
+
+
+
        SDKは、apiミドルウェアと併用するLaravelアプリケーションで認可ガードを自動的に登録します。Laravelはデフォルトで、アプリケーションのroutes/api.phpファイルのすべてのルートに適用します。
        構成を追加せずにSDKが期待通りに動作するには、routes/api.phpファイルでルートを定義する必要があります。
        アプリケーションの経路へのアクセスを制約するには、Auth0 SDKの認可ガードを使用することができます。
        Authorizationヘッダーで有効なアクセストークンを含まない要求を拒否するには、Laravelのauthミドルウェアを使用することができます。
        Route::get('/private', function () {
+
+ return response()->json([
+
+ 'message' \=> 'Your token is valid; you are authorized.',
+
+ ]);
+
+})->middleware('auth');
+
+
        
+
+
        また、これをLaravelのcanミドルウェアと組み合わせると、提供されたトークンに特定の権限を要求することができます。
        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');
+
+
        
+
+
        
+
+## トークン情報 {{{ data-action="code" data-code="routes/api.php#18:30" }}}
+
+
+
        提供されたアクセストークンについての情報は、LaravelのAuthファサードまたはauth()ヘルパー関数を介して利用できます。
        以下は、ユーザーの識別子とメールアドレスを取得する例です。
        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(),
+
+ ]);
+
+});
+
+
        
+
+
        
+
+## ユーザー情報を取得する {{{ data-action="code" data-code="routes/api.php#32:51" }}}
+
+
+
        Auth0 Management APIを使って、Auth0からアクセストークンを作成したユーザーについての情報を取得することができます。SDKにはこのAPIに便利なラッパーが備わっており、SDKのmanagement()メソッドからアクセス可能です。
        Management APIを呼び出す前に、アプリケーションがManagement APIと通信できるようにしなければなりません。これを実行するには、Auth0 DashboardのAPIページで［Auth0 Management API］を選択してから［Machine to Machine Applications（M2Mアプリケーション）］タブを選択します。Laravelアプリケーションを認可してから、下矢印をクリックして、付与したいスコープを選択します。
        以下の例では、read:usersスコープを付与する必要があります。APIエンドポイントのリストと必要なスコープについては、Management APIのドキュメントを参照してください。
        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');
+
+
        
+
+
        アプリケーションでユーザー情報を短期間キャッシュする必要があります。これによって、アプリケーションがAuth0に対して行う要求数を減らし、パフォーマンスが向上します。ユーザー情報をアプリケーションに長期間保存するとデータが古くなる可能性があるため避けてください。ユーザーの識別子以外のユーザー情報を持続的データベースに保存することも避けてください。
        
+
+## アプリケーションを実行する
+
+
+
        Laravelアプリケーションを起動する準備が整いました。要求を受け付けることができます：
        php artisan serve
+
+
        
+
+
        
+
+## テストトークンを取得する
+
+
+
        アクセストークンの取得については、こちらに詳しく記載されています。ただし、このクイックスタートでは、API設定の［test（テスト）］ビューからアクセストークンを簡単に使用することができます。
        上で作成した/meルートには関連付けられた実際のユーザーが存在しないため、テストトークンで動作しません。
        Laravelクイックスタート手順8「チェックポイント」 
        シェルを開き、アプリケーションに要求を発行するようにします。
        まず、パブリックルートを要求します。
        curl --request GET \ --url http://localhost:8000/api \ --header 'Accept: application/json'
        次に、Authorizationヘッダーでアクセストークンを使用して、保護されたルートを要求します。
        curl --request GET \ --url http://localhost:8000/api/private \ --header 'Accept: application/json' \ --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
        最後に、スコープで保護されたルートを要求するようにします。この要求は、アクセストークンにread:messagesスコープが付与されている場合にのみ成功します。
        curl --request GET \ --url http://localhost:8000/api/scope \ --header 'Accept: application/json' \ --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
        
+
+  
        
+
+  
        試せることがいくつかあります。
        • php artisan optimize:clearを実行してLaravelのキャッシュを消去してみます。
        • .auth0.app.jsonおよび.auth0.api.jsonファイルがプロジェクトのルートにあることを確認します。
        • Laravelアプリケーションをマシンツーマシンアプリケーションとして有効化し、Auth0 Dashboardを使用して、Auth0 Management APIで必要なスコープがすべて付与されていることを確認します。
        問題が発生しましたか？SDKのドキュメントまたはAuth0のドキュメンテーションハブを確認してください。また、コミュニティの利用も検討してください。Auth0チームや他のコミュニティメンバーがご質問にお答えします。
        
+
+  
        その他の情報
        • ユーザーリポジトリとモデルはAuth0 Laravel SDKを拡張して、カスタムのユーザーモデルを使用し、データベースでユーザーの保管や取得を行う方法を指定することができます。
        • イベントフックはAuth0 Laravel SDKで発生したイベントをリッスンする方法を処理して、統合の動作を完全にカスタマイズすることができます。
        • Management API対応はAuth0 Laravel SDKに組み込まれているため、LaravelアプリケーションからManagement APIと対話することができます。
        
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..4f8b8f5734
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/files/server.md
@@ -0,0 +1,43 @@
+---
+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..2f3be9d681
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,317 @@
+---
+title: Express.js APIアプリケーションに認可を追加する
+description: このガイドは、新規または既存のExpress.js APIアプリケーションにexpress-oauth2-jwt-bearerパッケージを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/server
+github:
+  path: 01-Authorization-RS256
+locale: ja-JP
+---
+
+# Express.js APIアプリケーションに認可を追加する
+
+
+
        このガイドは、新規または既存のExpress.js APIアプリケーションにexpress-oauth2-jwt-bearerパッケージを使ってAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、既存のプロジェクトAPIを選択します。
        Auth0 Dashboardを使って初めてAPIをセットアップする場合には、使用の開始ガイドを確認してください。それぞれのAuth0 APIにはAPI識別子があり、アプリケーションにアクセストークンの検証で使用されます。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み出しアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［APIs］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。
        null
        以下の例ではread:messagesスコープを使用します。
        
+
+## 依存関係をインストールする
+
+
+
        まず、npmでSDKをインストールします。
        npm install --save express-oauth2-jwt-bearer
+
+
        
+
+
        
+
+## ミドルウェアを構成する {{{ data-action="code" data-code="server.js#1:10" }}}
+
+
+
        ドメインとAPI識別子を使って、express-oauth2-jwt-bearerを構成します。
        右に示したcheckJwtミドルウェアは、要求に含まれるユーザーのアクセストークンが有効かを確認します。トークンが有効でない場合、ユーザーがエンドポイントにアクセスしようとすると、「401 Authorization」というエラーが発生します。
        ミドルウェアは、トークンに要求されたリソースにアクセスするだけの十分なスコープがあるかを確認しません。
        
+
+## APIエンドポイントを保護する {{{ data-action="code" data-code="server.js#12:32" }}}
+
+
+
        有効なJWTを必須して個々のルートを保護するには、express-oauth2-jwt-bearerから構築されたcheckJwtミドルウェアでルートを構成します。
        特定のスコープを検索するために、個々のルートを構成することができます。これを実現するには、requiresScopeメソッドで別のミドルウェアをセットアップします。必要なスコープを提供し、認可を追加したいルートにミドルウェアを適用します。
        checkJwtとrequiredScopesミドルウェアを保護したいルートに渡します。
        この構成では、read:messagesスコープを持つアクセストークンのみがエンドポイントにアクセスすることができます。
        APIを呼び出す
        APIを呼び出すにはアクセストークンが必要です。テスト用のアクセストークンは、API設定の［Test（テスト）］ビューから取得することができます。
        null
        要求のAuthorizationヘッダーにアクセストークンを指定します。
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url http:///%7ByourDomain%7D/api_path \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///%7ByourDomain%7D/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///%7ByourDomain%7D/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///%7ByourDomain%7D/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///%7ByourDomain%7D/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///%7ByourDomain%7D/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///%7ByourDomain%7D/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "%7ByourDomain%7D/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///%7ByourDomain%7D/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///%7ByourDomain%7D/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Node JS API手順4「チェックポイント」 
        アプリケーションの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • GET /api/publicが認証を必要としない要求に使用できる。
        • GET /api/privateが認証された要求に使用できる。
        • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • トークンをAuthorizationヘッダーに含めて追加したことを確認します。
        • トークンに正しいスコープがあることを確認します。確認にはjwt.ioを使用します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..5a0ab723f3
--- /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..73c5831f3c
--- /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..9e408ca0f0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/interactive.md
@@ -0,0 +1,66 @@
+---
+title: PHPアプリケーションに認可を追加する
+description: このガイドは、Auth0 PHP SDKを使ってAuth0を統合し、トークンベースの認可の追加とアプリケーションルートの保護を行う方法について説明します。
+interactive:  true
+files:
+ - files/index
+ - files/router
+github:
+  path: app
+locale: ja-JP
+---
+
+# PHPアプリケーションに認可を追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽にトークンベースのエンドポイント認可を追加することができます。このガイドは、Auth0 PHP SDKを使ってAuth0を統合し、トークンベースの認可の追加とアプリケーションルートの保護を行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • Auth0に統合したいPHPプロジェクトを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに登録済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        APIを構成する
        同様に、Auth0 APIを新規作成するか、Dashboardから統合するプロジェクトを表す既存のAPIを使用する必要があります。APIに一意の識別子を選択して記録します。以下のアプリケーションを構成するには、その識別子が必要です。
        
+
+## Auth0 PHP SDKをインストールする {{{ data-action="code" data-code="index.php" }}}
+
+
+
        PHPアプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はPHP SDK（Auth0-PHP）を提供しています。
        Auth0 PHP SDKでは、ネットワーク要求を管理するために、PSR-17とPSR-18対応HTTPライブラリーをインストールする必要があります。ライブラリーがない場合は、ターミナルで以下のコマンドを実行して、信頼できる選択肢をインストールすることができます：
        cd <your-project-directory>
+
+    composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        ターミナルで以下のコマンドを実行してAuth0 PHP SDKをインストールします：
        composer require auth0/auth0-php
+
+
        
+
+
        Auth0 SDKを構成する
        SDKが正しく機能するためには、次のプロパティを初期化中にAuth0 SDKで設定しなければなりません：
        • strategy：アプリのユースケースでSDKの動作を導くのに役立ちます。この場合は、以下の定数に設定します。
          Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API
        • domain：Auth0テナントのドメインです。通常、Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合は、この値をカスタムドメインの値に設定してください。
        • clientId：このクイックスタートで前にセットアップした、Auth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認できます。
        • clientSecret：このクイックスタートで前にセットアップしたAuth0アプリケーションのシークレットです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client Secret（クライアントシークレット）］フィールドにあります。
        • audience：上で登録したAuth0 APIの識別子です。配列として指定されている必要があります。
        PHP API手順2「チェックポイント」 
        Auth0 SDKが正しく構成されました。アプリケーションを実行して次の点を確認します：
        • SDKが正しく初期化している。
        • アプリケーションがAuth0に関連したエラーを投入していない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します。
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ベアラートークンをリッスンする {{{ data-action="code" data-code="index.php#20:23" }}}
+
+
+
        次に、ベアラートークンを取得し処理するためにアプリケーションを拡張します。ベアラートークンはAPIに提供されるアクセストークンで、ユーザーに代わってクライアントから要求されます。アクセストークンは、アプリケーションでルートへのアクセスを承認または拒否します。これは、エンドポイント認可と呼ばれます。
        要求からアクセストークンを取得する最も簡単な方法は、PHP SDKのgetBearerToken()メソッドを使用するものです。このメソッドは、GETパラメーター、POST本文、要求ヘッダー、および他のソースからトークンを取得します。この場合、PHP SDKはtokenパラメーターのGET要求、またはHTTP Authorizationヘッダーから渡されたトークンを処理します。
        
+
+## ルートを作成・構成する {{{ data-action="code" data-code="router.php" }}}
+
+
+
        次に、受信する要求をアプリケーションにダイレクトするために、ルーティングライブラリーをインストールします。これは必須手順ではありませんが、本クイックスタートの目的上、アプリケーション構造が簡略化されます。
        composer require steampixel/simple-php-router
+
+
        
+
+
        アプリケーションでrouter.phpと呼ばれる新規ファイルを作成し、ルートを定義します。router.phpタブにある、右のインタラクティブパネルからコードをコピーします。
        
+
+## エンドポイント認可を構成する {{{ data-action="code" data-code="router.php#21:31" }}}
+
+
+
        Auth0アプリケーションとAuth0 PHP SDKを構成し、アプリケーションで要求からベアラートークンを取得したら、次の手順はプロジェクトにエンドポイント認可をセットアップすることです。上で実装したgetBearerToken()メソッドは、要求のアクセスに関する詳細を含むTokenクラスを返します。
        getBearerToken()メソッドは受信要求を自動的に検証・確認するため、アプリケーションはメソッドの応答を評価することで、アクセストークンの詳細を判定します。応答がnullの場合、提供される有効なトークンはありません。そうでない場合は、応答の内容を検査し、要求の詳細を確認してください。
        右のインタラクティブパネルで、応答がnullであるかどうかをチェックし、/api/privateルートへのアクセスをフィルターすることができます。
        
+
+## スコープで認可する {{{ data-action="code" data-code="router.php#33:48" }}}
+
+
+
        アクセストークンで要求されたスコープに基づいて、特定のルートへのアクセスをフィルターしたい場合もあるでしょう。右のインタラクティブパネルに示すように、getBearerToken()メソッドの応答から'scope'プロパティのコンテンツを評価し、アクセストークンで付与されたスコープをチェックします。
        
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..7d7c5c8bc9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/files/server.md
@@ -0,0 +1,55 @@
+---
+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..bda3edb8ca
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/files/validator.md
@@ -0,0 +1,28 @@
+---
+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..b9aa8e4a81
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,318 @@
+---
+title: Flask APIアプリケーションに認可を追加する
+description: このガイドは、Flaskを使ってビルドされた新規または既存のPython APIにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/validator
+ - files/server
+github:
+  path: 00-Starter-Seed
+locale: ja-JP
+---
+
+# Flask APIアプリケーションに認可を追加する
+
+
+
        このガイドは、Flaskを使ってビルドされた新規または既存のPython APIにAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、統合したいプロジェクトを表す既存のAPIを選択することができます。
        または、Auth0 Dashboardを使って初めてAPIをセットアップする方法を使用の開始ガイドで確認することもできます。
        Auth0にあるAPIはそれぞれAPI識別子を使って構成され、アプリケーションのコードはAPI識別子をオーディエンスとしてアクセストークンを検証します。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み出しアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［APIs］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        以下の例ではread:messagesスコープを使用します。
        
+
+## 依存関係をインストールする
+
+
+
        requirements.txtに次の依存関係を追加します：
        # /requirements.txt
+
+
+
+    flask
+
+    Authlib
+
+
        
+
+
        
+
+## JWTバリデーターを作成する {{{ data-action="code" data-code="validator.py" }}}
+
+
+
        Authlibという名前のライブラリーを使用して、ResourceProtectorを作成します。これはFlaskデコレーターの一種で、該当するバリデーターを使ってリソース（APIルート）を保護します。
        バリデーターは、リソースに渡すアクセストークンに有効な署名とクレームがあることを検証します。
        AuthLibのJWTBearerTokenValidatorバリデーターに多少の変更を加えて、アクセストークンの検証要件が満たされるようにします。
        Auth0JWTBearerTokenValidatorを作成するには、domainとaudience（API識別子）に渡すことが必要です。そうすると、トークンの署名を検証するのに必要な公開鍵が取得され、JWTBearerTokenValidatorクラスに渡されます。
        そして、クラスのclaims_optionsをオーバーライドし、トークンのexpiry、audience、issueクレームが要件を満たして有効であることを確認します。
        
+
+## Flaskアプリケーションを作成する {{{ data-action="code" data-code="server.py" }}}
+
+
+
        次に、3つのAPIルートを使ってFlaskアプリケーションを作成します。
        • /api/public：認証を必要としないパブリックエンドポイントです。
        • /api/private：有効なJWTアクセストークンを必要とするプライベートエンドポイントです。
        • /api/private-scoped：与えられたscopeを含む有効なJWTアクセストークンを必要とするプライベートエンドポイントです。
        保護されたルートにはrequire_authデコレーターがあり、これは、以前に作成したAuth0JWTBearerTokenValidatorを使用するResourceProtectorです。
        Auth0JWTBearerTokenValidatorを作成するには、テナントのドメインと以前に作成したAPIのAPI識別子に渡します。
        private_scopedルートのrequire_authデコレーターは、追加の引数である"read:messages"を受け付けます。これは、以前に作成したアクセス許可（スコープ）について、アクセストークンをチェックします。
        APIを呼び出す
        APIを呼び出すにはアクセストークンが必要です。テスト用のアクセストークンは、API設定の［Test（テスト）］ビューから取得することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［API］>［Specific API（特定のAPI］>［Test（テスト）］タブ
        要求のAuthorizationヘッダーにアクセストークンを指定します。
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
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/app/controllers/application_controller.md b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
new file mode 100644
index 0000000000..75520386ba
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/application_controller.md
@@ -0,0 +1,12 @@
+---
+name: app/controllers/application_controller.rb
+language: powershell
+---
+    
+```powershell
+    # frozen_string_literal: true
+
+    class ApplicationController < ActionController::API
+      include Secured
+    end
+```
diff --git a/ja-jp/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
new file mode 100644
index 0000000000..c6529ef19b
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/concerns/secured.md
@@ -0,0 +1,67 @@
+---
+name: app/controllers/concerns/secured.rb
+language: powershell
+---
+    
+```powershell
+    # 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/files/app/controllers/private_controller.md b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
new file mode 100644
index 0000000000..336740f6cd
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/private_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/private_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/app/controllers/public_controller.md b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
new file mode 100644
index 0000000000..f8a6db5aff
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/app/controllers/public_controller.md
@@ -0,0 +1,13 @@
+---
+name: app/controllers/public_controller.rb
+language: powershell
+---
+    
+```powershell
+    # 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/app/lib/auth0_client.md b/ja-jp/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
new file mode 100644
index 0000000000..079089b4d9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/app/lib/auth0_client.md
@@ -0,0 +1,66 @@
+---
+name: app/lib/auth0_client.rb
+language: powershell
+---
+    
+```powershell
+    # 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
+```
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..ddf93805d0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,338 @@
+---
+title: Ruby on Rails APIに認可を追加する
+description: このチュートリアルでは、カスタムAuth0Clientクラス内のjwt Gemを使って、アクセストークンの検証を実施します。
+interactive:  true
+files:
+ - files/app/controllers/application_controller
+ - files/app/lib/auth0_client
+ - files/app/controllers/concerns/secured
+ - files/app/controllers/public_controller
+ - files/app/controllers/private_controller
+github:
+  path: 01-Authentication-RS256
+locale: ja-JP
+---
+
+# Ruby on Rails APIに認可を追加する
+
+
+
        このチュートリアルでは、カスタムAuth0Clientクラス内のjwt Gemを使って、アクセストークンの検証を実施します。Securedと呼ばれるConcernを使って、受信アクセストークンからの認証を必要とするエンドポイントを認可します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、プロジェクトに既存のAPIを選択します。
        Auth0 Dashboardを使って初めてAPIをセットアップする場合には、使用の開始ガイドを確認してください。
        それぞれのAuth0 APIにはAPI識別子があり、アプリケーションにアクセストークンの検証で使用されます。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み出しアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［APIs］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        以下の例ではread:messagesスコープを使用します。
        
+
+## 依存関係をインストールする
+
+
+
        jwt Gemをインストールします。
        gem 'jwt'
+
+    bundle install
+
+
        
+
+
        
+
+## Auth0Clientクラスを作成する {{{ data-action="code" data-code="app/controllers/concerns/secured.rb" }}}
+
+
+
        Auth0Clientと呼ばれるクラスを作成します。このクラスは要求のAuthorizationヘッダーから得た受信アクセストークンをデコードし検証します。
        Auth0ClientクラスはAuth0テナントの公開鍵を取得し、これを使ってアクセストークンの署名を検証します。Token構造体はvalidate_permissionsメソッドを定義し、必要なスコープの配列を指定してアクセストークン内の特定のscopeを検索し、トークンのペイロードに存在するかを確認します。
        
+
+## Secured concernを定義する {{{ data-action="code" data-code="app/controllers/concerns/secured.rb" }}}
+
+
+
        受信要求のAuthorizationヘッダー内でアクセストークンを検索するSecuredと呼ばれるConcernを作成します。
        トークンが存在する場合、Auth0Client.validate_tokenはjwt Gemを使用してトークンの署名を確認し、トークンのクレームを検証します。
        Concernには、アクセストークンが有効であることを検証するほか、トークンに要求されたリソースにアクセスするのに十分なスコープがあることを確認するためのメカニズムも整備されています。この例では、Auth0ClientクラスからToken.validate_permissionsメソッドを呼び出すことで、ブロックを受け取りアクセス許可を確認するvalidate_permissionsメソッドを定義します。
        /private-scopedルートでは、定義されたスコープはペイロードに入ってくるスコープと交差され、別の配列から1つ以上の項目が含まれているかを判定します。
        
+
+## ApplicationControllerにSecure concernを含める {{{ data-action="code" data-code="app/controllers/application_controller.rb" }}}
+
+
+
        アプリケーションコントローラーにSecure concernを追加すると、認可を必要とするコントローラーでbefore_actionフィルターのみを使用すればよいことになります。
        
+
+## パブリックエンドポイントを作成する {{{ data-action="code" data-code="app/controllers/public_controller.rb" }}}
+
+
+
        パブリックエンドポイント/api/publicを処理するようにコントローラーを作成します。
        /publicエンドポイントでは認可は必要でないため、before_actionは必要ありません。
        
+
+## プライベートエンドポイントを作成する {{{ data-action="code" data-code="app/controllers/private_controller.rb" }}}
+
+
+
        /api/privateと/api/private-scopedというプライベートエンドポイントを処理するようにコントローラーを作成します。
        /api/privateは、追加スコープのないアクセストークンを含む認証された要求に使用することができます。
        /api/private-scopedは、read:messagesスコープが付与されたアクセストークンを含む認証された要求に使用することができます。
        保護されたエンドポイントはSecured concernからauthorizeメソッドを呼び出す必要があります。そのためには、before_action :authorizeを使用します。これによって、Secured.authorizeメソッドがPrivateControllerの各アクションの前に呼び出されます。
        APIを呼び出す
        APIを呼び出すにはアクセストークンが必要です。テスト用のアクセストークンは、API設定の［Test（テスト）］ビューから取得することができます。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［API］>［Specific API（特定のAPI］>［Test（テスト）］タブ
        要求のAuthorizationヘッダーにアクセストークンを指定します。
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request get \
+
+  --url 'http:///${account.namespace}/api_path' \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
        var client = new RestClient("http:///${account.namespace}/api_path");
+
+var request = new RestRequest(Method.GET);
+
+request.AddHeader("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "http:///${account.namespace}/api_path"
+
+
+
+ req, _ := http.NewRequest("get", url, nil)
+
+
+
+ req.Header.Add("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.get("http:///${account.namespace}/api_path")
+
+  .header("authorization", "Bearer YOUR_ACCESS_TOKEN_HERE")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'get',
+
+  url: 'http:///${account.namespace}/api_path',
+
+  headers: {authorization: 'Bearer YOUR_ACCESS_TOKEN_HERE'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"authorization": @"Bearer YOUR_ACCESS_TOKEN_HERE" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http:///${account.namespace}/api_path"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"get"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "http:///${account.namespace}/api_path",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "get",
+
+  CURLOPT_HTTPHEADER => [
+
+    "authorization: Bearer YOUR_ACCESS_TOKEN_HERE"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPConnection("")
+
+
+
+headers = { 'authorization': "Bearer YOUR_ACCESS_TOKEN_HERE" }
+
+
+
+conn.request("get", "/${account.namespace}/api_path", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+
+
+url = URI("http:///${account.namespace}/api_path")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+
+
+request = Net::HTTP::Get.new(url)
+
+request["authorization"] = 'Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["authorization": "Bearer YOUR_ACCESS_TOKEN_HERE"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "http:///${account.namespace}/api_path")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "get"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        Ruby on rails手順7「チェックポイント」 
        アプリケーションの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • GET /api/publicが認証を必要としない要求に使用できる。
        • GET /api/privateが認証された要求に使用できる。
        • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • トークンをAuthorizationヘッダーに含めて追加したことを確認します。
        • トークンに正しいスコープがあることを確認します。確認にはjwt.ioを使用します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/ApiController.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/ApiController.md
new file mode 100644
index 0000000000..f2c2cd153e
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/ApiController.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."
+        });
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.md
new file mode 100644
index 0000000000..f15111e01b
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/OpenIdConnectSigningKeyResolver.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) };
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.md
new file mode 100644
index 0000000000..6d78b4041a
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/ScopeAuthorizeAttribute.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);
+    }
+}
+```
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..015db9db1d
--- /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);
+}
+```
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..ab14fd0fd0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/interactive.md
@@ -0,0 +1,58 @@
+---
+title: ASP.NET OWIN Web APIアプリケーションに認可を追加する
+description: このチュートリアルは、標準のJWTミドルウェアを使ってASP.NET OWIN APIアプリケーションに認可を追加する方法を説明します。
+interactive:  true
+files:
+ - files/Startup
+ - files/OpenIdConnectSigningKeyResolver
+ - files/ScopeAuthorizeAttribute
+ - files/ApiController
+github:
+  path: Quickstart/Sample
+locale: ja-JP
+---
+
+# ASP.NET OWIN Web APIアプリケーションに認可を追加する
+
+
+
        Auth0を使用すると、アプリケーションに認可を追加することができます。このガイドは、新規または既存のASP.NET Owin Web APIアプリケーションにMicrosoft.Owin.Security.Jwtパッケージを使ってAuth0を統合する方法を説明します。
        Auth0 DashboardでAPIをまだ作成していない場合は、対話型のセレクターを使ってAuth0 APIを新規作成します。そうでない場合は、プロジェクトに既存のAPIを選択することができます。
        Auth0 Dashboardを使って初めてAPIをセットアップする場合には、使用の開始ガイドを確認してください。
        それぞれのAuth0 APIにはAPI識別子があり、アプリケーションにアクセストークンの検証で使用されます。
        Auth0を初めてご利用ですか？Auth0の仕組みと、OAuth 2.0フレームワークを用いたAPI認証と認可の実装について説明します。
        
+
+## アクセス許可を定義する
+
+
+
        アクセス許可は、ユーザーの代わりに、提供されたアクセストークンを使ってどのようにしてリソースにアクセスできるのかを定義できるようにします。たとえば、ユーザーがマネージャーアクセスレベルを持つ場合には、messagesリソースに対して読み取りアクセスを付与し、管理者アクセスレベルを持つ場合には、書き込みアクセスを付与することができます。
        Auth0 Dashboardの［API］セクションにある［Permissions（権限）］ビューで使用可能なアクセス許可を定義することができます。以下の例ではread:messagesスコープを使用します。
        ［Auth0 Dashboard］>［Applications（アプリケーション）］>［APIs］>［Specific API（特定のAPI］>［Permissions（権限）］タブ
        
+
+## 依存関係をインストールする
+
+
+
        Microsoft.Owin.Security.Jwt NuGetパッケージをインストールします。このパッケージには、Auth0のアクセストークンをASP.NET Owin Web APIで使用するために必要なOWIN JWTミドルウェアが含まれています。
        Install-Package Microsoft.Owin.Security.Jwt
+
+
        
+
+
        
+
+## ミドルウェアを構成する {{{ data-action="code" data-code="Startup.cs" }}}
+
+
+
        StartupクラスのConfigurationメソッドに移動し、構成したJwtBearerAuthenticationOptionsを渡してUseJwtBearerAuthenticationの呼び出しを追加します。
        JwtBearerAuthenticationOptionsでは、Auth0 API識別子をValidAudienceプロパティで指定し、Auth0ドメインへのフルパスをValidIssuerとして指定する必要があります。OpenIdConnectSigningKeyResolverのインスタンスを使用するようにIssuerSigningKeyResolverを構成して、署名鍵を解決できるようにします。
        末尾のスラッシュを忘れてはいけません。
        ValidIssuerに指定したURLの末尾にフォワードスラッシュ（/）があることを必ず確認してください。これは、JWTの発行者クレームと一致しなければなりません。この値の構成を誤ると、APIの呼び出しが正しく認証されません。
        
+
+## トークンの署名を検証する {{{ data-action="code" data-code="OpenIdConnectSigningKeyResolver.cs" }}}
+
+
+
        OWINのJWTミドルウェアはOpen ID Connect Discoveryをデフォルトでは使用しないため、カスタムのIssuerSigningKeyResolverを提供する必要があります。
        OpenIdConnectSigningKeyResolverクラスを作成し、GetSigningKeyを実装して、正しいSecurityKeyが返されることを確認します。このクラスは、Startup.csでミドルウェアを構成する際に、TokenValidationParameters.IssuerSigningKeyResolverとして使用されます。
        
+
+## スコープを検証する {{{ data-action="code" data-code="ScopeAuthorizeAttribute.cs" }}}
+
+
+
        JWTミドルウェアは、要求に含まれたアクセストークンが有効であることを検証しますが、現時点では、トークンが要求されたリソースへのアクセスに十分なscopeを持っているのかを確認する手段はありません。
        System.Web.Http.AuthorizeAttributeを継承するScopeAuthorizeAttributeという名前のクラスを作成してください。この属性はAuth0テナントが発行したscopeクレームが存在することを確認し、存在する場合には、scopeクレームが要求されたスコープを含んでいることを確認します。
        
+
+## APIエンドポイントを保護する {{{ data-action="code" data-code="ApiController.cs" }}}
+
+
+
        以下に示されたルートは次の要求で使用することができます：
        • GET /api/public：認証を必要としない要求に使用することができます。
        • GET /api/private：追加スコープのないアクセストークンを含む認証された要求に使用することができます。
        • GET /api/private-scoped：read:messagesスコープが付与されたアクセストークンを含む認証された要求に使用することができます。
        JWTミドルウェアは標準のASP.NETの認証および認可メカニズムと統合できるため、コントローラーのアクションを[Authorize]属性で装飾するだけで、エンドポイントのセキュリティを確保できます。
        アクションをScopeAuthorize属性で更新し、必要なscopeの名前をscopeパラメーターに渡します。これにより、特定のAPIエンドポイントを呼び出すために、正しいスコープが利用できることが確実になります。
        ASP.NET API OWINクイックスタート - 手順6「チェックポイント」 
        アプリケーションの構成が完了したら、アプリケーションを実行して次の点を検証します：
        • GET /api/public が認証を必要としない要求に使用できる。
        • GET /api/private が認証された要求に使用できる。
        • GET /api/private-scoped がread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • ValidIssuerとValidAudienceの値が正しく構成されていることを確認します。
        • トークンをAuthorizationヘッダーに含めて追加したことを確認します。
        • トークンに正しいスコープがあることを確認します。確認にはjwt.ioを使用します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/snippets/application-platforms/emberjs/use.md b/ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
similarity index 100%
rename from snippets/application-platforms/emberjs/use.md
rename to ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
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/files/exchangeTokens.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
new file mode 100644
index 0000000000..c2593142a7
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/exchangeTokens.md
@@ -0,0 +1,26 @@
+---
+name: exchangeTokens
+language: kotlin
+---
+    
+```kotlin
+private fun exchangeTokens(
+        sessionToken: String,
+        userProfile: String,
+        callback: SimpleCallback
+    ) {
+        val params = mapOf("user_profile" to userProfile)
+        apiClient.loginWithNativeSocialToken(sessionToken, FACEBOOK_SUBJECT_TOKEN_TYPE)
+            .setScope(AUTH0_SCOPE)
+            .addParameters(params)
+            .start(object : Callback {
+                override fun onFailure(error: AuthenticationException) {
+                    callback.onError(error)
+                }
+
+                override fun onSuccess(result: Credentials) {
+                    callback.onResult(result)
+                }
+            })
+    }
+```
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
new file mode 100644
index 0000000000..24232d1f4c
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchSessionToken.md
@@ -0,0 +1,35 @@
+---
+name: fetchSessionToken
+language: kotlin
+---
+    
+```kotlin
+private fun fetchSessionToken(token: String, callback: SimpleCallback) {
+        val params = Bundle().apply {
+            putString("grant_type", "fb_attenuate_token")
+            putString("fb_exchange_token", token)
+            putString("client_id", getString(R.string.facebook_app_id))
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = "oauth/access_token"
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            if (response.error != null) {
+                callback.onError(response.error?.exception!!)
+                return@Callback
+            }
+
+            try {
+                val fbSessionToken = response.jsonObject!!.getString("access_token")
+                callback.onResult(fbSessionToken)
+            } catch (jsonException: JSONException) {
+                //Failed to parse session token
+                callback.onError(jsonException)
+            }
+        }
+        request.executeAsync()
+    }
+```
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
new file mode 100644
index 0000000000..d54981f1d4
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/fetchUserProfile.md
@@ -0,0 +1,32 @@
+---
+name: fetchUserProfile
+language: kotlin
+---
+    
+```kotlin
+private fun fetchUserProfile(token: String, userId: String, callback: SimpleCallback) {
+
+        val params = Bundle().apply {
+            putString("access_token", token)
+            putString("fields", "first_name,last_name,email")
+        }
+
+        val request = GraphRequest().apply {
+            parameters = params
+            graphPath = userId
+        }
+
+        request.callback = GraphRequest.Callback { response ->
+            val error = response.error
+            if (error != null) {
+                //Failed to fetch user profile
+                callback.onError(error.exception!!)
+                return@Callback
+            }
+            //Handle back the profile as received
+            callback.onResult(response.rawResponse!!)
+        }
+
+        request.executeAsync()
+    }
+```
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/files/onCreate.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/onCreate.md
new file mode 100644
index 0000000000..1102e17fb5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/onCreate.md
@@ -0,0 +1,41 @@
+---
+name: onCreate
+language: kotlin
+---
+    
+```kotlin
+override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+
+        FacebookSdk.setClientToken(getString(R.string.facebook_client_token))
+        FacebookSdk.sdkInitialize(this)
+
+        setContentView(R.layout.activity_login)
+
+        val auth0 =
+            Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain))
+        apiClient = AuthenticationAPIClient(auth0)
+
+        fbCallbackManager = CallbackManager.Factory.create()
+
+        val loginButton = findViewById(R.id.login_button).apply {
+            setPermissions(*FACEBOOK_PERMISSIONS)
+        }
+
+        loginButton.registerCallback(fbCallbackManager, object : FacebookCallback {
+            override fun onSuccess(result: LoginResult) {
+
+                val accessToken = result.accessToken
+                performLogin(accessToken)
+            }
+
+            override fun onCancel() {
+                Log.i(TAG, "Facebook sign-in cancelled")
+            }
+
+            override fun onError(error: FacebookException) {
+                Log.e(TAG, "Error {error.message}")
+            }
+        })
+    }
+```
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md
new file mode 100644
index 0000000000..6645fdf0d8
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin + SimpleCallback.md	
@@ -0,0 +1,12 @@
+---
+name: performLogin + SimpleCallback
+language: kotlin
+---
+    
+```kotlin
+private interface SimpleCallback {
+  fun onResult(result: T)
+
+  fun onError(cause: Throwable)
+}
+```
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin.md b/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin.md
new file mode 100644
index 0000000000..84a6251bd1
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/files/performLogin.md
@@ -0,0 +1,41 @@
+---
+name: performLogin
+language: kotlin
+---
+    
+```kotlin
+private fun performLogin(accessToken: AccessToken) {
+        val token = accessToken.token
+        fetchSessionToken(token, object : SimpleCallback {
+            override fun onResult(sessionToken: String) {
+                //2. Obtained the Facebook session token
+                fetchUserProfile(token, accessToken.userId, object : SimpleCallback {
+                    override fun onResult(userProfile: String) {
+                        //3. Obtained the user profile
+                        exchangeTokens(
+                            sessionToken,
+                            userProfile,
+                            object : SimpleCallback {
+                                override fun onResult(credentials: Credentials) {
+                                    //4. Exchanged the tokens
+                                    Log.i(TAG, "Logged in to Auth0")
+                                }
+
+                                override fun onError(cause: Throwable) {
+                                    Log.e(TAG, "Error exchanging tokens", cause)
+                                }
+                            })
+                    }
+
+                    override fun onError(cause: Throwable) {
+                        Log.e(TAG, "Error fetching the profile", cause)
+                    }
+                })
+            }
+
+            override fun onError(cause: Throwable) {
+                Log.e(TAG, "Error fetching the session token", cause)
+            }
+        })
+    }
+```
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..c4db748f26
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/index.yml
@@ -0,0 +1,55 @@
+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
+hidden_articles:
+  - interactive
+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-facebook-login/interactive.md b/ja-jp/articles/quickstart/native/android-facebook-login/interactive.md
new file mode 100644
index 0000000000..286877e3b5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/interactive.md
@@ -0,0 +1,127 @@
+---
+title: Android - Facebookログイン
+description: このチュートリアルは、ネイティブFacebookログインを使用して、Androidアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/performLogin + SimpleCallback
+ - files/onCreate
+ - files/fetchSessionToken
+ - files/fetchUserProfile
+ - files/exchangeTokens
+ - files/performLogin
+github:
+  path: 00-login-facebook
+locale: ja-JP
+---
+
+# Android - Facebookログイン
+
+
+
        このチュートリアルは、ネイティブFacebookログインを使用して、Androidアプリケーションにユーザーログインを追加する方法について説明します。ログインして、アカウント用に構成された例を参考にして、このクリックスタートに従うことをお勧めします。
        システム要件
        • Android Studio 3.6.1
        • Android SDK 25
        • Emulator - Nexus 5X - Android 6.0
        このチュートリアルは、Facebook SDKでログインを実装する方法について説明します。​
        始める前に
        • FacebookログインSDKをインストールして構成します。https://developers.facebook.comでFacebookアプリの作成プロセスも行います。この手順が終了したら、Facebookログインが統合された状態でモバイルアプリが稼働しているはずです。
        DashboardでFacebookネイティブサインインを使用するようにAuth0アプリケーションを構成します。「Facebookログインをネイティブアプリに追加する」を参照してください。この手順が終了したら、アプリケーションはFacebookネイティブログインを実装できるようになります。
        
+
+## Facebookのアクセス許可を要求する
+
+
+
        アプリケーションでは既にFacebookでサインインすることができますが、リッチユーザープロファイルを確保するには、Facebookログインボタンがセットアップされたアクセス許可を更新する必要があります。
        要求されたアクセス許可をpublic_profileとemailに設定します。これで、アクセス要求がユーザーによって受け入れられたという前提で、ユーザーメールも応答の一部に含まれます。
        loginButton.setPermissions(Arrays.asList("public_profile", "email"));
        
+
+## performLoginメソッドを作成する {{{ data-action="code" data-code="performLogin + SimpleCallback" }}}
+
+
+
        次に、Auth0で認証プロセスを始めるために、送信するペイロードの準備を行う新しいメソッドを作成します。
        内部コールバックを処理するために、小さなインターフェイスを利用します。
        サンプルでは、メソッドの名前はperformLogin、インターフェイスの名前はSimpleCallbackに指定されています。両方を追加してください。
        
+
+## performLoginメソッドを呼び出す {{{ data-action="code" data-code="onCreate" }}}
+
+
+
        次に、FacebookログインのコールバックのonSuccessメソッドから特定のメソッドを呼び出します。
        
+
+## Facebookを統合する
+
+
+
        Auth0でFacebookを使ってサインインすると、バックエンドはユーザーが主張する通りの本人であることを確認するために、バックグラウンドで確認作業を実施します。これを実現するには、セッションアクセストークンを提供する必要があります。
        さらに、このFacebookユーザーを表すために、ユーザーをAuth0で作成する必要がある場合、バックエンドでは姓名やメールなどの一部の情報が必要になります。Auth0ユーザープロファイルでは、メールは（提供された場合）未検証としてフラグが付けられます。
        セッションアクセストークンとユーザープロファイルを取得するには、Facebook APIに対してさらに2つの要求を行う必要があります。
        
+
+## Facebookセッションアクセストークンを取得する {{{ data-action="code" data-code="fetchSessionToken" }}}
+
+
+
        Facebook APIの/oauth/access_tokenエンドポイントに対して新しいGET要求を行います。以下のクエリパラメーターを使用します：
        • grant_type: fb_attenuate_token。
        • fb_exchange_token：ログイン時に受け取るアクセストークンです。
        • client_id：アプリIDです。この値は、Facebook開発者のダッシュボードから取得したもので、Facebookログインの統合に成功している場合は、アプリケーションで既に使用されているはずです。
        この手順で得たロジックを独自のメソッドに投入します。これを前に追加したメソッドから後で呼び出します。
        サンプルはFacebook SDKのGraphRequestクラスを使用して、この要求を実行します。
        
+
+## Facebookのユーザープロファイルを取得する {{{ data-action="code" data-code="fetchUserProfile" }}}
+
+
+
        上の手順と同様に、別のGET要求を行います。エンドポイントパスは、Facebookログイン結果から得たユーザーID値（/904636746222815など）になります。次のパラメーターを使用します：
        • access_token：ログイン時に受け取るアクセストークンです。
        • fields：応答で取得したいユーザープロファイルからのフィールドです。これらは、初めに構成されたFacebookログインボタンのアクセス許可に直接関連付けられています。アクセス許可が任意の場合、ユーザーはまずアクセス許可を付与することに同意する必要があります。Auth0でユーザーをサインアップするには、フルネームとメールを入力するだけで十分です。
        
+
+## Auth0を統合する
+
+
+
        必要なアーティファクトを取得したら、IDやアクセストークンなどAuth0のユーザー資格情報に交換する準備ができました。しかしまず、その最後の要求を行うためにAuth0 SDKをセットアップする必要があります。
        アプリケーションキーを取得する
        1. Auth0 Dashboardの［Applications（アプリケーション）］セクションで、［Sign in with Facebook（Facebookでサインイン）］を有効にした既存のアプリケーションを選択します。この手順で不明な点があれば、この記事の上に記載された要件セクションを確認してください。
        2. アプリケーションの設定ページから［Domain（ドメイン）］と［Client ID（クライアントID）］の値をコピーします。これらはSDKで必要です。
        3. Androidアプリケーションのstrings.xmlファイルで2つの新しいリソースを作成して保存します。キーの名前は以下で使用するキーと一致しなければなりません。
          <resources>
+
+    <string name="com_auth0_domain">${account.namespace}</string>
+
+    <string name="com_auth0_client_id">${account.clientId}</string>
+
+</resources>
+
+
          
+
+
        Auth0 SDKをインストールする
        Androidアプリケーションで、この行をapp/build.gradleファイルに追加します：
        dependencies {
+
+    implementation 'com.auth0.android:auth0:1.+'
+
+}
+
+
        
+
+
        次に、Gradle Syncタスクを実行し、プロジェクトとその依存関係を更新します。
        Web認証のマニフェストを更新する
        アプリケーションがSDKによって提供されるWeb認証モジュールを利用する予定がない場合は、未使用のアクティビティをAndroidManifest.xmlファイルから削除し、マニフェストのプレースホルダー問題を防ぐ必要があります。これを実現するには、アクティビティの宣言を追加し、tools:node="remove"の注釈を加えます。
        <application>
+
+  <!-- Add the activity declaration line below -->
+
+   <activity
+
+    android:name="com.auth0.android.provider.AuthenticationActivity"
+
+    tools:node="remove" />
+
+
+
+</application>
+
+
        
+
+
        ただし、Web認証をサポートする予定の場合は、ここでマニフェストのプレースホルダーを宣言する方法を確認してください。
        
+
+## 受け取ったデータをAuth0トークンに交換する {{{ data-action="code" data-code="exchangeTokens" }}}
+
+
+
        SDKは、使用する前にインスタンス化する必要があります。クラスレベルでフィールドを定義し、onCreateメソッドで初期化します。上の手順で定義した資格情報がAuth0コンストラクターに渡されたら、AuthenticationAPIClientの新しいインスタンスが作成されます。
        private AuthenticationAPIClient auth0Client;
+
+
+
+@Override
+
+public void onCreate(Bundle savedInstanceState) {
+
+    super.onCreate(savedInstanceState);
+
+
+
+    setContentView(R.layout.activity_login);
+
+
+
+    Auth0 account = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+
+    auth0Client = new AuthenticationAPIClient(account);
+
+
+
+    //...
+
+}
+
+
        
+
+
        ロジックを維持するメソッドを作成し、取得した2つのアーティファクトをAuth0のユーザー資格情報に交換します。サンプルでは、このメソッドの名前はexchangeTokensです。
        APIクライアントは、トークンとサブジェクトタイプを受け取るloginWithNativeSocialTokenメソッドを宣言します。前者はセッショントークンに対応し、後者はバックエンドが認証しようとする接続のタイプを示します。
        ネイティブFacebookログインでは、以下の値を使用します："http://auth0.com/oauth/token-type/facebook-info-session-access-token"
        構成する必要がある他の値は、ユーザープロファイル（user_profileキーを使用）とAuth0トークンに含まれる要求されたスコープです。
        変化しないことを把握している値はすべて、クラスの上部で定数として維持しておくと便利です。サンプルは、件名トークンタイプ、Facebookのアクセス許可、およびAuth0のスコープに対して定数を利用します。Auth0のスコープの詳細については、特集記事をお読みください。
        
+
+## performLoginメソッドを更新する {{{ data-action="code" data-code="performLogin" }}}
+
+
+
        すべての手順が独自のメソッドで定義されたら、performLoginメソッドに全部まとめて入れましょう。
        すべて正常に実行されると、FacebookログインSDKでネイティブ認証ができるようになります。つまり、Facebookアプリがデバイスにインストールされていると、認証はブラウザーアプリでなくアプリケーションを介して処理されます。
        
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/MainActivity.md b/ja-jp/articles/quickstart/native/android/files/MainActivity.md
new file mode 100644
index 0000000000..2e476f1606
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/MainActivity.md
@@ -0,0 +1,78 @@
+---
+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
+        }
+      })
+  }
+}
+```
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..949546a282
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/build.md
@@ -0,0 +1,26 @@
+---
+name: build.gradle
+language: javascript
+---
+    
+```javascript
+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.+'
+}
+```
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..b83b0540e1
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/strings.md
@@ -0,0 +1,11 @@
+---
+name: strings.xml
+language: 
+---
+    
+```
+
+    "${account.namespace}"
+    "${account.clientId}"
+
+```
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..fe357d30ae
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/interactive.md
@@ -0,0 +1,78 @@
+---
+title: Androidアプリケーションにログインを追加する
+description: このガイドでは、AndroidアプリケーションにAuth0 Android SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/build
+ - files/strings
+ - files/MainActivity
+github:
+  path: 00-Login-Kt
+locale: ja-JP
+---
+
+# Androidアプリケーションにログインを追加する
+
+
+
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに認証を構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0によって認証後のユーザーをダイレクトするアプリケーションURLです。この値を設定していない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、demo://{yourDomain}/android/YOUR_APP_PACKAGE_NAME/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0によってログアウト後のユーザーをリダイレクトするアプリケーションURLです。この値を設定していない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、demo://{yourDomain}/android/YOUR_APP_PACKAGE_NAME/callbackに設定してください。
        
+
+## Auth0 Android SDKをインストールする {{{ data-action="code" data-code="build.gradle#18:18" }}}
+
+
+
        Auth0 Android SDKをプロジェクトに追加します。ライブラリーはAuth0のAuthentication APIとManagement APIに要求を行います。
        アプリのbuild.gradle依存関係セクションで、以下を追加します。
        implementation 'com.auth0.android:auth0:2. '
+
+
        
+
+
        AndroidとKotlinのプラグインのそれぞれに対して、Java 8+バイトコードをターゲットにするようにします。
        
+
+## マニフェストのプレースホルダーを追加する {{{ data-action="code" data-code="build.gradle#10:12" }}}
+
+
+
        SDKにはマニフェストのプレースホルダーが必要です。Auth0は内部でプレースホルダーを使用して、認証のCallback URLを捉えるintent-filterを定義します。Auth0テナントのドメインとCallback URLスキームを設定する必要があります。
        アクティビティーに特別なintent-filterを宣言する必要はありません。これは、マニフェストのプレースホルダーをAuth0ドメインとスキームの値で定義したため、ライブラリーがリダイレクトを処理します。
        ここでは、auth0Schemeにdemoの値を使用したため、カスタムURLスキームをログイン後にAuth0がリダイレクトするURLに使用することができます。Androidアプリのリンクを使用したい場合は、httpsを使用する方法もあります。この値の設定に関する詳細情報は、Auth0.Android SDKのREADMEをお読みください。
        
+
+## アプリケーションを構成する {{{ data-action="code" data-code="strings.xml#2:3" }}}
+
+
+
        SDKが正しく機能するためには、次のプロパティをstrings.xmlで設定しなければなりません：
        • com_auth0_domain：Auth0テナントのドメインです。通常、Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合は、その値を代わりに設定してください。
        • com_auth0_client_id：このクイックスタートで前にセットアップしたAuth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認できます。
        AndroidManifest.xmlファイルがandroid.permissions.INTERNETのアクセス許可を指定していることを確認します。
        <uses-permission android:name="android.permission.INTERNET" />
+
+
        
+
+
        Android Studio内でSync Project with Gradle Filesを実行するか、コマンドラインから./gradlew clean assembleDebugを実行します。
        Gradleの使用に関する詳細は、Gradleの公式のドキュメンテーションを確認してください。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="MainActivity.kt#6:38" }}}
+
+
+
        アプリケーションに認証をセットアップするには、ユニバーサルログインが最も手軽な方法です。最良のエクスペリエンス、高い安全性、幅広い機能を活用するためにも、ユニバーサルログインの使用をお勧めします。
        onCreateメソッドで、Auth0クラスの新しいインスタンスを作成し、ユーザー資格情報を保持します。
        loginWithBrowserメソッドを作成し、WebAuthProviderクラスを使用して、Auth0 Dashboardのアプリケーションで有効にした接続で認証します。ここでは、初期設定の一部としてauth0Schemeマニフェストのプレースホルダーで使用されたスキーム値を渡すことができます。
        WebAuthProvider#start関数を呼び出した後、ブラウザーが起動し、ログインページが表示されます。ユーザーが認証を行うと、Callback URLが呼び出されます。Callback URLには、認証プロセスの最終結果が含まれています。
        Androidクイックスタート手順5「チェックポイント」 
        loginWithBrowserを呼び出すアプリケーションにボタンを追加します。このボタンをクリックすると、AndroidアプリケーションによってAuth0ユニバーサルログインページにリダイレクトされ、ユーザー名とパスワードまたはソーシャルプロバイダーを使ってログインまたはサインアップできるようになったことを確認します。
        完了したら、Auth0がアプリにリダイレクトで戻すことを確認します。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • 設定した［Allowed Callback URLs（許可されているCallback URL）］が正しいことを確認します
        • URLを入力した後で保存したことを確認します
        • ドメインとクライアントIDの値が正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainActivity.kt#40:52" }}}
+
+
+
        WebAuthProviderを使用して、認証時にブラウザーで設定されたクッキーを削除すると、ユーザーは次回の認証試行時に、資格情報を再入力するよう求められます。
        logoutメソッドをアプリに追加してユーザーのセッションを削除し、アプリからログアウトします。ここでは、初期設定の一部としてauth0Schemeマニフェストのプレースホルダーで使用されたスキーム値を渡すことができます。
        WebAuthProviderクラスを使用して、ログアウトを実装します。この呼び出しによってブラウザーが開き、ユーザーはログアウトエンドポイントに移動されます。ユーザーがログアウトをキャンセルする場合は、ユーザーを前のURLにリダイレクトすることを検討してください。
        Androidクイックスタート手順6「チェックポイント」 
        logoutを呼び出し、ユーザーをアプリケーションからログアウトするアプリにボタンを追加します。このボタンをクリックすると、Androidアプリがユーザーをログアウトページにリダイレクトしてからもう一度リダイレクトで戻すこと、そして、アプリケーションにログインしていないことを確認します。
        
+
+  
        
+
+  
        アプリケーションが正常にログアウトしなかった場合は以下を行います。
        • ［Allowed Logout URLs（許可されているログアウトURL）］が正しく設定されていることを確認します
        • URLを入力した後で保存したことを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="MainActivity.kt#54:70" }}}
+
+
+
        AuthenticationAPIClientクラスを使用して、Auth0からユーザーのプロファイルを取得します。これには以下のものが必要です。
        • ログインフェーズから返されるアクセストークン
        • WebAuthProvider.loginにprofileスコープが含まれる必要がある
        ユーザーのメールアドレスを取得する必要がある場合は、emailスコープを指定する必要があります。
        このクイックスタートで、上のログイン手順中にデフォルトでopenid profile emailスコープが設定されます。
        以下に、ユーザーのプロファイルを取得して画面上に表示するために使用できる関数を示します。
        Androidクイックスタート手順7「チェックポイント」 
        ログイン後にshowUserProfile関数を呼び出します。onSuccessコールバックがユーザーのプロファイル情報を返すことを確認します。
        
+
+  
        
+
+  
        アプリケーションがユーザープロファイル情報を返さなかった場合には以下を行います。
        • accessToken が有効であることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..172b69189f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/device/index.yml
@@ -0,0 +1,26 @@
+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
+hidden_articles:
+  - "interactive"
+show_steps: false
diff --git a/ja-jp/articles/quickstart/native/device/interactive.md b/ja-jp/articles/quickstart/native/device/interactive.md
new file mode 100644
index 0000000000..4a167ce153
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/device/interactive.md
@@ -0,0 +1,559 @@
+---
+title: デバイス認可フロー
+description: このチュートリアルでは、デバイス認可フローを使用して、入力に制約のあるデバイスからAPIを呼び出す方法について説明します。
+interactive:  true
+
+locale: ja-JP
+---
+
+# デバイス認可フロー
+
+
+
        このチュートリアルでは、デバイス認可フローを使用して、入力に制約のあるデバイスからAPIを呼び出す方法について説明します。 ログインして、アカウント用に構成された例を参考にこのクイックタートに従うことをお勧めします。
        対話型のエクスペリエンスには、Device Flow Playgroundを使用することができます。
        前提条件
        
+
+## デバイスコードを要求する
+
+
+
        ユーザーがデバイスアプリケーションを起動して、それを認可したい場合には、アプリケーションがAuth0 Authentication APIからのデバイスコードを要求して、ユーザーのセッションに関連付けなければなりません。
        デバイスコードを取得するには、アプリケーションがAuthentication APIのデバイス認可フローで認証エンドポイントを呼び出す必要があります：
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        curl --request post \
+
+  --url 'https://${account.namespace}/oauth/device/code' \
+
+  --header 'content-type: application/x-www-form-urlencoded'
        var client = new RestClient("https://${account.namespace}/oauth/device/code");
+
+var request = new RestRequest(Method.POST);
+
+request.AddHeader("content-type", "application/x-www-form-urlencoded");
+
+IRestResponse response = client.Execute(request);
        package main
+
+
+
+import (
+
+ "fmt"
+
+ "net/http"
+
+ "io/ioutil"
+
+)
+
+
+
+func main() {
+
+
+
+ url := "https://${account.namespace}/oauth/device/code"
+
+
+
+ req, _ := http.NewRequest("post", url, nil)
+
+
+
+ req.Header.Add("content-type", "application/x-www-form-urlencoded")
+
+
+
+ res, _ := http.DefaultClient.Do(req)
+
+
+
+ defer res.Body.Close()
+
+ body, _ := ioutil.ReadAll(res.Body)
+
+
+
+ fmt.Println(res)
+
+ fmt.Println(string(body))
+
+
+
+}
        HttpResponse<String> response = Unirest.post("https://${account.namespace}/oauth/device/code")
+
+  .header("content-type", "application/x-www-form-urlencoded")
+
+  .asString();
        var axios = require("axios").default;
+
+
+
+var options = {
+
+  method: 'post',
+
+  url: 'https://${account.namespace}/oauth/device/code',
+
+  headers: {'content-type': 'application/x-www-form-urlencoded'}
+
+};
+
+
+
+axios.request(options).then(function (response) {
+
+  console.log(response.data);
+
+}).catch(function (error) {
+
+  console.error(error);
+
+});
        #import <Foundation/Foundation.h>
+
+
+
+NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
+
+
+
+NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://${account.namespace}/oauth/device/code"]
+
+                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
+
+                                                   timeoutInterval:10.0];
+
+[request setHTTPMethod:@"post"];
+
+[request setAllHTTPHeaderFields:headers];
+
+
+
+NSURLSession *session = [NSURLSession sharedSession];
+
+NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
+
+                                            completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
+
+                                                if (error) {
+
+                                                    NSLog(@"%@", error);
+
+                                                } else {
+
+                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
+
+                                                    NSLog(@"%@", httpResponse);
+
+                                                }
+
+                                            }];
+
+[dataTask resume];
        $curl = curl_init();
+
+
+
+curl_setopt_array($curl, [
+
+  CURLOPT_URL => "https://${account.namespace}/oauth/device/code",
+
+  CURLOPT_RETURNTRANSFER => true,
+
+  CURLOPT_ENCODING => "",
+
+  CURLOPT_MAXREDIRS => 10,
+
+  CURLOPT_TIMEOUT => 30,
+
+  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
+
+  CURLOPT_CUSTOMREQUEST => "post",
+
+  CURLOPT_HTTPHEADER => [
+
+    "content-type: application/x-www-form-urlencoded"
+
+  ],
+
+]);
+
+
+
+$response = curl_exec($curl);
+
+$err = curl_error($curl);
+
+
+
+curl_close($curl);
+
+
+
+if ($err) {
+
+  echo "cURL Error #:" . $err;
+
+} else {
+
+  echo $response;
+
+}
        import http.client
+
+
+
+conn = http.client.HTTPSConnection("")
+
+
+
+headers = { 'content-type': "application/x-www-form-urlencoded" }
+
+
+
+conn.request("post", "/${account.namespace}/oauth/device/code", headers=headers)
+
+
+
+res = conn.getresponse()
+
+data = res.read()
+
+
+
+print(data.decode("utf-8"))
        require 'uri'
+
+require 'net/http'
+
+require 'openssl'
+
+
+
+url = URI("https://${account.namespace}/oauth/device/code")
+
+
+
+http = Net::HTTP.new(url.host, url.port)
+
+http.use_ssl = true
+
+http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+
+
+request = Net::HTTP::Post.new(url)
+
+request["content-type"] = 'application/x-www-form-urlencoded'
+
+
+
+response = http.request(request)
+
+puts response.read_body
        import Foundation
+
+
+
+let headers = ["content-type": "application/x-www-form-urlencoded"]
+
+
+
+let request = NSMutableURLRequest(url: NSURL(string: "https://${account.namespace}/oauth/device/code")! as URL,
+
+                                        cachePolicy: .useProtocolCachePolicy,
+
+                                    timeoutInterval: 10.0)
+
+request.httpMethod = "post"
+
+request.allHTTPHeaderFields = headers
+
+
+
+let session = URLSession.shared
+
+let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
+
+  if (error != nil) {
+
+    print(error)
+
+  } else {
+
+    let httpResponse = response as? HTTPURLResponse
+
+    print(httpResponse)
+
+  }
+
+})
+
+
+
+dataTask.resume()
        
+
+
+
+
        
+
+## デバイスコードを受け取る
+
+
+
        デバイスアプリケーションはHTTP 200応答と次のようなペイロードを受け取るはずです：
        {
+
+  "device_code": "GmRh...k9eS",
+
+  "user_code": "WDJB-MJHT",
+
+  "verification_uri": "https://my-tenant.auth0.com/device",
+
+  "verification_uri_complete": "https://my-tenant.auth0.com/device?user_code=WDJB-MJHT",
+
+  "expires_in": 900,
+
+  "interval": 5
+
+}
+
+
        
+
+
        
+
+## デバイスのアクティベーションを要求する
+
+
+
        デバイスアプリケーションは、device_codeとuser_codeの受信後に、ユーザーにverification_uriでuser_codeを入力するよう指示する必要があります。
        null
        device_codeはユーザーに直接提供するものではないため、ユーザーが混乱しないように、処理中に表示するべきではありません。
        CLIをビルドする際は、この手順をスキップし、verification_uri_completeを使って直接ブラウザーを開くことができます。
        
+
+## トークンエンドポイントをポーリングする
+
+
+
        ユーザーによるアクティベーションを待っている間、デバイスアプリケーションはAuthentication API POST /oauth/tokenエンドポイントを断続的に呼び出して、応答を適切に処理する必要があります。
        デバイスアプリケーションが確実にそのinterval（秒単位）または成功応答の受信で長い方の時間を待機して、ネットワーク遅延の問題を回避するようにします。
        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:device_code \ 
+
+--data device_code=__AUTH0_SCOPES__ \ 
+
+--data 'client_id=${account.clientId}'
+
+
        
+
+
        
+
+## ユーザーの認可
+
+
+
        ユーザーはQRコードをスキャンするか、アクティベーションページを開いてユーザーコードを入力します：
        null
        確認ページが表示され、ユーザーが正しいデバイスであることを確認します：
        null
        ユーザーがサインインして、トランザクションが完了します。この手順には、以下の1つ以上のプロセスが含まれます。
        • ユーザーを認証する
        • 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする
        • アクティブなSSOセッションを確認する
        • デバイスに関してユーザーの同意がまだ得られていない場合には、同意を得る
        null
        認証と同意が成功すると、確認のプロンプトが表示されます：
        null
        この時点で、ユーザーの認証とデバイスの認可は完了しています。
        
+
+## トークンを受け取る
+
+
+
        ユーザーがデバイスアプリケーションを認可すると、HTTP 200応答と次のペイロードを受け取ります：
        {
+
+  "access_token": "eyJz93a...k4laUWw",
+
+  "refresh_token": "GEbRxBN...edjnXbL",
+
+  "id_token": "eyJ0XAi...4faeEoQ",
+
+  "token_type": "Bearer",
+
+  "expires_in": 86400
+
+}
+
+
        
+
+
        トークンは検証してから保存します。方法については、「アクセストークンを検証する」と「IDトークンを検証する」をお読みください。
        アクセストークンは、Authentication APIのユーザー情報取得エンドポイント（デバイスアプリケーションがopenidスコープを要求した場合）、またはaudienceパラメーターが指定したAPIを呼び出すために使用されます。独自のAPIを呼び出す場合には、デバイスアプリケーションは使用する前にアクセストークンを検証しなければなりません。
        IDトークンには、デコードと抽出が必要なユーザー情報が含まれています。デバイスアプリケーションがopenidスコープを要求した場合には、Authentication APIはid_tokenのみを返します。
        リフレッシュトークンは、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。audienceパラメーターが指定するAPIに［Allow Offline Access（オフラインアクセスの許可）］設定が有効化されていて、デバイスアプリケーションがoffline_accessスコープを要求した場合には、Authentication APIはrefresh_tokenのみを返します。
        
+
+## APIを呼び出す
+
+
+
        APIを呼び出すには、デバイスアプリケーションはアクセストークンをベアラートークンとしてHTTP要求のAuthorizationヘッダーで渡さなければなりません。
        curl --request GET \
+
+  --url https://myapi.com/api \
+
+  --header 'authorization: Bearer __AUTH0_API_ACCESS_TOKEN__' \
+
+  --header 'content-type: application/json'
+
+
        
+
+
        
+
+## リフレッシュトークン
+
+
+
        ユーザーに新しいアクセストークンを取得するために、デバイスアプリケーションは、refresh_tokenパラメーターを指定してAuthentication API POST /oauth/tokenエンドポイントを呼び出すことができます。
        curl --request POST \
+
+  --url 'https://${account.namespace}/oauth/token' \
+
+  --header 'content-type: application/x-www-form-urlencoded' \
+
+  --data grant_type=refresh_token \
+
+  --data 'client_id=${account.clientId}' \
+
+  --data 'client_secret=${account.clientSecret}' \
+
+  --data refresh_token=__AUTH0_REFRESH_TOKEN__
+
+
        
+
+
        要求が成功すると、デバイスアプリケーションはHTTP 200応答で次のペイロードを受け取ります：
        {
+
+  "access_token": "eyJ...MoQ",
+
+  "expires_in": 86400,
+
+  "scope": "openid offline_access",
+
+  "id_token": "eyJ...0NE",
+
+  "token_type": "Bearer"
+
+}
+
+
        
+
+
        リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。
        
+
+## トラブルシューティング
+
+
+
        テナントログは実行されるあらゆるやり取りを記録し、問題の解決に利用することができます。
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **コード****名前****説明**
        fdeazデバイス認可要求の失敗
        fdeacデバイスのアクティベーションに失敗
        fdeccユーザーがデバイス確認をキャンセル
        fede交換の失敗アクセストークンのデバイスコード
        sede交換の成功アクセストークンのデバイスコード
        トークンの応答
        ユーザーによるデバイスの認可を待っている間には、さまざまなHTTP 4xx応答を受け取ります。
        認可待ち
        このエラーは、ユーザーの操作を待っている間に表示されます。このチュートリアルの前の手順で推奨されているintervalを使ってポーリングを継続してください。
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "authorization_pending", 
+
+  "error_description": "..." 
+
+}
+
+
        
+
+
        減速
        ポーリングが速すぎます。このチュートリアルの前の手順で推奨されている間隔を使ってポーリングしてください。ネットワーク遅延が原因でこのエラーを受け取ることを避けるには、ポーリング要求の応答を受け取ってから間隔をカウントし始めるようにします。
        `HTTP 429`
+
+
+
+{
+
+  "error": "slow_down",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        有効期限切れのトークン
        ユーザーによるデバイスの認可が遅かったため、device_codeの期限が切れました。アプリケーションはユーザーにフローの失効を通知して、フローをもう一度始めるように促す必要があります。
        expired_tokenエラーは一度だけ返されます。それ以降は、エンドポイントがinvalid_grantエラーを返します。
        `HTTP 403`
+
+
+
+{ 
+
+  "error": "expired_token",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        アクセス拒否
        アクセスが拒否された場合には、次を受け取ります：
        `HTTP 403`
+
+
+
+{
+
+  "error": "access_denied",
+
+  "error_description": "..."
+
+}
+
+
        
+
+
        これは、以下を含むさまざまな原因で発生します。
        • ユーザーがデバイスの認可を拒否した。
        • 認可サーバーがトランザクションを拒否した。
        • 構成済みのアクションがアクセスを拒否した。
        
+
+## 実装例
+
+
+
        以下の例を参考に、このフローを実際のアプリケーションに実装する方法を確認してください。
        • Device Authorization Playground
        • AppleTV（Swift）：AppleTVからのデバイス認可フローにAuth0を使用する方法を示す簡素なアプリケーションです。
        • CLI（Node.js）：認可コードフローではなく、デバイス認可フローを使用するCLIの実装例です。大きな違いは、CLIがWebサーバーのホスティングやポートの待ち受けを必要としないことです。
        
+
+## 制限事項
+
+
+
        デバイス認可フローを使用するには、デバイスアプリケーションに以下が必要です。
        また、デバイス認可フローには以下を使用できません：
        
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/app/build.md b/ja-jp/articles/quickstart/native/flutter/files/app/build.md
new file mode 100644
index 0000000000..c696fb8793
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/app/build.md
@@ -0,0 +1,21 @@
+---
+name: app/build.gradle
+language: 
+---
+    
+```
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion flutter.targetSdkVersion
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders += [auth0Domain: "auth0-dsepaid.auth0.com", auth0Scheme: "https"]
+        // <---
+    }
+}
+```
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/main_view.md b/ja-jp/articles/quickstart/native/flutter/files/main_view.md
new file mode 100644
index 0000000000..7ad3aa9879
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/main_view.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('auth0-dsepaid.auth0.com', 'OywWcFnHsbz50TfbRLWK0YTzrpxkwQL5');
+  }
+
+  @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/files/profile_view.md b/ja-jp/articles/quickstart/native/flutter/files/profile_view.md
new file mode 100644
index 0000000000..3dedf5c4b3
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/profile_view.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..94e8548e5f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/interactive.md
@@ -0,0 +1,76 @@
+---
+title: Flutterアプリケーションにログインを追加する
+description: このガイドでは、FlutterアプリにAuth0 Flutter SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/app/build
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: ja-JP
+---
+
+# Flutterアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスできます。このガイドでは、FlutterアプリにAuth0 Flutter SDKを使ってAuth0を統合する方法を説明します。
        Flutter SDKは現在、Android、iOS、macOS版のFlutterアプリのみに対応しています。
        このクイックスタートでは、すでにFlutterアプリが問題なく作動しているものとします。そうでない場合は、Flutter「入門」ガイドをチェックして、シンプルなアプリの始め方をご確認ください。
        Flutterコマンドラインツールの知識も必要になります。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        Auth0アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、既存のネイティブのAuth0アプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリをご覧ください。
        Callback URLとログアウトURLを構成する
        Callback URLとログアウトURLは、ユーザーをアプリにリダイレクトで戻すために、Auth0が呼び出すURLです。 Auth0は、ユーザーを認証した後にCallback URLを呼び出し、セッションのクッキーを削除した後にログアウトURLを呼び出します。Callback URLとログアウトURLを設定しないと、ユーザーはアプリにログインやログアウトが行えなくなり、エラーが発生します。
        プラットフォームに合わせて、Callback URLとログアウトURLに以下の値を設定します。
        Androidでは、SCHEMEプレースホルダーの値はhttpsや他のカスタムスキームでも構いません。httpsスキームでは、Androidアプリリンクを有効にする必要があります。
        iOS 17.4以降とmacOS 14.4以降では、ユニバーサルリンク（httpsスキーム）をCallback URLとログアウトURLに使うことができます。有効にすると、SDKは、iOS/macOSの古いバージョンではカスタムURLスキームにフォールバックして、アプリのバンドル識別子を使用します。この機能にはXcode 15.3以降と有料のApple Developerアカウントが必要です。
        Android
        SCHEME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        iOS
        https://{yourDomain}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://{yourDomain}/ios/YOUR_BUNDLE_IDENTIFIER/callback
        macOS
        https://{yourDomain}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://{yourDomain}/macos/YOUR_BUNDLE_IDENTIFIER/callback
        たとえば、iOSのバンドル識別子がcom.example.MyAppでAuth0ドメインがexample.us.auth0.comの場合には、次の値になります：
        https://example.us.auth0.com/ios/com.example.MyApp/callback,
+
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
        
+
+## Auth0 Flutter SDKをインストールする
+
+
+
        Auth0 Flutter SDKをプロジェクトに追加します：
        flutter pub add auth0_flutter
        
+
+## Androidを構成する
+
+
+
        Androidプラットフォームが開発対象でない場合には、この手順をスキップしてください。
        SDKにはマニフェストのプレースホルダーが必要です。Auth0は内部でプレースホルダーを使用して、認証のCallback URLを捉えるintent-filterを定義します。Auth0テナントのドメインとCallback URLスキームを設定する必要があります。
        サンプルでは、次のプレースホルダーを使用します：
        • auth0Domain：Auth0テナントのドメインです。通常、Auth0 Dashboardにあるアプリケーションの設定の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合には、この値をカスタムドメインの値に設定してください。
        • auth0Scheme：使用するスキームです。カスタムスキーム、または、Androidアプリリンクを利用したい場合はhttpsになります。この値の設定に関する詳細情報は、Auth0.Android SDK READMEをお読みください。
        アクティビティーに特別なintent-filterを宣言する必要はありません。これは、マニフェストのプレースホルダーをAuth0ドメインとスキームの値で定義したからです。リダイレクトはライブラリーによって処理されます。
        Android Studio内でSync Project with Gradle Filesを実行し、変更内容を適用します。
        
+
+## iOS/macOSを構成する
+
+
+
        iOSまたはmacOSプラットフォームが開発対象でない場合には、この手順をスキップしてください。
        この手順では、有料のApple Developerアカウントが必要です。Callback URLおよびログアウトURLとしてユニバーサルリンクを使用する必要があります。代わりにカスタムのURLスキームを使用する場合はこの手順をスキップしてください。
        チームIDとバンドル識別子を構成する
        Auth0アプリケーションの設定ページに移動して最後までスクロールし、 ［Advanced Settings（詳細設定）］>［Device Settings（デバイス設定）］を開きます。［iOS］セクションで［Team ID（チームID）］にApple Team IDを、［App ID（アプリID）］にアプリのバンドル識別子を設定します。
        null
        これで、アプリがAuth0テナントのapple-app-site-associationファイルに追加されます。
        関連ドメインの機能を追加する
        open ios/Runner.xcworkspace（macOSの場合にはopen macos/Runner.xcworkspace）を実行し、Xcodeでアプリを開きます。Runnerターゲット設定の［Signing & Capabilities（署名と機能）］タブに移動し、［+ Capability（＋機能）］ボタンを押します。それから［Associated Domains（関連ドメイン）］を選択します。
        null
        次に、以下のエントリーを［Associated Domains（関連ドメイン）］の下に追加します。
        webcredentials:{yourDomain}
        カスタムドメインがある場合は、Auth0ドメインの代わりに、設定ページにあるカスタムドメインを使用してください。
        関連ドメインが動作するためには、iOSシミュレーター用に構築されている場合でも、アプリが自分のチーム証明書で署名されている必要があります。Apple Teamには必ず、Auth0アプリケーションの設定ページで構成されたチームIDのものを使用してください。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="main_view.dart#29:40" }}}
+
+
+
        アプリに認証をセットアップするには、ユニバーサルログインが最も手軽な方法です。最良のエクスペリエンス、高い安全性、幅広い機能を活用するためにも、ユニバーサルログインの使用をお勧めします。
        Auth0クラスを使用して、Auth0のユニバーサルログインをFlutterアプリに統合します。webAuthentication().login()を使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトします。これはFutureであるため、ユーザートークンの取得を待ち合わせる必要があります。
        Android：カスタムスキームを使用している場合には、このスキームをログインメソッドに渡して、SDKが適切にログインページへ誘導してから戻せるようにします：
        await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login();
        ユーザーがログインすると、アプリへリダイレクトされます。その後、このユーザーのIDとアクセストークンにアクセスできるようになります。
        Flutter - 手順5 - アプリケーションにログインを追加する 
        webAuthentication().login()を呼び出してアプリにユーザーをログインするボタンをアプリに追加します。認証のためにAuth0へリダイレクトされてから、アプリケーションに戻されることを確認します。
        loginを呼び出した結果、トークンにアクセスできることを確認します
        
+
+  
        
+
+  
        アプリが正常に起動しなかった場合は以下を行います。
        • 設定した［Allowed Callback URLs（許可されているCallback URL）］が正しいことを確認します
        • URLを入力した後で保存したことを確認します
        • ドメインとクライアントIDの値が正常にインポートされていることを確認します
        • Androidを使用している場合は、アプリに正しくリダイレクトで戻されるように、マニフェストのプレースホルダーが正しくセットアップされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="main_view.dart#45:55" }}}
+
+
+
        ユーザーをログアウトさせるには、Auth0 Flutter SDKのwebAuthentication().logout()を呼び出してログインセッションをクリアし、ユーザーをAuth0のログアウトエンドポイントにリダイレクトします。Auth0からのログアウトについて詳しい情報をお読みください。
        Android：カスタムスキームを使用している場合には、このスキームをログアウトメソッドに渡して、SDKがアプリを適切に戻せるようにします：
        await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout();
        Flutter - 手順6 - アプリケーションにログアウトを追加する 
        アプリにwebAuthentication().logout()を呼び出して、ユーザーをアプリからログアウトさせるボタンを追加します。ボタンを選択し、Flutterアプリからログアウトエンドポイントにリダイレクトされ、再び戻されることを確認してください。アプリケーションにはログインされていないはずです。
        
+
+  
        
+
+  
        アプリが正常にログアウトしなかった場合は以下を行います。
        • ［Allowed Logout URLs（許可されているログアウトURL）］が正しく設定されていることを確認します
        • URLを入力した後で保存したことを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
        webAuthentication().login()を呼び出すと、ユーザープロファイルが自動的にユーザープロファイルプロパティを取得します。ログイン手順から返されたオブジェクトには、すべてのユーザープロファイルプロパティのあるuserプロパティが含まれ、これらはIDトークンをデコードすることで入力されます。
        Flutter - 手順7 - ユーザープロファイル情報を表示する 
        ログインして、結果のuserプロパティを調査します。emailやnameなど、現在のユーザーのプロファイル情報を確認します。
        
+
+  
        
+
+  
        アプリがユーザープロファイル情報を返さなかった場合には以下を行います。
        • アクセストークンが有効であることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/app.component.md b/ja-jp/articles/quickstart/native/ionic-angular/files/app.component.md
new file mode 100644
index 0000000000..0b54654bab
--- /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();
+          }
+        }
+      });
+    });
+  }
+}
+```
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..987cc68c0d
--- /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],
+})
+```
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..7821093b94
--- /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();
+  }
+}
+```
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..32da066dac
--- /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();
+  }
+}
+```
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..01fea0f83d
--- /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) {}
+}
+```
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..a2d4c3311c
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Capacitorを用いたIonic Angularアプリケーションにログインを追加する
+description: このガイドは、Ionic（Angular）とCapacitorのアプリケーションにAuth0 Angular SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/app.module
+ - files/app.component
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: angular
+locale: ja-JP
+---
+
+# Capacitorを用いたIonic Angularアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、Ionic（Angular）とCapacitorのアプリケーションにAuth0 Angular SDKを使ってAuth0を統合する方法を説明します。
        
+
+## 使用を開始する
+
+
+
        このクイックスタートは、IonicアプリケーションがCapacitorを使ってすでに実行されていることを前提としています。そうでない場合には、IonicフレームワークでCapacitorを使用するガイドを参照しながら簡単なアプリから始めるか、サンプリアプリを複製してください。
        また、Capacitorの開発ワークフローを理解しておく必要もあります。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        以下の説明では、「YOUR_PACKAGE_ID」を実際のアプリケーションのパッケージIDに置き換えてください。これは、capacitor.config.tsファイルのappIdフィールドで見つけて構成することができます。詳細については、Capacitorの構成スキーマを参照してください。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callback
        許可されているオリジンを構成する
        ネイティブアプリケーションからAuth0へ要求を送信できるようにするには、アプリケーションの設定で次の許可されているオリジンを設定します。
        サンプルプロジェクトに沿って進めている場合、capacitorにiOSとAndroidでそれぞれcapacitor://localhost, http://localhostを設定します。
        最後に、アプリケーションの［Application Type（アプリケーションタイプ）］が［Native（ネイティブ）］になっていることをアプリケーションの設定で必ず確認してください。
        
+
+## Auth0 Angular SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 Angular SDKをインストールします：
        npm install @auth0/auth0-angular
        SDKはモジュールや認証サービスなど、Auth0をAngularアプリケーションに慣用的に統合しやすくする種類をいくつか公開しています。
        Capacitorプラグインをインストールする
        このクイックスタートとサンプルでは、Capacitorの公式プラグインをいくつか使用しています。次のコマンドを使用して、これらをアプリにインストールします：
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser：デバイスのシステムブラウザーと対話できるようになり、Auth0の認可エンドポイントへのURLを開くために使用されます。
        • @capacitor/app：高レベルのアプリイベントを受け取れるようになるため、Auth0からのコールバックを扱うのに便利です。
        iOSのCapacitorのBrowserプラグインはSFSafariViewControllerを使用し、iOS 11以降ではデバイス上のSafariとクッキーを共有しません。つまり、これらのデバイスではSSOが機能しません。SSOが必要な場合には、ASWebAuthenticationSessionを使用する互換のプラグインを使用してください。
        
+
+## 認証モジュールを登録して構成する {{{ data-action="code" data-code="app.module.ts" }}}
+
+
+
        SDKは、SDKが機能するために必要なすべてのサービスを含んだAuthModuleをエクスポートします。このモジュールをアプリケーションに登録し、Auth0のドメインとクライアントIDで構成する必要があります。
        AuthModule.forRoot関数は以下の構成を使用します。
        • domain：Auth0 Dashboardで作成したアプリケーションの設定にあるdomain値、またはAuth0のカスタムドメイン機能を使用する場合のカスタムドメインです。
        • clientId：Auth0 Dashboardで作成したアプリケーションの設定にあるクライアントID値です。
        • useRefreshTokens：AndroidまたはiOSでauth0-angularをIonicと使用するには、リフレッシュトークンを有効にする必要があります。
        • useRefreshTokensFallback：AndroidまたはiOSでauth0-angularをIonicと使用するには、iframeのフォールバックを無効にする必要があります。
        • authorizationParams.redirect_uri：Auth0で認証した後に、ユーザーをリダイレクトするURLです。
        アプリケーションの閉開後に認証を継続するには、SDKを構成する際にcacheLocationをlocalstorageに設定することをお勧めします。ただし、localstorageにトークンを保管するリスクを理解してください。また、状況によってはlocalstorageのデータが思いがけず復元される可能性もあるため、Capacitorアプリ内では一次的なものとして扱ってください。Capacitorドキュメントに記載のストレージに関するガイドをお読みください。
        さらに、より安全で永続的なストレージの仕組みが要件である場合、SDKを使用すると、カスタムのキャッシュを実装してトークンを保管することができます。
        注意：CapacitorのStorageプラグインは、iOSではUserDefaults、AndroidではSharedPreferencesによってバックアップされるため、トークンの保管に使用しないことをお勧めします。これらのAPIを使って保管されたデータは暗号化されません。セキュリティで保護されることもなく、クラウドと同期される可能性があります。
        IonicとCapacitor（Angular）- 手順4 - 認証モジュールを登録して構成する 
        アプリがAuth0 Angular SDKで構成されました。今度は、アプリケーションを実行して、SDKがエラーなく初期化されること、そして、以前と同じように動作することを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login-button.ts" }}}
+
+
+
        Capacitorアプリケーションでは、CapacitorのBrowserプラグインによって、Auth0のユニバーサルログインページにリダイレクトされます。loginWithRedirect関数のopenUrlパラメーターにBrowser.openの使用を設定し、デバイスのシステムブラウザーコンポーネント（iOSではSFSafariViewController、AndroidではChrome Custom Tabs）でURLが開くようにします。
        SDKのloginWithRedirectメソッドは、デフォルトでwindow.location.hrefを使用して、ユーザーのデバイスにあるデフォルトのブラウザーアプリケーションでログインページを開きます。プラットフォームに適切なシステムブラウザーコンポーネントは使用しません。ユーザーが認証でアプリケーションを離れるため、ユーザーエクスペリエンスとしては最適ではありません。
        IonicとCapacitor（Angular）- 手順5 - アプリケーションにログインを追加する 
        loginWithRedirect関数は、SDKにログインフローを開始するように指示します。openUrlパラメーターにログインURLを設定して、Browser.open関数を呼し出し、プラットフォームのシステムブラウザーコンポーネントでログインURLを開きます。これは、ユーザーがアプリケーションにログインする方法を提供します。ユーザーはAuth0のログインページにリダイレクトされ、エラーは一切受け取りません。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログイン時にブラウザーのコンソールウィンドウでエラーが発生しないことを確認します
        • Auth0アプリケーションについて、DashboardでドメインとクライアントIDが正しいことを確認します
        • Auth0へのリダイレクトでエラーページを受け取った場合には、下部にある技術詳細セクションで失敗の理由を確認します
        
+
+  
        
+
+## ログインコールバックを処理する {{{ data-action="code" data-code="app.component.ts" }}}
+
+
+
        ユーザーがユニバーサルログインページでログインすると、カスタムURLスキームを使ったURLでアプリにリダイレクトされます。appUrlOpenイベントがアプリ内で処理されなければなりません。Auth0 SDKのhandleRedirectCallbackメソッドを呼び出すと、認証状態を初期化することができます。
        このメソッドは、Auth0からのリダイレクトでのみ使用することができます。正常に機能していることを確認するには、URL内のcodeとstateパラメーターを確認します。
        このイベントが発生した際に、Browser.close()メソッドがブラウザーを閉じるようにします。
        appUrlOpenイベントのコールバックがngZone.runでラップされていることに注意してください。handleRedirectCallbackの実行時に発生するオブザーバブルへの変更は、Angularアプリが受け取ります。詳細については、「AngularをCapacitorと使用する」をお読みください。それ以外の場合では、画面がログイン後の認証状態で更新されません。
        以下の説明では、カスタムURLスキームを使用して、アプリケーション内でコールバックを処理することを前提にしています。このためには、YOUR_PACKAGE_IDを選択したプラットのURLスキームで置き換えて登録します。詳細については、iOSには「カスタムURLスキームを定義する」、Androidには「アプリコンテンツ用のディープリンクを作成する」をお読みください。
        IonicとCapacitor（Angular）- 手順6 - ログインコールバックを処理する 
        アプリケーションのAppコンポーネントにappUrlOpenを追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout-button.ts" }}}
+
+
+
        ユーザーがログインできるようになりました。今度は、ログアウトする方法を構成する必要があります。ユーザーをAuth0のログアウトエンドポイントにリダイレクトし、ブラウザー内のセッションをクリアする必要があります。他の場合と同様に、ユーザーがアプリから離れることでユーザーエクスペリエンスが損なわれないように、CapacitorのBrowserプラグインがリダイレクトを処理するようにします。
        Auth0 SDKを使用してIonicとCapacitorで実現するには、以下を行います。
        • アプリについて、ログアウト後にAuth0のリダイレクト先となるURLを構築します。これは、登録済みのカスタムスキームとAuth0ドメインを使ったURLです。これを、Auth0 Dashboardの［Allowed Logout URLs（許可されているログアウトURL）］の構成に追加します。
        • logoutを呼び出し、logoutParams.returnToパラメーターにリダイレクト先のURLを渡して、SDKからログアウトします。
        • CapacitorのBrowserプラグインを使用してBrowser.openでURLを開くコールバックに、openUrlパラメーターを設定します。
        ログインの手順と同様に、logoutを呼び出す際にopenUrlを設定しないと、SDKがユーザーをログアウトURLにリダイレクトするのに、デバイスのデフォルトのブラウザーアプリケーションが使用されるため、ユーザーエクスペリエンスとしては最適ではありません。
        IonicとCapacitor（Angular）- 手順7 - アプリケーションにログアウトを追加する 
        ユーザーがアプリケーションからログアウトする方法を提供します。Auth0にリダイレクトしてから、returnToパラメーターで指定したアドレスへ移動することを確認します。ユーザーがアプリケーションにログインしていないことを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • returnToパラメーターに指定したURLがAuth0 Dashboardで［Allowed Callback URLs（許可されているCallback URL）］に登録済みであることを確認します
        
+
+  
        
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
        Auth0 SDKは必要な任意のコンポーネントについて、名前やプロフィール写真など、ログイン済みのユーザーに関連付けられたプロファイル情報を取得し、ユーザーインターフェイスをパーソナライズします。プロファイル情報は、AuthServiceが公開するuser$プロパティを介して使用することができます。
        IonicとCapacitor（Angular）- 手順8 - ユーザープロファイルを表示する 
        ユーザーがアプリ内でユーザープロファイルの詳細を表示できる手段を提供し、ログインした後に自分のプロファイル情報を取得して画面に表示できることを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • isLoadingがfalseの場合に、ユーザーのプロファイルを読み出しているだけであることを確認します
        • userがオブジェクトに解決され、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..f41566cdb1
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/app.md
@@ -0,0 +1,58 @@
+---
+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]);
+
+  // ..
+};// 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]);
+
+  // ..
+};
+```
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..ab848413f9
--- /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(
+  
+    
+  
+);
+```
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..20dc0072e2
--- /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;
+```
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..87d163ec18
--- /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;
+```
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..8d811b0020
--- /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;
+```
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..7e6701b4ec
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/interactive.md
@@ -0,0 +1,89 @@
+---
+title: Capacitorを用いたIonic React アプリにログインを追加する
+description: このガイドは、Ionic（React）とCapacitorのアプリケーションにAuth0 React SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/index
+ - files/login-button
+ - files/logout-button
+ - files/app
+ - files/user-profile
+github:
+  path: react
+locale: ja-JP
+---
+
+# Capacitorを用いたIonic React アプリにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、Ionic（React）とCapacitorのアプリケーションにAuth0 React SDKを使ってAuth0を統合する方法を説明します。
        
+
+## 使用を開始する
+
+
+
        このクイックスタートは、IonicアプリケーションがCapacitorを使ってすでに実行されていることを前提としています。そうでない場合には、IonicフレームワークでCapacitorを使用するガイドを参照しながら簡単なアプリから始めるか、サンプリアプリを複製してください。
        また、Capacitorの開発ワークフローを理解しておく必要もあります。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        以下の説明では、「YOUR_PACKAGE_ID」を実際のアプリケーションのパッケージIDに置き換えてください。これは、capacitor.config.tsファイルのappIdフィールドで見つけて構成することができます。詳細については、Capacitorの構成スキーマを参照してください。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/capacitor/YOUR_PACKAGE_ID/callback
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        YOUR_PACKAGE_ID://{yourTenant}.auth0.com/capacitor/YOUR_PACKAGE_ID/callback
        許可されているオリジンを構成する
        ネイティブアプリケーションからAuth0へ要求を送信できるようにするには、アプリケーションの設定で次の許可されているオリジンを設定します。
        サンプルプロジェクトに沿って進めている場合、capacitorにiOSとAndroidでそれぞれcapacitor://localhost, http://localhostを設定します。
        最後に、アプリケーションの［Application Type（アプリケーションタイプ）］が［Native（ネイティブ）］になっていることをアプリケーションの設定で必ず確認してください。
        
+
+## Auth0 React SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 React SDKをインストールします：
        npm install @auth0/auth0-react
        SDKは、慣用的にReact Hooksや高階コンポーネント（HOC）を使用して、Auth0をReactアプリケーションに統合しやすくするメソッドや変数を公開しています。
        Capacitorプラグインをインストールする
        このクイックスタートとサンプルでは、Capacitorの公式プラグインをいくつか使用しています。次のコマンドを使用して、これらをアプリにインストールします：
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser：デバイスのシステムブラウザーと対話できるようになり、Auth0の認可エンドポイントへのURLを開くために使用されます。
        • @capacitor/app：高レベルのアプリイベントを受け取れるようになるため、Auth0からのコールバックを扱うのに便利です。
        iOSのCapacitorのBrowserプラグインはSFSafariViewControllerを使用し、iOS 11以降ではデバイス上のSafariとクッキーを共有しません。つまり、これらのデバイスではSSOが機能しません。SSOが必要な場合には、ASWebAuthenticationSessionを使用する互換のプラグインを使用してください。
        
+
+## Auth0Providerコンポーネントを構成する {{{ data-action="code" data-code="index.tsx" }}}
+
+
+
        内部では、Auth0 React SDKはReact Contextを使用して、ユーザーの認証状態を管理します。Auth0をReactアプリに統合する1つの方法として、SDKからインポート可能なAuth0Providerでルートコンポーネントをラップすることができます。
        Auth0Providerコンポーネントは以下のプロパティを使用します。
        • domain：Auth0 Dashboardで作成したアプリケーションの設定にあるdomain値、またはAuth0のカスタムドメイン機能を使用する場合のカスタムドメインです。
        • clientId：Auth0 Dashboardで作成したアプリケーションの設定にあるクライアントID値です。
        • useRefreshTokens：AndroidまたはiOSでauth0-reactをIonicと使用するには、リフレッシュトークンを有効にする必要があります。
        • useRefreshTokensFallback：AndroidまたはiOSでauth0-reactをIonicと使用するには、iframeのフォールバックを無効にする必要があります。
        • authorizationParams.redirect_uri：Auth0で認証した後に、ユーザーをリダイレクトするURLです。
        アプリケーションの閉開後に認証を継続するには、SDKを構成する際にcacheLocationをlocalstorageに設定することをお勧めします。ただし、localstorageにトークンを保管するリスクを理解してください。また、状況によってはlocalstorageのデータが思いがけず復元される可能性もあるため、Capacitorアプリ内では一次的なものとして扱ってください。Capacitorドキュメントに記載のストレージに関するガイドをお読みください。
        さらに、より安全で永続的なストレージの仕組みが要件である場合、SDKを使用すると、カスタムのキャッシュを実装してトークンを保管することができます。
        注意：CapacitorのStorageプラグインは、iOSではUserDefaults、AndroidではSharedPreferencesによってバックアップされるため、トークンの保管に使用しないことをお勧めします。これらのAPIを使って保管されたデータは暗号化されません。セキュリティで保護されることもなく、クラウドと同期される可能性があります。
        Ionic と Capacitor（React）- 手順4 - Auth0Providerコンポーネントを構成する 
        Auth0ProviderコンポーネントがAppコンポーネントをラップするようにして追加してから、アプリケーションを実行し、SDKが正しく初期化されていること、そして、アプリケーションがAuth0に関連したエラーを投入していないことを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login-button.tsx" }}}
+
+
+
        Capacitorアプリケーションでは、CapacitorのBrowserプラグインによって、Auth0のユニバーサルログインページにリダイレクトされます。loginWithRedirect関数のopenUrlパラメーターにBrowser.openの使用を設定し、デバイスのシステムブラウザーコンポーネント（iOSではSFSafariViewController、AndroidではChrome Custom Tabs）でURLが開くようにします。
        SDKのloginWithRedirectメソッドは、デフォルトでwindow.location.hrefを使用して、ユーザーのデバイスにあるデフォルトのブラウザーアプリケーションでログインページを開きます。プラットフォームに適切なシステムブラウザーコンポーネントは使用しません。ユーザーが認証でアプリケーションを離れるため、ユーザーエクスペリエンスとしては最適ではありません。
        IonicとCapacitor（React）- 手順5 - アプリケーションにログインを追加する 
        loginWithRedirect関数は、SDKにログインフローを開始するように指示します。openUrlパラメーターにログインURLを設定して、Browser.open関数を呼び出し、プラットフォームのシステムブラウザーコンポーネントでログインURLを開きます。これは、ユーザーがアプリケーションにログインする方法を提供します。ユーザーはAuth0のログインページにリダイレクトされ、エラーは一切受け取りません。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログイン時にブラウザーのコンソールウィンドウでエラーが発生しないことを確認します
        • Auth0アプリケーションについて、DashboardでドメインとクライアントIDが正しいことを確認します
        • Auth0へのリダイレクトでエラーページを受け取った場合には、下部にある技術詳細セクションで失敗の理由を確認します
        
+
+  
        
+
+## ログインコールバックを処理する {{{ data-action="code" data-code="app.tsx" }}}
+
+
+
        ユーザーがユニバーサルログインページでログインすると、カスタムURLスキームを使ったURLでアプリにリダイレクトされます。appUrlOpenイベントがアプリ内で処理されなければなりません。Auth0 SDKのhandleRedirectCallbackメソッドを呼び出すと、認証状態を初期化することができます。
        このメソッドは、Auth0からのリダイレクトでのみ使用することができます。正常に機能していることを確認するには、URL内のcodeとstateパラメーターを確認します。
        このイベントが発生した際に、Browser.close()メソッドがブラウザーを閉じるようにします。
        以下の説明では、カスタムURLスキームを使用して、アプリケーション内でコールバックを処理することを前提にしています。このためには、YOUR_PACKAGE_IDを選択したプラットのURLスキームで置き換えて登録します。詳細については、iOSには「カスタムURLスキームを定義する」、Androidには「アプリコンテンツ用のディープリンクを作成する」をお読みください。
        IonicとCapacitor（React）- 手順6 - ログインコールバックを処理する 
        アプリケーションのAppコンポーネントにappUrlOpenを追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout-button.tsx" }}}
+
+
+
        ユーザーがログインできるようになりました。今度は、ログアウトする方法を構成する必要があります。ユーザーをAuth0のログアウトエンドポイントにリダイレクトし、ブラウザー内のセッションをクリアする必要があります。他の場合と同様に、ユーザーがアプリから離れることでユーザーエクスペリエンスが損なわれないように、CapacitorのBrowserプラグインがリダイレクトを処理するようにします。
        Auth0 SDKを使用してIonicとCapacitorで実現するには、以下を行います。
        • アプリについて、ログアウト後にAuth0のリダイレクト先となるURLを構築します。これは、登録済みのカスタムスキームとAuth0ドメインを使ったURLです。これを、Auth0 Dashboardの［Allowed Logout URLs（許可されているログアウトURL）］の構成に追加します。
        • logoutを呼び出し、logoutParams.returnToパラメーターにリダイレクト先のURLを渡して、SDKからログアウトします。
        • CapacitorのBrowserプラグインを使用してBrowser.openでURLを開くコールバックに、openUrlパラメーターを設定します。
        ログインの手順と同様に、logoutを呼び出す際にopenUrlを設定しないと、SDKがユーザーをログアウトURLにリダイレクトするのに、デバイスのデフォルトのブラウザーアプリケーションが使用されるため、ユーザーエクスペリエンスとしては最適ではありません。
        IonicとCapacitor（React）- 手順7 - アプリケーションにログアウトを追加する 
        ユーザーがアプリケーションからログアウトする方法を提供します。Auth0にリダイレクトしてから、returnToパラメーターで指定したアドレスへ移動することを確認します。アプリケーションにログインしていないことを確認します。
        
+
+  
        
+
+  
        
+
+  
        
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="user-profile.tsx" }}}
+
+
+
        Auth0 React SDKは必要な任意のコンポーネントについて、名前やプロフィール写真など、ログイン済みのユーザーに関連付けられたユーザープロファイルを取得し、ユーザーインターフェイスをパーソナライズします。プロファイル情報は、useAuth0()フックが公開するuserプロパティを介して使用することができます。
        SDKの初期化は非同期に行われます。isLoadingとuserプロパティを確認して、ユーザープロファイルを保護する必要があります。isLoadingがfalseになり、userが値を持つと、ユーザープロファイルを利用することができます。
        Ionic と Capacitor（React）- 手順8 - ユーザープロファイルを表示する 
        ユーザーがアプリ内でユーザープロファイルの詳細を表示できる手段を提供し、ログインした後に自分のプロファイル情報を取得して画面に表示できることを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • isLoadingがfalseの場合に、ユーザーのプロファイルを読み出しているだけであることを確認します
        • userがオブジェクトに解決され、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/LoginButton.md b/ja-jp/articles/quickstart/native/ionic-vue/files/LoginButton.md
new file mode 100644
index 0000000000..ceb58fc255
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/LoginButton.md
@@ -0,0 +1,41 @@
+---
+name: LoginButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+
+```
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/LogoutButton.md b/ja-jp/articles/quickstart/native/ionic-vue/files/LogoutButton.md
new file mode 100644
index 0000000000..6ebfb8809e
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/LogoutButton.md
@@ -0,0 +1,44 @@
+---
+name: LogoutButton.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/UserProfile.md b/ja-jp/articles/quickstart/native/ionic-vue/files/UserProfile.md
new file mode 100644
index 0000000000..0366a88cc4
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/UserProfile.md
@@ -0,0 +1,35 @@
+---
+name: UserProfile.vue
+language: 
+---
+    
+```
+
+
+
+```
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..1f9bee09d5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/app.md
@@ -0,0 +1,45 @@
+---
+name: App.vue
+language: javascript
+---
+    
+```javascript
+
+
+
+```
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..38d763e101
--- /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");
+});
+```
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..a52f0fd6aa
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/interactive.md
@@ -0,0 +1,89 @@
+---
+title: CapacitorアプリでIonic Vueにログインを追加する
+description: このガイドは、Ionic（Vue）とCapacitrorのアプリケーションにAuth0 Vue SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/main
+ - files/LoginButton
+ - files/LogoutButton
+ - files/App
+ - files/UserProfile
+github:
+  path: vue
+locale: ja-JP
+---
+
+# CapacitorアプリでIonic Vueにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、Ionic（Vue）とCapacitrorのアプリケーションにAuth0 Vue SDKを使ってAuth0を統合する方法を説明します。
        
+
+## 使用を開始する
+
+
+
        このクイックスタートは、IonicアプリケーションがCapacitorを使ってすでに実行されていることを前提としています。そうでない場合には、IonicフレームワークでCapacitorを使用するガイドを参照しながら簡単なアプリから始めるか、サンプルアプリを複製してください。
        また、Capacitorの開発ワークフローを理解しておく必要もあります。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        以下の説明では、YOUR_PACKAGE_IDを実際のアプリケーションのパッケージIDに置き換えてください。これは、capacitor.config.tsファイルのappIdフィールドで見つけて構成することができます。詳細については、Capacitorの構成スキーマを参照してください。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、YOUR_PACKAGE_ID://{yourDomain}/capacitor/YOUR_PACKAGE_ID/callbackに設定してください。
        許可されているオリジンを構成する
        ネイティブアプリケーションからAuth0へ要求を送信できるようにするには、アプリケーションの設定で次の許可されているオリジンを設定します。
        サンプルプロジェクトに沿って進めている場合、iOSとAndroidでそれぞれcapacitor://localhost, http://localhostを設定します。
        最後に、アプリケーションの［Application Type（アプリケーションタイプ）］が［Native（ネイティブ）］になっていることをアプリケーションの設定で必ず確認してください。
        
+
+## Auth0 Vue SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 Vue SDKをインストールします：
        npm install @auth0/auth0-vue
        SDKはモジュールや認証サービスなど、Auth0をVueアプリケーションに慣用的に統合しやすくする種類をいくつか公開しています。
        Capacitorプラグインをインストールする
        このクイックスタートとサンプルでは、Capacitorの公式プラグインをいくつか使用しています。次のコマンドを使用して、これらをアプリにインストールします：
        npm install @capacitor/browser @capacitor/app
        • @capacitor/browser：デバイスのシステムブラウザーと対話できるようになり、Auth0の認可エンドポイントへのURLを開くために使用されます
        • @capacitor/app：高レベルのアプリイベントを受け取れるようになるため、Auth0からのコールバックを扱うのに便利です
        iOSのCapacitorのBrowserプラグインはSFSafariViewControllerを使用し、iOS 11以降ではデバイス上のSafariとクッキーを共有しません。つまり、これらのデバイスではSSOが機能しません。SSOが必要な場合には、ASWebAuthenticationSessionを使用する互換性のあるプラグインを使用してください。
        
+
+## CreateAuht0プラグインを構成する {{{ data-action="code" data-code="main.ts" }}}
+
+
+
        SDKは、SDKが機能するために必要なすべてのサービスを含んだコンポーザブル、createAuth0をエクスポートします。このコンポーザブルをアプリケーションに登録し、Auth0のドメインとクライアントIDで構成する必要があります。
        createAuth0コンポーザブルは以下の構成を取ります。
        • domain：Auth0 Dashboardで作成したアプリケーションの［Settings（設定）］にあるdomain値、またはAuth0のカスタムドメイン機能を使用する場合のカスタムドメインです。
        • clientId：Auth0 Dashboardで作成したアプリケーションの［Settings（設定）］にあるクライアントID値です。
        • useRefreshTokens：AndroidまたはiOSでauth0-vueをIonicと使用するには、リフレッシュトークンを有効にする必要があります。
        • useRefreshTokensFallback：AndroidまたはiOSでauth0-vueをIonicと使用するには、iframeのフォールバックを無効にする必要があります。
        • authorizationParams.redirect_uri：Auth0で認証した後に、ユーザーをリダイレクトするURLです。
        アプリケーションの閉開後に認証を継続するには、SDKを構成する際にcacheLocationをlocalstorageに設定することをお勧めします。ただし、localstorageにトークンを保管するリスクを理解してください。また、状況によってはlocalstorageのデータが思いがけず復元される可能性もあるため、Capacitorアプリ内では一次的なものとして扱ってください。Capacitorドキュメントに記載のストレージに関するガイドをお読みください。
        さらに、より安全で永続的なストレージの仕組みが要件である場合、SDKを使用すると、カスタムのキャッシュを実装してトークンを保管することができます。
        注意：CapacitorのStorageプラグインは、iOSではUserDefaults、AndroidではSharedPreferencesによってバックアップされるため、トークンの保管に使用しないことをお勧めします。これらのAPIを使って保管されたデータは暗号化されません。セキュリティで保護されることもなく、クラウドと同期される可能性があります。
        ionic クイックスタート - 手順4「チェックポイント」 
        アプリがAuth0 Vue SDKで構成されました。今度は、アプリケーションを実行して、SDKがエラーなく初期化されること、そして、以前と同じように動作することを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="LoginButton.vue" }}}
+
+
+
        Capacitorアプリケーションでは、CapacitorのBrowserプラグインによって、Auth0のユニバーサルログインページにリダイレクトされます。loginWithRedirect関数のopenUrlパラメーターにBrowser.openの使用を設定し、デバイスのシステムブラウザーコンポーネント（iOSではSFSafariViewController、AndroidではChrome Custom Tabs）でURLが開くようにします。
        SDKのloginWithRedirectメソッドは、デフォルトでwindow.location.hrefを使用して、ユーザーのデバイスにあるデフォルトのブラウザーアプリケーションでログインページを開きます。プラットフォームに適切なシステムブラウザーコンポーネントは使用しません。ユーザーが認証でアプリケーションを離れるため、ユーザーエクスペリエンスとしては最適ではありません。
        ionic手順5「チェックポイント」 
        loginWithRedirect関数は、SDKにログインフローを開始するように指示します。openUrlパラメーターを設定して、Browser.open関数を呼び出し、プラットフォームのシステムブラウザーコンポーネントでログインURLを開きます。これは、ユーザーがアプリケーションにログインする方法を提供します。ユーザーはAuth0のログインページにリダイレクトされ、エラーは一切受け取りません。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログイン時にブラウザーのコンソールウィンドウでエラーが発生しないことを確認します
        • Auth0アプリケーションについて、DashboardでドメインとクライアントIDが正しいことを確認します
        • Auth0へのリダイレクトでエラーページを受け取った場合には、下部にある技術詳細セクションで失敗の理由を確認します
        
+
+  
        
+
+## ログインコールバックを処理する {{{ data-action="code" data-code="App.vue" }}}
+
+
+
        ユーザーがユニバーサルログインページでログインすると、カスタムURLスキームを使ったURLでアプリにリダイレクトされます。appUrlOpenイベントがアプリ内で処理されなければなりません。Auth0 SDKのhandleRedirectCallbackメソッドを呼び出すと、認証状態を初期化することができます。
        このメソッドは、Auth0からのリダイレクトでのみ使用することができます。正常に機能していることを確認するには、URL内のcodeとstateパラメーターを確認します。
        このイベントが発生した際に、Browser.close()メソッドがブラウザーを閉じるようにします。
        以下の説明では、カスタムURLスキームを使用して、アプリケーション内でコールバックを処理することを前提にしています。このためには、YOUR_PACKAGE_IDを選択したプラットフォームのURLスキームで置き換えて登録します。詳細については、iOSには「カスタムURLスキームを定義する」、Androidには「アプリコンテンツ用のディープリンクを作成する」をお読みください。
        ionic手順6「チェックポイント」 
        アプリケーションのAppコンポーネントセットアップにappUrlOpenを追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="LogoutButton.vue" }}}
+
+
+
        ユーザーがログインできるようになりました。今度は、ログアウトする方法を構成する必要があります。ユーザーをAuth0のログアウトエンドポイントにリダイレクトし、ブラウザー内のセッションをクリアする必要があります。他の場合と同様に、ユーザーがアプリから離れることでユーザーエクスペリエンスが損なわれないように、CapacitorのBrowserプラグインがリダイレクトを処理するようにします。
        Auth0 SDKを使用してIonicとCapacitorで実現するには、以下を行います。
        • アプリについて、ログアウト後にAuth0のリダイレクト先となるURLを構築します。これは、登録済みのカスタムスキームとAuth0ドメインを使ったURLです。これを、Auth0 Dashboardの［Allowed Logout URLs（許可されているログアウトURL）］の構成に追加します。
        • logoutを呼び出し、logoutParams.returnToパラメーターにリダイレクト先のURLを渡して、SDKからログアウトします。
        • CapacitorのBrowserプラグインを使用してBrowser.openでURLを開くコールバックに、openUrlパラメーターを設定します。
        ログインの手順と同様に、logoutを呼び出す際にopenUrlを設定しないと、SDKがユーザーをログアウトURLにリダイレクトするのに、デバイスのデフォルトのブラウザーアプリケーションが使用されるため、ユーザーエクスペリエンスとしては最適ではありません。
        ionic手順7「チェックポイント」 
        ユーザーがアプリケーションからログアウトする方法を提供します。Auth0にリダイレクトしてから、returnToパラメーターで指定したアドレスへ移動することを確認します。アプリケーションにログインしていないことを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • returnToパラメーターに指定したURLがAuth0 Dashboardで［Allowed Callback URLs（許可されているCallback URL）］に登録済みであることを確認します
        
+
+  
        
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="UserProfile.vue" }}}
+
+
+
        Auth0 Vue SDKは必要な任意のコンポーネントについて、名前やプロフィール写真など、ログイン済みのユーザーに関連付けられたユーザープロファイルを取得し、ユーザーインターフェイスをパーソナライズします。プロファイル情報は、useAuth0()コンポーザブルが公開するuserプロパティを介して使用することができます。
        SDKの初期化は非同期に行われます。isLoadingとuserプロパティを確認して、ユーザープロファイルを保護する必要があります。isLoadingがfalseになり、userが値を持つと、ユーザープロファイルを利用することができます。
        ionic手順8「チェックポイント」 
        ユーザーがアプリ内でユーザープロファイルの詳細を表示できる手段を提供し、ログインした後に自分のプロファイル情報を取得して画面に表示できることを確認します。
        
+
+  
        
+
+  
        
+
+  
        
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..06a0a42d16
--- /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..c7dd749fe5
--- /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..cd896b9fe0
--- /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..ac70c8d6b6
--- /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..09d7f3df15
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/interactive.md
@@ -0,0 +1,106 @@
+---
+title: iOSまたはmacOSアプリケーションにログインを追加する
+description: このガイドは、iOSやmacOSアプリにAuth0.swift SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/Auth0
+ - files/MainView
+ - files/ProfileView
+ - files/User
+github:
+  path: Sample-01
+locale: ja-JP
+---
+
+# iOSまたはmacOSアプリケーションにログインを追加する
+
+
+
        このガイドは、Auth0.swift SDKを使って、iOSやmacOSアプリで認証の追加とユーザプロファイル情報へのにアクセスを行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいiOSまたはmacOSのアプリを準備します。または、ログインした後に、サンプルアプリを表示してダウンロードすることもできます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションが必要です。Auth0アプリケーションは、開発中のアプリに対してどのように認証が動作して欲しいかを構成する場所です。
        Auth0アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、既存のネイティブのAuth0アプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、DashboardのAuth0アプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリをご覧ください。
        Callback URLとログアウトURLを構成する
        Auth0はリダイレクトでユーザーをアプリに戻すため、Callback URLとログアウトURLを呼び出します。Auth0は、ユーザーを認証した後にCallback URLを呼び出し、セッションのクッキーを削除した後にログアウトURLを呼び出します。Callback URLとログインURLを設定しないと、ユーザーはアプリにログインやログアウトが行えなくなり、アプリにエラーが発生します。
        iOS 17.4以降とmacOS 14.4以降では、ユニバーサルリンクをCallback URLおよびログアウトURLとして使用できます。有効になっている場合、古いバージョンのiOS/macOSでは、Auth0.swiftはフォールバックとしてカスタムURLスキームを使用します。
        この機能にはXcode 15.3以降と有料のApple Developerアカウントが必要です。
        アプリのプラットフォームに応じて、以下のCallback URLとログアウトURLを追加してください。カスタムドメインがある場合は、Auth0テナントのドメインに代わってそちらを使用します。
        iOS
        https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+
+
        
+
+
        macOS
        https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+
+
        
+
+
        たとえば、iOSのバンドル識別子がcom.example.MyAppでAuth0ドメインがexample.us.auth0.comの場合には、次の値になります：
        https://example.us.auth0.com/ios/com.example.MyApp/callback,
+
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+
+
        
+
+
        関連ドメインを構成する
        この手順では有料のApple Developerアカウントが必要になります。Callback URLおよびログアウトURLとしてユニバーサルリンクを使用する必要があります。代わりにカスタムURLスキームを使用する場合はこの手順をスキップしてください。
        チームIDとバンドル識別子を構成する
        Auth0アプリケーションの設定ページに移動して最後までスクロールし、 ［Advanced Settings（詳細設定）］>［Device Settings（デバイス設定）］を開きます。［iOS］セクションで［Team ID（チームID）］にApple Team IDを、［App ID（アプリID）］にアプリのバンドルIDを設定します。
        Auth0 Dashboard> ［Applications（アプリケーション）］ > ［Applications（アプリケーション）］ > ［Native App（ネイティブアプリ）］ > ［Settings（設定）］タブ > ［Advanced Settings（詳細設定）］ > ［Device Settings（デバイス設定）］タブ
        これで、アプリがAuth0テナントのapple-app-site-associationファイルに追加されます。
        関連ドメインの機能を追加する
        Xcodeで、アプリのターゲット設定の［Signing & Capabilities（署名と機能）］タブに移動し、［+ Capability（＋機能）］ボタンを押します。それから［Associated Domains（関連ドメイン）］を選択します。
        ［Xcode］> ［Signing & Capabilities（署名と機能）］タブ > ［Add New（新規追加）］ > ［Associated Domains（関連ドメイン）］
        次に、以下の エントリーを［Associated Domains（関連ドメイン）］の下に追加します：
        webcredentials:labs-fundtraining.us.auth0.com
+
+
        
+
+
        カスタムドメインがある場合は、Auth0テナントのドメインではなくそちらを使用してください。
        関連ドメインが動作するためには、iOSシミュレーター用に構築されている場合でも、アプリが自分のチーム証明書で署名されている必要があります。Apple Teamには必ず、Auth0アプリケーションの設定ページで構成されたチームIDのものを使用してください。
        
+
+## SDKをインストールする
+
+
+
        Swift Package Managerを使用する
        Xcodeで以下のメニュー項目を開きます：
        ［File（ファイル）］ > ［Add Package Dependencies...（パッケージの依存関係を追加する...）］
        ［Search or Enter Package URL（パッケージURLを検索または入力）］検索ボックスに次のURLを入力します：
        https://github.com/auth0/Auth0.swift
+
+
        
+
+
        それから依存ルールを選択して［Add Package（パッケージを追加）］を押します。
        SPMの詳細については、公式ドキュメントを確認してください。
        CocoaPodsを使用する
        以下のラインをPodfileに追加します：
        pod 'Auth0', '~> 2.0'
+
+
        
+
+
        それからpod installを実行します。
        CocoaPodsの詳細は、公式ドキュメントを確認してください。
        Carthageを使用する
        以下のラインをCartfileに追加します：
        github "auth0/Auth0.swift" ~> 2.0
+
+
        
+
+
        それからcarthage bootstrap --use-xcframeworksを実行します。
        Carthageの詳細については、公式ドキュメントを確認してください。
        
+
+## SDKを構成する {{{ data-action="code" data-code="Auth0.plist" }}}
+
+
+
        Auth0.swiftのSDKにはAuth0domainとClient IDが必要です。これらの値はAuth0アプリケーションの設定ページで確認できます
        • domain：Auth0テナントのドメインです。カスタムドメインがある場合は、Auth0テナントのドメインではなくそちらを使用してください。
        • クライアントID：このクイックスタートで前にセットアップした、Auth0アプリケーションの英数字からなる一意のIDです。
        Auth0ドメインとクライアントIDの値を含むアプリバンドルにAuth0.plistという名前のplistファイルを作成します。
        SDKはプログラムコードによって構成することも可能です。詳細はREADMEをご覧ください。
        iOS Swiftクイックスタート - 手順3「チェックポイント」 
        Auth0.swift SDKの構成を完了しました。アプリを実行して、SDKに関連したエラーを出していないことを確認します。
        
+
+  
        
+
+  
        アプリでSDK関連のエラーが発生する場合には以下を行います。
        • 正しいAuth0アプリケーションが選択されていることを確認します
        • URLを更新した後で保存したことを確認します
        • Auth0のドメインとクライアントIDが正しく設定されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="MainView.swift#20:31" }}}
+
+
+
        ログインページを提示したいファイルにAuth0モジュールをインポートします。それからログインボタンのアクションでユニバーサルログインページを提示します。
        コールバックに基づいたAPIの代わりにasync/awaitまたはCombineを使用できます。詳細はREADMEをご覧ください。
        iOSアプリのユニバーサルログイン画面の例
        iOS Swiftクイックスタート - 手順4「チェックポイント」 
        ログインボタンを押して次の点を確認します：
        • アラートボックスが表示され、同意を求める。
        • ［Continue（続行）］を選択するとSafariモーダルでユニバーサルログインページが開く。
        • ユーザー名とパスワード、またはソーシャルプロバイダーを使って、ログインまたはサインアップできる。
        • その後、Safariモーダルが自動的に閉じる。
        
+
+  
        
+
+  
        ログインが失敗するか、エラーが起きる場合には以下を行います。
        • 正しいCallback URLが入力されていることを確認します
        • Auth0のドメインとクライアントIDが正しく設定されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainView.swift#34:45" }}}
+
+
+
        アプリにログインできるようになったら、ログアウトする方法が必要です。ログアウトボタンのアクションでclearSession()メソッドを呼び出し、ユニバーサルログインセッションのクッキーを消去します。
        iOS Swiftクイックスタート - 手順5「チェックポイント」 
        ログアウトボタンを押して次の点を確認します：
        • アラートボックスが表示され、同意を求める。
        • ［Continue（続行）］を選択するとSafariモーダルでページが開く。
        • その直後にSafariモーダルが自動的に閉じる。
        
+
+  
        
+
+  
        ログアウトが失敗するか、エラーが起きる場合には以下を行います。
        • 正しいCallback URLが入力されていることを確認します
        • Auth0のドメインとクライアントIDが正しく設定されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報にアクセスする {{{ data-action="code" data-code="User.swift#11:14" }}}
+
+
+
        ログイン後に得るCredentialsインスタンスにはIDトークンが含まれます。IDトークンは、ログインしたユーザーに関連するプロファイル情報（メールアドレスやプロフィール写真など）を含みます。これらの詳細情報はアプリのユーザーインターフェイスをパーソナライズするために使用できます。
        Auth0.swiftのSDKには、IDトークンのようなJWTをデコードするためのユーティリティが含まれています。ユーザープロファイル情報にアクセスしたいファイルへJWTDecodeモジュールをインポートすることで開始します。それから、decode(jwt:)メソッドを使ってIDトークンをデコードし、そこに含まれるクレームにアクセスします。
        最新のユーザー情報はuserInfo(withAccessToken:)メソッドで取得できます。詳細はEXAMPLESをご覧ください。
        iOS Swiftクイックスタート - 手順6「チェックポイント」 
        ログイン後にemail、picture、その他すべてのクレームにアクセスできることを確認します。
        
+
+  
        
+
+  
        ユーザー情報にアクセスできない場合は以下を行います。
        • decode(jwt:)メソッドを呼び出すJWTDecodeモジュールがインポートされていることを確認します
        • クレームの綴りが間違っていないことを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティフォーラムで詳しい情報を確認してください。
        
+
+  
        
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/MainPage.xaml.md b/ja-jp/articles/quickstart/native/maui/files/MainPage.xaml.md
new file mode 100644
index 0000000000..010c5970f8
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/files/MainPage.xaml.md
@@ -0,0 +1,73 @@
+---
+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 = "";
+    }
+}
+```
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..8a966f5476
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,158 @@
+---
+title: MAUIアプリケーションにログインを追加する
+description: このチュートリアルは、Auth0を使用して、.NET MAUIアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/MainPage.xaml
+github:
+  path: Sample
+locale: ja-JP
+---
+
+# MAUIアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、.NET MAUIアプリケーションにMAUI用のAuth0 SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        MAUI SDKは、Android、iOS、macOS、Windowsに対応しています。プラットフォーム特有の構成に関しては、以下をお読みください。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、myapp://callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、myapp://callbackに設定してください。
        
+
+## Auth0 SDKをインストールする
+
+
+
        MAUIアプリケーションで、Auth0認証を手軽に実装できるように、Auth0はMAUIのSDKを提供しています。
        NuGetパッケージ マネージャー（［Tools（ツール）］ -> ［Library Package Manager（ライブラリーパッケージマネージャー）］ -> ［Package Manager Console（パッケージマネージャーコンソール）］）を使ってAuth0.OidcClient.MAUIパッケージをインストールしてください。
        NuGetパッケージマネージャーコンソール（Install-Package）やdotnet CLI（dotnet add）を代わりに使用することもできます。
        Install-Package Auth0.OidcClient.MAUI
+
+
        
+
+
        dotnet add package Auth0.OidcClient.MAUI
+
+
        
+
+
        
+
+## プラットフォーム特定の構成
+
+
+
        SDKをAndroidとWindowsで使うためにはプラットフォーム特定の構成が必要です。
        Android
        WebAuthenticatorCallbackActivityを展開する新しいアクティビティを作成します：
        [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";
+
+}
+
+
        
+
+
        上記のアクティビティは、ログイン後にAuth0がAndroidアプリケーションへリダイレクトで戻る時に、アプリケーションがmyapp://callback URLをハンドリングできることを保証します。
        Windows
        Auth0にリダイレクトで戻された後、アプリケーションが適切に再アクティブ化されるには、2つのことを行う必要があります：
        • 対応するプロトコルをPackage.appxmanifestに加えます。この場合、設定はmyappになっていますが、お好きなものに変更できます（関連するすべてのAuth0 URLも確実に更新してください）。
        <Applications>
+
+ <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="$targetentrypoint$">
+
+ <Extensions>
+
+ <uap:Extension Category="windows.protocol">
+
+ <uap:Protocol Name="myapp"/>
+
+ </uap:Extension>
+
+ </Extensions>
+
+ </Application>
+
+</Applications>
+
+
        
+
+
        • Windows固有のApp.xaml.csファイルでActivator.Default.CheckRedirectionActivation()を呼び出します。
        public App()
+
+{
+
+ if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation())
+
+ return;
+
+
+
+ this.InitializeComponent();
+
+}
+
+
        
+
+
        
+
+## Auth0Clientをインスタンス化する {{{ data-action="code" data-code="MainPage.xaml.cs#3:10" }}}
+
+
+
        Auth0をアプリケーションに統合するには、Auth0ドメイン、クライアントID、要求されたスコープを含むAuth0ClientOptionsのインスタンスを渡してAuth0Clientクラスをインスタンス化します。また、Auth0が構成したURLを使って確実にアプリケーションにリダイレクトするよう、RedirectUriとPostLogoutRedirectUriも構成する必要があります。
        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"
+
+ });
+
+
        
+
+
        SDKは初期設定で、AndroidにはChrome Custom Tabs、iOS・macOSにはASWebAuthenticationSessionを利用し、Windowsではシステムの既定ブラウザーが開きます。
        MAUIクイックスタート - 手順4「チェックポイント」 
        Auth0Clientが適切にインスタンス化されました。アプリケーションを実行して次の点を確認します：
        • Auth0ClientがMainPageで正しくインスタンス化されている。
        • アプリケーションがAuth0に関連したエラーを投入していない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="MainPage.xaml.cs#25:25" }}}
+
+
+
        Auth0アプリケーションとAuth0 SDKの構成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、SDKのLoginAsync()メソッドを使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトするログインボタンを作成します。
        var loginResult = await client.LoginAsync();
+
+
        
+
+
        エラーがなければ、LoginAsync()が返すLoginResultでUser、IdentityToken、AccessToken、RefreshTokenにアクセスすることができます。
        MAUIクイックスタート - 手順5「チェックポイント」 
        ユーザー名とパスワードを使ってログインやサインアップができるようになりました。
        ログインボタンをクリックして次の点を確認します：
        • アプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる。
        • ログインまたはサインアップできる。
        • Auth0によってアプリケーションにリダイレクトされる。
        
+
+  
        
+
+  
        すみません。以下の点をもう一度確認してください。
        • 期待されているようにLoginAsyncを呼び出した
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainPage.xaml.cs#32:32" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのLogoutAsync()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
        await client.LogoutAsync();
+
+
        
+
+
        MAUIクイックスタート - 手順6「チェックポイント」 
        アプリケーションを実行してログアウトボタンをクリックし、次の点を確認します：
        • アプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
        • アプリケーションにログインしていない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいログアウトURLが構成されている
        • 期待されているようにLogoutAsyncを呼び出した
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="MainPage.xaml.cs#55:58" }}}
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。
        MAUI用のAuth0 SDKでは、LoginResult.Userプロパティを通じてユーザー情報を提供します。
        
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/AppDelegate.md b/ja-jp/articles/quickstart/native/net-android-ios/files/AppDelegate.md
new file mode 100644
index 0000000000..0efcf0d8ce
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/AppDelegate.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;
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/files/MainActivity.md b/ja-jp/articles/quickstart/native/net-android-ios/files/MainActivity.md
new file mode 100644
index 0000000000..dcf30e59af
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/MainActivity.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 = "${account.namespace}",
+    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();
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/files/MyViewController.md b/ja-jp/articles/quickstart/native/net-android-ios/files/MyViewController.md
new file mode 100644
index 0000000000..99821cc2bd
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/MyViewController.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();
+    }
+}
+```
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..4fef804271
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/interactive.md
@@ -0,0 +1,163 @@
+---
+title: .NET AndroidまたはiOSアプリケーションにログインを追加する
+description: このチュートリアルは、Auth0を使用して、.NET AndroidまたはiOSアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/MainActivity
+ - files/AppDelegate
+ - files/MyViewController
+github:
+  path: Quickstart/01-Login
+locale: ja-JP
+---
+
+# .NET AndroidまたはiOSアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、.NET AndroidまたはiOSアプリケーションにAndroidやiOS用のAuth0 SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートは、Xamarin.AndroidとXamarin.iOSの次世代である.NET AndroidとiOSについて説明します。現在、Xamarin.AndroidやXamarin.iOSを使用している場合は、統合が同一でSDKにも互換性があるため、このガイドに従ってください。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいAndroidまたはiOSのプロジェクトで、.NET 6以降を使用したものを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、プロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使って「ネイティブアプリケーション」を新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、プラットフォームに応じて、これを次のURLの1つに設定します：
        • Android：YOUR_PACKAGE_NAME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS：YOUR_BUNDLE_ID://{yourDomain}/ios/YOUR_BUNDLE_ID/callback
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、プラットフォームに応じて、これを次のURLの1つに設定します：
        • Android：YOUR_PACKAGE_NAME://{yourDomain}/android/YOUR_PACKAGE_NAME/callback
        • iOS：YOUR_BUNDLE_ID://{yourDomain}/ios/YOUR_BUNDLE_ID/callback
        最後に、アプリケーションの［Application Type（アプリケーションタイプ）］が［Native（ネイティブ）］になっていることをアプリケーションの設定で必ず確認してください。
        
+
+## Auth0 SDKをインストールする
+
+
+
        .NET AndroidとiOSアプリケーションで、Auth0認証が手軽に実装できるように、Auth0はAndroidとiOSのSDKを提供しています。
        NuGetパッケージマネージャ（［Tools（ツール）］ -> ［Library Package Manager（ライブラリーパッケージマネージャー）］ -> ［Package Manager Console（パッケージマネージャーコンソール）］）を使用して、AndroidまたはiOSアプリケーションのどちらをビルドするかに応じて、Auth0.OidcClient.AndroidXまたはAuth0.OidcClient.iOSパッケージをインストールします。
        NuGetパッケージマネージャーコンソール（Install-Package）やdotnet CLI（dotnet add）を代わりに使用することもできます。
        Install-Package Auth0.OidcClient.AndroidX
+
+Install-Package Auth0.OidcClient.iOS
+
+
        
+
+
        dotnet add Auth0.OidcClient.AndroidX
+
+dotnet add Auth0.OidcClient.iOS
+
+
        
+
+
        
+
+## Auth0Clientをインスタンス化する
+
+
+
        Auth0をアプリケーションに統合するには、Auth0のドメインとクライアントIDを含むAuth0ClientOptionsのインスタンスを渡して、Auth0Clientクラスをインスタンス化します。
        using Auth0.OidcClient;
+
+
+
+var client = new Auth0Client(new Auth0ClientOptions {
+
+  Domain = "${account.namespace}",
+
+  ClientId = "${account.clientId}"
+
+}, this);
+
+
        
+
+
        SDKは初期設定で、AndroidにはChrome Custom Tabs、iOSにはASWebAuthenticationSessionを利用します。
        .NET Android/iOSクイックスタート - 手順3「チェックポイント」 
        Auth0Clientが適切にインスタンス化されました。アプリケーションを実行して次の点を確認します：
        • Auth0ClientのインスタンスがActivity（Android）またはUIViewController（iOS）で正しく作成されている。
        • アプリケーションがAuth0に関連したエラーを投入していない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## Androidを構成する {{{ data-action="code" data-code="MainActivity.cs#2:9" }}}
+
+
+
        ユーザーが認証に成功すると、このクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        Androidデバイスでコールバックを扱うには、Callback URLを扱うインテントを登録する必要があります。これを手軽に実現するには、認証フローをインスタンス化するためにLoginAsyncメソッドを呼び出したのと同じアクティビティーにインテントを登録します。
        必ず、サンプルコードにあるYOUR_ANDROID_PACKAGE_NAMEは実際のアプリケーションのパッケージ名（com.mycompany.myapplicationなど）で置き換えてください。また、DataScheme、DataHost、DataPathPrefixのテキストがすべて小文字であることを確認してください。アクティビティーにはLaunchMode = LaunchMode.SingleTaskを設定します。設定しないと、Callback URLが呼び出されるたびに、システムがアクティビティーの新しいインスタンスを作成します。
        また、ActivityクラスにあるOnNewIntentイベントでインテントを扱う必要があります。ActivityMediatorシングルトンのSendメソッドを呼び出して受け取ったURLを渡し、Auth0のOIDCクライアントに認証フローを終わらせるよう通知する必要があります。
        protected override void OnNewIntent(Intent intent)
+
+    {
+
+        base.OnNewIntent(intent);
+
+        ActivityMediator.Instance.Send(intent.DataString);
+
+    }
+
+
        
+
+
        
+
+## iOSを構成する {{{ data-action="code" data-code="AppDelegate.cs#6:11" }}}
+
+
+
        ユーザーが認証に成功すると、このクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        iOSデバイスでコールバックを扱うには、以下を行います：
        1. アプリケーションのInfo.plistファイルをVisual Studioで開いて、［Advanced（詳細）］タブに移動します。
        2. ［URL Types（URLタイプ）］にある［Add URL Type（URLタイプの追加）］ボタンをクリックします。
        3. 識別子をAuth0、URLスキーマをアプリケーションのバンドル識別子、ロールを［None（なし）］に設定します。
        これは、URLタイプを追加した後でXML表記されたinfo.plistファイルの例です：
        <key>CFBundleURLTypes</key>
+
+<array>
+
+ <dict>
+
+ <key>CFBundleTypeRole</key>
+
+ <string>None</string>
+
+ <key>CFBundleURLName</key>
+
+ <string>Auth0</string>
+
+ <key>CFBundleURLSchemes</key>
+
+ <array>
+
+ <string>YOUR_BUNDLE_IDENTIFIER</string>
+
+ </array>
+
+ </dict>
+
+</array>
+
+
        
+
+
        さらに、AppDelegateクラスにあるOpenUrlイベントでCallback URLを扱う必要があります。ActivityMediatorシングルトンのSendメソッドを呼び出して受け取ったURLを渡し、Auth0のOIDCクライアントに認証フローを終わらせるよう通知する必要があります。
        
+
+## アプリケーションにログインを追加する
+
+
+
        Auth0アプリケーションとAuth0 SDKの構成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、SDKのLoginAsync()メソッドを使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトするログインボタンを作成します。
        var loginResult = await client.LoginAsync();
+
+
        
+
+
        エラーがなければ、LoginAsync()が返すLoginResultでUser、IdentityToken、AccessToken、RefreshTokenにアクセスすることができます。
        .NET Android/iOSクイックスタート - 手順6「チェックポイント」 
        ユーザー名とパスワードを使ってログインやサインアップができるようになりました。
        ログインボタンをクリックして次の点を確認します：
        • AndroidまたはiOSアプリケーションによってAuth0のユニバーサルログインページにリダイレクトされる。
        • ログインまたはサインアップできる。
        • Auth0によってアプリケーションにリダイレクトされる。
        
+
+  
        
+
+  
        すみません。以下の点をもう一度確認してください。
        • 期待されているようにLoginAsyncを呼び出した
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのLogoutAsync()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
        await client.LogoutAsync();
+
+
        
+
+
        .NET Android/iOSクイックスタート - 手順7「チェックポイント」 
        アプリケーションを実行して、ログアウトボタンをクリックします。以下の点を確認します：
        • AndroidまたはiOSアプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
        • アプリケーションにログインしていない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいログアウトURLが構成されている
        • 期待されているようにLogoutAsyncを呼び出した
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。
        AndroidまたはiOS用のAuth0 SDKでは、LoginResult.Userプロパティを通じてユーザー情報を提供します。
        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-button.md b/ja-jp/articles/quickstart/spa/angular/files/login-button.md
new file mode 100644
index 0000000000..e23ae11430
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/login-button.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();
+  }
+}
+```
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-button.md b/ja-jp/articles/quickstart/spa/angular/files/logout-button.md
new file mode 100644
index 0000000000..15c515882b
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/logout-button.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 
+      }
+    });
+  }
+}
+```
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/main.md b/ja-jp/articles/quickstart/spa/angular/files/main.md
new file mode 100644
index 0000000000..75912e62eb
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/main.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
+      }
+    }),
+  ]
+});
+```
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/files/user-profile.md b/ja-jp/articles/quickstart/spa/angular/files/user-profile.md
new file mode 100644
index 0000000000..711e1577df
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/user-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) {}
+}
+```
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..6d191a88e9
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/interactive.md
@@ -0,0 +1,66 @@
+---
+title: Angularアプリケーションにログインを追加する
+description: このガイドは、AngularアプリケーションにAuth0 Angular SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
+interactive:  true
+files:
+ - files/main
+ - files/login-button
+ - files/logout-button
+ - files/user-profile
+github:
+  path: Sample-01
+locale: ja-JP
+---
+
+# Angularアプリケーションにログインを追加する
+
+
+
        Angularでユーザー認証を実装するための詳しい情報については、「例を挙げて説明するAngular認証ガイド」を参照してください。このガイドでは、サインアップボタンを作成する方法、ルートガードを追加する方法、そして保護されたAPIをAngularから呼び出す方法が詳しく説明されています。
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、AngularアプリケーションにAuth0 Angular SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいAngularプロジェクトを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:4200に設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:4200に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        ［Allowed Web Origin（許可されているWebオリジン）］とは、認証フローにアクセスすることを許可して欲しいURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:4200に設定してください。
        
+
+## Auth0 Angular SDKをインストールする
+
+
+
        Angularアプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はAngular SDKを提供しています。
        ターミナルで以下のコマンドを実行してAuth0 Angular SDKをインストールします：
        npm install @auth0/auth0-angular
        SDKはモジュールや認証サービスなど、Auth0をAngularアプリケーションに慣用的に統合しやすくする種類をいくつか公開しています。
        
+
+## Auth0を登録・提供する {{{ data-action="code" data-code="main.ts#7:13" }}}
+
+
+
        SDKは、SDKが機能するために必要なすべてのサービスを含んだprovide関数である、provideAuth0をエクスポートします。これをアプリケーションで登録するには、以下のようにします。
        1. main.tsファイルを開きます。
        2. @auth0/auth0-angularパッケージからprovideAuth0関数をインポートします。
        3. provideAuth0をbootstrapApplication内のprovidersに追加することで、アプリケーションに追加します。
        4. AuthServiceをAppComponentに注入します。
        provideAuth0関数はdomainプロパティとclientIdプロパティを取ります。これらのプロパティの値は、Auth0で登録したシングルページアプリケーション（SPA）の［Settings（設定）］にあるDomain（ドメイン）とClient ID（クライアントID）の値に対応します。その上に、authorizationParams.redirect_uriを構成します。これによって、認証に成功した後、Auth0はユーザーを特定のURLにリダイレクトで戻すことができます。
        Auth0を使用したカスタムドメインでは、ドメインプロパティの値は［Settings（設定）］タブに反映された値でなく、カスタムドメインの値になります。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login-button.ts#11:13" }}}
+
+
+
        Auth0アプリケーションとAuth0 Angular SDKの構成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、AuthServiceクラスからSDKのloginWithRedirect()メソッドを使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトします。そこでAuth0はユーザーを認証することができます。ユーザーが認証に成功すると、アプリケーション、およびこのクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        アプリケーションで選択時にloginWithRedirect()を呼び出すログインボタンを作成します。
        Angular手順4「チェックポイント」 
        アプリケーションにログインできるようになります。
        アプリケーションを実行し、ログインボタンを選択します。以下の点を確認します：
        • ユーザー名とパスワードを使って、ログインまたはサインアップできる。
        • アプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる。
        • 認証用にAuth0にリダイレクトされる。
        • 認証した後、Auth0はアプリケーションにリダイレクトで戻される。
        • コンソールでAuth0に関連したエラーを受け取らない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいauthorizationParams.redirect_uriが構成されていることを確認します
        • モジュールの宣言にLogoutButtonComponentボタンが追加されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout-button.ts#19:25" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKには、AuthServiceクラスでアプリからユーザーをログアウトするのに使用できるlogout()メソッドが用意されています。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、アプリケーションとこのクイックスタートで先ほどセットアップしたログアウトURLへとリダイレクトで戻されます。
        アプリケーションで選択時にlogout()を呼び出すログアウトボタンを作成します。
        SDKによってAuthServiceクラスでisAuthenticated$ Observableが公開されることで、ユーザーが認証されているかどうかを確認することができます。isAuthenticated$ Observableの値に基づいて、条件付きでログインボタンとログアウトボタンを作成することができます。または、シングルボタンを使って、ログインとログアウトの両方のボタンと条件付きレンダリングを組み合わせることができます。
        Angular手順5「チェックポイント」 
        アプリケーションからログアウトできるようになります。
        アプリケーションを実行し、ログインし、ログアウトボタンを選択します。以下の点を確認します：
        • Auth0のログアウトエンドポイントにリダイレクトされている。
        • Auth0がアプリケーションと正しいログアウトURLへのリダイレクトで戻される。
        • アプリケーションにログインしていない。
        • コンソールでAuth0に関連したエラーを受け取らない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログアウトURLが［Allowed Logout URLs（許可されているログアウトURL）］としてアプリケーションの［Settings（設定）］で構成されていることを確認します
        • モジュールの宣言にLogoutButtonComponentが追加されていることを確認します
        • アプリケーションログで他にもエラーがないかを調べます
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済みのユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真を表示することで、ユーザーインターフェイスをパーソナライズできるようになりたいかもしれません。
        Auth0 Angular SDKは、AuthServiceクラスによって公開されたuser$ Observableを介してユーザー情報を提供します。user$ Observableにはユーザーのアイデンティティに関する機密情報とアーティファクトが含まれるため、この方法が使用できるかはユーザーの認証ステータスによります。幸い、user$ Observableは、isAuthenticated$ Observableがtrueである場合にのみ値を出力するよう構成されています。そのため、ユーザープロファイルデータにアクセスする前に、認証状態を手動で確認する必要はありません。
        SDKは、AuthServiceクラスでユーザーが認証されているかどうかを確認することができるisAuthenticated$ Observableも公開します。これを使って、たとえば、UI要素を表示・非表示にするかを判断することができます。
        インタラクティブパネルでUserProfileComponentコードを確認し、これらの関数の使用方法の例をチェックします。
        Angular手順6「チェックポイント」 
        ユーザープロファイル情報を表示することができるようになります。
        アプリケーションを実行して次の点を確認します：
        • ログイン後にユーザー情報が正しく表示される。
        • ログアウト後にユーザー情報が表示されない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログインしていることを確認します
        • user.nameなど、既存のプロパティにアクセスしようとしていることを確認します
        • 正しいモジュールの宣言にUserProfileComponentコンポーネントが追加されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/main_view.md b/ja-jp/articles/quickstart/spa/flutter/files/main_view.md
new file mode 100644
index 0000000000..3d1a6f111c
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/files/main_view.md
@@ -0,0 +1,58 @@
+---
+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/files/profile_view.md b/ja-jp/articles/quickstart/spa/flutter/files/profile_view.md
new file mode 100644
index 0000000000..34ada342a4
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/files/profile_view.md
@@ -0,0 +1,26 @@
+---
+name: profile_view.dart
+language: javascript
+---
+    
+```javascript
+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..783f284340
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/interactive.md
@@ -0,0 +1,77 @@
+---
+title: Flutterアプリケーションにログインを追加する
+description: このガイドでは、FlutterアプリケーションにAuth0 Flutter SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/main_view
+ - files/profile_view
+github:
+  path: sample
+locale: ja-JP
+---
+
+# Flutterアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドでは、FlutterアプリケーションにAuth0 Flutter SDKを使ってAuth0を統合する方法を説明します。
        Flutter SDKは現在、Android、iOS、またはWebプラットフォームで実行されるFlutterアプリケーションのみに対応しています。
        このクイックスタートでは、すでにFlutterアプリケーションが問題なく作動しているものとします。そうでない場合は、Flutter「入門」ガイドをチェックして、シンプルなアプリの始め方を確認してください。
        Flutterコマンドラインツールの知識も必要になります。
        
+
+## Auth0を構成する
+
+
+
        Auth0にサインアップすると、新しいアプリケーションが作成されたか、あるいは既に作成していた可能性があります。Auth0と通信するためのアプリケーションに関する詳細が必要になります。これらの詳細は、Auth0 Dashboardのアプリケーションの設定セクションで入手することができます。
        null
        ネイティブまたはシングルページアプリケーションでデフォルトのアプリを使用する場合は、［Token Endpoint Authentication Method（トークンエンドポイント認証方法）］をNoneに更新し、［Application Type（アプリケーションタイプ）］をSPAまたはNativeに設定していることを確認します。
        必要な情報は以下のとおりです。
        • Domain（ドメイン）
        • Client ID（クライアントID）
        このページの上部からサンプルをダウンロードする場合、これらの詳細は入力されています。
        Callback URLを構成する
        Callback URLとは、Auth0によって認証後のユーザーをリダイレクトするアプリケーション内URLです。アプリのCallback URLは、アプリケーションの設定で［Allowed Callback URLs（許可されているコールバックURL）］フィールドに追加される必要があります。このフィールドが設定されていない場合、ユーザーはアプリケーションにログインできず、エラーが返されます。
        このページの上部からダウンロードしたサンプルプロジェクトに沿って進めている場合には、［Allowed Callback URLs（許可されているコールバックURL）］にhttp://localhost:3000を設定します。
        ログアウトURLを構成する
        ログアウトURLとは、ユーザーが認可サーバーからログアウトした後にAuth0が戻ることができるアプリケーション内URLです。これは、returnToクエリパラメーターで指定されています。アプリのログアウトURLは、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］フィールドに追加される必要があります。このフィールドが設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーが返されます。
        このページの上部からダウンロードしたサンプルプロジェクトに沿って進めている場合には、［Allowed Logout URLs（許可されているログアウトURL）］フィールドに追加する必要があるログアウトURLはhttp://localhost:3000です。
        許可されているWebオリジンを構成する
        アプリのURLをアプリケーションの設定で［Allowed Web Origins（許可されているWebオリジン）］フィールドに追加する必要があります。ここでアプリケーションURLを登録しないと、アプリケーションは認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        このページの上部からダウンロードしたサンプルプロジェクトに沿って進めている場合には、［Allowed Web Origins（許可されているWebオリジン）］をhttp://localhost:3000に設定します。
        
+
+## Auth0 Flutter SDKをインストールする
+
+
+
        Auth0 Flutter SDKをプロジェクトに追加します：
        flutter pub add auth0_flutter
+
+
        
+
+
        以下のスクリプトタグをindex.htmlページに追加します：
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js" defer></script>
+
+
        
+
+
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="main_view.dart" }}}
+
+
+
        アプリに認証をセットアップするには、ユニバーサルログインが最も手軽な方法です。最良のエクスペリエンス、高い安全性、幅広い機能を活用するためにも、ユニバーサルログインの使用をお勧めします。
        Auth0Webクラスを使用して、Auth0のユニバーサルログインをFlutter Webアプリに統合します。loginWithRedirect()を使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトします。
        通常、redirectUrlパラメーターをloginWithRedirectに指定する必要があります。この操作を省くと、Auth0はデフォルトで構成されていない、デフォルトのログインルートを使用することになります。
        ユーザーはログインすると、リダイレクトでアプリケーションに戻されます。次に、起動中にonLoadを呼び出し、付与された資格情報を処理することで、このユーザーのIDとアクセストークンにアクセスすることができます。
        auth0.onLoad().then((final credentials) => setState(() {
+
+    // Handle or store credentials here
+
+    _credentials = credentials;
+
+  }));
+
+
        
+
+
        Flutter web手順3「チェックポイント」 
        loginWithRedirect()を呼び出してアプリにユーザーをログインするボタンをアプリに追加します。認証のためにAuth0へリダイレクトされてから、アプリケーションに戻されることを確認します。
        onLoadを呼び出した結果、credentialsにアクセスできることと、IDとアクセストークンにアクセスできることを確認します。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • ［Allowed Callback URLs（許可されているCallback URL）］が正しく設定されていることを確認します
        • URLを入力した後で保存したことを確認します
        • ドメインとクライアントIDの値が正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する
+
+
+
        ユーザーをログアウトさせるには、Auth0 Flutter SDKのlogout()を呼び出してログインセッションをクリアし、ユーザーをAuth0のログアウトエンドポイントにリダイレクトします。Auth0からのログアウトについて詳しい情報をお読みください。
        通常、logoutを呼び出すときにreturnToUrlを指定しますが、そうしない場合、Auth0は ［Allowed Logout URLs（許可されているログアウトURL）］リストの最初のURLにデフォルトで指定されます。
        Flutter web手順4「チェックポイント」 
        logout()を呼び出し、ユーザーをアプリケーションからログアウトするアプリにボタンを追加します。このボタンを選択すると、Flutterアプリがログアウトエンドポイントにリダイレクトしてからもう一度戻ることを確認します。アプリケーションにはログインされていないはずです。
        
+
+  
        
+
+  
        アプリケーションが正常にログアウトしなかった場合は以下を行います。
        • ［Allowed Logout URLs（許可されているログアウトURL）］が正しく設定されていることを確認します
        • URLを入力した後で保存したことを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
        ユーザープロファイルは、ページが読み込まれるとユーザープロファイルプロパティを自動的に取得し、アプリケーション起動中にonLoadを呼び出すことでアクセス・保存することができます。onLoadから返されたオブジェクトには、すべてのユーザープロファイルプロパティのあるuserプロパティが含まれています。これらはIDトークンをデコードすることで内部で入力されます。
        Flutter web手順5「チェックポイント」 
        ログインして、結果のuserプロパティを調査します。emailやnameなど、現在のユーザーのプロファイル情報を確認します。
        
+
+  
        
+
+  
        アプリケーションがユーザープロファイル情報を返さなかった場合には以下を行います。
        • IDトークンが有効であることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..2efeee2d47
--- /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(
+
+    
+  ,
+);
+```
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..f490be840d
--- /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;
+```
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..466de32532
--- /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;
+```
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..032891f7bb
--- /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;
+```
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..93ebac4457
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Reactアプリケーションにログインを追加する
+description: このガイドは、新規または既存のReactアプリケーションにAuth0 React SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: Sample-01
+locale: ja-JP
+---
+
+# Reactアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、ReactアプリケーションにAuth0 React SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいReactアプリケーションを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        Reactでユーザー認証を実装するための詳しい情報については、例を挙げて説明するReact認証ガイドを参照してください。このガイドでは、サインアップボタンを作成する方法、React Routerを使用してルートガードを追加する方法、そして保護されたAPIをReactから呼び出す方法が詳しく説明されています。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        Allowed Web Origin（許可されているWebオリジン）とは、認証フローへのアクセスを許可されるURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## Auth0 React SDKをインストールする {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Reactアプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はReact SDK（auth0-react.js）を提供しています。
        ターミナルで以下のコマンドを実行してAuth0 React SDKをインストールします：
        cd <your-project-directory>
+
+npm install @auth0/auth0-react
+
+
        
+
+
        Auth0Providerコンポーネントを構成する
        SDKが正しく機能するためには、次のプロパティをAuth0Providerコンポーネントで設定しなければなりません：
        • domain：Auth0テナントのドメインです。通常、Auth0 Dashboardにあるアプリケーションの設定の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合は、その値を代わりに設定してください。
        • clientId：このクイックスタートで前にセットアップした、Auth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの設定の［Client ID（クライアントID）］フィールドで確認できます。
        • authorizationParams.redirect_uri：ユーザー認証の後、Auth0にユーザーをリダイレクトして欲しいアプリケーション内URLです。このクイックスタートで前にセットアップしたCallback URLと呼応します。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Callback URLs（コールバックURL）］フィールドでもこの値を確認できます。コードに入力した値と前にセットアップした値は必ず一致させてください。異なった場合はユーザーにエラーが表示されます。
        Reactクイックスタート - 手順2「チェックポイント」 
        Auth0Providerコンポーネントが適切に構成されました。アプリケーションを実行して次の点を検証します：
        • SDKが正しく初期化している。
        • アプリケーションがAuth0に関連したエラーを投入していない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login.js" }}}
+
+
+
        Auth0アプリケーションとAuth0 React SDKの構成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、SDKのloginWithRedirect()メソッドを使用して、ユーザをAuth0のユニバーサルログインページにリダイレクトするログインボタンを作成します。ユーザーが認証に成功すると、このクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        このガイドではuseAuth0()のカスタムReactフックに焦点を当てています。クラスコンポーネントを使用している場合は、withAuth0()を使用したこちらのサンプルを確認してください。
        ログインボタンコンポーネントのためにアプリケーションでlogin.jsという名前の新規ファイルを作成し、インタラクティブパネルから右へとコードにコピーします。これにはログインに必要なロジックが含まれています。それからindex.jsファイルを更新して新しいログインボタンを含めます。
        Reactクイックスタート - 手順3「チェックポイント」 
        ユーザー名とパスワードを使ってログインやサインアップができるようになりました。
        ログインボタンをクリックして次の点を検証します：
        • ReactアプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる。
        • ログインまたはサインアップできる。
        • Auth0が、Auth0Providerを構成するために使ったauthorizationParams.redirect_uriの値を使用し、アプリケーションへリダイレクトする。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいauthorizationParams.redirect_uriが構成されている
        • ログインボタンがindex.jsファイルに追加されている
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.js" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのlogout()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
        ログアウトボタンコンポーネントのためにアプリケーションでlogout.jsという名前の新規ファイルを作成し、インタラクティブパネルからコードにコピーします。これにはログアウトに必要なロジックが含まれています。それからindex.jsファイルを更新して新しいログアウトボタンを含めます。
        Reactクイックスタート - 手順4「チェックポイント」 
        アプリケーションを実行してログアウトボタンをクリックし、次の点を検証します：
        • Reactアプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の一つに指定したアドレスへリダイレクトされる。
        • アプリケーションにログインしていない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいログアウトURLが構成されている
        • ログアウトボタンがindex.jsファイルに追加されている
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロファイル画像をプロジェクトに表示できるようになりたいかもしれません。
        React用のAuth0 SDKでは、userプロパティを通じてユーザー情報を提供します。インタラクティブパネルでprofile.jsコードを確認し、使用方法の例をチェックします。
        userプロパティにはユーザーのアイデンティティに関する機密情報が含まれるため、この方法が使用できるかはユーザーの認証ステータスによります。エラーを防ぐため、常に以下を行ってください：
        • Reactがuserプロパティを使用するコンポーネントを呼び出す前に、isAuthenticatedプロパティを使用してAuth0がユーザーを認証したかどうかを定義する。
        • isAuthenticatedプロパティにアクセスする前に、isLoadingがfalseであることをチェックして、SDKの読み込みが完了したことを確認する。
        null
        Reactクイックスタート - 手順5「チェックポイント」 
        以下の点を確認します：
        • ログイン後、コンポーネント内のuser.name やその他のユーザープロパティをすべて正しく表示できる。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • isAuthenticatedプロパティへのアクセス以前にisLoadingの確認が追加されている
        • Profileコンポーネントがindex.jsファイルに追加されている
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..52be06a92e
--- /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..8305c130e4
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/interactive.md
@@ -0,0 +1,78 @@
+---
+title: JavaScriptアプリケーションにログインを追加する
+description: このガイドは、単純なJavaScriptを使用するシングルページアプリケーション（SPA）にAuth0 SPA SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
+interactive:  true
+files:
+ - files/app
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# JavaScriptアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、単純なJavaScriptを使用するシングルページアプリケーション（SPA）にAuth0 SPA SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいプロジェクトを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        このクイックスタートでは、ReactやAngularなどのフレームワークを使用しているのでなく、単純なJavaScriptアプリケーションにAuth0を追加しているものとします。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadでセットアップしたアプリケーションが必要です。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        ［Allowed Web Origin（許可されているWebオリジン）］とは、認証フローにアクセスすることを許可して欲しいURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## Auth0 SPA SDKを追加する
+
+
+
        JavaScriptアプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はSPA SDK（auth0-spa-js）を提供しています。Auth0 SPA SDKはNPMパッケージとして、またはCDNからインストールすることができます。このクイックスタートの目的上、CDNを使用します。HTMLページにこのスクリプトタグを含めます。
        <script src="https://cdn.auth0.com/js/auth0-spa-js/2.0/auth0-spa-js.production.js"></script>
+
+
        
+
+
        
+
+## Auth0クライアントを作成する {{{ data-action="code" data-code="app.js#1:7" }}}
+
+
+
        Auth0 SPA SDKで提供されているAuth0クライアントの新規インスタンスを作成し、このクイックスタートで前に作成したAuth0アプリケーションの詳細を提供します。
        ユーザーが以前にログインしている場合、クライアントはページの読み込み時に認証状態を更新します。ページが更新されても、ユーザーはこれまでと変わらずログインされます。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="app.js#8:14" }}}
+
+
+
        Auth0アプリケーションの構成、Auth0 SPA SDKの追加、Auth0クライアントの作成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、SDKのloginWithRedirect()メソッドを使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトします。ここでAuth0はユーザーを認証することができます。ユーザーが認証に成功すると、このクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        アプリケーションで選択時にloginWithRedirect()を呼び出すログインボタンを作成します。
        Javascriptクイックスタート手順4「チェックポイント」 
        アプリケーションにログインできるようになります。
        アプリケーションを実行し、ログインボタンを選択します。以下の点を確認します：
        • ユーザー名とパスワードを使って、ログインまたはサインアップできる
        • アプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる
        • 認証用にAuth0にリダイレクトされる
        • 認証した後、Auth0はユーザーをアプリケーションにリダイレクトで戻す
        • コンソールでAuth0に関連したエラーを受け取らない
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存したことを確認します
        • Auth0クライアントがAuth0のドメインとクライアントIDで正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## Auth0からのコールバックを処理する {{{ data-action="code" data-code="app.js#16:21" }}}
+
+
+
        ブラウザーでアプリケーションプロセスへとリダイレクトで戻されると、アプリケーションはAuth0からのコールバックを検出した場合にのみ、Auth0クライアントでhandleRedirectCallback()関数を呼び出します。これを実行する1つの方法は、codeとstateのクエリパラメーターが検出されたときに、handleRedirectCallback()のみを呼び出すことです。
        コールバックの処理に成功すると、パラメーターはURLから削除されます。これによって、次回ページが読み込まれても、コールバックハンドラーがトリガーされることはありません。
        Javascriptクイックスタート手順5「チェックポイント」 
        Auth0からのコールバックが正しく処理されます。
        アプリケーションを実行し、ログインボタンをもう一度選択します。以下の点を確認します：
        • 認証した後、Auth0はアプリケーションにリダイレクトで戻される。
        • クエリパラメータがURLから削除される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • アプリケーションのURLにredirect_uriオプションが構成されていることを確認します
        • errorクエリパラメーターがある場合は、それを調べてエラーの原因を確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="app.js#23:29" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。Auth0クライアントには、アプリからユーザーをログアウトするのに使用できるlogout()メソッドが用意されています。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、アプリケーションとこのクイックスタートで先ほどセットアップしたログアウトURLへとリダイレクトで戻されます。
        アプリケーションで選択時にlogout()を呼び出すログアウトボタンを作成します。
        SDKによってisAuthenticated()関数が公開されることで、ユーザーが認証されているかどうかを確認することができます。isAuthenticated()関数の値に基づいて、条件付きでログインボタンとログアウトボタンを表示することができます。または、シングルボタンを使って、ログインとログアウトの両方のボタンと条件付きレンダリングを組み合わせることができます。
        javascriptクイックスタート手順6「チェックポイント」 
        アプリケーションからログアウトできるようになります。
        アプリケーションを実行し、ログインし、ログアウトボタンを選択します。以下の点を確認します：
        • Auth0のログアウトエンドポイントにリダイレクトされている。
        • Auth0がアプリケーションと正しいログアウトURLへのリダイレクトで戻される。
        • アプリケーションにログインしていない。
        • コンソールでAuth0に関連したエラーを受け取らない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • ログアウトURLが［Allowed Logout URLs（許可されているログアウトURL）］としてアプリケーションの［Settings（設定）］で構成されていることを確認します
        • アプリケーションログで他にもエラーがないかを調べます
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="app.js#31:45" }}}
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済みのユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真を表示することで、ユーザーインターフェイスをパーソナライズできるようになりたいかもしれません。
        Auth0 SPA SDKは、Auth0クライアントによって公開されたgetUser()関数を介してユーザー情報を提供します。Auth0クライアントは、ユーザーが認証されているかどうかを確認することができるisAuthenticated()関数も公開します。これを使って、たとえば、UI要素を表示・非表示にするかを判断することができます。インタラクティブパネルでコードを確認し、これらの関数の使用方法の例をチェックします。
        Javascriptクイックスタート手順7「チェックポイント」 
        ユーザープロファイル情報を表示することができるようになります。
        アプリケーションを実行して次の点を確認します：
        • ログイン後にユーザー情報が正しく表示される。
        • ログアウト後にユーザー情報が表示されない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • これまでの手順がすべて問題なく動作することを確認します
        • 認証状態に対する応答でUIを管理するコードを確認します
        • アプリケーションログでサイレント認証に関連のエラーが他にもないか調べます
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..7f2f476128
--- /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');
+```
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..21ef76110f
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/login.md
@@ -0,0 +1,37 @@
+---
+name: login.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..6e0420788f
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..97966a2320
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/profile.md
@@ -0,0 +1,50 @@
+---
+name: profile.js
+language: javascript
+---
+    
+```javascript
+
+
+```
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..bd0d484ed9
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/interactive.md
@@ -0,0 +1,73 @@
+---
+title: Vueアプリケーションにログインを追加する
+description: このガイドは、VueアプリケーションにAuth0 Vue SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Vueアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに認証を追加することができます。このガイドは、VueアプリケーションにAuth0 Vue SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートは、Vue 3アプリケーションでAuth0 Vueを使用するために設計されています。Vue 2を使用している場合は、Auth0 SPA SDKを使ったVue 2チュートリアルを確認するか、「例を挙げて説明するVue.js認証2」ガイドを参照してください。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントを使用するか、Auth0にサインアップします。
        • 統合する作業中のVueプロジェクト、または、ログインした後に、サンプルアプリケーションをダウンロードすることができます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        ［Allowed Web Origin（許可されているWebオリジン）］とは、認証フローにアクセスすることを許可して欲しいURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## Auth0 Vue SDKをインストールする {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Vue 3アプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はVue SDKを提供しています。
        ターミナルで以下のコマンドを実行してAuth0 Vue SDKをインストールします：
        cd <your-project-directory>
+
+npm install @auth0/auth0-vue
+
+
        
+
+
        プラグインを登録する
        SDKが機能するには、以下のプロパティを使ってVueアプリケーションでプラグインを登録する必要があります。
        • domain：Auth0テナントのドメインです。この値は、Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Domain（ドメイン）］フィールドにあります。カスタムドメインを使用している場合は、この値をカスタムドメインの値に設定してください。
        • clientId：このクイックスタートで前にセットアップした、Auth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認してください。
        • authorizationParams.redirect_uri：ユーザー認証の後、Auth0にユーザーをリダイレクトして欲しいアプリケーション内URLです。このクイックスタートで前にセットアップしたCallback URLと呼応します。この値は、Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Callback URLs（コールバックURL）］フィールドにあります。コードに入力した値と前にセットアップした値は必ず一致させてください。異なった場合はユーザーにエラーが表示されます。
        プラグインは、provideとapp.config.globalPropertiesの両方を使ってSDKを登録します。これによって、Composition APIとOptions APIの両方が有効になります。
        vueクイックスタート手順2「チェックポイント」 
        プラグインが構成されました。アプリケーションを実行して次の点を確認します：
        • SDKが正しく初期化している
        • アプリケーションがAuth0に関連したエラーを投入していない
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で変更内容を保存します
        • ドメインとクライアントIDが正常にインポートされていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login.js" }}}
+
+
+
        次に、プロジェクト用のログインを設定します。useAuth0の返り値に表示されたSDKのloginWithRedirect関数を使用します。これには、コンポーネントのsetup関数でアクセスすることができます。ユーザーはAuth0ユニバーサルログインページにリダイレクトされ、ユーザーの認証後、このクイックスタートで前に設定したCallback URLにリダイレクトされます。
        Options APIの使用
        Options APIでは、thisアクセサを通じてグローバル$auth0プロパティからの同じloginWithRedirectメソッドを使用することができます。
        Vueクイックスタート手順3「チェックポイント」 
        Auth0ユニバーサルログインからログインできるようになります。
        ログインボタンをクリックして次の点を確認します：
        • VueアプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる
        • ログインまたはサインアップできる
        • Auth0が、プラグインを構成するために使ったauthorizationParams.redirect_uriの値を使用し、アプリケーションへリダイレクトする。
        
+
+  
        
+
+  
        Auth0のユニバーサルログインを使用してログインできない場合には以下を行います。
        • 正しいauthorizationParams.redirect_uriが構成されていることを確認します
        • ドメインとクライアントIDが正しく設定されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.js" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。ユーザーがログアウトすると、アプリケーションによってAuth0 logoutエンドポイントにリダイレクトされてから、指定されたlogoutParams.returnToパラメーターにリダイレクトされます。
        useAuth0の返り値に表示されたlogout関数を使用します。これには、コンポーネントのsetup関数でアクセスすることができ、ユーザーをアプリケーションからログアウトします。
        Options APIの使用
        Options APIでは、thisアクセサを通じてグローバル$auth0プロパティからの同じlogoutメソッドを使用することができます。
        vueクイックスタート手順4「チェックリスト」 
        アプリケーションを実行してログアウトボタンをクリックし、次の点を検証します：
        • VueアプリケーションによってlogoutParams.returnToアドレスにリダイレクトされる
        • アプリケーションにログインしていない
        
+
+  
        
+
+  
        ログアウトできない場合には以下を行います。
        • logoutを呼び出すときにlogoutParams.returnToの値が指定されていることを確認します
        • ［Application Settings（アプリケーションの設定）］で［Allowed Logout URLs（許可されているログアウトURL）］にreturnTo値が含まれていることを確認します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        次に、認証ユーザーに関連するプロファイル情報を取得する方法を構成します。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。ユーザーが認証を行うと、SDKはユーザーのプロファイル情報を抽出し、メモリ内に保存します。アプリケーションは、リアクティブなuserプロパティを使ってユーザープロファイルにアクセスすることができます。このプロパティにアクセスするには、コンポーネントのsetup関数を確認し、userAuth0返り値を見つけます。
        userプロパティには、ユーザーIDに関する機微な情報が含まれています。これは、ユーザーの認証ステータスに基づいてのみ利用できます。エラーを防ぐため、常に以下を行ってください：
        • Vueがuserプロパティを使用するコンポーネントを呼び出す前に、isAuthenticatedプロパティを使用してAuth0がユーザーを認証したかどうかを定義する。
        • isAuthenticatedプロパティにアクセスする前に、isLoadingがfalseであることをチェックして、SDKの読み込みが完了したことを確認する。
        Options APIの使用
        Options APIでは、アクセサthisを通じてグローバル$auth0プロパティからの同じリアクティブなuser、isLoading、およびisAuthenticatedプロパティを使用します。
        vue手順5「チェックポイント」 
        以下の点を確認します：
        • ログイン後、コンポーネント内のuserやその他のユーザープロパティをすべて正しく表示できる
        
+
+  
        
+
+  
        userプロパティで問題が発生している場合には以下を行います。
        • isAuthenticatedプロパティへのアクセス以前にisLoadingの確認が追加されていることを確認します
        • userプロパティへのアクセス以前にisAuthenticatedの確認が追加されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/files/auth_openidc.md b/ja-jp/articles/quickstart/webapp/apache/files/auth_openidc.md
new file mode 100644
index 0000000000..44d311ab8e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/files/auth_openidc.md
@@ -0,0 +1,23 @@
+---
+name: auth_openidc.conf
+language: 
+---
+    
+```
+OIDCProviderMetadataURL https://${account.namespace}/.well-known/openid-configuration OIDCClientID ${account.clientId} 
+OIDCClientSecret ${account.clientSecret}
+OIDCScope "openid name email" 
+OIDCRedirectURI https://your_apache_server/your_path/redirect_uri/ OIDCCryptoPassphrase  
+
+ 
+   AuthType openid-connect 
+   Require valid-user 
+   LogLevel debug 
+
+
+ 
+   AuthType openid-connect 
+   #Require valid-user 
+   Require claim folder:admin 
+
+```
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..d90cb29e77
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/index.yml
@@ -0,0 +1,20 @@
+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
+hidden_articles:
+  - "interactive"
+contentType: tutorial
+useCase: quickstart
diff --git a/ja-jp/articles/quickstart/webapp/apache/interactive.md b/ja-jp/articles/quickstart/webapp/apache/interactive.md
new file mode 100644
index 0000000000..722d3e90f4
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,49 @@
+---
+title: Apache
+description: このチュートリアルでは、Webアプリに認証と認可を追加するために、Apacheを構成する方法について説明します。
+interactive:  true
+files:
+ - files/auth_openidc
+locale: ja-JP
+---
+
+# Apache
+
+
+
        このチュートリアルでは、Webアプリに認証と認可を追加するために、Apacheを構成する方法について説明します。ログインして、アカウント用に構成された例を参考にこのクイックタートに従うことをお勧めします。
        システム要件
        このチュートリアルとサンプルプロジェクトは次を使用してテストが完了しています：
        • Apache 2.4
        
+
+## mod_auth_openidcモジュールをインストールして有効にする
+
+
+
        まず、Apacheにmod_auth_openidcモジュールをインストールする必要があります。
        GitHubからバイナリを取得して、OSにインストールすることができます。OSがバイナリのどれとも互換でない場合には、ソースからビルドすることができます。
        モジュールをインストールしたら、a2enmodコマンドを実行して、Apacheで有効化します。詳細については、Ubuntu Manpageでの2enmodで次を参照してください：
        a2enmod auth_openidc
        Windowsについては、こちらのPowershellスクリプトを使用すると、システム上でa2enmodを動作させることができます。
        
+
+## Auth0アカウント情報でモジュールを構成する {{{ data-action="code" data-code="auth_openidc.conf#1:12" }}}
+
+
+
        新しい構成ファイル（auth_openidc.conf）を更新します。このファイルは/etc/apache2/mods-availableフォルダーにあります。
        Windowsでは、/apache/conf/httpd.confファイルを使用する必要があります
        
+
+## Auth0を構成する
+
+
+
        Auth0 Dashboardで以下を行います。
        1. ［Applications（アプリケーション）］ > ［Applications（アプリケーション）］に移動し、リストからアプリケーションを選択します。
        2. ［Settings（設定）］ビューに切り替えて、［Application URIs（アプリケーションURL）］セクションを見つけます。
        3. OIDCRedirectURIの値を［Allowed Callback URLs（許可されているCallback URL）］に追加します。
        4. ページ下部の［Advanced Settings（詳細設定）］を見つけます。
        5. ［OAuth］ビューに切り替えます。
        6. ［JSON Web Token (JWT) Signature Algorithm（JSON Web Token（JWT）署名アルゴリズム）］をRS256に設定します。
        
+
+## 認可 {{{ data-action="code" data-code="auth_openidc.conf#14:18" }}}
+
+
+
        Apacheを構成して、ユーザーのIDトークンにあるクレームの値を基に特定の場所を保護することができます。これを行うには、Locationブロックをauth_openidc.confファイルに追加します。
        たとえば、ユーザーのロールを読み出すアクションを作成して、保護された場所へのアクセスを付与するクレームを追加することができます：
        exports.onExecutePostLogin = async (event, api) => {
+
+  const roles = event.authorization.roles; // ['user', 'admin']
+
+
+
+  if (roles.includes('admin')) {
+
+    api.idToken.setCustomClaim('folder', 'admin');
+
+  }
+
+};
+
+
        
+
+
        
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/Login.cshtml.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.md
new file mode 100644
index 0000000000..bc1fc7b36d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/Login.cshtml.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);
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.md
new file mode 100644
index 0000000000..9e54f3d16d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/Logout.cshtml.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);
+    }
+}
+```
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..b20d6763a5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
@@ -0,0 +1,37 @@
+---
+name: Profile.razor
+language: 
+---
+    
+```
+@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();
+    }
+}
+```
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..80c23e3cb0
--- /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();
+```
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..3215b694cd
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
@@ -0,0 +1,61 @@
+---
+title: Blazor Serverアプリケーションにログインを追加する
+description: このガイドは、新規または既存のBlazor ServerアプリケーションにAuth0.AspNetCore.Authentication SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/Login.cshtml
+ - files/Logout.cshtml
+ - files/Profile
+ - files/Program
+github:
+  path: Quickstart/Sample
+locale: ja-JP
+---
+
+# Blazor Serverアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、新規または既存のBlazor ServerアプリケーションにAuth0.AspNetCore.Authentication SDKを使ってAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## SDKをインストールして構成する {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        NuGetからインストールする
        Auth0をBlazor Serverと統合するには、Auth0.AspNetCore.AuthenticationNuGetパッケージをアプリケーションにインストールすることでSDKを使用できます。
        ミドルウェアを構成する
        Blazor Serverアプリケーションで認証を可能にするには、SDKが提供するミドルウェアを使います。Program.csファイルに移動してbuilder.Services.AddAuth0WebAppAuthentication()を呼び出し、SDKのミドルウェアを登録します。
        DomainとClientIdは必ず構成してください。SDKがどのAuth0テナントとアプリケーションを使用すべきかを認識するために必要となるフィールドです。
        認証と認可がProgram.csファイルで有効になったことを確認します。
        
+
+## ログイン {{{ data-action="code" data-code="Login.cshtml.cs" }}}
+
+
+
        Blazor Serverアプリケーションにユーザーをログインさせるには、LoginModelをPagesディレクトリに追加します。
        LoginModelのOnGetメソッド内でHttpContext.ChallengeAsync()を呼び出し、Auth0Constants.AuthenticationSchemeを認証スキームとして渡します。これにより当社のSDKが内部に登録しているOIDC認証ハンドラーが発動されます。関連するauthenticationPropertiesも必ず指定してください。構築はLoginAuthenticationPropertiesBuilderで行えます。
        HttpContext.ChallengeAsync()の呼び出し成功後、ユーザーはAuth0にリダイレクトされます。その後アプリケーションにリダイレクトで戻された際に、OIDCミドルウェアとクッキーミドルウェアの両方にサインインしています。これにより、ユーザーは後続の要求でも認証されるようになります。
        ASP.NET Core Blazor Server - 手順3 - チェックポイント 
        Loginの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Loginページに移動すると、Auth0にリダイレクトされる。
        • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="Profile.razor" }}}
+
+
+
        ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、AuthenticationStateを介して利用できるようにします。これはCascadingParameterとして追加できます。
        ユーザーの名前や追加クレーム（メールアドレスや画像など）を表示するカスタムのユーザープロファイルページは、AuthenticationStateのUserプロパティから関連情報を取得し、Blazorコード内からビューに渡すことで作成できます。
        ASP.NET Core Blazor Server - 手順4 - チェックポイント 
        ユーザープロファイルを表示するようセットアップし終えたら、アプリケーションを実行して次の点を確認します：
        • ログイン成功後にプロファイルを含んだエンドポイントに移動すると、ユーザーのプロファイルが表示される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ログアウト {{{ data-action="code" data-code="Logout.cshtml.cs" }}}
+
+
+
        LogoutModelのOnGetメソッド内からHttpContext.SignOutAsyncをCookieAuthenticationDefaults.AuthenticationScheme認証スキームで呼び出すと、ユーザーをアプリケーションからログアウトさせられます。
        さらに、ユーザーをAuth0からもログアウトさせたい場合は（これによりシングルサインオンに依拠している他のアプリケーションからもログアウトさせる可能性があります）、HttpContext.SignOutAsyncをAuth0Constants.AuthenticationScheme認証スキームで呼び出します。また、LogoutAuthenticationPropertiesBuilderを使って構築できる適切なauthenticationPropertiesも同じ認証スキームで呼び出します。
        ASP.NET Core Blazor Server - 手順5 - チェックポイント 
        Logoutの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Logoutページに移動すると、ユーザーがログアウトする。
        • Auth0からもログアウトすると、Auth0にリダイレクトされ、即座にアプリケーションにリダイレクトで戻される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/AccountController.md b/ja-jp/articles/quickstart/webapp/aspnet-core/files/AccountController.md
new file mode 100644
index 0000000000..52bd2b6799
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/files/AccountController.md
@@ -0,0 +1,62 @@
+---
+name: AccountController.cs
+language: javascript
+---
+    
+```javascript
+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
+    );
+  }
+}
+```
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..8e344581e6
--- /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}"
+  }
+}
+```
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..9383bb20e1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: javascript
+---
+    
+```javascript
+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();
+```
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..c370d253b1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/interactive.md
@@ -0,0 +1,60 @@
+---
+title: ASP.NET MVCアプリケーションにログインを追加する
+description: このガイドは、新規または既存のASP.NET MVCアプリケーションにAuth0.AspNetCore.Authentication SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/Program
+ - files/appsettings
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: ja-JP
+---
+
+# ASP.NET MVCアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、新規または既存のASP.NET MVCアプリケーションにAuth0.AspNetCore.Authentication SDKを使ってAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## SDKをインストールして構成する {{{ data-action="code" data-code="Program.cs" }}}
+
+
+
        Nugetからインストールする
        Auth0をASP.NET Coreと統合するには、Auth0.AspNetCore.AuthenticationNugetパッケージをアプリケーションにインストールすることでSDKを使用できます。
        ミドルウェアを構成する
        ASP.NET Coreアプリケーションで認証を可能にするには、SDKが提供するミドルウェアを使います。Program.csファイルに移動してbuilder.Services.AddAuth0WebAppAuthentication()を呼び出し、SDKのミドルウェアを登録します。
        DomainとClientIdは必ず構成してください。SDKがどのAuth0テナントとアプリケーションを使用すべきかを認識するために必要となるフィールドです。
        認証と認可がProgram.csファイルで有効になったことを確認します。
        
+
+## ログイン {{{ data-action="code" data-code="AccountController.cs" }}}
+
+
+
        ユーザーによるASP.NET MVCアプリケーションへのログインを許可するには、コントローラーにLoginアクションを追加します。
        HttpContext.ChallengeAsync()を呼び出し、Auth0Constants.AuthenticationSchemeを認証スキームとして渡します。これによりSDKが内部に登録しているOIDC認証ハンドラーが発動されます。関連するauthenticationPropertiesも必ず指定してください。構築はLoginAuthenticationPropertiesBuilderで行えます。
        HttpContext.ChallengeAsync()の呼び出し成功後、ユーザーはAuth0にリダイレクトされます。その後アプリケーションにリダイレクトで戻された際に、OIDCミドルウェアとクッキーミドルウェアの両方にサインインしています。これにより、ユーザーは後続の要求でも認証されるようになります。
        ASP.NET MWC手順3「チェックポイント」 
        Loginの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Loginアクションに移動すると、Auth0にリダイレクトされる。
        • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイルを表示する
+
+
+
        ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、コントローラーでUser.Claimsプロパティとして利用できるようにします。
        ユーザーの名前、メールアドレス、プロファイル画像を表示するカスタムユーザープロファイルを作成するには、Userから関連する情報を取得し、コントローラー内からビューに渡します。
        ASP.NET MWC手順4「チェックポイント」 
        ユーザープロファイルを表示するようアクションをセットアップし終えたら、アプリケーションを実行して次の点を確認します：
        • ログイン成功後にProfileアクションに移動すると、ユーザープロファイルが表示される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ログアウト
+
+
+
        コントローラーのアクション内からHttpContext.SignOutAsyncをCookieAuthenticationDefaults.AuthenticationScheme認証スキームで呼び出すと、ユーザーをアプリケーションからログアウトさせられます。
        さらに、ユーザーをAuth0からもログアウトさせたい場合は（これによりシングルサインオンに依拠している他のアプリケーションからもログアウトさせる可能性があります）、HttpContext.SignOutAsyncをAuth0Constants.AuthenticationScheme認証スキームで呼び出します。また、LogoutAuthenticationPropertiesBuilderを使って構築できる適切なauthenticationPropertiesも同じ認証スキームで呼び出します。
        ASP.NET MWC手順5「チェックポイント」 
        Logoutの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Logoutアクションに移動すると、ユーザーが確実にログアウトする。
        • Auth0からもログアウトすると、Auth0にリダイレクトされ、即座にアプリケーションにリダイレクトで戻される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/AccountController.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
new file mode 100644
index 0000000000..0f87e854e3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/AccountController.md
@@ -0,0 +1,47 @@
+---
+name: AccountController.cs
+language: csharp
+---
+    
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+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/Web.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/Web.md
new file mode 100644
index 0000000000..c88062828f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/Web.md
@@ -0,0 +1,14 @@
+---
+name: Web.config
+language: 
+---
+    
+```
+
+
+  
+    
+    
+  
+
+```
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..d1fbe54773
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/startup.md
@@ -0,0 +1,82 @@
+---
+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);
+            }
+        }
+    });
+}
+```
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..f925c83774
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/interactive.md
@@ -0,0 +1,71 @@
+---
+title: ASP.NET OWINアプリケーションにログインを追加する
+description: このガイドは、新規または既存のASP.NET OWINアプリケーションにMicrosoft.Owin.Security.OpenIdConnect Nugetパッケージを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/Web
+ - files/Startup
+ - files/AccountController
+github:
+  path: Quickstart/Sample
+locale: ja-JP
+---
+
+# ASP.NET OWINアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、新規または既存のASP.NET OWINアプリケーションにMicrosoft.Owin.Security.OpenIdConnect Nugetパッケージを使ってAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## プロジェクトを構成する {{{ data-action="code" data-code="Web.config" }}}
+
+
+
        NuGetからインストールする
        Auth0をASP.NET OWINに統合するには、Microsoft.Owin.Security.OpenIdConnectおよびMicrosoft.Owin.Security.Cookies NuGetパッケージが使用できます。
        Install-Package Microsoft.Owin.Security.OpenIdConnect
+
+Install-Package Microsoft.Owin.Security.Cookies
+
+
        
+
+
        OWINクッキーミドルウェアとSystem.Webクッキーを同時に構成すると不具合が発生します。この問題の影響を抑えるには、詳細について「System.Web cookie integration issues（System.Webクッキーの統合不具合）」ドキュメントでご確認ください。
        資格情報を構成する
        SDKが適切に動作するためには、Web.configで次のプロパティを設定します：
        • auth0:Domain：Auth0テナントのドメインです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合は、この値をカスタムドメインの値に設定してください。
        • auth0:ClientId：Auth0 Dashboardで作成したAuth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認できます。
        
+
+## ミドルウェアを構成する {{{ data-action="code" data-code="Startup.cs#18:74" }}}
+
+
+
        ASP.NET OWINアプリケーションで認証を有効にするには、StartupクラスのConfigurationメソッドに移動し、クッキーミドルウェアとOIDCミドルウェアを構成します。
        認証の作動にはクッキーミドルウェアとOpenID Connectミドルウェアの両方が（この順番で）要求されるため、どちらも必ず登録してください。OpenID ConnectミドルウェアはAuth0による認証をハンドリングします。ユーザーの認証が完了すると、そのIDはクッキーミドルウェアに保存されます。
        コードスニペットではAuthenticationTypeがAuth0に設定されています。次のセクションでAuthenticationTypeを使用しOpenID Connectミドルウェアにチャレンジして、認証フローを開始します。RedirectToIdentityProvider通知イベントが正しいログアウトURLを構築します。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="AccountController.cs#7:16" }}}
+
+
+
        ユーザーによるASP.NET OWINアプリケーションへのログインを許可するには、コントローラーにLoginアクションを追加します。
        HttpContext.GetOwinContext().Authentication.Challengeを呼び出し、認証スキームとして"Auth0"を渡します。これにより、以前登録されたOIDC認証ハンドラーが発動されます。対応するAuthenticationProperties（RedirectUri含む）を必ず指定してください。
        HttpContext.GetOwinContext().Authentication.Challengeの呼び出し成功後、ユーザーはAuth0にリダイレクトされます。その後アプリケーションにリダイレクトで戻された際に、OIDCミドルウェアとクッキーミドルウェアの両方にサインインしています。これにより、ユーザーは後続の要求でも認証されるようになります。
        ASP.NET（OWIN） - 手順4 - チェックポイント 
        Loginの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Loginアクションに移動すると、Auth0にリダイレクトされる。
        • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="AccountController.cs#34:39" }}}
+
+
+
        ユーザーをアプリケーションからログアウトさせるには、コントローラーのアクションからHttpContext.GetOwinContext().Authentication.SignOutをCookieAuthenticationDefaults.AuthenticationType認証スキームで呼び出します。
        さらに、ユーザーをAuth0からログアウトさせたい場合は（この際にシングルサインオンに依拠している他のアプリケーションからもログアウトさせる可能性があります）、 HttpContext.GetOwinContext().Authentication.SignOutを"Auth0"認証スキームで呼び出します。
        ASP.NET（OWIN） - 手順5 - チェックポイント 
        Logoutの構成が完了したら、アプリケーションを実行して次の点を確認します：
        • Logoutアクションに移動すると、ユーザーがログアウトする。
        • ログアウト中Auth0にリダイレクトし、その後ログアウト中にただちにアプリケーションにリダイレクトで戻る。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="AccountController.cs#18:32" }}}
+
+
+
        ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、ClaimsIdentityとして利用できるようにします。抽出した情報にはコントローラーのUserプロパティを使ってアクセスします。
        ユーザープロファイルを作成するには、Userからユーザーの名前、メールアドレス、プロファイル画像を取得し、コントローラー内からビューに渡します。
        ASP.NET（OWIN） - 手順6 - チェックポイント 
        ユーザープロファイルを表示するようアクションをセットアップし終えたら、アプリケーションを実行して次の点を確認します：
        • ログイン成功後にProfileアクションに移動すると、ユーザープロファイルが表示される。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します
        • ドメインとクライアントIDが正しく構成されていることを確認します
        • スコープとしてopenid profile emailを設定しましたか？
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/files/webappexample/settings.md b/ja-jp/articles/quickstart/webapp/django/files/webappexample/settings.md
new file mode 100644
index 0000000000..28f748dd86
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/webappexample/settings.md
@@ -0,0 +1,35 @@
+---
+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/webappexample/templates/index.md b/ja-jp/articles/quickstart/webapp/django/files/webappexample/templates/index.md
new file mode 100644
index 0000000000..a1c6426ea1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/webappexample/templates/index.md
@@ -0,0 +1,23 @@
+---
+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/webappexample/urls.md b/ja-jp/articles/quickstart/webapp/django/files/webappexample/urls.md
new file mode 100644
index 0000000000..6a3c8bda44
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/webappexample/urls.md
@@ -0,0 +1,17 @@
+---
+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/webappexample/views.md b/ja-jp/articles/quickstart/webapp/django/files/webappexample/views.md
new file mode 100644
index 0000000000..f141c8ea43
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/webappexample/views.md
@@ -0,0 +1,59 @@
+---
+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..17801aa80a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/interactive.md
@@ -0,0 +1,98 @@
+---
+title: Djangoアプリケーションにログインを追加する
+description: このガイドでは、Python DjangoアプリケーションにAuthlib SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/webappexample/templates/index
+ - files/webappexample/settings
+ - files/webappexample/urls
+ - files/webappexample/views
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Djangoアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドでは、Python DjangoアプリケーションにAuthlib SDKを使ってAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## 依存関係をインストールする
+
+
+
        この統合では、さまざまなライブラリー依存関係（Authlibなど）を追加します。プロジェクトディレクトリにrequirements.txtファイルを作成し、以下を含めます：
        authlib ~= 1.0
+
+django ~= 4.0
+
+python-dotenv ~= 0.19
+
+requests ~= 2.27
+
+
        
+
+
        シェルから以下のコマンドを実行し、依存関係が利用できるようにします：
        pip install -r requirements.txt
        
+
+## .envファイルを構成する
+
+
+
        次に、プロジェクトのディレクトリに.envファイルを作成します。このファイルにはクライアントキーやその他の構成情報が含まれます。
        AUTH0_CLIENT_ID=${account.clientId}
+
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+AUTH0_DOMAIN=${account.namespace}
+
+
        
+
+
        
+
+## アプリケーションを作成する
+
+
+
        セットアップ済みのDjangoアプリケーションがある場合は、次の手順へスキップしてください。新しいアプリケーションプロジェクトには、次のコマンドを実行します：
        django-admin startproject webappexample
        新しいプロジェクトフォルダに変更します：
        cd webappexample
        
+
+## settings.pyを更新する {{{ data-action="code" data-code="webappexample/settings.py" }}}
+
+
+
        webappexample/settings.pyファイルを開いて.env値を確認します。
        ファイルの上部にosインポートとdotenvインポートを追加します。
        次に、BASE_DIR定義の下にTEMPLATE_DIR変数を追加します。
        次にTEMPLATES変数を見付けてDIRS値を更新し、当社のTEMPLATE_DIRストリングを追加します。これにより、後の手順で作成するテンプレートファイルのパスが定義されます。この配列のすべてのコンテンツは同じにしておいてください。
        ファイルの最後にAuth0の構成を読み込むコードを追加します。
        
+
+## アプリケーションをセットアップする {{{ data-action="code" data-code="webappexample/views.py#1:18" }}}
+
+
+
        アプリケーションの作成を始めるには、IDEでwebappexample/views.pyファイルを開きます。
        アプリケーションに必要なすべてのライブラリーをインポートします。
        Auth0でアプリケーションの認証を処理するために、Authlibを構成できるようになりました。
        AuthlibのOAuthregister()メソッドで使用できる構成オプションの詳細については、Authlibのドキュメント
        
+
+## ルートハンドラーをセットアップする {{{ data-action="code" data-code="webappexample/views.py#20:52" }}}
+
+
+
        この例では、アプリケーションにlogin、callback、logout、indexの4つのルートを追加します。
        • login - アプリへの訪問者は/loginルートを訪ねる時、Auth0に到達して認証フローを開始します。
        • callback - ユーザーはAuth0でログインを完了した後、/callbackルートでアプリケーションに戻ります。このルートはユーザーのためにセッションを保存し、戻ってきた時に再度ログインする必要性を回避します。
        • logout - /logoutルートは、ユーザーをアプリケーションからサインアウトさせます。アプリのユーザーセッションを消去し、Auth0ログアウトエンドポイントにリダイレクトして、セッションがもう保存されていないことを保証します。その後、アプリケーションは、ユーザーをホームルートにリダイレクトします。
        • index - ホームルートは認証されたユーザーの詳細を表示したり、訪問者のサインインを許可したりします。
        
+
+## ルートを登録する {{{ data-action="code" data-code="webappexample/urls.py" }}}
+
+
+
        webappexample/urls.pyファイルのコンテンツを右のコードに置き換えて、新規ルートに接続します。
        これにより/login、/callback、/logout、/のルートが正しいハンドラーへルートされます。
        
+
+## テンプレートを追加する {{{ data-action="code" data-code="webappexample/templates/index.html" }}}
+
+
+
        次に、ホームページルートで使用するテンプレートファイルを作成します。
        templatesと名付けたwebappexampleフォルダー内に新しいサブディレクトリを作成し、index.htmlファイルを作成します。
        index.htmlファイルにはテンプレートコードが含まれており、ログインした際にユーザー情報を表示したり、ログアウトした際にログインボタンを表示したりします。
        
+
+## アプリケーションを実行する
+
+
+
        アプリケーションを実行する準備ができました。プロジェクトディレクトリからシェルを開き、以下を使用します：
        python3 manage.py migrate
+
+python3 manage.py runserver 3000
+
+
        
+
+
        アプリケーションは、http://localhost:3000でブラウザーから開けるようになっています。
        Django - 手順10 - アプリケーションを実行する - チェックポイント 
        http://localhost:3000を訪問して、確認します。ログインのためにAuth0へルートするログインボタンがあり、ログイン後アプリケーションに戻るとプロファイル情報を確認できます。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • コンソールでエラーを確認します。
        • ドメインとクライアントIDが正常にインポートされていることを確認します。
        • テナントの構成を確認します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..ed5b9ef117
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/files/server.md
@@ -0,0 +1,39 @@
+---
+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..dabe94ae1a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,48 @@
+---
+title: Expressアプリケーションにログインを追加する
+description: このガイドは、Node.js ExpressアプリケーションにExpress OpenID Connect SDKを使ってAuth0を統合し、ユーザーのログイン、ログアウト、およびプロファイルを追加する方法を説明します。
+interactive:  true
+files:
+ - files/server
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Expressアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、Node.js ExpressアプリケーションにExpress OpenID Connect SDKを使ってAuth0を統合し、ユーザーのログイン、ログアウト、およびプロファイルを追加する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/logoutに設定してください。
        
+
+## ExpressのOpenID Connect SDKをインストールする {{{ data-action="code" data-code="server.js#2:16" }}}
+
+
+
        アプリケーションには、Auth0がメンテナンスするOIDC準拠のExpress向けSDKであるexpress-openid-connectパッケージが必要です。
        ターミナルで以下のコマンドを実行してExpress OpenID Connect SDKをインストールします：
        cd <your-project-directory>
+
+npm install express-openid-connect
+
+
        
+
+
        ルーターを構成する
        Express OpenID Connect SDKライブラリーは、認証ルートをアプリケーションに結びつけるために、authルーターを提供します。以下の構成キーでルーターを構成する必要があります：
        • authRequired - すべてのルートに対して認証が必要かを制御します。
        • auth0Logout - Auth0ログアウト機能を使います。
        • baseURL - アプリケーションが作動するURLです。
        • secret - 長くて無作為な文字列です。
        • issuerBaseURL - 安全なURLとしてのドメインで、アプリケーションの設定で確認できます。
        • clientID - アプリケーションの設定で確認できるクライアントIDです。
        その他の構成オプションについては、APIドキュメントをご覧ください。
        LONG_RANDOM_STRINGに適した文字列は、コマンドラインのopenssl rand -hex 32で生成できます。
        Express - 手順2 - ExpressのOpenID Connect SDKをインストールする - チェックポイント 
        ユーザーはライブラリーによって提供された/loginルートを訪れることで、アプリケーションにログインできるようになりました。プロジェクトをlocalhost:3000で実行している場合のリンクは、http://localhost:3000/loginです。
        
+
+  
        
+
+  
        すみません。Auth0のログインページのエラー詳細を使って、正しいCallback URLが入力されていることを確認してください。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="server.js#25:28" }}}
+
+
+
        ユーザーのプロファイルを表示するには、アプリケーションに保護されたルートがなければなりません。
        認証を必要とするルートにrequiresAuthミドルウェアを追加してください。このミドルウェアを使用するすべてのルートは有効なユーザーセッションをチェックし、ない場合にはユーザーをログインへリダイレクトします。
        Express - 手順3 - ユーザープロファイルを表示する - チェックポイント 
        ユーザーはライブラリーによって提供された/logoutルートを訪れることで、アプリケーションからログアウトできます。プロジェクトをlocalhost:3000で実行している場合のリンクは、http://localhost:3000/logoutです。
        
+
+  
        
+
+  
        すみません。ログアウトURLが正しく構成されていることを確認してください。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..bd316c62dc
--- /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..c0abe39ef0
--- /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..e777b2df02
--- /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/go.md b/ja-jp/articles/quickstart/webapp/golang/files/go.md
new file mode 100644
index 0000000000..ccdace1ba9
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/go.md
@@ -0,0 +1,20 @@
+---
+name: go.mod
+language: go
+---
+    
+```go
+// 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..9613366e02
--- /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..67dc5740d9
--- /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..a239d207be
--- /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..5dcf244bcd
--- /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..bcb15eb5ff
--- /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..9976a1a8a3
--- /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..6351ddfe29
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,79 @@
+---
+title: Goアプリケーションにログインを追加する
+description: このガイドは、新規または既存のGo WebアプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/auth
+ - files/callback
+ - files/env
+ - files/go
+ - files/isAuthenticated
+ - files/login
+ - files/logout
+ - files/main
+ - files/router
+ - files/user
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Goアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができますこのガイドは、新規または既存のGo WebアプリケーションにAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## 依存関係をインストールする {{{ data-action="code" data-code="go.mod" }}}
+
+
+
        go.modファイルを作成して、アプリケーションの依存関係をすべてリストします。
        GoアプリケーションでAuth0を統合するには、coreos/go-oidc/v3パッケージとx/oauth2パッケージを追加します。
        OIDCパッケージとOAuth2パッケージに加え、joho/godotenv、gin-gonic/gin、gin-contrib/sessionsを追加します。
        この例ではルーティングにginを使用しますが、お好きなルーターを使用できます。
        go.modファイルを必要な依存関係で保存し、ターミナルで次のコマンドを使ってインストールします：
        go mod download
        
+
+## 環境変数を構成する {{{ data-action="code" data-code=".env" }}}
+
+
+
        プロジェクトディレクトリのルート内の.envで以下の環境変数を設定してください：
        • AUTH0_DOMAIN：Auth0テナントのドメインです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Domain（ドメイン）］フィールドで確認してください。カスタムドメインを使用する場合は、この値をカスタムドメインの値に設定してください。
        • AUTH0_CLIENT_ID：このクイックスタートで前にセットアップしたAuth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認してください。
        • AUTH0_CLIENT_SECRET：このクイックスタートで前にセットアップしたAuth0アプリケーションのシークレットです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client Secret（クライアントシークレット）］フィールドで確認してください。
        • AUTH0_CALLBACK_URL：認証成功後にユーザーをリダイレクトするためにAuth0が使用するURLです。
        
+
+## OAuth2パッケージとOpenID Connectパッケージを構成する {{{ data-action="code" data-code="auth.go" }}}
+
+
+
        次にOAuth2パッケージとOpenID Connectパッケージを構成します。
        platform/authenticatorフォルダーにauth.goという名前のファイルを作成します。このパッケージ内で、OAuth2クライアントとOIDCクライアントを構成してリターンするメソッドを作成し、IDトークンを検証するもう1つのメソッドを作成します。
        
+
+## アプリケーションルートをセットアップする {{{ data-action="code" data-code="router.go" }}}
+
+
+
        platform/routerフォルダーにrouter.goという名前のファイルを作成します。このパッケージで、github.com/gin-gonic/ginを使ってルートを構成、リターンするメソッドを作成します。loginハンドラーとcallbackハンドラーで使用するために、Authenticatorのインスタンスをメソッドに渡すことになります。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login.go" }}}
+
+
+
        ユーザーが自分で認証するには、/loginルートを処理するハンドラー関数を作成する必要があります。
        web/app/loginフォルダーにlogin.goという名前のファイルを作成し、Handler関数を追加します。ハンドラーの実行時にユーザーはAuth0へリダイレクトされ、資格情報を入力できるようになります。
        /loginルートを呼び出すには、web/templateディレクトリにあるhome.htmlテンプレートに/loginへのリンクを追加します。
        
+
+## 認証コールバックを処理する {{{ data-action="code" data-code="callback.go" }}}
+
+
+
        ユーザーはAuth0ユニバーサルログインページを使って認証すると、 /callbackルートでアプリに戻ります。
        web/app/callbackフォルダーにcallback.goという名前のファイルを作成し、Handler関数を追加します。
        このハンドラーはAuth0によって提供されたcodeクエリ文字列を受け取り、IDトークンおよびアクセストークンと交換します。
        IDトークンが有効である場合、セッションにプロファイル情報とアクセストークンが保存されます。プロファイル情報はIDトークンに含まれるクレームに基づいています。セッションストレージは、必要に応じてアプリケーションがこの情報にアクセスすることを許可します。
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="user.go" }}}
+
+
+
        ユーザーがログインできるようになったら、認証済みのユーザーに関連付けられたプロファイル情報を取得し、使用できるようにしたいと考えるはずです。
        ニックネームやプロフィール写真といったプロファイル情報は、前のセッションで保存されたprofileからアクセスできます。
        web/app/user/user.goで/userエンドポイント用のハンドラーを作成し、対応するHTMLファイルを返します。profileがctx.HTML()に渡されているため、同じHTMLファイル内のpictureやnicknameといったプロファイル情報にアクセスできます。
        このようなHTMLファイルは以下の例のように見えることがありますが、カスタムクレームを含め、いかなるプロファイル情報も取得できます。
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.go" }}}
+
+
+
        ユーザーをログアウトさせるには、セッションのデータを消去し、ユーザーをAuth0ログアウトエンドポイントにリダイレクトします。詳細はログアウトドキュメントをご覧ください。
        web/app/logoutフォルダーにlogout.goという名前のファイルを作成し、ユーザーをAuth0ログアウトエンドポイントにリダイレクトするためにHandler関数を追加します。
        returnTo URLは、アプリケーションの設定セクションで［Allowed Logout URLs（許可されているログアウトURL）］のリストに載っていなければなりません。詳細は「ログアウト後にユーザーをリダイレクトする」をご覧ください。
        web/static/jsフォルダーにuser.jsという名前のファイルを作成し、ログインしたユーザーからクッキーを削除するためのコードを追加します。
        
+
+## ルートを保護する {{{ data-action="code" data-code="isAuthenticated.go" }}}
+
+
+
        推奨プラクティスでは、認証されたユーザーだけが特定のルートにアクセスできるようにするべきです。認証されていないユーザーが保護されたルートにアクセスしようとした場合、アプリケーションによってリダイレクトされる必要があります。
        この場合、HTTPの要求に接続するミドルウェアを実装します。ミドルウェアの関数は、要求がエンドポイントハンドラーにルートされるべきか、ブロックされるべきかを決定します。
        platform/middlewareにisAuthenticated.goという名前のファイルを作成し、profileセッションキーに基づいてユーザーが認証されているかいないかをチェックする関数を追加します。認証されていないユーザーは、ミドルウェアがアプリケーションのルートへリダイレクトします。
        ミドルウェアを作成すると、ルーターに追加することで、認証を必要とするすべてのルートにセットアップできます。
        
+
+## アプリケーションを仕上げる {{{ data-action="code" data-code="main.go" }}}
+
+
+
        鑑別工具とルーターの構成が完了したら、アプリケーションのエントリーポイントを使って全体を結び付けます。main.go内で、鑑別工具とルーターのインスタンスを作成すると鑑別工具インスタンスが渡されます。
        .envファイルを使用している場合は、main()関数の冒頭でgodotenv.Load()を呼び出さなくてはなりません。
        ターミナルで次のコマンドを使いアプリケーションを仕上げます：
        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/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
new file mode 100644
index 0000000000..29a24545b4
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.md
@@ -0,0 +1,52 @@
+---
+name: src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java
+language: javascript
+---
+    
+```javascript
+// 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;
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
new file mode 100644
index 0000000000..ed6667e7e3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/HomeServlet.md
@@ -0,0 +1,23 @@
+---
+name: src/main/java/com/auth0/example/web/HomeServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
new file mode 100644
index 0000000000..c818e9a8b0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LoginServlet.md
@@ -0,0 +1,38 @@
+---
+name: src/main/java/com/auth0/example/web/LoginServlet.java
+language: javascript
+---
+    
+```javascript
+// 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);
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
new file mode 100644
index 0000000000..929dd24742
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/java/com/auth0/example/web/LogoutServlet.md
@@ -0,0 +1,54 @@
+---
+name: src/main/java/com/auth0/example/web/LogoutServlet.java
+language: 
+---
+    
+```
+// 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://${account.namespace}/v2/logout?client_id=${account.clientId}&returnTo=http://localhost:3000/
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                config.getDomain(),
+                config.getClientId(),
+                returnUrl
+        );
+
+        return logoutUrl;
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
new file mode 100644
index 0000000000..58f32a0fdc
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/files/src/main/webapp/WEB-INF/web.md
@@ -0,0 +1,30 @@
+---
+name: src/main/webapp/WEB-INF/web.xml
+language: powershell
+---
+    
+```powershell
+
+
+
+    auth0.domain
+    java.lang.String
+    ${account.namespace}
+
+
+    auth0.clientId
+    java.lang.String
+    ${account.clientId}
+
+
+    auth0.clientSecret
+    java.lang.String
+    ${account.clientSecret}
+
+
+    auth0.scope
+    java.lang.String
+    openid profile email
+
+
+```
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..3b54b03c6a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/index.yml
@@ -0,0 +1,52 @@
+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
+hidden_articles:
+  - "interactive"
+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-ee/interactive.md b/ja-jp/articles/quickstart/webapp/java-ee/interactive.md
new file mode 100644
index 0000000000..dae032c796
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/interactive.md
@@ -0,0 +1,408 @@
+---
+title: Java EEアプリケーションにログインを追加する
+description: このチュートリアルは、Java EE Webアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/src/main/webapp/WEB-INF/web
+ - files/src/main/java/com/auth0/example/security/Auth0AuthenticationConfig
+ - files/src/main/java/com/auth0/example/web/LoginServlet
+ - files/src/main/java/com/auth0/example/web/HomeServlet
+ - files/src/main/java/com/auth0/example/web/LogoutServlet
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Java EEアプリケーションにログインを追加する
+
+
+
        このチュートリアルは、Java EE Webアプリケーションにユーザーログインを追加する方法について説明します。ログインして、アカウント用に構成された例を参考にこのクイックタートに従うことをお勧めします。
        システム要件
        このチュートリアルとサンプルプロジェクトは次を使用してテストが完了しています：
        • Java 11
        
+
+## Auth0を構成する
+
+
+
        アプリケーションキーを取得する
        Auth0にサインアップしたときには、新しいアプリケーションが作成されたか、すでに作成済みであった可能性があります。Auth0と通信するには、アプリケーションについての詳細が必要になります。これらの詳細は、Auth0 Dashboardのアプリケーションの設定セクションで入手できます。
        以下の情報が必要です。
        • Domain (ドメイン)
        • Client ID（クライアントID）
        • Client Secret（クライアントシークレット）
        このページの上部からサンプルをダウンロードした場合は、これらの詳細が入力されます。
        Callback URLを構成する
        Callback URLはアプリケーション内にあるURLで、Auth0は認証後にユーザーをここにリダイレクトします。アプリのCallback URLはアプリケーションの設定にある［Allowed Callback URLs（許可されているコールバックURL）］フィールドに追加する必要があります。このフィールドが設定されていない場合、ユーザーはアプリケーションにログインできず、エラーが返されます。
        このページの上部からダウンロードしたサンプルプロジェクトに沿って進めている場合には、［Allowed Callback URLs（許可されているコールバックURL）］フィールドにhttp://localhost:3000/callbackを追加する必要があります。
        ログアウトURLを構成する
        ログアウトURLはアプリケーション内にあるURLで、Auth0は認可サーバーからのログアウト後にユーザーをここに戻すことができます。これは、returnToクエリパラメーターで指定されます。アプリのログアウトURLはアプリケーションの設定にある［Allowed Logout URLs（許可されているログアウトURL）］フィールドに追加する必要があります。このフィールドが設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーが返されます。
        このページの上部からダウンロードしたサンプルプロジェクトに沿って進めている場合には、［Allowed Logout URLs（許可されているログアウトURL）］フィールドにhttp://localhost:3000/を追加する必要があります。
        
+
+## JavaEEにAuth0の使用を構成する {{{ data-action="code" data-code="src/main/webapp/WEB-INF/web.xml" }}}
+
+
+
        依存関係をセットアップする
        Java EEアプリケーションをAuth0と統合するには、以下の依存関係を追加します。
        • javax.javaee-api：Java EE 8を使ってアプリケーションを作成するために必要なJava EE 8 APIです。実際の統合はアプリケーションコンテナーが提供するため、WARファイルに含める必要はありません。
        • javax.security.enterprise：EEアプリケーションでセキュリティ上の懸念に対処できるようにするJava EE 8 Security APIです。javax.javaee-apiの依存関係と同様に、統合はアプリケーションコンテナーが提供するため、WARファイルには含まれません。
        • auth0-java-mvc-commons：Auth0 Java MVC SDKは、サーバー側のMVC WebアプリケーションにAuth0とJavaを使用できるようにします。これは、アプリケーションがAuth0を使ったユーザー認証で呼び出すべき認可URLを生成します。
        Mavenを使用している場合は、次の依存関係をpom.xmlに追加します：
        <!-- pom.xml -->
+
+<dependency>
+
+ <groupId>com.auth0</groupId>
+
+ <artifactId>mvc-auth-commons</artifactId>
+
+ <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax</groupId>
+
+ <artifactId>javaee-api</artifactId>
+
+ <version>8.0.1</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+<dependency>
+
+ <groupId>javax.security.enterprise</groupId>
+
+ <artifactId>javax.security.enterprise-api</artifactId>
+
+ <version>1.0</version>
+
+ <scope>provided</scope>
+
+</dependency>
+
+
        
+
+
        Gradleを使用している場合は、次をbuild.gradleに追加します：
        // 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. '
+
+
        
+
+
        Java EEアプリケーションを構成する
        このチュートリアルに付属のサンプルはJSPを使用して作成され、WildFlyアプリケーションサーバーでテストが完了しています。他のアプリケーションコンテナーや技術を使用して作業する場合には、一部の手順を調整する必要があるかもしれません。
        Java EEアプリケーションは、Auth0アプリケーションを使ってユーザーを認証するために、いくつかの情報を必要とします。この情報の保管にはデプロイメント記述子であるweb.xmlファイルを使用できますが、別の安全な場所に保管することもできます。
        この情報は、ユーザーがアプリケーションにログインできるように、auth0-java-mvc-commonsライブラリーを構成するために使用されます。ライブラリーとその構成オプションについては、ライブラリーのREADMEを参照してください。
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **入力済みの属性を確認する**
        このサンプルを__［Download Sample（サンプルをダウンロード）］__ボタンでダウンロードした場合は、domain、clientId、clientSecretの属性が自動的に入力されます。アカウントに複数のAuth0アプリケーションがある場合は特に、値が正しいことを確認してください。
        
+
+## Java EE Securityを構成する {{{ data-action="code" data-code="src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java" }}}
+
+
+
        Java EE 8 Security APIには新たにHttpAuthenticationMechanismインターフェイスが搭載され、アプリケーションがユーザーの資格情報を取得できるようにしています。Basic認証とフォームベースの認証にはデフォルトの実装があり、カスタム認証ストラテジーを構成しやすくしています。
        Auth0を使用して認証するには、以下のインターフェイスをカスタムで実装します。
        • HttpAuthenticationMechanism：Auth0から戻されるユーザーの認証ワークフローを処理します（JavaDoc）。
        • IdentityStore：ユーザーの資格情報を検証します（JavaDoc）。
        • CallerPrincipal：現在のHTTP要求の呼び出し元プリンシパルを表します（JavaDoc）。
        • Credential：呼び出し元が認証に使用する資格情報を表します（JavaDoc）。
        まず、アプリケーションがAuth0設定を使用できるように、@ApplicationScoped Beanを作成してWebコンテキストから値を取得し、getterを通して利用できるようにします。
        次に、現在の要求の呼び出し元を表すカスタムのCallerPrincipalを作成します：
        // 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;
+
+    }
+
+}
+
+
        
+
+
        これで、ユーザーの資格情報を表すために使用されるカスタムのCredentialが実装できるようになりました。これには、プリンシパルについての情報が保管されます：
        // 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;
+
+    }
+
+}
+
+
        
+
+
        これで、呼び出し元プリンシパルと資格情報を表すクラスが定義できました。次に、IdentityStoreのカスタム実装を作成します。このクラスはユーザー資格情報の検証に使用されます。
        // 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;
+
+    }
+
+}
+
+
        
+
+
        credentialがAuth0Credentialの場合はユーザーの呼び出しが認証され有効であるため、正常として、資格情報を使って作成されたCredentialValidationResultが返されます。Auth0Credentialでない場合には、CredentialValidationResult.NOT_VALIDATED_RESULTが返されます。
        これらのすべてを使用するHttpAuthenticationMechanismインターフェイスを実装する前に、Beanを作成して、Auth0 Java MVC SDKにある構成済みのAuthenticationControllerインスタンスが提供されるようにします。AuthenticationControllerはユーザーがログインする認可URLの構築と、ユーザーを認証するトークン交換の処理に使用されます。
        • Auth0アプリケーションにRS256署名アルゴリズム（新しいAuth0アプリケーション作成時のデフォルト）の使用が構成されている場合には、JwkProviderを構成して、トークン署名の検証に使われる公開鍵を取得するようにします。その他の構成オプションについては、jwks-rsa-javaレポジトリを参照してください。
        • Auth0アプリケーションにHS256署名アルゴリズムの使用が構成されている場合には、JwkProviderを構成する必要はありません。
        使用可能な署名アルゴリズムについては、こちらのドキュメントを参照してください。
        以下のサンプルは、RS256署名アルゴリズムの使用にAuthenticationControllerをどのように構成するのかを示しています。
        // 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();
+
+    }
+
+}
+
+
        
+
+
        最後に、カスタムのHttpAuthenticationMechanismを実装します。
        // 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;
+
+    }
+
+}
+
+
        
+
+
        このクラスはvalidateRequestメソッドをオーバーライドします。このメソッドはAuth0アプリケーションに対するすべての要求で呼び出され、コンテナーに認証ステータスを通知します。
        このサンプルでは、認可コードフローを使用して、認証フロー中に認可コードをトークンと交換します。この要求が/callbackエンドポイントに対するもので、code要求パラメーターが含まれている場合には、以下にあるいくつかの重要な処理を行います。
        • AuthenticationControllerのhandleメソッドを呼び出して、認可コードをIDトークンおよびアクセストークンと交換する。
        • IDトークンを使用して、新たにAuth0Credentialを作成する。
        • カスタムのIdentityStore実装のvalidateメソッドを呼び出して、検証結果を取得する。
        • アプリケーションコンテナーにログインステータスを通知する。
        要求されたリソースが/callbackでない場合には、httpMessageContext.doNothing()を返して、要求の処理が続行できるようにします。後ほど、認証のトリガーやWebビューの表示で認証情報をどのように使用するかについて説明します。
        最後に、認証したユーザーのセッションをコンテナーが作成できるように、@AutoApplySessionアノテーションが追加されたことに注意してください。
        
+
+## 認証をトリガーする {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LoginServlet.java" }}}
+
+
+
        ユーザーがログインできるようにするには、/loginパスへの要求を処理するサーブレットを作成します。
        LoginControllerは、ユーザーがAuth0で認証できるように、正しい認可URLに要求をリダイレクトします。正しい認可URLの構築には、Auth0AuthenticationConfigを通して投入された構成値と、Auth0 Java MVC SDKが提供するAuthenticationControllerが使用されます。このサンプルはデフォルトでopenid profile emailスコープを要求して、アプリケーションが基本的なプロファイル情報を認証済みのユーザーから取得できるようにします。これらのスコープについては、OpenID Connectスコープのドキュメントをお読みください。
        ユーザーが資格情報を入力し、要求されたアクセス権を認可すると、Auth0はcallbackUrlに対して要求を発行し、IDトークンおよびアクセストークンと交換できるcodeクエリパラメーターを含めます。先ほど説明したように、上記で作成したAuth0HttpAuthenticationMechanismがこの交換を処理し、アプリケーションコンテナーに認証ステータスを通知できるようにします。そうすることで、/callbackパスへの要求を処理するサーブレットは、ログイン前に要求された元のリソースに要求を転送するか、ホームページにリダイレクトするだけで済みます。
        // 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);
+
+    }
+
+}
+
+
        
+
+
        
+
+## ユーザー情報を表示する {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/HomeServlet.java" }}}
+
+
+
        認証したユーザーのプロファイル情報を取得するには、Auth0JwtPrincipalを使用することができます。HomeServlet.javaのサンプルコードでは、IDトークンでクレームを使ってプロファイルデータを要求属性に設定する方法を例示しています。
        そのプロファイル情報は、ユーザーについての情報を表示するビューで使用できます。
        <!-- src/main/webapp/WEB-INF/jsp/fragments/navbar.jspf -->
+
+
+
+<c:choose>
+
+ <c:when test="{empty profile}">
+
+<li>
+
+ <form action="/login" method="GET">
+
+<input type="submit" value="Login"/>
+
+ </form>
+
+</li>
+
+ </c:when>
+
+ <c:otherwise>
+
+<li>
+
+ <a href="#">
+
+<!-- Profile image should be set to the profile picture from the id token -->
+
+<img src="{profile.get('picture').asString()}" alt="Profile picture"/>
+
+ </a>
+
+ <div>
+
+<!-- Show the user's full name from the id token here -->
+
+<div>"{profile.get('name').asString()}"</div>
+
+<a href="/profile">Profile</a>
+
+<a href="/logout">Log out</a>
+
+ </div>
+
+</li>
+
+ </c:otherwise>
+
+</c:choose>
+
+
        
+
+
        
+
+## ログアウトを処理する {{{ data-action="code" data-code="src/main/java/com/auth0/example/web/LogoutServlet.java" }}}
+
+
+
        ユーザーをログアウトさせるには、アプリケーションセッションを消去して、Auth0からユーザーをログアウトさせる必要があります。これはLogoutServletで処理されます。
        まず、request.getSession().invalidate()を呼び出して、セッションを消去します。それから、ログアウトURLを構築して、必ずreturnToクエリパラメーターを含めます。ユーザーはログアウト後にこのURLにリダイレクトされます。最後に、アプリケーションのをログアウトURLに応答をリダイレクトします。
        
+
+## サンプルを実行する
+
+
+
        サンプルを構築し実行するには、Mavenゴールに対してwildfly:runを実行し、このアプリケーションをデプロイした組み込みのWildFlyアプリケーションサーバーを起動します。詳細については、WildFly Maven Pluginのドキュメントを参照してください。
        LinuxまたはMacOSを使用している場合は、次を行います：
        ./mvnw clean wildfly:run
+
+
        
+
+
        Windows：
        mvnw.cmd clean wildfly:run
+
+
        
+
+
        使用しているブラウザーでhttp://localhost:3000をポイントします。ログインリンクを使用して、Auth0テナントにログインまたはサインアップします。
        null
        ログインに成功すると、ユーザーのプロフィール画像とログインリンクのあるドロップダウンメニューが表示されます。プロファイルリンクをクリックすると、ユーザーのプロファイルページを表示することができます。ドロップダウンメニューにあるログアウトリンクをクリックすると、ログアウトできます。
        
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/HomeController.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
new file mode 100644
index 0000000000..4ca305ce5e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/HomeController.md
@@ -0,0 +1,29 @@
+---
+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";
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
new file mode 100644
index 0000000000..a08d869b03
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfig.md
@@ -0,0 +1,31 @@
+---
+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();
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.md
new file mode 100644
index 0000000000..d36c761126
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/SecurityConfigWithLogout.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);
+            }
+        };
+    }
+}
+```
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..035001998b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/application.md
@@ -0,0 +1,12 @@
+---
+name: application.yml
+language: javascript
+---
+    
+```javascript
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: ${account.clientSecret}
+```
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..9c8255bdc8
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/index.md
@@ -0,0 +1,24 @@
+---
+name: index.html
+language: html
+---
+    
+```html
+
+
+    
+        
        
+            Log In
+        
        
+        
        
+            
        You are logged in!
        
+            " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+            
        ">
        
+            
        ">
        
+            
        
+                
        
+    
+
+```
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..9853ab4887
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,198 @@
+---
+title: Spring Webアプリケーションにログインを追加する
+description: このガイドでは、Spring BootアプリケーションにAuth0 Spring Boot SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/index
+ - files/HomeController
+ - files/SecurityConfigWithLogout
+github:
+  path: mvc-login
+locale: ja-JP
+---
+
+# Spring Webアプリケーションにログインを追加する
+
+
+
        Spring WebFluxを使用する？
        このチュートリアルではSpring MVCを使用します。Spring WebFluxを使用している場合、認証を追加する手順は似ていますが、実装の詳細は一部異なります。Spring Boot WebFluxサンプルコードで、Auth0とSpring Boot WebFluxアプリケーションの統合方法を確認してください。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadでセットアップしたアプリケーションが必要です。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        インタラクティブセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0の全てのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションに自動更新を行います。今後、アプリケーションの管理はDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        http://localhost:3000/login/oauth2/code/okta
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合には、次の値に設定します：
        http://localhost:3000
        
+
+## Sprint Bootアプリケーションを構成する
+
+
+
        Spring依存関係を追加する
        Spring BootアプリケーションをAuth0と統合するには、Okta Spring Boot Starterをアプリケーションの依存関係に含めます。
        このガイドでは、ビューレイヤー用にThymeleafとSpring Security統合モジュールを使用しています。別の表示技術を使用している場合、Spring Securityの構成とコンポーネントはそのまま同じです。
        Gradleを使用している場合は、以下のようにこれらの依存関係を含めることができます。
        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'
+
+
        
+
+
        Mavenを使用している場合：
        <parent>
+
+ <groupId>org.springframework.boot</groupId>
+
+ <artifactId>spring-boot-starter-parent</artifactId>
+
+ <version>3.1.4</version>
+
+ <relativePath/>
+
+</parent>
+
+
+
+<dependencies>
+
+ <dependency>
+
+<groupId>com.okta</groupId>
+
+<artifactId>okta-spring-boot-starter</artifactId>
+
+<version>3.0.5</version>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-web</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-oauth2-client</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.springframework.boot</groupId>
+
+<artifactId>spring-boot-starter-thymeleaf</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>org.thymeleaf.extras</groupId>
+
+<artifactId>thymeleaf-extras-springsecurity6</artifactId>
+
+ </dependency>
+
+ <dependency>
+
+<groupId>nz.net.ultraq.thymeleaf</groupId>
+
+<artifactId>thymeleaf-layout-dialect</artifactId>
+
+ </dependency>
+
+</dependencies>
+
+
        
+
+
        
+
+## Spring Securityを構成する {{{ data-action="code" data-code="application.yml" }}}
+
+
+
        Okta Spring Boot Starterでは、Auth0でアプリケーションを簡単に構成できます。以下のサンプルではapplication.ymlファイルを使用していますが、プロパティファイルや他のサポートされる表出化メカニズムを使用することもできます。
        #src/main/resources/application.yml
+
+
+
+okta:
+
+  oauth2:
+
+    issuer: https://${account.namespace}/
+
+    client-id: ${account.clientId}
+
+    client-secret: ${account.clientSecret}
+
+
+
+#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
+
+
        
+
+
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="SecurityConfig.java" }}}
+
+
+
        Auth0でユーザーログインを有効にするには、SecurityFilterChainを登録するクラスを作成し、@Configurationの注釈を追加します。
        すべてまたは特定のパスで認証を必須にするために、HttpSecurityインスタンスを構成することができます。たとえば、ホームページを除くすべてのパスで認証を必須にするには、以下のようにします：
        http.authorizeHttpRequests(authorize -> authorize
+
+        .requestMatchers("/").permitAll()
+
+        .anyRequest().authenticated()
+
+    );
+
+
        
+
+
        
+
+## 表紙ページを追加する {{{ data-action="code" data-code="index.html" }}}
+
+
+
        Okta Spring Boot Starterは以前に定義したクライアント構成を使って、ユーザーがアプリケーションの/oauth2/authorization/oktaパスにアクセスしたときのログインを処理します。これを使用して、アプリケーションでログインリンクを作成することができます。
        このページは、ユーザー認証時にユーザー属性を返します。テンプレートの/logoutリンクを使用して、ログアウト機能を実装します。
        
+
+## コントローラーを追加する {{{ data-action="code" data-code="HomeController.java" }}}
+
+
+
        受信要求を処理するようにコントロールを作成します。このコントローラはindex.htmlページをレンダリングします。ユーザー認証時に、アプリケーションはユーザーのプロファイル情報の属性を取得し、ページをレンダリングします。
        spring boot手順6「チェックポイント」 
        ログインリンクをクリックすると、アプリケーションによってAuth0ユニバーサルログインページにリダイレクトされ、ユーザー名とパスワードまたはソーシャルプロバイダーを使ってログインまたはサインアップできるようになったことを確認します。
        
+
+  
        
+
+  
        
+
+  
        null
        Auth0は、Googleソーシャルプロバイダーを新しいテナントでデフォルトで有効にし、ソーシャルIDプロバイダーでログインテストを実施するための開発者キーを提供します。ただし、これらの開発者キーにはいくつかの制限が設けられており、これによってアプリケーションが異なる動作をする場合があります。この動作の様子と修正方法については、「Auth0開発者キーを使ってソーシャル接続をテストする」ドキュメントを参照してください。
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="SecurityConfigWithLogout.java" }}}
+
+
+
        アプリケーションにログインできるようになったら、ログアウトする方法が必要です。デフォルトで、ログアウトが有効になると、Spring Securityはユーザーをアプリケーションからログアウトし、セッションを消去します。Auth0から正常にログアウトするには、LogoutHandlerでユーザーをAuth0ログアウトエンドポイント（https://{yourDomain}/v2/logout）にリダイレクトした直後に、アプリケーションにリダイレクトします。
        SecurityConfigクラスでLogoutHandlerを指定すると、Auth0ログアウトエンドポイントにリダイレクトされ、ログアウトハンドラを追加するようにHttpSecurityを構成します。
        spring boot手順7「チェックポイント」 
        ログアウトリンクをクリックすると、「Settings（設定）」にある［Allowed Logout URLs（許可されているログアウトURL）］のいずれかに指定されたアドレスにリダイレクトされ、アプリケーションにログインされなくなります。
        
+
+  
        
+
+  
        
+
+  
        
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/AuthenticationControllerProvider.md b/ja-jp/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
new file mode 100644
index 0000000000..badefcb759
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/AuthenticationControllerProvider.md
@@ -0,0 +1,34 @@
+---
+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;
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java/files/CallbackServlet.md b/ja-jp/articles/quickstart/webapp/java/files/CallbackServlet.md
new file mode 100644
index 0000000000..ff5d16fdd5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/CallbackServlet.md
@@ -0,0 +1,45 @@
+---
+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);
+        }
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java/files/HomeServlet.md b/ja-jp/articles/quickstart/webapp/java/files/HomeServlet.md
new file mode 100644
index 0000000000..edec61b849
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/HomeServlet.md
@@ -0,0 +1,22 @@
+---
+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);
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java/files/LoginServlet.md b/ja-jp/articles/quickstart/webapp/java/files/LoginServlet.md
new file mode 100644
index 0000000000..e05ba29f75
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/LoginServlet.md
@@ -0,0 +1,32 @@
+---
+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);
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/java/files/LogoutServlet.md b/ja-jp/articles/quickstart/webapp/java/files/LogoutServlet.md
new file mode 100644
index 0000000000..95dd2ed96b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/LogoutServlet.md
@@ -0,0 +1,39 @@
+---
+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);
+    }
+
+}
+```
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..1adea02008
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/web.md
@@ -0,0 +1,21 @@
+---
+name: web.xml
+language: 
+---
+    
+```
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    ${account.clientSecret}
+
+```
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..6e9c2f4ae5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,139 @@
+---
+title: Java Servletアプリケーションにログインを追加する
+description: このガイドは、新規または既存のJava ServletアプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/web
+ - files/AuthenticationControllerProvider
+ - files/LoginServlet
+ - files/CallbackServlet
+ - files/HomeServlet
+ - files/LogoutServlet
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Java Servletアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドは、新規または既存のJava ServletアプリケーションにAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/logoutに設定してください。
        
+
+## Auth0をアプリケーションに統合する
+
+
+
        依存関係をセットアップする
        Auth0でJavaアプリケーションを統合するには、以下の依存関係を追加します：
        • javax.servlet-api
          ：Java Servletsの作成を許可するライブラリーです。TomcatやGrettyのようなサーバー依存関係を追加する必要があります。どれを追加するかは自己判断です。詳細はサンプルコードをご覧ください。
        • auth0-java-mvc-commons：サーバー側のMVC Webアプリ用にJavaでAuth0の使用を許可するJavaライブラリーです。ユーザーを識別するAuth0トークンを最後に取得する過程で受け取った結果を認証、検証するために呼び出す必要のある認可URLを生成します。
        Gradleを使用している場合は、build.gradleに追加します：
        // build.gradle
+
+
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+
+compile 'com.auth0:mvc-auth-commons:1.+'W
+
+
        
+
+
        Mavenを使用している場合は、pom.xmlに追加します：
        <!-- pom.xml -->
+
+
+
+<dependency>
+
+  <groupId>com.auth0</groupId>
+
+  <artifactId>mvc-auth-commons</artifactId>
+
+  <version>[1.0, 2.0)</version>
+
+</dependency>
+
+<dependency>
+
+  <groupId>javax.servlet</groupId>
+
+  <artifactId>javax.servlet-api</artifactId>
+
+  <version>3.1.0</version>
+
+</dependency>
+
+
        
+
+
        
+
+## Javaアプリケーションを構成する {{{ data-action="code" data-code="web.xml" }}}
+
+
+
        Javaアプリは、Auth0アカウントに対して認証するために、いくつかの情報を必要とします。サンプルではこの情報をデプロイメント記述子ファイル（src/main/webapp/WEB-INF/web.xml）から読み取っていますが、任意の場所に保存できます。
        この情報はauth0-java-mvc-commonsライブラリーを構成するために使用され、ユーザーがアプリケーションにログインすることを可能にします。ライブラリーや各構成オプションの詳細情報については、ライブラリーのドキュメントをご覧ください。
        入力された属性をチェックする
        このサンプルを［Download Sample（サンプルをダウンロード）］ボタンでダウンロードした場合は、domain、clientId、clientSecret属性が自動的に入力されます。特にアカウントに複数のAuth0アプリケーションがある場合は、値が正しいことを確認してください。
        プロジェクト構造
        ［Download Sample（サンプルをダウンロード）］ボタンでダウンロードできるサンプルプロジェクトは以下の構造になっています：
        - 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
+
+
        
+
+
        プロジェクトには単一のJSPがあります：home.jspは、ログイン成功後にユーザーに関連付けられたトークンを表示し、ログアウトオプションを提供します。
        プロジェクトはWebFilterを含みます：Auth0Filter.javaは、保護された/portal/*パスへのユーザーアクセスを付与する前に、既存のトークンを確認します。トークンが存在しない場合、要求はLoginServletへリダイレクトされます。
        プロジェクトにはサーブレットも4つあります：
        • LoginServlet.java：ユーザーがログインしようとした時に発動します。client_idパラメーターとdomainパラメーターを使って有効な認可URLを作成し、ユーザーをリダイレクトします。
        • CallbackServlet.java：Callback URLへの要求をキャッチし、データを処理して資格情報を取得するサーブレットです。資格情報はログイン成功後、要求のHttpSessionに保存されます。
        • HomeServlet.java：以前保存されたトークンを読み取り、home.jspリソースで表示するサーブレットです。
        • LogoutServlet.java：ユーザーがログアウトリンクをクリックすると発動します。ユーザーセッションを無効化し、LoginServletでハンドリングされたログインページにユーザーをリダイレクトします。
        • AuthenticationControllerProvider.java：AuthenticationControllerの単一インスタンスを作成・管理するためのものです。
        
+
+## AuthenticationControllerを作成する {{{ data-action="code" data-code="AuthenticationControllerProvider.java#5:26" }}}
+
+
+
        ユーザー認証を可能にするために、domain、clientId、clientSecretを使ってauth0-java-mvc-commons SDKから提供されたAuthenticationControllerのインスタンスを作成します。サンプルでは、RS256非対称署名アルゴリズムを使って署名したトークンで使用するためのコンポーネントの構成方法が紹介されています。トークンの署名を検証するために使用された公開鍵を取得するJwkProviderが指定されています。その他の構成オプションについての詳細は、jwks-rsa-javaレポジトリをご覧ください。HS256を使用している場合は、JwkProviderを構成する必要はありません。
        AuthenticationControllerはコンテキストを一切保存せず、再使用を意図しています。不必要な作成はリソースの追加作成を招き、パフォーマンスに影響が出る可能性があります。
        
+
+## ログインにリダイレクトする {{{ data-action="code" data-code="LoginServlet.java#21:23" }}}
+
+
+
        アプリケーションは、ユーザーがログインできるように、ユニバーサルログインページへリダイレクトします。AuthenticationControllerインスタンスを使うと、buildAuthorizeUrl(HttpServletRequest request、HttpServletResponse response、String redirectUrl)メソッドを呼び出すことでリダイレクトURLを生成できます。リダイレクトURLは、Auth0アプリケーションの［Allowed Callback URLs（許可されているコールバックURL）］に追加されたURLである必要があります。
        
+
+## トークンの処理 {{{ data-action="code" data-code="CallbackServlet.java#16:37" }}}
+
+
+
        ユーザーがログインした後、結果はGET要求またはPOST HTTP要求経由でCallbackServletで受信されます。（初期設定として）Authorization Code Flowを使用しているため、GET要求が送信されます。ライブラリーを暗黙フロー用に構成している場合は、代わりにPOST要求が送信されます。
        認可URLをAuthenticationControllerで生成することにより、要求はライブラリーで以前設定した呼び出しコンテキストを保持します。コントローラーに渡されると、有効なTokensインスタンスまたは不具合を特定するExceptionが返ってきます。呼び出しに成功した場合、後でアクセスするために資格情報をどこかに保存しておく必要があります。ライブラリーに含まれるSessionsUtilsクラスを使って、要求のHttpSessionを使用できます。
        トークンを要求した時刻と受け取ったexpiresIn値は保存することを推奨します。そうすることで、次回トークンを使用する時に、すでに有効期限が切れているか、または引き続き有効かを確認できます。このサンプルでは検証をスキップします。
        
+
+## ホームページを表示する {{{ data-action="code" data-code="HomeServlet.java#4:14" }}}
+
+
+
        ユーザーは認証される（トークンが存在する）と、Auth0Filterによって保護されたリソースへのアクセスを許可されます。HomeServletで要求セッションからトークンが取得され、userId属性として設定されることで、JSPコードから使用できるようになります。
        
+
+## ログアウトを処理する {{{ data-action="code" data-code="LogoutServlet.java#13:30" }}}
+
+
+
        ログアウトを適切に処理するには、セッションを消去し、ユーザーをAuth0からログアウトさせる必要があります。この処理は、サンプルアプリケーションのLogoutServletで行われます。
        まず、request.getSession().invalidate()を呼び出してセッションを消去します。それから、returnToクエリパラメーターを含めることを念頭に置きつつ、ログアウトURLを構築します。ユーザーはログアウト後にこのURLにリダイレクトされます。最後に応答をログアウトURLにリダイレクトします。
        
+
+## サンプルを実行する
+
+
+
        ターミナルからサンプルを実行するには、ディレクトリをプロジェクトのルートフォルダーに変更して以下のラインを実行します：
        ./gradlew clean app
        数秒後、アプリケーションがhttp://localhost:3000/でアクセスできるようになります。保護されたリソース（http://localhost:3000/portal/home）にアクセスしてみて、Auth0FilterによるAuth0ログインページへのリダイレクト方法を観察します。ウィジェット が、Dashboardでこのアプリケーションに定義したソーシャル接続とデータベース接続をすべて表示します。
        null
        認証成功後、ホームページのコンテンツを見られるようになります。
        null
        ホームページ右上の［logout（ログアウト）］ボタン をクリックしてログアウトします。
        
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/routes/web.md b/ja-jp/articles/quickstart/webapp/laravel/files/routes/web.md
new file mode 100644
index 0000000000..3552be454c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/files/routes/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/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..8550a63707
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,253 @@
+---
+title: Laravelアプリケーションにログインを追加する
+description: このガイドでは、新規（または既存）のLaravel 9または10アプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/routes/web
+github:
+  path: sample
+locale: ja-JP
+---
+
+# Laravelアプリケーションにログインを追加する
+
+
+
        Auth0のLaravel SDKを使用すると、Laravelアプリケーションに認証、ユーザープロファイル管理、ルーティングに基づくアクセスコントロールを手軽に追加できます。このガイドでは、新規（または既存）のLaravel 9または10アプリケーションにAuth0を統合する方法を説明します。
        
+
+## Laravelをインストールする
+
+
+
        Laravelアプリケーションをまだセットアップしていない場合には、シェルを開いて、新規プロジェクトに適切なディレクトリに移動し、次のコマンドを実行します：
        composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+
+
        
+
+
        このガイドにあるすべてのコマンドは、Laravelプロジェクトディレクトリのルートから実行されていることを前提としています。必ず新規プロジェクトのディレクトリに移動（cd）してください：
        cd auth0-laravel-app
+
+
        
+
+
        
+
+## SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 Laravel SDKをインストールします：
        composer require auth0/login:^7.8 --update-with-all-dependencies
+
+
        
+
+
        そして、アプリケーションにSDK構成ファイルを生成します：
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## SDKを構成する
+
+
+
        プロジェクトディレクトリから次のコマンドを実行して、Auth0 CLIをダウンロードします：
        curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+
+
        
+
+
        そして、Auth0アカウントを使ってCLIを認証し、プロンプトでユーザーとしてログインすることを選択します：
        ./auth0 login
+
+
        
+
+
        次に、Auth0で新しいアプリケーションを作成します：
        ./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
+
+
        
+
+
        また、新しいAPIも作成します：
        ./auth0 apis create \
+
+  --name "My Laravel Application's API" \
+
+  --identifier "https://github.com/auth0/laravel-auth0" \
+
+  --offline-access \
+
+  --no-input \
+
+  --json > .auth0.api.json
+
+
        
+
+
        これで、SDKを構成するプロジェクトディレクトリ内に2つのファイルが作成されます。
        これらのファイルには資格情報が保管されているため、機密として扱うことが重要です。必ず、バージョン管理では、これらのファイルをコミットしないようにしてください。Gitを使用している場合は、必ず.gitignoreファイルに追加します：
        echo ".auth0.*.json" >> .gitignore
+
+
        
+
+
        
+
+## ログイン経路
+
+
+
        SDKは、アプリケーションのユーザーを認証するために必要なすべての経路を自動的に登録します。
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        **経路****目的**
        /login認証フローを開始します。
        /logoutユーザーをログアウトさせます。
        /callbackAuth0からのコールバックを処理します。
        これらについて細かな制御が必要な場合や、アプリケーションで既存の経路と競合する場合には、SDKのコントローラーを手動で登録することができます。高度な統合について、SDKのREADMEを参照してください。
        
+
+## アクセス制御 {{{ data-action="code" data-code="routes/web.php#6:12" }}}
+
+
+
        Laravelの認証機能は「guards」を使用して、それぞれの要求でユーザーがどのように認証されるのかを定義します。アプリケーションの経路へのアクセスを制約するには、Auth0 SDKの認証ガードを使用することができます。
        経路へのアクセスに先だって、ユーザーの認証を要求するには、Laravelのauthミドルウェアを使用することができます。
        Route::get('/private', function () {
+
+  return response('Welcome! You are logged in.');
+
+})->middleware('auth');
+
+
        
+
+
        また、これをLaravelのcanミドルウェアと組み合わせると、認証済みのユーザーに特定の権限を要求することができます。
        Route::get('/scope', function () {
+
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+
+})->middleware('auth')->can('read:messages');
+
+
        
+
+
        
+
+## ユーザー情報 {{{ data-action="code" data-code="routes/web.php#14:24" }}}
+
+
+
        認証済みのユーザーについての情報は、LaravelのAuthファサードまたはauth()ヘルパー関数を介して利用できます。
        以下は、ユーザーの識別子とメールアドレスを取得する例です。
        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}.");
+
+});;
+
+
        
+
+
        
+
+## ユーザー管理 {{{ data-action="code" data-code="routes/web.php#26:43" }}}
+
+
+
        ユーザー情報は、Auth0 Management APIを使用して更新することができます。管理エンドポイントはすべて、SDKのmanagement()メソッドでアクセスすることができます。
        Management APIを呼び出す前に、アプリケーションがManagement APIと通信できるようにしなければなりません。これを実行するには、Auth0 DashboardのAPIページで［Auth0 Management API］を選択してから［Machine to Machine Applications（M2Mアプリケーション）］タブを選択します。Laravelアプリケーションを認可してから、下矢印をクリックして、付与したいスコープを選択します。
        以下の例では、ユーザーのメタデータを更新し、好きな色をランダムに割り当てますが、必ずread:usersとupdate:usersのスコープを付与するようにします。APIエンドポイントのリストと必要なスコープについては、Management APIのドキュメントを参照してください。
        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');
+
+
        
+
+
        SDKにあるManagement APIの全メソッドについては、こちらにクイックリファレンスガイドがあります。
        
+
+## アプリケーションを実行する
+
+
+
        Laravelアプリケーションを起動する準備が整いました。要求を受け付けることができます：
        php artisan serve
        Laravel - 手順8 - アプリケーションを実行する - チェックポイント 
        ブラウザーを開いて、以下の経路にアクセスしてみてください。
        
+
+  
        
+
+  
        
+
+  
        その他の情報
        • ユーザーリポジトリとモデルはAuth0 Laravel SDKを拡張して、カスタムのユーザーモデルを使用し、データベースでユーザーの保管や取得を行う方法を指定することができます。
        • イベントフックはAuth0 Laravel SDKで発生したイベントを聞く方法を処理して、統合の動作を完全にカスタマイズすることができます。
        • Management API対応はAuth0 Laravel SDKに組み込まれているため、LaravelアプリケーションからManagement APIと対話することができます。
        
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/.env.md b/ja-jp/articles/quickstart/webapp/nextjs/files/.env.md
new file mode 100644
index 0000000000..e4de060766
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/.env.md
@@ -0,0 +1,12 @@
+---
+name: .env.local
+language: 
+---
+    
+```
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+APP_BASE_URL='http://localhost:3000'
+AUTH0_DOMAIN='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
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/files/src/app/page.md b/ja-jp/articles/quickstart/webapp/nextjs/files/src/app/page.md
new file mode 100644
index 0000000000..c623d584a1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/src/app/page.md
@@ -0,0 +1,40 @@
+---
+name: src/app/page.tsx
+language: javascript
+---
+    
+```javascript
+import { auth0 } from "@/lib/auth0";
+import './globals.css';
+
+export default async function Home() {
+  // Fetch the user session
+  const session = await auth0.getSession();
+
+  // If no session, show sign-up and login buttons
+  if (!session) {
+    return (
+      
        
+        
+          
+        
+        
+          
+        
+      
        
+    );
+  }
+
+  // If session exists, show a welcome message and logout button
+  return (
+    
        
+      
        Welcome, {session.user.name}!
        
+      
        
+        
+          
+        
+      
        
+    
        
+  );
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md b/ja-jp/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
new file mode 100644
index 0000000000..d6a24d5995
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/src/lib/auth0.md
@@ -0,0 +1,10 @@
+---
+name: src/lib/auth0.ts
+language: javascript
+---
+    
+```javascript
+import { Auth0Client } from "@auth0/nextjs-auth0/server";
+
+export const auth0 = new Auth0Client();
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/src/middleware.md b/ja-jp/articles/quickstart/webapp/nextjs/files/src/middleware.md
new file mode 100644
index 0000000000..cac77eaa10
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/src/middleware.md
@@ -0,0 +1,25 @@
+---
+name: src/middleware.ts
+language: javascript
+---
+    
+```javascript
+import type { NextRequest } from "next/server";
+import { auth0 } from "./lib/auth0";
+
+export async function middleware(request: NextRequest) {
+  return await auth0.middleware(request);
+}
+
+export const config = {
+  matcher: [
+    /*
+     * Match all request paths except for the ones starting with:
+     * - _next/static (static files)
+     * - _next/image (image optimization files)
+     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
+     */
+    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
+  ],
+};
+```
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..bf675dba9d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,71 @@
+---
+title: Next.jsアプリケーションにログインを追加する
+description: このガイドは、新規または既存のNext.jsアプリケーションにAuth0 Next.js SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/.env
+ - files/src/lib/auth0
+ - files/src/middleware
+ - files/src/app/page
+github:
+  path: Sample-01
+locale: ja-JP
+---
+
+# Next.jsアプリケーションにログインを追加する
+
+
+
        このガイドは、新規または既存のNext.jsアプリケーションにAuth0 Next.js SDKを使ってAuth0を統合する方法を説明します。アカウント用に構成された例を参考にして、このクイックスタートに従うことをお勧めします。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻されません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/auth/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## Auth0 Next.js SDKをインストールする
+
+
+
        プロジェクトディレクトリで次のコマンドを実行して、Auth0 Next.js SDKをインストールします：
        npm install @auth0/nextjs-auth0
        SDKは、Auth0をNext.jsアプリケーションに統合するのに役立つメソッドと変数を公開します。この際、バックエンドではルートハンドラーを、フロントエンドではReactフックが付いたReactコンテキストを使用します。
        
+
+## SDKを構成する {{{ data-action="code" data-code=".env.local" }}}
+
+
+
        プロジェクトのルートディレクトリで、.env.localファイルを追加し、以下の変数環境を設定します：
        • AUTH0_SECRET：セッションクッキーの暗号化に使用する長いシークレット値です。適した文字列は、コマンドラインのopenssl rand -hex 32で生成できます。
        • AUTH0_BASE_URL：アプリケーションのベースURLです。
        • AUTH0_ISSUER_BASE_URL：Auth0テナントドメインのURLです。Auth0を使用したカスタムドメインでは、この値を［Settings（設定）］タブに反映された値でなく、カスタムドメインの値に設定します。
        • AUTH0_CLIENT_ID：Auth0アプリケーションのクライアントIDです。
        • AUTH0_CLIENT_SECRET：Auth0アプリケーションのクライアントシークレットです。
        SDKは、Node.jsプロセス環境からこれらの値を読み取り、自動構成します。
        
+
+## 動的ルートハンドラーを追加する {{{ data-action="code" data-code="src/lib/auth0.ts" }}}
+
+
+
        このクイックスタートは、Next.jsアプリルーターを取り扱います。ページルーターを使用している場合は、SDKのREADMEの例を確認してください。
        app/api/auth/[auth0]/route.jsでファイルを作成します。これは、動的ルートセグメントを持つルートハンドラーです。
        次に、SDKからhandleAuthメソッドをインポートし、GETエクスポートから呼び出します。これで、以下のルートが作成されます。
        • /api/auth/login：Auth0でログインを実行するために使用されるルートです。
        • /api/auth/logout：ユーザーをログアウトするために使用されるルートです。
        • /api/auth/callback：ログインに成功した後、Auth0がユーザーをリダイレクトするルートです。
        • /api/auth/me：ユーザープロファイルを取得するためのルートです。
        
+
+## UserProviderコンポーネントを追加する {{{ data-action="code" data-code="src/middleware.ts" }}}
+
+
+
        フロントエンド側では、SDKはReact Contextを使用して、ユーザーの認証状態を管理します。その状態をすべてのページで使用できるようにするには、Root Layoutコンポーネントを上書きし、app/layout.jsxファイルで<body>タグをUserProviderでラップする必要があります。
        UserProviderによって公開された認証状態は、useUser()フックを使って任意のクライアントコンポーネントでアクセスすることができます。
        Next.js手順5「チェックポイント」 
        ルートハンドラーとUserProviderを追加したら、アプリケーションを実行してAuth0に関連したエラーを投入していないか確認します。
        
+
+  
        
+
+  
        
+
+  
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="src/app/page.tsx" }}}
+
+
+
        ユーザーはSDKによって提供された/api/auth/loginルートハンドラーを訪れることで、アプリケーションにログインできるようになりました。アンカータグを使ってログインルートを指すリンクをクリックします。クリックするとユーザーはAuth0ユニバーサルログインページにリダイレクトされ、そこで、Auth0はユーザーを認証することができます。認証に成功したら、Auth0はユーザーをアプリケーションにリダイレクトで戻します。
        ログアウトの機能性はすでにsrc/app/page.tsxファイルに含まれています。ユーザーが［Log out（ログアウト）］ボタンを選択すると、Auth0のログアウトエンドポイントにリダイレクトされ、セッションの消去後にアプリにリダイレクトで戻されます。
        Next.js手順6「チェックポイント」 
        アプリケーションにログインリンクを追加する
        • ログインリンクをクリックすると、Next.jsアプリケーションによってAuth0ユニバーサルログインページにリダイレクトされ、ユーザー名とパスワードまたはソーシャルプロバイダーを使ってログインまたはサインアップできるようになったことを確認します。
        • 完了したら、Auth0がアプリケーションにリダイレクトで戻すことを確認します。
        
+
+  
        
+
+  
        
+
+  
        null
        Auth0は、Googleソーシャルプロバイダーを新しいテナントでデフォルトで有効にし、ソーシャルIDプロバイダーでログインテストを実施するための開発者キーを提供します。ただし、これらの開発者キーにはいくつかの制限が設けられており、これによってアプリケーションが異なる動作をする場合があります。この動作の様子と修正方法については、「Auth0開発者キーを使ってソーシャル接続をテストする」ドキュメントを参照してください。
        
+
+## アプリケーションにログアウトを追加する
+
+
+
        Next.jsアプリケーションにログインできるようになったら、ログアウトする方法が必要です。/api/auth/logout APIルートを指すリンクを追加します。クリックするとユーザーは、Auth0ログアウトエンドポイント（https://YOUR_DOMAIN/v2/logout）にリダイレクトされ、即座にアプリケーションにリダイレクトで戻ります。
        チェックポイント 
        アプリケーションを実行する
        • Next.jsアプリケーションがAuth0のユニバーサルログインページにリダイレクトし、ユーザー名とパスワードまたはソーシャルプロバイダーを使ってログインまたはサインアップできるようになったことを確認します。
        • 完了したら、Auth0がアプリケーションにリダイレクトで戻すことを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 環境変数が正しく入力されていますか？
        • テナントに［Allowed Callback URLs（許可されているCallback URL）］が正しく構成されていることを確認します
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/files/frontend.md b/ja-jp/articles/quickstart/webapp/nginx-plus/files/frontend.md
new file mode 100644
index 0000000000..20c215f56b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/files/frontend.md
@@ -0,0 +1,34 @@
+---
+name: frontend.conf
+language: 
+---
+    
+```
+# auth_jwt_claim_set $claim_name https://namespace/key;
+
+server {
+    include conf.d/openid_connect.server_conf; # Authorization code flow and Relying Party processing
+    error_log /var/log/nginx/error.log debug;  # Reduce severity level as required
+
+    listen 8010; # Use SSL/TLS in production
+
+    location / {
+        # This site is protected with OpenID Connect
+        auth_jwt "" token=$session_jwt;
+        error_page 401 = @do_oidc_flow;
+
+        #auth_jwt_key_file $oidc_jwt_keyfile; # Enable when using filename
+        auth_jwt_key_request /_jwks_uri; # Enable when using URL
+
+        # Successfully authenticated users are proxied to the backend,
+        # with 'sub' claim passed as HTTP header
+        proxy_set_header username $jwt_claim_sub;
+        proxy_set_header x-email $jwt_claim_email;
+        #proxy_set_header x-custom $claim_name;             # namespaced claim
+
+        proxy_pass http://my_backend; # The backend site/app
+
+        access_log /var/log/nginx/access.log main_jwt;
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/files/nginx.md b/ja-jp/articles/quickstart/webapp/nginx-plus/files/nginx.md
new file mode 100644
index 0000000000..e3f7cac534
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/files/nginx.md
@@ -0,0 +1,10 @@
+---
+name: nginx.conf
+language: 
+---
+    
+```
+...
+load_module modules/ngx_http_js_module.so;
+...
+```
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connect.md b/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
new file mode 100644
index 0000000000..3e1a926164
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connect.md
@@ -0,0 +1,22 @@
+---
+name: openid_connect.server_conf
+language: 
+---
+    
+```
+location = /_jwks_uri {
+    internal;
+    ...
+    proxy_set_header    Content-Length "";           
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+
+location = /_token {
+    internal;
+    ...
+    proxy_set_header    Content-Type "application/x-www-form-urlencoded";
+    proxy_set_header    Accept-Encoding "gzip";
+    ...
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md b/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
new file mode 100644
index 0000000000..429c0e2605
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/files/openid_connection_configuration.md
@@ -0,0 +1,10 @@
+---
+name: openid_connection_configuration.conf
+language: 
+---
+    
+```
+map $host $oidc_logout_redirect {
+    default "https://${account.namespace}/v2/logout";
+}
+```
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..39515d2a7f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/index.yml
@@ -0,0 +1,24 @@
+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
+hidden_articles:
+  - "interactive"
+contentType: tutorial
+useCase: quickstart
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/interactive.md b/ja-jp/articles/quickstart/webapp/nginx-plus/interactive.md
new file mode 100644
index 0000000000..6955b3554a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,71 @@
+---
+title: NGINX Plus
+description: このチュートリアルでは、nginx-openid-connectモジュールを使用して、NGINXサーバーに認証と認可を追加する方法について説明します。
+interactive:  true
+files:
+ - files/nginx
+ - files/openid_connection_configuration
+ - files/openid_connect
+ - files/frontend
+locale: ja-JP
+---
+
+# NGINX Plus
+
+
+
        このチュートリアルでは、nginx-openid-connectモジュールを使用して、NGINXサーバーに認証と認可を追加する方法について説明します。 ログインして、アカウント用に構成された例を参考にこのクイックタートに従うことをお勧めします。
        システム要件
        このチュートリアルとシードプロジェクトは次を使用してテストが完了しています：
        • NGINX Plus R24
        
+
+## nginx-plus-module-njsモジュールをインストールして有効にする {{{ data-action="code" data-code="nginx.conf" }}}
+
+
+
        まず、NGINX Plusにnginx-plus-module-njsモジュールをインストールする必要があります。
        動的モジュールのインストールガイドに従って、ホストOSにパッケージをインストールします。
        yumパッケージ管理ツールを使用しているLinuxディストリビューションでは、soのようなモジュールをインストールすることができます：
        sudo yum install nginx-plus-module-njs jq
        インストールしたら、それをNGINXに有効化する必要があります。次の行を/etc/nginx/nginx.confファイルの最上部近くに追加してください：
        load_module modules/ngx_http_js_module.so;
        
+
+## nginx-openid-connectテンプレートリポジトリを確認する
+
+
+
        nginx-openid-connectリポジトリをクローンします。このリポジトリにはテンプレート構成があります。
        git clone https://github.com/nginxinc/nginx-openid-connect
        
+
+## Auth0アプリケーションの詳細でNGINXを構成する {{{ data-action="code" data-code="openid_connection_configuration.conf" }}}
+
+
+
        nginx-openid-connectフォルダーにあるconfigure.shスクリプトを実行して、テンプレートの構成にAuth0アプリケーションの詳細を入力します。
        ./configure.sh --auth_jwt_key request \
+
+  --client_id ${account.clientId} \
+
+  --pkce_enable \
+
+  https://${account.namespace}/.well-known/openid-configuration
+
+
        
+
+
        次に、テナントのログアウトURLをopenid_connect_configuration.confファイルに追加します。
        
+
+## トークンとJWKSエンドポイントにAccept-Encodingヘッダーを構成する {{{ data-action="code" data-code="openid_connect.server_conf" }}}
+
+
+
        openid_connect.server_confファイルにAccept-Encodingヘッダーを追加して、 gzipに値を設定します。
        
+
+## OpenID Connect構成ファイルをコピーする
+
+
+
        4つの構成ファイルをconf.dフォルダーにコピーします。
        sudo cp openid_connect.js \ 
+
+   frontend.conf \
+
+   openid_connect_configuration.conf \
+
+   openid_connect.server_conf /etc/nginx/conf.d
+
+
        
+
+
        
+
+## Auth0のアプリケーション設定を構成する
+
+
+
        Auth0 Dashboardで以下を行います。
        1. ［Applications（アプリケーション）］ > ［Applications（アプリケーション）］に移動し、リストからアプリケーションを選択します。
        2. ［Settings（設定）］ビューに切り替えます。
        3. ［Application URI（アプリケーションURI）］セクションの［Allowed Callback URLs（許可されているコールバックURL）］にhttps://{yourDomain}/_codexchを追加します。
        4. ［Credentials（資格情報）］ビューに切り替えます。
        ［Application Authentication（アプリケーション認証）］セクションで、認証方法を［None（なし）］に設定します。
        
+
+## アップストリームアプリケーションにヘッダーを渡す {{{ data-action="code" data-code="frontend.conf" }}}
+
+
+
        IDトークン（JWT）からの追加のヘッダーを/etc/nginx/conf.d/frontend.confファイルでアップストリームの対象に追加します。
        
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..d6d8f81048
--- /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..da33ff8012
--- /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..cd4e6a9608
--- /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..fc2fbda6e1
--- /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..35740dafe5
--- /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..a985fe6cd3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/interactive.md
@@ -0,0 +1,88 @@
+---
+title: PHPアプリケーションにログインを追加する
+description: このガイドは、PHPアプリケーションにAuth0 PHP SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+ - files/router
+ - files/callback
+github:
+  path: app
+locale: ja-JP
+---
+
+# PHPアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに手軽に認証を追加することができます。このガイドは、PHPアプリケーションにAuth0 PHP SDKを使ってAuth0を統合し、認証の追加とユーザープロファイル情報の表示を行う方法について説明します。
        このクイックスタートを使用するには、以下の手順に従います：
        • Auth0の無料アカウントにサインアップするか、Auth0にログインします。
        • 統合したいPHPプロジェクトを用意します。または、ログインした後に、サンプルアプリケーションを表示してダウンロードすることもできます。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadでセットアップしたアプリケーションが必要です。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        インタラクティブセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0の全てのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションに自動更新を行います。今後、アプリケーションの管理はDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        ［Allowed Web Origin（許可されているWebオリジン）］とは、認証フローにアクセスすることを許可して欲しいURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## Auth0 PHP SDKをインストールする {{{ data-action="code" data-code="index.php" }}}
+
+
+
        PHPアプリで、Auth0の認証・認可を手軽に実装できるように、Auth0はPHP SDK（Auth0-PHP）を提供しています。
        Auth0 PHP SDKでは、ネットワーク要求を管理するために、PSR-17とPSR-18対応HTTPライブラリーをインストールする必要があります。ライブラリーがない場合は、ターミナルで以下のコマンドを実行して、信頼できる選択肢をインストールすることができます：
        cd <your-project-directory>
+
+composer require symfony/http-client nyholm/psr7
+
+
        
+
+
        ターミナルで以下のコマンドを実行してAuth0 PHP SDKをインストールします：
        composer require auth0/auth0-php
+
+
        
+
+
        Auth0 SDKを構成する
        アプリケーションでindex.phpと呼ばれる新しいファイルを作成し、index.phpタブにある、右のインタラクティブパネルからコードをコピーします。
        SDKが正しく機能するためには、次のプロパティを初期化中にAuth0 SDKで設定しなければなりません：
        • domain：Auth0テナントのドメインです。通常、Auth0 Dashboardにあるアプリケーションの設定の［Domain（ドメイン）］フィールドで確認できます。カスタムドメインを使用している場合は、その値を代わりに設定してください。
        • clientId：このクイックスタートで前にセットアップした、Auth0アプリケーションのIDです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client ID（クライアントID）］フィールドで確認できます。
        • clientSecret：このクイックスタートで前にセットアップしたAuth0アプリケーションのシークレットです。Auth0 Dashboardにあるアプリケーションの［Settings（設定）］の［Client Secret（クライアントシークレット）］フィールドで確認できます。
        • redirectUri：ユーザー認証の後、Auth0にユーザーをリダイレクトするアプリケーション内URLです。このクイックスタートで前にセットアップしたCallback URLと呼応します。Auth0 Dashboardにあるアプリケーションの設定の［Callback URLs（コールバックURL）］フィールドでもこの値を確認できます。コードに入力した値と前にセットアップした値は必ず一致させてください。異なった場合はユーザーにエラーが表示されます。
        • cookieSecret：セッションクッキーの暗号化に使用する長いシークレット値です。ターミナルでopenssl rand -hex 32を実行すると、適切な文字列を生成することができます。
        PHP手順2「チェックポイント」 
        Auth0 SDKが正しく構成されました。アプリケーションを実行して次の点を確認します：
        • SDKが正しく初期化している。
        • アプリケーションがAuth0に関連したエラーを投入していない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいアプリケーションが選択されていることを確認します。
        • URLを入力した後で保存しましたか？
        • ドメインとクライアントIDが正常にインポートされていることを確認します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ルートを作成する {{{ data-action="code" data-code="router.php" }}}
+
+
+
        次に、受信要求をアプリケーションにダイレクトするために、ルーティングライブラリーをインストールします。これは必須手順ではありませんが、本クイックスタートの目的上、アプリケーション構造が簡略化されます。
        composer require steampixel/simple-php-router
+
+
        
+
+
        アプリケーションでrouter.phpと呼ばれる新しいファイルを作成してルートを定義し、右のインタラクティブパネルからコードをコピーします。
        
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="login.php" }}}
+
+
+
        Auth0アプリケーションとAuth0 PHP SDKの構成が完了したら、プロジェクトのためにログインをセットアップする必要があります。これを実現するには、SDKのlogin()メソッドを使用して、ユーザーをAuth0のユニバーサルログインページにリダイレクトするログインボタンを作成します。ユーザーが認証に成功すると、このクイックスタートで前にセットアップしたCallback URLへリダイレクトされます。
        アプリケーションでlogin.phpという名前の新規ファイルを作成し、右のインタラクティブパネルからコードをコピーします。これにはログインに必要なロジックが含まれています。
        Php手順4「チェックポイント」 
        ユーザー名とパスワードを使ってログインやサインアップができるようになりました。
        ログインリンクをクリックして次の点を確認します：
        • アプリケーションによってAuth0ユニバーサルログインページにリダイレクトされる。
        • ログインまたはサインアップできる。
        • Auth0が、SDKを構成するために使ったredirectUriの値を使用し、アプリケーションへリダイレクトする。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいredirectUriが構成されている。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.php" }}}
+
+
+
        プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのlogout()メソッドを使用してログアウトボタンを処理します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLへとリダイレクトで戻されます。
        アプリケーションでlogout.phpという名前の新規ファイルを作成し、インタラクティブパネルからコードをコピーします。これにはログアウトに必要なロジックが含まれています。それからindex.phpファイルを更新して新しいログアウトボタンを含めます。
        PHPセクション5「チェックポイント」 
        アプリケーションを実行してログアウトボタンをクリックし、次の点を確認します：
        • アプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
        • アプリケーションにもうログインしていない。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • 正しいログアウトURLが構成されている。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile.php" }}}
+
+
+
        ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。
        Auth0 PHP SDKではgetCredentials()メソッドからユーザー情報が提供されます。インタラクティブパネルでprofile.phpコードを確認し、使用方法の例をチェックします。
        このメソッドにはユーザーのアイデンティティに関する機密情報が含まれるため、この方法が使用できるかはユーザーの認証ステータスによります。エラーを防ぐため、getCredentials()メソッドがobjectまたはnullを返すかを必ず確認し、アプリケーションが結果を使用する前に、Auth0がユーザーを認証したかどうか判定します。
        Phpセクション6「チェックポイント」 
        以下の点を確認します：
        • ログイン後、nicknameやその他のユーザープロパティをすべて正しく表示できる。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • profile.phpファイルが作成済みで、ログインされている。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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..194c279e61
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/files/server.md
@@ -0,0 +1,67 @@
+---
+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/files/templates/home.md b/ja-jp/articles/quickstart/webapp/python/files/templates/home.md
new file mode 100644
index 0000000000..d543f58b29
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/files/templates/home.md
@@ -0,0 +1,23 @@
+---
+name: templates/home.html
+language: markup
+---
+    
+```markup
+
+
+  
+  Auth0 Example
+
+
+  {% if session %}
+      
        Welcome {{session.userinfo.name}}!
        
+      
        Logout
        
+      
        {{pretty}}
        
+  {% else %}
+    
        Welcome Guest
        
+    
        Login
        
+  {% endif %}
+
+
+```
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..410381ee31
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/interactive.md
@@ -0,0 +1,93 @@
+---
+title: Python Flaskアプリケーションにログインを追加する
+description: このガイドでは、Python FlaskアプリケーションにAuthlib SDKを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/server
+ - files/templates/home
+github:
+  path: 01-Login
+locale: ja-JP
+---
+
+# Python Flaskアプリケーションにログインを追加する
+
+
+
        Auth0を使用すると、アプリケーションに認証を追加して、ユーザープロファイル情報にアクセスすることができます。このガイドでは、Python FlaskアプリケーションにAuthlib SDKを使ってAuth0を統合する方法を説明します。
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadでセットアップしたアプリケーションが必要です。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        代わりに完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## 依存関係をインストールする
+
+
+
        プロジェクトディレクトリにrequirements.txtファイルを作成します：
        # 📁 requirements.txt -----
+
+
+
+flask>=2.0.3
+
+python-dotenv>=0.19.2
+
+authlib>=1.0
+
+requests>=2.27.1
+
+
        
+
+
        シェルから以下のコマンドを実行し、プロジェクトで依存関係が利用できるようにします：
        pip install -r requirements.txt
+
+
        
+
+
        
+
+## .envファイルを構成する
+
+
+
        次に、プロジェクトのディレクトリに.envファイルを作成します。このファイルにはクライアントキーやその他の構成情報が含まれます。
        # 📁 .env -----
+
+
+
+AUTH0_CLIENT_ID=${account.clientId}
+
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+AUTH0_DOMAIN=${account.namespace}
+
+APP_SECRET_KEY=
+
+
        
+
+
        • シェルからopenssl rand -hex 32を使って、APP_SECRET_KEYの文字列を生成します。
        
+
+## アプリケーションをセットアップする {{{ data-action="code" data-code="templates/home.html" }}}
+
+
+
        次に、アプリケーションをセットアップします。プロジェクトディレクトリでserver.pyファイルを作成します。このファイルにはアプリケーションロジックが含まれます。
        アプリケーションに必要なすべてのライブラリーをインポートします。
        前の手順で作成した構成.envファイルを読み込みます。
        Auth0でアプリケーションの認証を処理するためにAuthlibを構成します。AuthlibのOAuth register()メソッドで使用できる構成オプションの詳細については、Authlibのドキュメント
        
+
+## ルートをセットアップする {{{ data-action="code" data-code="server.py" }}}
+
+
+
        この例では、アプリケーションにlogin、callback、logout、homeの4つのルートを追加します。
        アプリ訪問者が/loginルートにアクセスすると、アプリケーションはユーザーをAuth0ログインページに遷移します。
        ユーザーがAuth0でログインした後、アプリケーションはユーザーを/callbackルートに遷移します。このルートはユーザーのためにセッションを保存し、戻ってきた時に再度ログインする必要性を回避します。
        /logoutルートは、ユーザーをアプリケーションからサインアウトさせます。アプリのユーザーセッションを消去し、Auth0ログアウトエンドポイントにリダイレクトして、セッションがもう保存されていないことを保証します。その後、アプリケーションはユーザーをホームルートにリダイレクトします。
        /ホームルートは認証されたユーザーの詳細を表示したり、訪問者のサインインを許可したりします。
        
+
+## テンプレートを追加する
+
+
+
        次に、（render_template()の呼び出し中に）ホームルートで使用されるテンプレートファイルを作成します。
        templatesという名前のプロジェクトフォルダーに新しいサブディレクトリを作成し、ディレクトリにhome.htmlを作成します。コンテンツを右から対象ファイルに貼り付けます。
        
+
+## アプリケーションを実行する
+
+
+
        アプリケーションを実行するには、プロジェクトディレクトリのルートに移動し、ターミナルを開きます。次のコマンドを実行します：
        python3 server.py
+
+
        
+
+
        Python手順7「チェックポイント」 
        検証するにはhttp://localhost:3000を訪問します。ログインのためにAuth0へルートするログインボタンがあり、ログイン後アプリケーションに戻るとプロファイル情報を確認できます。
        
+
+  
        
+
+  
        アプリケーションが正常に起動しなかった場合は以下を行います。
        • コンソールでエラーを確認します。
        • ドメインとクライアントIDが正常にインポートされていることを確認します。
        • テナントの構成を確認します。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
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/auth0.md b/ja-jp/articles/quickstart/webapp/rails/files/auth0.md
new file mode 100644
index 0000000000..1f2fac9081
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/auth0.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
+```
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/auth0_controller.md b/ja-jp/articles/quickstart/webapp/rails/files/auth0_controller.md
new file mode 100644
index 0000000000..af8dc0c527
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/auth0_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/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/config/auth0.md b/ja-jp/articles/quickstart/webapp/rails/files/config/auth0.md
new file mode 100644
index 0000000000..35907e29d2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/config/auth0.md
@@ -0,0 +1,11 @@
+---
+name: config/auth0.yml
+language: yaml
+---
+    
+```yaml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: ${account.clientSecret}
+```
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..f4b9d7219d
--- /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
+```
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/secured.md b/ja-jp/articles/quickstart/webapp/rails/files/secured.md
new file mode 100644
index 0000000000..a1f58412c4
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/secured.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
+```
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..22a84ad8ff
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,132 @@
+---
+title: Ruby on Railsアプリケーションにログインを追加する
+description: このチュートリアルは、Ruby on Railsアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/config/auth0
+ - files/auth0
+ - files/auth0_controller
+ - files/routes
+ - files/secured
+github:
+  path: sample
+locale: ja-JP
+---
+
+# Ruby on Railsアプリケーションにログインを追加する
+
+
+
        
+
+## Auth0を構成する
+
+
+
        Auth0のサービスを利用するには、Auth0 Dashboadに設定済みのアプリケーションがある必要があります。Auth0アプリケーションは、開発中のプロジェクトに対してどのように認証が動作して欲しいかを構成する場所です。
        アプリケーションを構成する
        対話型のセレクターを使ってAuth0アプリケーションを新規作成するか、統合したいプロジェクトを表す既存のアプリケーションを選択します。Auth0のすべてのアプリケーションには英数字からなる一意のクライアントIDが割り当てられており、アプリケーションのコードがSDKを通じてAuth0 APIを呼び出す際に使用されます。
        このクイックスタートを使って構成されたすべての設定は、Dashboardのアプリケーションを自動更新します。今後、アプリケーションの管理もDashboardで行えます。
        完了済みの構成を見てみたい場合は、サンプルアプリケーションをご覧ください。
        Callback URLを構成する
        Callback URLとは、Auth0がユーザーを認証後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはログイン後にアプリケーションに戻りません。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000/auth/auth0/callbackに設定してください。
        ログアウトURLを構成する
        ログアウトURLとは、Auth0がユーザーをログアウト後にリダイレクトするアプリケーション内URLです。設定されていない場合、ユーザーはアプリケーションからログアウトできず、エラーを受け取ります。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        Allowed Web Origins（許可されているWebオリジン）を構成する
        Allowed Web Origin（許可されているWebオリジン）とは、認証フローへのアクセスを許可されるURLです。これにはプロジェクトのURLが含まれている必要があります。適切に設定されていない場合、プロジェクトが認証トークンを暗黙でリフレッシュできず、ユーザーがアプリケーションを再び訪問した時、またはページを再読み込みした時にログアウトした状態になってしまいます。
        サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
        
+
+## 依存関係を追加する
+
+
+
        認証フローをハンドリングするには、カスタムOmniAuthストラテジーであるomniauth-auth0を使います。
        Gemfileに次の依存関係を追加します：
        gem 'omniauth-auth0', '~> 3.0'
+
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+
+
        
+
+
        gemが追加されたら、bundle installでインストールします。
        
+
+## SDKを構成する {{{ data-action="code" data-code="config/auth0.yml" }}}
+
+
+
        構成ファイル./config/auth0.ymlを作成して、Auth0 Dashboardにあるアプリケーションの［Settings（設定）］で確認できるAuth0ドメイン、クライアントID、クライアントシークレットの値を指定します。
        
+
+## OmniAuthミドルウェアを構成する {{{ data-action="code" data-code="auth0.rb" }}}
+
+
+
        ./config/initializers/auth0.rbという以下のイニシャライザーファイルを作成し、前の手順で作成した構成ファイルでOmniAuthミドルウェアを構成します。
        callback_pathがAuth0アプリケーションの［Allowed Callback URLs（許可されているコールバックURL）］にある値と一致することを確認します。
        
+
+## Auth0コントローラーを追加する {{{ data-action="code" data-code="auth0_controller.rb" }}}
+
+
+
        ログアウトURLを構築するために、認証コールバック、logoutアクション、メソッドをハンドリングするAuth0コントローラーを作成します。
        次のコマンドを実行します：rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine。
        コールバックメソッドの内部で、（request.env['omniauth.auth']として返された）ユーザー情報のハッシュをアクティブセッションに割り当てます。
        ログアウトを構築するため、logoutアクションの内部でreset_sessionメソッドを呼び出し、セッション内に保存されたオブジェクトをすべて消去します。それから、Auth0ログアウトエンドポイントにリダイレクトします。reset_sessionについての詳細は、「Ruby on Rails ActionController」ドキュメントをご覧ください。
        
+
+## ルートを構成する {{{ data-action="code" data-code="routes.rb" }}}
+
+
+
        これらのルートを./config/routes.rbファイルに追加します。
        ルートは所定の位置になければなりません。これにより、RailsはさまざまなAuth0 Callback URLを前の手順で作成したAuth0コントローラーにルートする方法を認識します。
        Ruby on Railsクイックスタート - 手順6「チェックポイント」 
        アプリケーションを実行して、意図通りに動作し続け、Auth0に関連したエラーを受け取らないことを確認します。
        
+
+  
        
+
+  
        すみません。エラーが起きることなく以前の手順が完了したことをもう一度確認してください。
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログインを追加する
+
+
+
        ユーザーが/auth/auth0エンドポイントを訪れると、アプリケーションにログインできるようになりました。
        偽の認証要求を防ぐためには、link_toまたはbutton_toヘルパーメソッドを:postメソッドと一緒に使います。
        <!-- Place a login button anywhere on your application -->
+
+\${ "<\%= button_to 'Login', '/auth/auth0', method: :post %>" }
+
+
        
+
+
        Ruby on Railsクイックスタート - 手順7「チェックポイント」 
        選択されるとユーザーを/auth/auth0エンドポイントにリダイレクトするボタンを、アプリケーションに追加します。ログインのためAuth0にリダイレクトされ、認証に成功するとアプリに戻されることを確認してください。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • クイックスタートの最初の手順で行ったように、Auth0アプリケーションに正しいURLが設定されていることを確認します
        • すべての必要なgemが正しくインストールされていることを確認します
        • 経路がセットアップされ、アプリにAuth0の構成がセットアップされていることを確認します
        • ログを確認して、ログインの動作を妨げているかもしれない他のエラーやメッセージについて調べます
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## アプリケーションにログアウトを追加する
+
+
+
        Railsアプリケーションにログインできるようになったら、ログアウトする方法が必要です。ユーザーをauth/logoutアクションにリダイレクトしてログアウトさせると、ユーザーはAuth0ログアウトエンドポイントへリダイレクトされます。
        前の手順の後にこの手順をテストするには、セッションを消去して、ユーザーをAuth0ログアウトエンドポイントへリダイレクトしなければならない可能性があります。
        <!-- Place a logout button anywhere on your application -->
+
+\${"<%= button_to 'Logout', 'auth/logout', method: :get %>"}
+
+
        
+
+
        Ruby on Railsクイックスタート - 手順8「チェックポイント」 
        選択されるとユーザーを/auth/logoutエンドポイントにリダイレクトするボタンを、アプリケーションに追加します。Auth0にリダイレクトされた後即座にアプリケーションに戻り、ログインした状態ではないことを確認します。
        
+
+  
        
+
+  
        すみません。いくつかの点をもう一度確認してください。
        • クイックスタートの最初の手順で行ったように、Auth0クライアントに正しいURLが設定されていることを確認します
        • 経路がセットアップされ、アプリにAuth0の構成がセットアップされていることを確認します
        • ログを確認して、ログインの動作を妨げているかもしれない他のエラーやメッセージについて調べます
        まだお困りですか？当社提供のドキュメントまたはコミュニティページで詳しい情報を確認してください。
        
+
+  
        
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="routes.rb" }}}
+
+
+
        ユーザーのプロファイルを表示するには、アプリケーションに保護されたルートがなければなりません。ルートへのアクセスはConcernで管理でき、複数のコントローラーで共有できます。Concernはユーザーが認証されていない場合、自動的にAuth0にリダイレクトしなければなりません。そうでない場合は、Concernは現在のユーザープロファイルを返します。
        Concernができたら、ログインユーザーを必要とするすべてのコントローラーに含めます。その後、次の例のように、session[:userinfo]セッションからユーザーにアクセスできます：
        class DashboardController < ApplicationController
+
+  include Secured
+
+
+
+  def show
+
+    @user = session[:userinfo]
+
+  end
+
+end
+
+
        
+
+
        ユーザーがセッションから読み込まれたら、フロントエンドで情報を表示するために使います：
        <div>
+
+  <p>Normalized User Profile:\${"<%= JSON.pretty_generate(@user[:info])%>"}</p>
+
+  <p>Full User Profile:\${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}</p>
+
+</div>
+
+
        
+
+
        Ruby on Railsクイックスタート - 手順9「チェックポイント」 
        Secured concernをアプリに追加してから、認証されたユーザーがアクセスするために必要なコントローラーに含めます。 認証されたユーザーがこのコントローラー内でアクションにアクセスでき、認証されていないユーザーは認証のためにAuth0にリダイレクトされることを確認します。
        
+
+  
        
+
+  
        
+
+  
        
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.
          
+  
          • 
+
        
diff --git a/media/articles/anomaly-detection/anomaly-detection-features.png b/media/articles/anomaly-detection/anomaly-detection-features.png
new file mode 100644
index 0000000000..d44d01a7b8
Binary files /dev/null and b/media/articles/anomaly-detection/anomaly-detection-features.png differ
diff --git a/media/articles/anomaly-detection/anomaly-detection-overview.png b/media/articles/anomaly-detection/anomaly-detection-overview.png
old mode 100755
new mode 100644
index c60af55889..e58a7aad6d
Binary files a/media/articles/anomaly-detection/anomaly-detection-overview.png and b/media/articles/anomaly-detection/anomaly-detection-overview.png differ
diff --git a/media/articles/anomaly-detection/breached-password-shield.png b/media/articles/anomaly-detection/breached-password-shield.png
index 058c16ba10..1c080f81d4 100644
Binary files a/media/articles/anomaly-detection/breached-password-shield.png and b/media/articles/anomaly-detection/breached-password-shield.png differ
diff --git a/media/articles/anomaly-detection/brute-force-shield.png b/media/articles/anomaly-detection/brute-force-shield.png
index 401306bca7..b60f04ff95 100644
Binary files a/media/articles/anomaly-detection/brute-force-shield.png and b/media/articles/anomaly-detection/brute-force-shield.png differ
diff --git a/media/articles/anomaly-detection/captcha-login-screen.png b/media/articles/anomaly-detection/captcha-login-screen.png
new file mode 100644
index 0000000000..5e8a2153cf
Binary files /dev/null and b/media/articles/anomaly-detection/captcha-login-screen.png differ
diff --git a/media/articles/anomaly-detection/credential-stuffing-attack.png b/media/articles/anomaly-detection/credential-stuffing-attack.png
new file mode 100644
index 0000000000..1f1222bec1
Binary files /dev/null and b/media/articles/anomaly-detection/credential-stuffing-attack.png differ
diff --git a/media/articles/anomaly-detection/traffic-failure-trends.png b/media/articles/anomaly-detection/traffic-failure-trends.png
new file mode 100644
index 0000000000..d052594af9
Binary files /dev/null and b/media/articles/anomaly-detection/traffic-failure-trends.png differ
diff --git a/media/articles/api-auth/apis-authorize-client-tab.png b/media/articles/api-auth/apis-authorize-client-tab.png
index becef76036..d8ddef3ccb 100644
Binary files a/media/articles/api-auth/apis-authorize-client-tab.png and b/media/articles/api-auth/apis-authorize-client-tab.png differ
diff --git a/media/articles/api-auth/consent-scopes.png b/media/articles/api-auth/consent-scopes.png
new file mode 100755
index 0000000000..2213e3c36f
Binary files /dev/null and b/media/articles/api-auth/consent-scopes.png differ
diff --git a/media/articles/api-auth/create-api.png b/media/articles/api-auth/create-api.png
index 26c53e749b..bad32c1053 100644
Binary files a/media/articles/api-auth/create-api.png and b/media/articles/api-auth/create-api.png differ
diff --git a/media/articles/api-auth/create-client.png b/media/articles/api-auth/create-client.png
index c48cc8568c..232137eb2c 100644
Binary files a/media/articles/api-auth/create-client.png and b/media/articles/api-auth/create-client.png differ
diff --git a/media/articles/api-auth/create-scope.png b/media/articles/api-auth/create-scope.png
index ee378f1526..dc9a192d2c 100644
Binary files a/media/articles/api-auth/create-scope.png and b/media/articles/api-auth/create-scope.png differ
diff --git a/media/articles/api-auth/default-directory-setting.png b/media/articles/api-auth/default-directory-setting.png
old mode 100755
new mode 100644
index 7bc165fe18..1524d8ae4b
Binary files a/media/articles/api-auth/default-directory-setting.png and b/media/articles/api-auth/default-directory-setting.png differ
diff --git a/media/articles/api-auth/oauth2-grants-flow.png b/media/articles/api-auth/oauth2-grants-flow.png
index de7af12143..b8f0adde50 100755
Binary files a/media/articles/api-auth/oauth2-grants-flow.png and b/media/articles/api-auth/oauth2-grants-flow.png differ
diff --git a/media/articles/api-auth/safari-privacy-preferences.png b/media/articles/api-auth/safari-privacy-preferences.png
new file mode 100644
index 0000000000..176bd4ebac
Binary files /dev/null and b/media/articles/api-auth/safari-privacy-preferences.png differ
diff --git a/media/articles/api/tokens/copy-token.png b/media/articles/api/tokens/copy-token.png
old mode 100755
new mode 100644
index df410e7e43..fab3684023
Binary files a/media/articles/api/tokens/copy-token.png and b/media/articles/api/tokens/copy-token.png differ
diff --git a/media/articles/api/tokens/set-token.png b/media/articles/api/tokens/set-token.png
old mode 100755
new mode 100644
index d633239b9a..01655edae7
Binary files a/media/articles/api/tokens/set-token.png and b/media/articles/api/tokens/set-token.png differ
diff --git a/media/articles/appliance/instrumentation/general-data.png b/media/articles/appliance/instrumentation/general-data.png
deleted file mode 100755
index a28044526b..0000000000
Binary files a/media/articles/appliance/instrumentation/general-data.png and /dev/null differ
diff --git a/media/articles/appliance/instrumentation/grafana-users-1.png b/media/articles/appliance/instrumentation/grafana-users-1.png
deleted file mode 100755
index 0d674f3673..0000000000
Binary files a/media/articles/appliance/instrumentation/grafana-users-1.png and /dev/null differ
diff --git a/media/articles/appliance/instrumentation/grafana-users-2.png b/media/articles/appliance/instrumentation/grafana-users-2.png
deleted file mode 100755
index a2e72e9b76..0000000000
Binary files a/media/articles/appliance/instrumentation/grafana-users-2.png and /dev/null differ
diff --git a/media/articles/appliance/instrumentation/grafana-users-3.png b/media/articles/appliance/instrumentation/grafana-users-3.png
deleted file mode 100755
index cc72200162..0000000000
Binary files a/media/articles/appliance/instrumentation/grafana-users-3.png and /dev/null differ
diff --git a/media/articles/appliance/instrumentation/grafana-users-4.png b/media/articles/appliance/instrumentation/grafana-users-4.png
deleted file mode 100755
index dc9c9707d1..0000000000
Binary files a/media/articles/appliance/instrumentation/grafana-users-4.png and /dev/null differ
diff --git a/media/articles/appliance/instrumentation/tag-dashboard.png b/media/articles/appliance/instrumentation/tag-dashboard.png
deleted file mode 100755
index fd48530c6f..0000000000
Binary files a/media/articles/appliance/instrumentation/tag-dashboard.png and /dev/null differ
diff --git a/media/articles/appliance/migrations/node-version.png b/media/articles/appliance/migrations/node-version.png
new file mode 100644
index 0000000000..5e2f40141c
Binary files /dev/null and b/media/articles/appliance/migrations/node-version.png differ
diff --git a/media/articles/appliance/migrations/sandbox.png b/media/articles/appliance/migrations/sandbox.png
new file mode 100644
index 0000000000..851f3563e2
Binary files /dev/null and b/media/articles/appliance/migrations/sandbox.png differ
diff --git a/media/articles/applications/advanced-settings.png b/media/articles/applications/advanced-settings.png
index c50ec842e5..ba638cd9b3 100644
Binary files a/media/articles/applications/advanced-settings.png and b/media/articles/applications/advanced-settings.png differ
diff --git a/media/articles/applications/app-list.png b/media/articles/applications/app-list.png
new file mode 100644
index 0000000000..ad55fbd48a
Binary files /dev/null and b/media/articles/applications/app-list.png differ
diff --git a/media/articles/applications/app-settings-danger-zone-legacy.png b/media/articles/applications/app-settings-danger-zone-legacy.png
new file mode 100644
index 0000000000..d9e2323d70
Binary files /dev/null and b/media/articles/applications/app-settings-danger-zone-legacy.png differ
diff --git a/media/articles/applications/device-settings.png b/media/articles/applications/device-settings.png
new file mode 100644
index 0000000000..bfbeb34745
Binary files /dev/null and b/media/articles/applications/device-settings.png differ
diff --git a/media/articles/applications/m2m-apis.png b/media/articles/applications/m2m-apis.png
new file mode 100755
index 0000000000..47e575eef7
Binary files /dev/null and b/media/articles/applications/m2m-apis.png differ
diff --git a/media/articles/applications/m2m-create.png b/media/articles/applications/m2m-create.png
new file mode 100755
index 0000000000..cbd20b7feb
Binary files /dev/null and b/media/articles/applications/m2m-create.png differ
diff --git a/media/articles/applications/m2m-quickstart.png b/media/articles/applications/m2m-quickstart.png
new file mode 100755
index 0000000000..243b672bbf
Binary files /dev/null and b/media/articles/applications/m2m-quickstart.png differ
diff --git a/media/articles/applications/m2m-select-api.png b/media/articles/applications/m2m-select-api.png
new file mode 100755
index 0000000000..4d660f657b
Binary files /dev/null and b/media/articles/applications/m2m-select-api.png differ
diff --git a/media/articles/applications/m2m-select-scopes.png b/media/articles/applications/m2m-select-scopes.png
new file mode 100755
index 0000000000..c4360a1f14
Binary files /dev/null and b/media/articles/applications/m2m-select-scopes.png differ
diff --git a/media/articles/applications/mobile-settings.png b/media/articles/applications/mobile-settings.png
deleted file mode 100644
index 3a76ec1c14..0000000000
Binary files a/media/articles/applications/mobile-settings.png and /dev/null differ
diff --git a/media/articles/applications/settings.png b/media/articles/applications/settings.png
index f4a86c19ea..e6a7cf066d 100644
Binary files a/media/articles/applications/settings.png and b/media/articles/applications/settings.png differ
diff --git a/media/articles/applications/token-signature-algorithm.png b/media/articles/applications/token-signature-algorithm.png
new file mode 100644
index 0000000000..0971627d85
Binary files /dev/null and b/media/articles/applications/token-signature-algorithm.png differ
diff --git a/media/articles/architecture-scenarios/b2b.png b/media/articles/architecture-scenarios/b2b.png
index 0af632be6d..53d2c9b8cc 100644
Binary files a/media/articles/architecture-scenarios/b2b.png and b/media/articles/architecture-scenarios/b2b.png differ
diff --git a/media/articles/architecture-scenarios/checklists/Analyze-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Analyze-Checklist.xlsx
new file mode 100644
index 0000000000..e4f18e1347
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Analyze-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/Build-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Build-Checklist.xlsx
new file mode 100644
index 0000000000..02792a2b02
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Build-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/Deploy-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Deploy-Checklist.xlsx
new file mode 100644
index 0000000000..d9c576520d
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Deploy-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/Design-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Design-Checklist.xlsx
new file mode 100644
index 0000000000..be9d551b76
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Design-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/Monitor-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Monitor-Checklist.xlsx
new file mode 100644
index 0000000000..6b71d3d953
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Monitor-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/Test-Checklist.xlsx b/media/articles/architecture-scenarios/checklists/Test-Checklist.xlsx
new file mode 100644
index 0000000000..e90bc5740a
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/Test-Checklist.xlsx differ
diff --git a/media/articles/architecture-scenarios/checklists/file_type_icons-02.png b/media/articles/architecture-scenarios/checklists/file_type_icons-02.png
new file mode 100644
index 0000000000..8783d99434
Binary files /dev/null and b/media/articles/architecture-scenarios/checklists/file_type_icons-02.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/add-permissions.png b/media/articles/architecture-scenarios/mobile-api/add-permissions.png
new file mode 100644
index 0000000000..c77683e215
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/add-permissions.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/add-scopes.png b/media/articles/architecture-scenarios/mobile-api/add-scopes.png
deleted file mode 100755
index ce1f320662..0000000000
Binary files a/media/articles/architecture-scenarios/mobile-api/add-scopes.png and /dev/null differ
diff --git a/media/articles/architecture-scenarios/planning/B2B-Project-Planning.pdf b/media/articles/architecture-scenarios/planning/B2B-Project-Planning.pdf
new file mode 100644
index 0000000000..03940ad7ca
Binary files /dev/null and b/media/articles/architecture-scenarios/planning/B2B-Project-Planning.pdf differ
diff --git a/media/articles/architecture-scenarios/planning/B2C-Project-Planning.pdf b/media/articles/architecture-scenarios/planning/B2C-Project-Planning.pdf
new file mode 100644
index 0000000000..8465131913
Binary files /dev/null and b/media/articles/architecture-scenarios/planning/B2C-Project-Planning.pdf differ
diff --git a/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf b/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf
new file mode 100644
index 0000000000..7239ede0ed
Binary files /dev/null and b/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf differ
diff --git a/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Users-Isolated-by-Organization.pdf b/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Users-Isolated-by-Organization.pdf
new file mode 100644
index 0000000000..82dc6030fc
Binary files /dev/null and b/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Users-Isolated-by-Organization.pdf differ
diff --git a/media/articles/architecture-scenarios/planning/file_type_icons-04.png b/media/articles/architecture-scenarios/planning/file_type_icons-04.png
new file mode 100644
index 0000000000..cd2a23977e
Binary files /dev/null and b/media/articles/architecture-scenarios/planning/file_type_icons-04.png differ
diff --git a/media/articles/authorization/api-def-permissions.png b/media/articles/authorization/api-def-permissions.png
new file mode 100755
index 0000000000..54036a40ec
Binary files /dev/null and b/media/articles/authorization/api-def-permissions.png differ
diff --git a/media/articles/authorization/api-list.png b/media/articles/authorization/api-list.png
new file mode 100755
index 0000000000..71b269da90
Binary files /dev/null and b/media/articles/authorization/api-list.png differ
diff --git a/media/articles/authorization/api-settings-rbac.png b/media/articles/authorization/api-settings-rbac.png
new file mode 100644
index 0000000000..3954dd6d78
Binary files /dev/null and b/media/articles/authorization/api-settings-rbac.png differ
diff --git a/media/articles/authorization/role-def-empty-permissions.png b/media/articles/authorization/role-def-empty-permissions.png
new file mode 100755
index 0000000000..35de6bbacc
Binary files /dev/null and b/media/articles/authorization/role-def-empty-permissions.png differ
diff --git a/media/articles/authorization/role-def-permissions.png b/media/articles/authorization/role-def-permissions.png
new file mode 100755
index 0000000000..1e0365106f
Binary files /dev/null and b/media/articles/authorization/role-def-permissions.png differ
diff --git a/media/articles/authorization/role-def-settings.png b/media/articles/authorization/role-def-settings.png
new file mode 100755
index 0000000000..bee5a98197
Binary files /dev/null and b/media/articles/authorization/role-def-settings.png differ
diff --git a/media/articles/authorization/role-def-users.png b/media/articles/authorization/role-def-users.png
new file mode 100755
index 0000000000..45af415010
Binary files /dev/null and b/media/articles/authorization/role-def-users.png differ
diff --git a/media/articles/authorization/role-list-added.png b/media/articles/authorization/role-list-added.png
new file mode 100755
index 0000000000..2f2e649163
Binary files /dev/null and b/media/articles/authorization/role-list-added.png differ
diff --git a/media/articles/authorization/role-list.png b/media/articles/authorization/role-list.png
new file mode 100755
index 0000000000..343d262a03
Binary files /dev/null and b/media/articles/authorization/role-list.png differ
diff --git a/media/articles/authorization/role-name-role.png b/media/articles/authorization/role-name-role.png
new file mode 100755
index 0000000000..23c06ef7dc
Binary files /dev/null and b/media/articles/authorization/role-name-role.png differ
diff --git a/media/articles/authorization/role-select-add-permissions.png b/media/articles/authorization/role-select-add-permissions.png
new file mode 100755
index 0000000000..bb4b06d55d
Binary files /dev/null and b/media/articles/authorization/role-select-add-permissions.png differ
diff --git a/media/articles/authorization/user-add-permissions.png b/media/articles/authorization/user-add-permissions.png
new file mode 100755
index 0000000000..dfbf6f0729
Binary files /dev/null and b/media/articles/authorization/user-add-permissions.png differ
diff --git a/media/articles/authorization/user-assign-roles.png b/media/articles/authorization/user-assign-roles.png
new file mode 100755
index 0000000000..d039671d8f
Binary files /dev/null and b/media/articles/authorization/user-assign-roles.png differ
diff --git a/media/articles/authorization/user-list-assign-permissions.png b/media/articles/authorization/user-list-assign-permissions.png
new file mode 100755
index 0000000000..9defb37b86
Binary files /dev/null and b/media/articles/authorization/user-list-assign-permissions.png differ
diff --git a/media/articles/authorization/user-list-assign-roles.png b/media/articles/authorization/user-list-assign-roles.png
new file mode 100755
index 0000000000..89352d7b1d
Binary files /dev/null and b/media/articles/authorization/user-list-assign-roles.png differ
diff --git a/media/articles/authorization/user-list.png b/media/articles/authorization/user-list.png
new file mode 100755
index 0000000000..3aa2a2d078
Binary files /dev/null and b/media/articles/authorization/user-list.png differ
diff --git a/media/articles/authorization/user-prof-empty-permissions.png b/media/articles/authorization/user-prof-empty-permissions.png
new file mode 100755
index 0000000000..d6b4d9f8c9
Binary files /dev/null and b/media/articles/authorization/user-prof-empty-permissions.png differ
diff --git a/media/articles/authorization/user-prof-empty-roles.png b/media/articles/authorization/user-prof-empty-roles.png
new file mode 100755
index 0000000000..539599f28f
Binary files /dev/null and b/media/articles/authorization/user-prof-empty-roles.png differ
diff --git a/media/articles/authorization/user-prof-permissions.png b/media/articles/authorization/user-prof-permissions.png
new file mode 100755
index 0000000000..50dd94838c
Binary files /dev/null and b/media/articles/authorization/user-prof-permissions.png differ
diff --git a/media/articles/authorization/user-prof-roles.png b/media/articles/authorization/user-prof-roles.png
new file mode 100755
index 0000000000..f2ae21fd42
Binary files /dev/null and b/media/articles/authorization/user-prof-roles.png differ
diff --git a/media/articles/clients/change-client-secret/client-settings.png b/media/articles/clients/change-client-secret/client-settings.png
deleted file mode 100644
index f4a86c19ea..0000000000
Binary files a/media/articles/clients/change-client-secret/client-settings.png and /dev/null differ
diff --git a/media/articles/clients/change-client-secret/clients.png b/media/articles/clients/change-client-secret/clients.png
deleted file mode 100644
index f2538f8f72..0000000000
Binary files a/media/articles/clients/change-client-secret/clients.png and /dev/null differ
diff --git a/media/articles/clients/change-client-secret/rotate-client-secret.jpg b/media/articles/clients/change-client-secret/rotate-client-secret.jpg
new file mode 100644
index 0000000000..ff63243cfb
Binary files /dev/null and b/media/articles/clients/change-client-secret/rotate-client-secret.jpg differ
diff --git a/media/articles/cms/wordpress/app-advanced-settings.png b/media/articles/cms/wordpress/app-advanced-settings.png
new file mode 100644
index 0000000000..3ea1dd15db
Binary files /dev/null and b/media/articles/cms/wordpress/app-advanced-settings.png differ
diff --git a/media/articles/cms/wordpress/application-listing.png b/media/articles/cms/wordpress/application-listing.png
new file mode 100644
index 0000000000..e6751c7960
Binary files /dev/null and b/media/articles/cms/wordpress/application-listing.png differ
diff --git a/media/articles/cms/wordpress/auth0-app-settings.png b/media/articles/cms/wordpress/auth0-app-settings.png
new file mode 100644
index 0000000000..bbed34e149
Binary files /dev/null and b/media/articles/cms/wordpress/auth0-app-settings.png differ
diff --git a/media/articles/cms/wordpress/auth0-custom-database-config.png b/media/articles/cms/wordpress/auth0-custom-database-config.png
new file mode 100644
index 0000000000..29ee565184
Binary files /dev/null and b/media/articles/cms/wordpress/auth0-custom-database-config.png differ
diff --git a/media/articles/cms/wordpress/auth0-incoming-ip-addresses.png b/media/articles/cms/wordpress/auth0-incoming-ip-addresses.png
new file mode 100644
index 0000000000..e88707cc3c
Binary files /dev/null and b/media/articles/cms/wordpress/auth0-incoming-ip-addresses.png differ
diff --git a/media/articles/cms/wordpress/client-advanced-settings.png b/media/articles/cms/wordpress/client-advanced-settings.png
index d12705afd0..7d5550d530 100644
Binary files a/media/articles/cms/wordpress/client-advanced-settings.png and b/media/articles/cms/wordpress/client-advanced-settings.png differ
diff --git a/media/articles/cms/wordpress/client-grant-types.png b/media/articles/cms/wordpress/client-grant-types.png
index d1930408f9..9a38e6602b 100644
Binary files a/media/articles/cms/wordpress/client-grant-types.png and b/media/articles/cms/wordpress/client-grant-types.png differ
diff --git a/media/articles/cms/wordpress/database-connection-listing.png b/media/articles/cms/wordpress/database-connection-listing.png
deleted file mode 100644
index a7cdab3198..0000000000
Binary files a/media/articles/cms/wordpress/database-connection-listing.png and /dev/null differ
diff --git a/media/articles/cms/wordpress/db-connection-apps.png b/media/articles/cms/wordpress/db-connection-apps.png
new file mode 100644
index 0000000000..bc1602701f
Binary files /dev/null and b/media/articles/cms/wordpress/db-connection-apps.png differ
diff --git a/media/articles/cms/wordpress/db-connection-listing.png b/media/articles/cms/wordpress/db-connection-listing.png
new file mode 100644
index 0000000000..84c9d8715a
Binary files /dev/null and b/media/articles/cms/wordpress/db-connection-listing.png differ
diff --git a/media/articles/cms/wordpress/fingerprint_logo.png b/media/articles/cms/wordpress/fingerprint_logo.png
new file mode 100644
index 0000000000..6503b52f26
Binary files /dev/null and b/media/articles/cms/wordpress/fingerprint_logo.png differ
diff --git a/media/articles/cms/wordpress/grant-app-access-to-api.png b/media/articles/cms/wordpress/grant-app-access-to-api.png
new file mode 100644
index 0000000000..82b91c6453
Binary files /dev/null and b/media/articles/cms/wordpress/grant-app-access-to-api.png differ
diff --git a/media/articles/cms/wordpress/migration-ip-whitelist-setting-field.png b/media/articles/cms/wordpress/migration-ip-whitelist-setting-field.png
new file mode 100644
index 0000000000..07ea77fbe6
Binary files /dev/null and b/media/articles/cms/wordpress/migration-ip-whitelist-setting-field.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-migrate-admin.png b/media/articles/cms/wordpress/setup-wizard-migrate-admin.png
index fce6c505ba..ee9b8c53b7 100644
Binary files a/media/articles/cms/wordpress/setup-wizard-migrate-admin.png and b/media/articles/cms/wordpress/setup-wizard-migrate-admin.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-select-setup.png b/media/articles/cms/wordpress/setup-wizard-select-setup.png
new file mode 100644
index 0000000000..da8e00f684
Binary files /dev/null and b/media/articles/cms/wordpress/setup-wizard-select-setup.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-social-modal.png b/media/articles/cms/wordpress/setup-wizard-social-modal.png
index f0f28c785d..3e0b96eeaa 100644
Binary files a/media/articles/cms/wordpress/setup-wizard-social-modal.png and b/media/articles/cms/wordpress/setup-wizard-social-modal.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-standard.png b/media/articles/cms/wordpress/setup-wizard-standard.png
new file mode 100644
index 0000000000..ea30867bc4
Binary files /dev/null and b/media/articles/cms/wordpress/setup-wizard-standard.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-step-1.png b/media/articles/cms/wordpress/setup-wizard-step-1.png
index d36e7245f7..06e3b7c695 100644
Binary files a/media/articles/cms/wordpress/setup-wizard-step-1.png and b/media/articles/cms/wordpress/setup-wizard-step-1.png differ
diff --git a/media/articles/connections/azuread-adfs-email-verification.png b/media/articles/connections/azuread-adfs-email-verification.png
new file mode 100644
index 0000000000..f4c84ab1f7
Binary files /dev/null and b/media/articles/connections/azuread-adfs-email-verification.png differ
diff --git a/media/articles/connections/criipto/adfs-connections-dk.png b/media/articles/connections/criipto/adfs-connections-dk.png
index 9c284fd7a5..b2a41479ec 100644
Binary files a/media/articles/connections/criipto/adfs-connections-dk.png and b/media/articles/connections/criipto/adfs-connections-dk.png differ
diff --git a/media/articles/connections/criipto/adfs-connections-no.png b/media/articles/connections/criipto/adfs-connections-no.png
index 44e46b1216..f97d85d09d 100644
Binary files a/media/articles/connections/criipto/adfs-connections-no.png and b/media/articles/connections/criipto/adfs-connections-no.png differ
diff --git a/media/articles/connections/criipto/adfs-connections-se.png b/media/articles/connections/criipto/adfs-connections-se.png
index 3197baf476..769918ca32 100644
Binary files a/media/articles/connections/criipto/adfs-connections-se.png and b/media/articles/connections/criipto/adfs-connections-se.png differ
diff --git a/media/articles/connections/criipto/auth0-app-dk.png b/media/articles/connections/criipto/auth0-app-dk.png
index b8bcd06315..cefdb32126 100644
Binary files a/media/articles/connections/criipto/auth0-app-dk.png and b/media/articles/connections/criipto/auth0-app-dk.png differ
diff --git a/media/articles/connections/criipto/auth0-app-no.png b/media/articles/connections/criipto/auth0-app-no.png
index cd3d268e15..f1a5f9620b 100644
Binary files a/media/articles/connections/criipto/auth0-app-no.png and b/media/articles/connections/criipto/auth0-app-no.png differ
diff --git a/media/articles/connections/criipto/auth0-app-se.png b/media/articles/connections/criipto/auth0-app-se.png
index f19d101587..e6095dc043 100644
Binary files a/media/articles/connections/criipto/auth0-app-se.png and b/media/articles/connections/criipto/auth0-app-se.png differ
diff --git a/media/articles/connections/criipto/auth0-consent.png b/media/articles/connections/criipto/auth0-consent.png
index 245c21c163..f8c7f9016a 100644
Binary files a/media/articles/connections/criipto/auth0-consent.png and b/media/articles/connections/criipto/auth0-consent.png differ
diff --git a/media/articles/connections/criipto/auth0-details.png b/media/articles/connections/criipto/auth0-details.png
index b99bd51391..d4d5c994af 100644
Binary files a/media/articles/connections/criipto/auth0-details.png and b/media/articles/connections/criipto/auth0-details.png differ
diff --git a/media/articles/connections/criipto/dk-nemid-prod.png b/media/articles/connections/criipto/dk-nemid-prod.png
index ef6f8771c3..9572d703aa 100644
Binary files a/media/articles/connections/criipto/dk-nemid-prod.png and b/media/articles/connections/criipto/dk-nemid-prod.png differ
diff --git a/media/articles/connections/criipto/easyid-signup.png b/media/articles/connections/criipto/easyid-signup.png
index fed6647364..cd833bcf22 100644
Binary files a/media/articles/connections/criipto/easyid-signup.png and b/media/articles/connections/criipto/easyid-signup.png differ
diff --git a/media/articles/connections/criipto/no-bankid-prod.png b/media/articles/connections/criipto/no-bankid-prod.png
index 474fe787e1..c6a811fa7d 100644
Binary files a/media/articles/connections/criipto/no-bankid-prod.png and b/media/articles/connections/criipto/no-bankid-prod.png differ
diff --git a/media/articles/connections/criipto/se-bankid-prod.png b/media/articles/connections/criipto/se-bankid-prod.png
index f103a26e08..3292f7c3a1 100644
Binary files a/media/articles/connections/criipto/se-bankid-prod.png and b/media/articles/connections/criipto/se-bankid-prod.png differ
diff --git a/media/articles/connections/dashboard-apis-edit_view-m2m_mgmt-api-permissions.png b/media/articles/connections/dashboard-apis-edit_view-m2m_mgmt-api-permissions.png
new file mode 100644
index 0000000000..b835da4be2
Binary files /dev/null and b/media/articles/connections/dashboard-apis-edit_view-m2m_mgmt-api-permissions.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_ad-ldap_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_ad-ldap_default-empty.png
new file mode 100644
index 0000000000..22fca222dc
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_ad-ldap_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_adfs_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_adfs_default-empty.png
new file mode 100644
index 0000000000..e5d1cab049
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_adfs_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_azure-ad_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_azure-ad_default-empty.png
new file mode 100644
index 0000000000..7f43f33133
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_azure-ad_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_google-workspace_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_google-workspace_default-empty.png
new file mode 100644
index 0000000000..5216dc5070
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_google-workspace_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_oidc_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_oidc_default-empty.png
new file mode 100644
index 0000000000..5c8235c4bc
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_oidc_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_ping-federate_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_ping-federate_default-empty.png
new file mode 100644
index 0000000000..d118f7530d
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_ping-federate_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-create_saml_default-empty.png b/media/articles/connections/dashboard-connections-enterprise-create_saml_default-empty.png
new file mode 100644
index 0000000000..0a0f4a7f57
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-create_saml_default-empty.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-edit_adfs_view-applications.png b/media/articles/connections/dashboard-connections-enterprise-edit_adfs_view-applications.png
new file mode 100644
index 0000000000..e584e89989
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-edit_adfs_view-applications.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise-list.png b/media/articles/connections/dashboard-connections-enterprise-list.png
new file mode 100644
index 0000000000..b9353af686
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise-list.png differ
diff --git a/media/articles/connections/dashboard-connections-enterprise_adfs_try.png b/media/articles/connections/dashboard-connections-enterprise_adfs_try.png
new file mode 100644
index 0000000000..e218d8b0f5
Binary files /dev/null and b/media/articles/connections/dashboard-connections-enterprise_adfs_try.png differ
diff --git a/media/articles/connections/dashboard-connections-social-edit_sync-user-profile-attributes.png b/media/articles/connections/dashboard-connections-social-edit_sync-user-profile-attributes.png
new file mode 100644
index 0000000000..2a7757a870
Binary files /dev/null and b/media/articles/connections/dashboard-connections-social-edit_sync-user-profile-attributes.png differ
diff --git a/media/articles/connections/dashboard-create-tenant.png b/media/articles/connections/dashboard-create-tenant.png
new file mode 100644
index 0000000000..55b47898d9
Binary files /dev/null and b/media/articles/connections/dashboard-create-tenant.png differ
diff --git a/media/articles/connections/database/custom-database-connections.png b/media/articles/connections/database/custom-database-connections.png
new file mode 100644
index 0000000000..dfa31aeeb1
Binary files /dev/null and b/media/articles/connections/database/custom-database-connections.png differ
diff --git a/media/articles/connections/database/custom-database.png b/media/articles/connections/database/custom-database.png
deleted file mode 100644
index 4f419218b8..0000000000
Binary files a/media/articles/connections/database/custom-database.png and /dev/null differ
diff --git a/media/articles/connections/database/dashboard-connections-database-create_user-password-auth.png b/media/articles/connections/database/dashboard-connections-database-create_user-password-auth.png
new file mode 100644
index 0000000000..323c04abe9
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-create_user-password-auth.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-applications.png b/media/articles/connections/database/dashboard-connections-database-edit_view-applications.png
new file mode 100644
index 0000000000..14a017ff20
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-applications.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database.png b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database.png
new file mode 100644
index 0000000000..222ee665d6
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_settings.png b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_settings.png
new file mode 100644
index 0000000000..7544d25746
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_settings.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_use-my-own-database.png b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_use-my-own-database.png
new file mode 100644
index 0000000000..f184b206fc
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_use-my-own-database.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-password-policy_password-options.png b/media/articles/connections/database/dashboard-connections-database-edit_view-password-policy_password-options.png
new file mode 100644
index 0000000000..97c5582e5f
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-password-policy_password-options.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-edit_view-try-connection-requires-username.png b/media/articles/connections/database/dashboard-connections-database-edit_view-try-connection-requires-username.png
new file mode 100644
index 0000000000..c743819653
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-edit_view-try-connection-requires-username.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-list-hbms.png b/media/articles/connections/database/dashboard-connections-database-list-hbms.png
new file mode 100644
index 0000000000..512921d266
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-list-hbms.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-list.png b/media/articles/connections/database/dashboard-connections-database-list.png
new file mode 100644
index 0000000000..9851c12027
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-list.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-settings.png b/media/articles/connections/database/dashboard-connections-database-settings.png
new file mode 100644
index 0000000000..468ccf2e31
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-settings.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-settings_requires-username.png b/media/articles/connections/database/dashboard-connections-database-settings_requires-username.png
new file mode 100644
index 0000000000..3afed03215
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-settings_requires-username.png differ
diff --git a/media/articles/connections/database/dashboard-connections-database-try.png b/media/articles/connections/database/dashboard-connections-database-try.png
new file mode 100644
index 0000000000..0aa6d57766
Binary files /dev/null and b/media/articles/connections/database/dashboard-connections-database-try.png differ
diff --git a/media/articles/connections/database/dashboard-users-edit_view-details_danger-zone.png b/media/articles/connections/database/dashboard-users-edit_view-details_danger-zone.png
new file mode 100644
index 0000000000..c79c60dc1a
Binary files /dev/null and b/media/articles/connections/database/dashboard-users-edit_view-details_danger-zone.png differ
diff --git a/media/articles/connections/database/database-connections.png b/media/articles/connections/database/database-connections.png
deleted file mode 100644
index c55832c306..0000000000
Binary files a/media/articles/connections/database/database-connections.png and /dev/null differ
diff --git a/media/articles/connections/database/db-connections-page.png b/media/articles/connections/database/db-connections-page.png
deleted file mode 100644
index d1370e506f..0000000000
Binary files a/media/articles/connections/database/db-connections-page.png and /dev/null differ
diff --git a/media/articles/connections/database/import-scripts.png b/media/articles/connections/database/import-scripts.png
deleted file mode 100644
index 1919d83830..0000000000
Binary files a/media/articles/connections/database/import-scripts.png and /dev/null differ
diff --git a/media/articles/connections/database/import-users.png b/media/articles/connections/database/import-users.png
deleted file mode 100644
index 5d1a0904c4..0000000000
Binary files a/media/articles/connections/database/import-users.png and /dev/null differ
diff --git a/media/articles/connections/database/lock-usernamestyle.png b/media/articles/connections/database/lock-usernamestyle.png
deleted file mode 100644
index ecc5c0cc11..0000000000
Binary files a/media/articles/connections/database/lock-usernamestyle.png and /dev/null differ
diff --git a/media/articles/connections/database/migrated-users.png b/media/articles/connections/database/migrated-users.png
deleted file mode 100644
index 19ca1c0b47..0000000000
Binary files a/media/articles/connections/database/migrated-users.png and /dev/null differ
diff --git a/media/articles/connections/database/mysql/db-connection-configurate.png b/media/articles/connections/database/mysql/db-connection-configurate.png
deleted file mode 100644
index 501b2f6f69..0000000000
Binary files a/media/articles/connections/database/mysql/db-connection-configurate.png and /dev/null differ
diff --git a/media/articles/connections/database/mysql/db-connection-login-script.png b/media/articles/connections/database/mysql/db-connection-login-script.png
deleted file mode 100644
index 0f8ac2780b..0000000000
Binary files a/media/articles/connections/database/mysql/db-connection-login-script.png and /dev/null differ
diff --git a/media/articles/connections/database/mysql/db-connection-parameters.png b/media/articles/connections/database/mysql/db-connection-parameters.png
new file mode 100644
index 0000000000..9a2c6e583f
Binary files /dev/null and b/media/articles/connections/database/mysql/db-connection-parameters.png differ
diff --git a/media/articles/connections/database/mysql/db-connection-try-ok.png b/media/articles/connections/database/mysql/db-connection-try-ok.png
deleted file mode 100644
index f8a12e4005..0000000000
Binary files a/media/articles/connections/database/mysql/db-connection-try-ok.png and /dev/null differ
diff --git a/media/articles/connections/database/password-reset-email.png b/media/articles/connections/database/password-reset-email.png
new file mode 100644
index 0000000000..3d6beb313a
Binary files /dev/null and b/media/articles/connections/database/password-reset-email.png differ
diff --git a/media/articles/connections/database/password-strength/7cmjQFY45M.png b/media/articles/connections/database/password-strength/7cmjQFY45M.png
index e18d2c552b..d1bcb1bd5f 100644
Binary files a/media/articles/connections/database/password-strength/7cmjQFY45M.png and b/media/articles/connections/database/password-strength/7cmjQFY45M.png differ
diff --git a/media/articles/connections/database/password-strength/dashboard-connections-database-edit_view-password-policy_password-strength.png b/media/articles/connections/database/password-strength/dashboard-connections-database-edit_view-password-policy_password-strength.png
new file mode 100644
index 0000000000..088d407734
Binary files /dev/null and b/media/articles/connections/database/password-strength/dashboard-connections-database-edit_view-password-policy_password-strength.png differ
diff --git a/media/articles/connections/database/password-strength/moUbn4XXxR.png b/media/articles/connections/database/password-strength/moUbn4XXxR.png
index e801612bd9..aec4ec20b6 100644
Binary files a/media/articles/connections/database/password-strength/moUbn4XXxR.png and b/media/articles/connections/database/password-strength/moUbn4XXxR.png differ
diff --git a/media/articles/connections/database/password-strength/pw-manage.png b/media/articles/connections/database/password-strength/pw-manage.png
deleted file mode 100644
index 76e71a1895..0000000000
Binary files a/media/articles/connections/database/password-strength/pw-manage.png and /dev/null differ
diff --git a/media/articles/connections/database/pw-options.png b/media/articles/connections/database/pw-options.png
deleted file mode 100644
index 288ac626d3..0000000000
Binary files a/media/articles/connections/database/pw-options.png and /dev/null differ
diff --git a/media/articles/connections/edit-granted-scopes.png b/media/articles/connections/edit-granted-scopes.png
deleted file mode 100644
index 38ee6a9d9c..0000000000
Binary files a/media/articles/connections/edit-granted-scopes.png and /dev/null differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-0.png b/media/articles/connections/enterprise/azure-active-directory/waad-0.png
index e0220876eb..434da9d20a 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-0.png and b/media/articles/connections/enterprise/azure-active-directory/waad-0.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-1.png b/media/articles/connections/enterprise/azure-active-directory/waad-1.png
index bfa0ed1b61..d2f2ed0c40 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-1.png and b/media/articles/connections/enterprise/azure-active-directory/waad-1.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-10.png b/media/articles/connections/enterprise/azure-active-directory/waad-10.png
index 7654ab97f0..e618a00521 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-10.png and b/media/articles/connections/enterprise/azure-active-directory/waad-10.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-2.png b/media/articles/connections/enterprise/azure-active-directory/waad-2.png
index 5e1f04e35d..f536ae6a5a 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-2.png and b/media/articles/connections/enterprise/azure-active-directory/waad-2.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-3.png b/media/articles/connections/enterprise/azure-active-directory/waad-3.png
index fe0afa1ccf..50e88d3a37 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-3.png and b/media/articles/connections/enterprise/azure-active-directory/waad-3.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-3b.png b/media/articles/connections/enterprise/azure-active-directory/waad-3b.png
index 64a9db359c..2a8bb637af 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-3b.png and b/media/articles/connections/enterprise/azure-active-directory/waad-3b.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-4.png b/media/articles/connections/enterprise/azure-active-directory/waad-4.png
index b05b278081..589cd44e85 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-4.png and b/media/articles/connections/enterprise/azure-active-directory/waad-4.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-5.png b/media/articles/connections/enterprise/azure-active-directory/waad-5.png
index 31cf3c55db..ae823a1533 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-5.png and b/media/articles/connections/enterprise/azure-active-directory/waad-5.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-8.png b/media/articles/connections/enterprise/azure-active-directory/waad-8.png
index c8dcd94e91..bf93790bfc 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-8.png and b/media/articles/connections/enterprise/azure-active-directory/waad-8.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-8b.png b/media/articles/connections/enterprise/azure-active-directory/waad-8b.png
index a2251ce33c..4f6dd1ebca 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-8b.png and b/media/articles/connections/enterprise/azure-active-directory/waad-8b.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/waad-9.png b/media/articles/connections/enterprise/azure-active-directory/waad-9.png
index d78ea0dffb..ae02b143e6 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/waad-9.png and b/media/articles/connections/enterprise/azure-active-directory/waad-9.png differ
diff --git a/media/articles/connections/enterprise/oidc/oidc-details.png b/media/articles/connections/enterprise/oidc/oidc-details.png
new file mode 100755
index 0000000000..563266116e
Binary files /dev/null and b/media/articles/connections/enterprise/oidc/oidc-details.png differ
diff --git a/media/articles/connections/enterprise/oidc/oidc-small.png b/media/articles/connections/enterprise/oidc/oidc-small.png
new file mode 100755
index 0000000000..7c196cf4f7
Binary files /dev/null and b/media/articles/connections/enterprise/oidc/oidc-small.png differ
diff --git a/media/articles/connections/nativesocial/dashboard-applications-edit_view-settings-advanced_device-settings_facebook-enabled.png b/media/articles/connections/nativesocial/dashboard-applications-edit_view-settings-advanced_device-settings_facebook-enabled.png
new file mode 100644
index 0000000000..e619c66060
Binary files /dev/null and b/media/articles/connections/nativesocial/dashboard-applications-edit_view-settings-advanced_device-settings_facebook-enabled.png differ
diff --git a/media/articles/connections/nativesocial/native-social-login.png b/media/articles/connections/nativesocial/native-social-login.png
new file mode 100644
index 0000000000..5a748bb67a
Binary files /dev/null and b/media/articles/connections/nativesocial/native-social-login.png differ
diff --git a/media/articles/connections/passwordless/connections-passwordless-email.png b/media/articles/connections/passwordless/connections-passwordless-email.png
new file mode 100644
index 0000000000..ef2cd9ec87
Binary files /dev/null and b/media/articles/connections/passwordless/connections-passwordless-email.png differ
diff --git a/media/articles/connections/passwordless/connections-passwordless-list.png b/media/articles/connections/passwordless/connections-passwordless-list.png
new file mode 100644
index 0000000000..952a0aa6c3
Binary files /dev/null and b/media/articles/connections/passwordless/connections-passwordless-list.png differ
diff --git a/media/articles/connections/passwordless/connections-passwordless-sms.png b/media/articles/connections/passwordless/connections-passwordless-sms.png
new file mode 100644
index 0000000000..6f457f1e90
Binary files /dev/null and b/media/articles/connections/passwordless/connections-passwordless-sms.png differ
diff --git a/media/articles/connections/passwordless/passwordless-connections.png b/media/articles/connections/passwordless/passwordless-connections.png
deleted file mode 100644
index bc3ed5b8f5..0000000000
Binary files a/media/articles/connections/passwordless/passwordless-connections.png and /dev/null differ
diff --git a/media/articles/connections/passwordless/passwordless-email-config.png b/media/articles/connections/passwordless/passwordless-email-config.png
deleted file mode 100644
index 05576f409f..0000000000
Binary files a/media/articles/connections/passwordless/passwordless-email-config.png and /dev/null differ
diff --git a/media/articles/connections/passwordless/passwordless-email-enter-code-android.png b/media/articles/connections/passwordless/passwordless-email-enter-code-android.png
index c7e11544a9..00e1e47b69 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-enter-code-android.png and b/media/articles/connections/passwordless/passwordless-email-enter-code-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png b/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png
index e91602ff8c..db486c99c6 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png and b/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-enter-code-web.png b/media/articles/connections/passwordless/passwordless-email-enter-code-web.png
index d70052b29d..ffadfdc06a 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-enter-code-web.png and b/media/articles/connections/passwordless/passwordless-email-enter-code-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-receive-code-android.png b/media/articles/connections/passwordless/passwordless-email-receive-code-android.png
index 15f1fbe162..13550c37c1 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-receive-code-android.png and b/media/articles/connections/passwordless/passwordless-email-receive-code-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-receive-code-ios.png b/media/articles/connections/passwordless/passwordless-email-receive-code-ios.png
index 138ac8ee93..2d0bc3c148 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-receive-code-ios.png and b/media/articles/connections/passwordless/passwordless-email-receive-code-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-receive-code-web.png b/media/articles/connections/passwordless/passwordless-email-receive-code-web.png
index 138ac8ee93..b091169e84 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-receive-code-web.png and b/media/articles/connections/passwordless/passwordless-email-receive-code-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-receive-link.png b/media/articles/connections/passwordless/passwordless-email-receive-link.png
index 86c03c89bc..4fbc6a6f1c 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-receive-link.png and b/media/articles/connections/passwordless/passwordless-email-receive-link.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-request-android.png b/media/articles/connections/passwordless/passwordless-email-request-android.png
index 06bc0c6fa4..2919d70170 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-request-android.png and b/media/articles/connections/passwordless/passwordless-email-request-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-request-ios.png b/media/articles/connections/passwordless/passwordless-email-request-ios.png
index 6750b64ad6..a93d34e808 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-request-ios.png and b/media/articles/connections/passwordless/passwordless-email-request-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email-request-web.png b/media/articles/connections/passwordless/passwordless-email-request-web.png
index b974a3b1e2..0eee1a45d5 100644
Binary files a/media/articles/connections/passwordless/passwordless-email-request-web.png and b/media/articles/connections/passwordless/passwordless-email-request-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-email.png b/media/articles/connections/passwordless/passwordless-email.png
new file mode 100644
index 0000000000..23bee08a57
Binary files /dev/null and b/media/articles/connections/passwordless/passwordless-email.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-config.png b/media/articles/connections/passwordless/passwordless-sms-config.png
deleted file mode 100644
index 2abc5caf29..0000000000
Binary files a/media/articles/connections/passwordless/passwordless-sms-config.png and /dev/null differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-enter-code-android.png b/media/articles/connections/passwordless/passwordless-sms-enter-code-android.png
index 3a13beef82..4802d34eac 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-enter-code-android.png and b/media/articles/connections/passwordless/passwordless-sms-enter-code-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png b/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png
index 380bfbaee6..73ecb23f10 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png and b/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png b/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png
index 291c1208c1..354ae103fd 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png and b/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png b/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png
index 3bee4c39db..b3b1c55d45 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png and b/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-receive-code-android.png b/media/articles/connections/passwordless/passwordless-sms-receive-code-android.png
index 3fc9883338..6cdfee7580 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-receive-code-android.png and b/media/articles/connections/passwordless/passwordless-sms-receive-code-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-receive-code-ios.png b/media/articles/connections/passwordless/passwordless-sms-receive-code-ios.png
index 9ac8d401d9..f11c2dc04b 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-receive-code-ios.png and b/media/articles/connections/passwordless/passwordless-sms-receive-code-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-receive-code-web.png b/media/articles/connections/passwordless/passwordless-sms-receive-code-web.png
index ada6f315a6..e393a8578a 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-receive-code-web.png and b/media/articles/connections/passwordless/passwordless-sms-receive-code-web.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-request-android.png b/media/articles/connections/passwordless/passwordless-sms-request-android.png
index d2b3215d8b..403dcfa4b9 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-request-android.png and b/media/articles/connections/passwordless/passwordless-sms-request-android.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms-request-ios.png b/media/articles/connections/passwordless/passwordless-sms-request-ios.png
index 4c078adec9..3a75b9ea4a 100644
Binary files a/media/articles/connections/passwordless/passwordless-sms-request-ios.png and b/media/articles/connections/passwordless/passwordless-sms-request-ios.png differ
diff --git a/media/articles/connections/passwordless/passwordless-sms.png b/media/articles/connections/passwordless/passwordless-sms.png
new file mode 100644
index 0000000000..d3365f1e7f
Binary files /dev/null and b/media/articles/connections/passwordless/passwordless-sms.png differ
diff --git a/media/articles/connections/passwordless/passwordless-touchid-start.png b/media/articles/connections/passwordless/passwordless-touchid-start.png
index 350d03d9dc..98457290bb 100644
Binary files a/media/articles/connections/passwordless/passwordless-touchid-start.png and b/media/articles/connections/passwordless/passwordless-touchid-start.png differ
diff --git a/media/articles/connections/social/apple/apple-2FA.png b/media/articles/connections/social/apple/apple-2FA.png
new file mode 100644
index 0000000000..5f35db731c
Binary files /dev/null and b/media/articles/connections/social/apple/apple-2FA.png differ
diff --git a/media/articles/connections/social/apple/apple-app-mobile-settings.png b/media/articles/connections/social/apple/apple-app-mobile-settings.png
new file mode 100644
index 0000000000..a7277e290b
Binary files /dev/null and b/media/articles/connections/social/apple/apple-app-mobile-settings.png differ
diff --git a/media/articles/connections/social/apple/apple-configureurls.jpg b/media/articles/connections/social/apple/apple-configureurls.jpg
new file mode 100644
index 0000000000..b0ae789c3a
Binary files /dev/null and b/media/articles/connections/social/apple/apple-configureurls.jpg differ
diff --git a/media/articles/connections/social/apple/apple-configurls2.png b/media/articles/connections/social/apple/apple-configurls2.png
new file mode 100644
index 0000000000..2137e8c3c0
Binary files /dev/null and b/media/articles/connections/social/apple/apple-configurls2.png differ
diff --git a/media/articles/connections/social/apple/apple-connection.png b/media/articles/connections/social/apple/apple-connection.png
new file mode 100644
index 0000000000..e87a4c9743
Binary files /dev/null and b/media/articles/connections/social/apple/apple-connection.png differ
diff --git a/media/articles/connections/social/apple/apple-developerprogram.jpg b/media/articles/connections/social/apple/apple-developerprogram.jpg
new file mode 100755
index 0000000000..c174d94619
Binary files /dev/null and b/media/articles/connections/social/apple/apple-developerprogram.jpg differ
diff --git a/media/articles/connections/social/apple/apple-email-preferences.png b/media/articles/connections/social/apple/apple-email-preferences.png
new file mode 100644
index 0000000000..dc4c1d768c
Binary files /dev/null and b/media/articles/connections/social/apple/apple-email-preferences.png differ
diff --git a/media/articles/connections/social/apple/apple-login-page.png b/media/articles/connections/social/apple/apple-login-page.png
new file mode 100644
index 0000000000..3526ebeacd
Binary files /dev/null and b/media/articles/connections/social/apple/apple-login-page.png differ
diff --git a/media/articles/connections/social/apple/apple-membership.png b/media/articles/connections/social/apple/apple-membership.png
new file mode 100644
index 0000000000..0a6e75ace6
Binary files /dev/null and b/media/articles/connections/social/apple/apple-membership.png differ
diff --git a/media/articles/connections/social/apple/apple-registerservicesid.png b/media/articles/connections/social/apple/apple-registerservicesid.png
new file mode 100644
index 0000000000..48a19fbd9c
Binary files /dev/null and b/media/articles/connections/social/apple/apple-registerservicesid.png differ
diff --git a/media/articles/connections/social/apple/apple-siwa-authn-flow.png b/media/articles/connections/social/apple/apple-siwa-authn-flow.png
new file mode 100644
index 0000000000..bc2d1aa956
Binary files /dev/null and b/media/articles/connections/social/apple/apple-siwa-authn-flow.png differ
diff --git a/media/articles/connections/social/apple/apple-siwa-setup-flow.png b/media/articles/connections/social/apple/apple-siwa-setup-flow.png
new file mode 100644
index 0000000000..8fd567dd0f
Binary files /dev/null and b/media/articles/connections/social/apple/apple-siwa-setup-flow.png differ
diff --git a/media/articles/connections/social/apple/dashboard-applications-edit_view-settings-advanced_device-settings_native_apple-enabled.png b/media/articles/connections/social/apple/dashboard-applications-edit_view-settings-advanced_device-settings_native_apple-enabled.png
new file mode 100644
index 0000000000..73bc3f5857
Binary files /dev/null and b/media/articles/connections/social/apple/dashboard-applications-edit_view-settings-advanced_device-settings_native_apple-enabled.png differ
diff --git a/media/articles/connections/social/apple/dashboard-connections-social-create_enter-details_apple.png b/media/articles/connections/social/apple/dashboard-connections-social-create_enter-details_apple.png
new file mode 100644
index 0000000000..04958d8f8b
Binary files /dev/null and b/media/articles/connections/social/apple/dashboard-connections-social-create_enter-details_apple.png differ
diff --git a/media/articles/connections/social/apple/native-apple-siwa-flow.png b/media/articles/connections/social/apple/native-apple-siwa-flow.png
new file mode 100644
index 0000000000..fdcfbe8ff5
Binary files /dev/null and b/media/articles/connections/social/apple/native-apple-siwa-flow.png differ
diff --git a/media/articles/connections/social/auth0-oidc/child-app.png b/media/articles/connections/social/auth0-oidc/child-app.png
deleted file mode 100644
index 6ec2fe4a3e..0000000000
Binary files a/media/articles/connections/social/auth0-oidc/child-app.png and /dev/null differ
diff --git a/media/articles/connections/social/auth0-oidc/login-page.png b/media/articles/connections/social/auth0-oidc/login-page.png
deleted file mode 100644
index b29dfad675..0000000000
Binary files a/media/articles/connections/social/auth0-oidc/login-page.png and /dev/null differ
diff --git a/media/articles/connections/social/connection-social-applications.png b/media/articles/connections/social/connection-social-applications.png
new file mode 100644
index 0000000000..2e9764d1ae
Binary files /dev/null and b/media/articles/connections/social/connection-social-applications.png differ
diff --git a/media/articles/connections/social/connection-social-list-configured.png b/media/articles/connections/social/connection-social-list-configured.png
new file mode 100644
index 0000000000..a66164fd2d
Binary files /dev/null and b/media/articles/connections/social/connection-social-list-configured.png differ
diff --git a/media/articles/connections/social/connection-social-list-unconfigured.png b/media/articles/connections/social/connection-social-list-unconfigured.png
new file mode 100644
index 0000000000..4ecb2c2711
Binary files /dev/null and b/media/articles/connections/social/connection-social-list-unconfigured.png differ
diff --git a/media/articles/connections/social/connection-social-settings.png b/media/articles/connections/social/connection-social-settings.png
new file mode 100644
index 0000000000..4e5cbcfc1d
Binary files /dev/null and b/media/articles/connections/social/connection-social-settings.png differ
diff --git a/media/articles/connections/social/connection-social-try-choose-account.png b/media/articles/connections/social/connection-social-try-choose-account.png
new file mode 100644
index 0000000000..90db9fc78c
Binary files /dev/null and b/media/articles/connections/social/connection-social-try-choose-account.png differ
diff --git a/media/articles/connections/social/connection-social-try-success.png b/media/articles/connections/social/connection-social-try-success.png
new file mode 100644
index 0000000000..b5dbdaec77
Binary files /dev/null and b/media/articles/connections/social/connection-social-try-success.png differ
diff --git a/media/articles/connections/social/dashboard-connections-social-create_google.png b/media/articles/connections/social/dashboard-connections-social-create_google.png
new file mode 100644
index 0000000000..8c6c2e89f8
Binary files /dev/null and b/media/articles/connections/social/dashboard-connections-social-create_google.png differ
diff --git a/media/articles/connections/social/dashboard-connections-social-edit_view-applications.png b/media/articles/connections/social/dashboard-connections-social-edit_view-applications.png
new file mode 100644
index 0000000000..85e4c3d69c
Binary files /dev/null and b/media/articles/connections/social/dashboard-connections-social-edit_view-applications.png differ
diff --git a/media/articles/connections/social/dashboard-connections-social-try.png b/media/articles/connections/social/dashboard-connections-social-try.png
new file mode 100644
index 0000000000..bc06603def
Binary files /dev/null and b/media/articles/connections/social/dashboard-connections-social-try.png differ
diff --git a/media/articles/connections/social/dashboard-connections-social-try_choose-account.png b/media/articles/connections/social/dashboard-connections-social-try_choose-account.png
new file mode 100644
index 0000000000..e6af2483eb
Binary files /dev/null and b/media/articles/connections/social/dashboard-connections-social-try_choose-account.png differ
diff --git a/media/articles/connections/social/devkeys/consent-screen.png b/media/articles/connections/social/devkeys/consent-screen.png
index f7230e785f..8dab9b40a3 100644
Binary files a/media/articles/connections/social/devkeys/consent-screen.png and b/media/articles/connections/social/devkeys/consent-screen.png differ
diff --git a/media/articles/connections/social/exact/exact-register-1.png b/media/articles/connections/social/exact/exact-register-1.png
deleted file mode 100644
index d94be671d9..0000000000
Binary files a/media/articles/connections/social/exact/exact-register-1.png and /dev/null differ
diff --git a/media/articles/connections/social/exact/exact-register-2.png b/media/articles/connections/social/exact/exact-register-2.png
deleted file mode 100644
index fd1ea79e13..0000000000
Binary files a/media/articles/connections/social/exact/exact-register-2.png and /dev/null differ
diff --git a/media/articles/connections/social/exact/exact-register-3.png b/media/articles/connections/social/exact/exact-register-3.png
deleted file mode 100644
index 553c5a42c5..0000000000
Binary files a/media/articles/connections/social/exact/exact-register-3.png and /dev/null differ
diff --git a/media/articles/connections/social/exact/exact-register-4.png b/media/articles/connections/social/exact/exact-register-4.png
deleted file mode 100644
index 3540495e36..0000000000
Binary files a/media/articles/connections/social/exact/exact-register-4.png and /dev/null differ
diff --git a/media/articles/connections/social/exact/exact-register-5.png b/media/articles/connections/social/exact/exact-register-5.png
deleted file mode 100644
index 28a0adf165..0000000000
Binary files a/media/articles/connections/social/exact/exact-register-5.png and /dev/null differ
diff --git a/media/articles/connections/social/exact/exact-register-6.png b/media/articles/connections/social/exact/exact-register-6.png
index 98c6b32087..f2ac3f334d 100644
Binary files a/media/articles/connections/social/exact/exact-register-6.png and b/media/articles/connections/social/exact/exact-register-6.png differ
diff --git a/media/articles/connections/social/facebook/enable-clients.png b/media/articles/connections/social/facebook/enable-applications.png
similarity index 100%
rename from media/articles/connections/social/facebook/enable-clients.png
rename to media/articles/connections/social/facebook/enable-applications.png
diff --git a/media/articles/connections/social/facebook/facebook-connection-permissions.png b/media/articles/connections/social/facebook/facebook-connection-permissions.png
new file mode 100644
index 0000000000..b4ce991d0a
Binary files /dev/null and b/media/articles/connections/social/facebook/facebook-connection-permissions.png differ
diff --git a/media/articles/connections/social/github/github-add-app-1.png b/media/articles/connections/social/github/github-add-app-1.png
index 6077b688fc..d8fa1436eb 100644
Binary files a/media/articles/connections/social/github/github-add-app-1.png and b/media/articles/connections/social/github/github-add-app-1.png differ
diff --git a/media/articles/connections/social/github/github-add-app-2.png b/media/articles/connections/social/github/github-add-app-2.png
index e2889d763b..cbc50df964 100644
Binary files a/media/articles/connections/social/github/github-add-app-2.png and b/media/articles/connections/social/github/github-add-app-2.png differ
diff --git a/media/articles/connections/social/github/github-add-app-3.png b/media/articles/connections/social/github/github-add-app-3.png
index 66b4892e7a..2d4109039c 100644
Binary files a/media/articles/connections/social/github/github-add-app-3.png and b/media/articles/connections/social/github/github-add-app-3.png differ
diff --git a/media/articles/connections/social/github/github-add-app-4.png b/media/articles/connections/social/github/github-add-app-4.png
index 655120c00f..977b2683f7 100644
Binary files a/media/articles/connections/social/github/github-add-app-4.png and b/media/articles/connections/social/github/github-add-app-4.png differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-0.png b/media/articles/connections/social/instagram/instagram-devportal-0.png
deleted file mode 100644
index 426697ffca..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-0.png and /dev/null differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-1.png b/media/articles/connections/social/instagram/instagram-devportal-1.png
deleted file mode 100644
index 230b26d8f3..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-1.png and /dev/null differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-2.png b/media/articles/connections/social/instagram/instagram-devportal-2.png
deleted file mode 100644
index 955e843f3a..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-2.png and /dev/null differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-3.png b/media/articles/connections/social/instagram/instagram-devportal-3.png
deleted file mode 100644
index db8caa5173..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-3.png and /dev/null differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-4-1.png b/media/articles/connections/social/instagram/instagram-devportal-4-1.png
deleted file mode 100644
index 07a1b99363..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-4-1.png and /dev/null differ
diff --git a/media/articles/connections/social/instagram/instagram-devportal-4.png b/media/articles/connections/social/instagram/instagram-devportal-4.png
deleted file mode 100644
index 55f3a09f9e..0000000000
Binary files a/media/articles/connections/social/instagram/instagram-devportal-4.png and /dev/null differ
diff --git a/media/articles/connections/social/line/line_connection.png b/media/articles/connections/social/line/line_connection.png
new file mode 100644
index 0000000000..33794b70c9
Binary files /dev/null and b/media/articles/connections/social/line/line_connection.png differ
diff --git a/media/articles/connections/social/linkedin/linkedin-connection-new.png b/media/articles/connections/social/linkedin/linkedin-connection-new.png
new file mode 100644
index 0000000000..cf9809468c
Binary files /dev/null and b/media/articles/connections/social/linkedin/linkedin-connection-new.png differ
diff --git a/media/articles/connections/social/microsoft-account/microsoft-account-azureid.png b/media/articles/connections/social/microsoft-account/microsoft-account-azureid.png
new file mode 100644
index 0000000000..b3b9b70f14
Binary files /dev/null and b/media/articles/connections/social/microsoft-account/microsoft-account-azureid.png differ
diff --git a/media/articles/connections/social/oauth2/custom-connection-icon.png b/media/articles/connections/social/oauth2/custom-connection-icon.png
new file mode 100644
index 0000000000..4e8ae05dd8
Binary files /dev/null and b/media/articles/connections/social/oauth2/custom-connection-icon.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-1.png b/media/articles/connections/social/shopify/shopify-devportal-1.png
index bfbd600e83..494df18d98 100644
Binary files a/media/articles/connections/social/shopify/shopify-devportal-1.png and b/media/articles/connections/social/shopify/shopify-devportal-1.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-2.png b/media/articles/connections/social/shopify/shopify-devportal-2.png
index 587e9691b3..964bbb3965 100644
Binary files a/media/articles/connections/social/shopify/shopify-devportal-2.png and b/media/articles/connections/social/shopify/shopify-devportal-2.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-3.png b/media/articles/connections/social/shopify/shopify-devportal-3.png
index 0538577ba5..48b8876a0a 100644
Binary files a/media/articles/connections/social/shopify/shopify-devportal-3.png and b/media/articles/connections/social/shopify/shopify-devportal-3.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-4.png b/media/articles/connections/social/shopify/shopify-devportal-4.png
index a5d1389fec..0343666f65 100644
Binary files a/media/articles/connections/social/shopify/shopify-devportal-4.png and b/media/articles/connections/social/shopify/shopify-devportal-4.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-5.png b/media/articles/connections/social/shopify/shopify-devportal-5.png
index 4bab95c5a0..cd136622dc 100644
Binary files a/media/articles/connections/social/shopify/shopify-devportal-5.png and b/media/articles/connections/social/shopify/shopify-devportal-5.png differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-6.png b/media/articles/connections/social/shopify/shopify-devportal-6.png
deleted file mode 100644
index 7ce1c13d2b..0000000000
Binary files a/media/articles/connections/social/shopify/shopify-devportal-6.png and /dev/null differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-7.png b/media/articles/connections/social/shopify/shopify-devportal-7.png
deleted file mode 100644
index 1996f167b8..0000000000
Binary files a/media/articles/connections/social/shopify/shopify-devportal-7.png and /dev/null differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-8.png b/media/articles/connections/social/shopify/shopify-devportal-8.png
deleted file mode 100644
index 2e22a77bd8..0000000000
Binary files a/media/articles/connections/social/shopify/shopify-devportal-8.png and /dev/null differ
diff --git a/media/articles/connections/social/shopify/shopify-devportal-9.png b/media/articles/connections/social/shopify/shopify-devportal-9.png
deleted file mode 100644
index d2a757ded9..0000000000
Binary files a/media/articles/connections/social/shopify/shopify-devportal-9.png and /dev/null differ
diff --git a/media/articles/connections/social/twitter/twitter-api-1.png b/media/articles/connections/social/twitter/twitter-api-1.png
index 52daf3e7eb..6a6406c668 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-1.png and b/media/articles/connections/social/twitter/twitter-api-1.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-10.png b/media/articles/connections/social/twitter/twitter-api-10.png
deleted file mode 100644
index d2a757ded9..0000000000
Binary files a/media/articles/connections/social/twitter/twitter-api-10.png and /dev/null differ
diff --git a/media/articles/connections/social/twitter/twitter-api-2.png b/media/articles/connections/social/twitter/twitter-api-2.png
index 9b633168f9..7126adf76f 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-2.png and b/media/articles/connections/social/twitter/twitter-api-2.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-3.png b/media/articles/connections/social/twitter/twitter-api-3.png
index 91400064d8..b14126b126 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-3.png and b/media/articles/connections/social/twitter/twitter-api-3.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-4.png b/media/articles/connections/social/twitter/twitter-api-4.png
index 9670b067dd..950102ad82 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-4.png and b/media/articles/connections/social/twitter/twitter-api-4.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-5.png b/media/articles/connections/social/twitter/twitter-api-5.png
index b53ef3a9d9..a4d7a3ead2 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-5.png and b/media/articles/connections/social/twitter/twitter-api-5.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-6.png b/media/articles/connections/social/twitter/twitter-api-6.png
index 57b3882909..41df531a84 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-6.png and b/media/articles/connections/social/twitter/twitter-api-6.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-7.png b/media/articles/connections/social/twitter/twitter-api-7.png
index a9b722d4ac..2287567ae5 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-7.png and b/media/articles/connections/social/twitter/twitter-api-7.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-8.png b/media/articles/connections/social/twitter/twitter-api-8.png
index 85614b2812..6cef53480c 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-8.png and b/media/articles/connections/social/twitter/twitter-api-8.png differ
diff --git a/media/articles/connections/social/twitter/twitter-api-9.png b/media/articles/connections/social/twitter/twitter-api-9.png
index 692c603511..0201a3466b 100644
Binary files a/media/articles/connections/social/twitter/twitter-api-9.png and b/media/articles/connections/social/twitter/twitter-api-9.png differ
diff --git a/media/articles/connections/social/weibo/click-advanced.png b/media/articles/connections/social/weibo/click-advanced.png
deleted file mode 100644
index 170d970e0e..0000000000
Binary files a/media/articles/connections/social/weibo/click-advanced.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/click-basic.png b/media/articles/connections/social/weibo/click-basic.png
deleted file mode 100644
index 37eadf152d..0000000000
Binary files a/media/articles/connections/social/weibo/click-basic.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/confirmation.png b/media/articles/connections/social/weibo/confirmation.png
deleted file mode 100644
index 5a4d2d29e7..0000000000
Binary files a/media/articles/connections/social/weibo/confirmation.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/create-app.png b/media/articles/connections/social/weibo/create-app.png
deleted file mode 100644
index 1501212bfc..0000000000
Binary files a/media/articles/connections/social/weibo/create-app.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/development-page.png b/media/articles/connections/social/weibo/development-page.png
deleted file mode 100644
index f4d9cab2e5..0000000000
Binary files a/media/articles/connections/social/weibo/development-page.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/enable-clients.png b/media/articles/connections/social/weibo/enable-clients.png
deleted file mode 100644
index 17783cb407..0000000000
Binary files a/media/articles/connections/social/weibo/enable-clients.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/enter-callback.png b/media/articles/connections/social/weibo/enter-callback.png
deleted file mode 100644
index 21e008a6bb..0000000000
Binary files a/media/articles/connections/social/weibo/enter-callback.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/enter-keys.png b/media/articles/connections/social/weibo/enter-keys.png
deleted file mode 100644
index 27f58a7c80..0000000000
Binary files a/media/articles/connections/social/weibo/enter-keys.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/get-app-key-secret.png b/media/articles/connections/social/weibo/get-app-key-secret.png
deleted file mode 100644
index 558ceea764..0000000000
Binary files a/media/articles/connections/social/weibo/get-app-key-secret.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/select-web-app.png b/media/articles/connections/social/weibo/select-web-app.png
deleted file mode 100644
index 80740be38f..0000000000
Binary files a/media/articles/connections/social/weibo/select-web-app.png and /dev/null differ
diff --git a/media/articles/connections/social/weibo/try-connection.png b/media/articles/connections/social/weibo/try-connection.png
deleted file mode 100644
index 1c90c2784d..0000000000
Binary files a/media/articles/connections/social/weibo/try-connection.png and /dev/null differ
diff --git a/media/articles/connections/social/yahoo/api-permissions.png b/media/articles/connections/social/yahoo/api-permissions.png
deleted file mode 100644
index f8d7d49ac5..0000000000
Binary files a/media/articles/connections/social/yahoo/api-permissions.png and /dev/null differ
diff --git a/media/articles/connections/social/yahoo/client-id-and-secret.png b/media/articles/connections/social/yahoo/client-id-and-secret.png
deleted file mode 100644
index 54f034898f..0000000000
Binary files a/media/articles/connections/social/yahoo/client-id-and-secret.png and /dev/null differ
diff --git a/media/articles/connections/social/yahoo/create-an-app.png b/media/articles/connections/social/yahoo/create-an-app.png
deleted file mode 100644
index f955f4d230..0000000000
Binary files a/media/articles/connections/social/yahoo/create-an-app.png and /dev/null differ
diff --git a/media/articles/connections/social/yahoo/enter-fields.png b/media/articles/connections/social/yahoo/enter-fields.png
deleted file mode 100644
index 5c247fc859..0000000000
Binary files a/media/articles/connections/social/yahoo/enter-fields.png and /dev/null differ
diff --git a/media/articles/connections/tenant-create.png b/media/articles/connections/tenant-create.png
new file mode 100644
index 0000000000..858eaea005
Binary files /dev/null and b/media/articles/connections/tenant-create.png differ
diff --git a/media/articles/connector/install/adldap-connector-setup.png b/media/articles/connector/install/adldap-connector-setup.png
index ddd41885b1..0919cb760e 100644
Binary files a/media/articles/connector/install/adldap-connector-setup.png and b/media/articles/connector/install/adldap-connector-setup.png differ
diff --git a/media/articles/custom-domains/custom-domains-self-managed.png b/media/articles/custom-domains/custom-domains-self-managed.png
index e21b373d51..e8bcc9b2dd 100644
Binary files a/media/articles/custom-domains/custom-domains-self-managed.png and b/media/articles/custom-domains/custom-domains-self-managed.png differ
diff --git a/media/articles/custom-domains/custom-domains.png b/media/articles/custom-domains/custom-domains.png
index f21a07c57b..9e5c1d7ba7 100644
Binary files a/media/articles/custom-domains/custom-domains.png and b/media/articles/custom-domains/custom-domains.png differ
diff --git a/media/articles/dashboard/client_settings.png b/media/articles/dashboard/client_settings.png
index 3263fdb6a4..884d7a1ed7 100644
Binary files a/media/articles/dashboard/client_settings.png and b/media/articles/dashboard/client_settings.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-create.png b/media/articles/dashboard/connections/database/connections-db-create.png
new file mode 100644
index 0000000000..22fc611a6a
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-create.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-apps.png b/media/articles/dashboard/connections/database/connections-db-settings-apps.png
new file mode 100644
index 0000000000..98e12d51d4
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-apps.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png b/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png
new file mode 100644
index 0000000000..c158df6f8d
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-custom-2.png b/media/articles/dashboard/connections/database/connections-db-settings-custom-2.png
new file mode 100644
index 0000000000..ec593c993c
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-custom-2.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-main-1.png b/media/articles/dashboard/connections/database/connections-db-settings-main-1.png
new file mode 100644
index 0000000000..c0b61d7180
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-main-1.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-main-2.png b/media/articles/dashboard/connections/database/connections-db-settings-main-2.png
new file mode 100644
index 0000000000..494e0b1f21
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-main-2.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-1.png b/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-1.png
new file mode 100644
index 0000000000..ab11543dc4
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-1.png differ
diff --git a/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-2.png b/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-2.png
new file mode 100644
index 0000000000..ecb788d534
Binary files /dev/null and b/media/articles/dashboard/connections/database/connections-db-settings-passwordpolicy-2.png differ
diff --git a/media/articles/dashboard/connections/database/dashboard-connections-database-create_default-empty.png b/media/articles/dashboard/connections/database/dashboard-connections-database-create_default-empty.png
new file mode 100644
index 0000000000..a1f46ab086
Binary files /dev/null and b/media/articles/dashboard/connections/database/dashboard-connections-database-create_default-empty.png differ
diff --git a/media/articles/dashboard/connections/database/dashboard-connections-database-edit_view-applications.png b/media/articles/dashboard/connections/database/dashboard-connections-database-edit_view-applications.png
new file mode 100644
index 0000000000..14a017ff20
Binary files /dev/null and b/media/articles/dashboard/connections/database/dashboard-connections-database-edit_view-applications.png differ
diff --git a/media/articles/dashboard/connections/database/dashboard-connections-database-list.png b/media/articles/dashboard/connections/database/dashboard-connections-database-list.png
new file mode 100644
index 0000000000..9851c12027
Binary files /dev/null and b/media/articles/dashboard/connections/database/dashboard-connections-database-list.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-1.png
new file mode 100644
index 0000000000..9bb22dc82c
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-2.png
new file mode 100644
index 0000000000..7786e24744
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ad-ldap-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-additional-oidc-settings.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-additional-oidc-settings.png
new file mode 100644
index 0000000000..14bf1afc2e
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-additional-oidc-settings.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-1.png
new file mode 100644
index 0000000000..9a51c07db0
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-2.png
new file mode 100644
index 0000000000..39ec7e292a
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-adfs-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1-new.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1-new.png
new file mode 100644
index 0000000000..10c351a5a0
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1-new.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1.png
new file mode 100644
index 0000000000..67681c2cf4
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-2.png
new file mode 100644
index 0000000000..a7d150262c
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-gsuite-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ip-addr-auth-settings.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ip-addr-auth-settings.png
new file mode 100644
index 0000000000..a656e36caa
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ip-addr-auth-settings.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-list-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-list-2.png
new file mode 100644
index 0000000000..a6e0a8c842
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-list-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-list.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-list.png
new file mode 100644
index 0000000000..7f9351a324
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-list.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-1.png
new file mode 100644
index 0000000000..35b2151164
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-2.png
new file mode 100644
index 0000000000..59b3139172
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ms-azure-ad-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-1.png
new file mode 100644
index 0000000000..b312de420e
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-2.png
new file mode 100644
index 0000000000..5e07e71d8b
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-oidc-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-1.png
new file mode 100644
index 0000000000..d15132b4ea
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-2.png
new file mode 100644
index 0000000000..3369440a27
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-ping-federate-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-applications.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-applications.png
new file mode 100644
index 0000000000..6556199dfc
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-applications.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png
new file mode 100644
index 0000000000..a6e8d8e6cf
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-list.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-list.png
new file mode 100644
index 0000000000..8fa46ef14a
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-list.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-mappings.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-mappings.png
new file mode 100644
index 0000000000..bbd5a237a6
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-mappings.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-1.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-1.png
new file mode 100644
index 0000000000..7b99241338
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-1.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-2.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-2.png
new file mode 100644
index 0000000000..d2d19e7b49
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-2.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-3.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-3.png
new file mode 100644
index 0000000000..ad62fff005
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-settings-3.png differ
diff --git a/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-setup.png b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-setup.png
new file mode 100644
index 0000000000..02312b56af
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-setup.png differ
diff --git a/media/articles/dashboard/connections/enterprise/dashboard-connections-enterprise-edit_view-mappings_saml.png b/media/articles/dashboard/connections/enterprise/dashboard-connections-enterprise-edit_view-mappings_saml.png
new file mode 100644
index 0000000000..4c6a13640b
Binary files /dev/null and b/media/articles/dashboard/connections/enterprise/dashboard-connections-enterprise-edit_view-mappings_saml.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-list.png b/media/articles/dashboard/emails/providers/emails-providers-list.png
new file mode 100644
index 0000000000..745c3a3fae
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-list.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-aws.png b/media/articles/dashboard/emails/providers/emails-providers-settings-aws.png
new file mode 100644
index 0000000000..848423a10e
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-aws.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-mailgun.png b/media/articles/dashboard/emails/providers/emails-providers-settings-mailgun.png
new file mode 100644
index 0000000000..3a1d84b5b6
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-mailgun.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-mandrill.png b/media/articles/dashboard/emails/providers/emails-providers-settings-mandrill.png
new file mode 100644
index 0000000000..fbaddb7595
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-mandrill.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-sendgrid.png b/media/articles/dashboard/emails/providers/emails-providers-settings-sendgrid.png
new file mode 100644
index 0000000000..57994cb365
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-sendgrid.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.png b/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.png
new file mode 100644
index 0000000000..c82caafef5
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.png differ
diff --git a/media/articles/dashboard/emails/providers/emails-providers-settings-sparkpost.png b/media/articles/dashboard/emails/providers/emails-providers-settings-sparkpost.png
new file mode 100644
index 0000000000..cd73d7132d
Binary files /dev/null and b/media/articles/dashboard/emails/providers/emails-providers-settings-sparkpost.png differ
diff --git a/media/articles/dashboard/guides/app-list.png b/media/articles/dashboard/guides/app-list.png
new file mode 100644
index 0000000000..ad55fbd48a
Binary files /dev/null and b/media/articles/dashboard/guides/app-list.png differ
diff --git a/media/articles/dashboard/guides/app-settings-danger-zone.png b/media/articles/dashboard/guides/app-settings-danger-zone.png
new file mode 100644
index 0000000000..cdad788ac5
Binary files /dev/null and b/media/articles/dashboard/guides/app-settings-danger-zone.png differ
diff --git a/media/articles/dashboard/guides/app-settings.png b/media/articles/dashboard/guides/app-settings.png
new file mode 100644
index 0000000000..8f54b1c56b
Binary files /dev/null and b/media/articles/dashboard/guides/app-settings.png differ
diff --git a/media/articles/dashboard/guides/applications/app-settings-advanced-oauth.png b/media/articles/dashboard/guides/applications/app-settings-advanced-oauth.png
new file mode 100644
index 0000000000..430d14f590
Binary files /dev/null and b/media/articles/dashboard/guides/applications/app-settings-advanced-oauth.png differ
diff --git a/media/articles/dashboard/guides/rotate-client-secret.png b/media/articles/dashboard/guides/rotate-client-secret.png
new file mode 100644
index 0000000000..27bb8e4bcb
Binary files /dev/null and b/media/articles/dashboard/guides/rotate-client-secret.png differ
diff --git a/media/articles/dashboard/guides/users-roles/users-list.png b/media/articles/dashboard/guides/users-roles/users-list.png
new file mode 100644
index 0000000000..1a58aac848
Binary files /dev/null and b/media/articles/dashboard/guides/users-roles/users-list.png differ
diff --git a/media/articles/dashboard/guides/users-roles/users-prof-devices.png b/media/articles/dashboard/guides/users-roles/users-prof-devices.png
new file mode 100644
index 0000000000..861a30276e
Binary files /dev/null and b/media/articles/dashboard/guides/users-roles/users-prof-devices.png differ
diff --git a/media/articles/dashboard/rules/rules-edit-rule.png b/media/articles/dashboard/rules/rules-edit-rule.png
new file mode 100644
index 0000000000..4f4a74ade0
Binary files /dev/null and b/media/articles/dashboard/rules/rules-edit-rule.png differ
diff --git a/media/articles/dashboard/rules/rules-list-empty.png b/media/articles/dashboard/rules/rules-list-empty.png
new file mode 100644
index 0000000000..e949f79566
Binary files /dev/null and b/media/articles/dashboard/rules/rules-list-empty.png differ
diff --git a/media/articles/dashboard/rules/rules-list-with-rules-variables.png b/media/articles/dashboard/rules/rules-list-with-rules-variables.png
new file mode 100644
index 0000000000..516811b650
Binary files /dev/null and b/media/articles/dashboard/rules/rules-list-with-rules-variables.png differ
diff --git a/media/articles/dashboard/rules/rules-list-with-rules.png b/media/articles/dashboard/rules/rules-list-with-rules.png
new file mode 100644
index 0000000000..219aafec23
Binary files /dev/null and b/media/articles/dashboard/rules/rules-list-with-rules.png differ
diff --git a/media/articles/dashboard/rules/rules-settings-add-variable.png b/media/articles/dashboard/rules/rules-settings-add-variable.png
new file mode 100644
index 0000000000..e5aac978f3
Binary files /dev/null and b/media/articles/dashboard/rules/rules-settings-add-variable.png differ
diff --git a/media/articles/dashboard/rules/rules-templates.png b/media/articles/dashboard/rules/rules-templates.png
new file mode 100644
index 0000000000..0df165b06f
Binary files /dev/null and b/media/articles/dashboard/rules/rules-templates.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-ad-rms.png b/media/articles/dashboard/sso-integrations/create-authorize-ad-rms.png
new file mode 100644
index 0000000000..d2c2bca036
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-ad-rms.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-adobe-sign.png b/media/articles/dashboard/sso-integrations/create-authorize-adobe-sign.png
new file mode 100644
index 0000000000..a72f195163
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-adobe-sign.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-box.png b/media/articles/dashboard/sso-integrations/create-authorize-box.png
new file mode 100644
index 0000000000..82176c5c9f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-box.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-cisco-webex.png b/media/articles/dashboard/sso-integrations/create-authorize-cisco-webex.png
new file mode 100644
index 0000000000..246b12c06f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-cisco-webex.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-cloudbees.png b/media/articles/dashboard/sso-integrations/create-authorize-cloudbees.png
new file mode 100644
index 0000000000..0c3775955d
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-cloudbees.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-concur.png b/media/articles/dashboard/sso-integrations/create-authorize-concur.png
new file mode 100644
index 0000000000..bca0f92e56
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-concur.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-datadog.png b/media/articles/dashboard/sso-integrations/create-authorize-datadog.png
new file mode 100644
index 0000000000..289226d28b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-datadog.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-dropbox.png b/media/articles/dashboard/sso-integrations/create-authorize-dropbox.png
new file mode 100644
index 0000000000..a3c49aa0af
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-dropbox.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-dynamics-crm.png b/media/articles/dashboard/sso-integrations/create-authorize-dynamics-crm.png
new file mode 100644
index 0000000000..eb7d8e622b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-dynamics-crm.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-egencia.png b/media/articles/dashboard/sso-integrations/create-authorize-egencia.png
new file mode 100644
index 0000000000..1ba2e3c3d1
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-egencia.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-egnyte.png b/media/articles/dashboard/sso-integrations/create-authorize-egnyte.png
new file mode 100644
index 0000000000..f7703d79d1
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-egnyte.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-eloqua.png b/media/articles/dashboard/sso-integrations/create-authorize-eloqua.png
new file mode 100644
index 0000000000..d82b13858e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-eloqua.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-freshdesk.png b/media/articles/dashboard/sso-integrations/create-authorize-freshdesk.png
new file mode 100644
index 0000000000..c46fc5aada
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-freshdesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-g-suite.png b/media/articles/dashboard/sso-integrations/create-authorize-g-suite.png
new file mode 100644
index 0000000000..0a52539811
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-g-suite.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-cloud.png b/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-cloud.png
new file mode 100644
index 0000000000..56eaf86316
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-cloud.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-server.png b/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-server.png
new file mode 100644
index 0000000000..cc7d027550
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-github-enterprise-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-heroku.png b/media/articles/dashboard/sso-integrations/create-authorize-heroku.png
new file mode 100644
index 0000000000..f7420f1296
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-heroku.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-hosted-graphite.png b/media/articles/dashboard/sso-integrations/create-authorize-hosted-graphite.png
new file mode 100644
index 0000000000..0362f3c799
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-hosted-graphite.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-litmos.png b/media/articles/dashboard/sso-integrations/create-authorize-litmos.png
new file mode 100644
index 0000000000..9089c76280
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-litmos.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-new-relic.png b/media/articles/dashboard/sso-integrations/create-authorize-new-relic.png
new file mode 100644
index 0000000000..900872332a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-new-relic.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-office-365.png b/media/articles/dashboard/sso-integrations/create-authorize-office-365.png
new file mode 100644
index 0000000000..120d30f812
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-office-365.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-pluralsight.png b/media/articles/dashboard/sso-integrations/create-authorize-pluralsight.png
new file mode 100644
index 0000000000..860aa570f4
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-pluralsight.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-salesforce.png b/media/articles/dashboard/sso-integrations/create-authorize-salesforce.png
new file mode 100644
index 0000000000..fe8534cc2b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-salesforce.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-sentry.png b/media/articles/dashboard/sso-integrations/create-authorize-sentry.png
new file mode 100644
index 0000000000..8695b88f99
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-sentry.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-sharepoint.png b/media/articles/dashboard/sso-integrations/create-authorize-sharepoint.png
new file mode 100644
index 0000000000..c71991153e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-sharepoint.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-slack.png b/media/articles/dashboard/sso-integrations/create-authorize-slack.png
new file mode 100644
index 0000000000..d8db6248f3
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-slack.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-springcm.png b/media/articles/dashboard/sso-integrations/create-authorize-springcm.png
new file mode 100644
index 0000000000..ab814fcdb4
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-springcm.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-sprout-video.png b/media/articles/dashboard/sso-integrations/create-authorize-sprout-video.png
new file mode 100644
index 0000000000..fe2879fc51
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-sprout-video.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-tableau-online.png b/media/articles/dashboard/sso-integrations/create-authorize-tableau-online.png
new file mode 100644
index 0000000000..b736c62584
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-tableau-online.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-tableau-server.png b/media/articles/dashboard/sso-integrations/create-authorize-tableau-server.png
new file mode 100644
index 0000000000..e5badeab50
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-tableau-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-workday.png b/media/articles/dashboard/sso-integrations/create-authorize-workday.png
new file mode 100644
index 0000000000..bbfdc80769
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-workday.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-workpath.png b/media/articles/dashboard/sso-integrations/create-authorize-workpath.png
new file mode 100644
index 0000000000..44250fcb99
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-workpath.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-zendesk.png b/media/articles/dashboard/sso-integrations/create-authorize-zendesk.png
new file mode 100644
index 0000000000..75c2384114
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-zendesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-authorize-zoom.png b/media/articles/dashboard/sso-integrations/create-authorize-zoom.png
new file mode 100644
index 0000000000..dd5e9b1a32
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-authorize-zoom.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-ad-rms.png b/media/articles/dashboard/sso-integrations/create-save-ad-rms.png
new file mode 100644
index 0000000000..3edf42c3db
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-ad-rms.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-adobe-sign.png b/media/articles/dashboard/sso-integrations/create-save-adobe-sign.png
new file mode 100644
index 0000000000..4a2829827e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-adobe-sign.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-box.png b/media/articles/dashboard/sso-integrations/create-save-box.png
new file mode 100644
index 0000000000..eb08f879bf
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-box.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-cisco-webex.png b/media/articles/dashboard/sso-integrations/create-save-cisco-webex.png
new file mode 100644
index 0000000000..de37e1c5b0
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-cisco-webex.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-cloudbees.png b/media/articles/dashboard/sso-integrations/create-save-cloudbees.png
new file mode 100644
index 0000000000..820383a6f4
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-cloudbees.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-concur.png b/media/articles/dashboard/sso-integrations/create-save-concur.png
new file mode 100644
index 0000000000..d0e80a0999
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-concur.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-datadog.png b/media/articles/dashboard/sso-integrations/create-save-datadog.png
new file mode 100644
index 0000000000..4da094b505
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-datadog.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-dropbox.png b/media/articles/dashboard/sso-integrations/create-save-dropbox.png
new file mode 100644
index 0000000000..ae0e02c979
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-dropbox.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-dynamics-crm.png b/media/articles/dashboard/sso-integrations/create-save-dynamics-crm.png
new file mode 100644
index 0000000000..98d08ea57c
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-dynamics-crm.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-egencia.png b/media/articles/dashboard/sso-integrations/create-save-egencia.png
new file mode 100644
index 0000000000..8ff63e8dc5
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-egencia.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-egnyte.png b/media/articles/dashboard/sso-integrations/create-save-egnyte.png
new file mode 100644
index 0000000000..2e31bd8a49
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-egnyte.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-eloqua.png b/media/articles/dashboard/sso-integrations/create-save-eloqua.png
new file mode 100644
index 0000000000..6b1dd7a95b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-eloqua.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-freshdesk.png b/media/articles/dashboard/sso-integrations/create-save-freshdesk.png
new file mode 100644
index 0000000000..a0e975c46e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-freshdesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-g-suite.png b/media/articles/dashboard/sso-integrations/create-save-g-suite.png
new file mode 100644
index 0000000000..dc3eb4db49
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-g-suite.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-github-enterprise-cloud.png b/media/articles/dashboard/sso-integrations/create-save-github-enterprise-cloud.png
new file mode 100644
index 0000000000..d93b95b5d0
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-github-enterprise-cloud.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-github-enterprise-server.png b/media/articles/dashboard/sso-integrations/create-save-github-enterprise-server.png
new file mode 100644
index 0000000000..011972f923
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-github-enterprise-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-heroku.png b/media/articles/dashboard/sso-integrations/create-save-heroku.png
new file mode 100644
index 0000000000..c212da02a4
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-heroku.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-hosted-graphite.png b/media/articles/dashboard/sso-integrations/create-save-hosted-graphite.png
new file mode 100644
index 0000000000..334ba26163
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-hosted-graphite.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-litmos.png b/media/articles/dashboard/sso-integrations/create-save-litmos.png
new file mode 100644
index 0000000000..443da9258f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-litmos.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-new-relic.png b/media/articles/dashboard/sso-integrations/create-save-new-relic.png
new file mode 100644
index 0000000000..0552e5258e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-new-relic.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-office-365.png b/media/articles/dashboard/sso-integrations/create-save-office-365.png
new file mode 100644
index 0000000000..ea9783eeae
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-office-365.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-pluralsight.png b/media/articles/dashboard/sso-integrations/create-save-pluralsight.png
new file mode 100644
index 0000000000..5f64e42c1b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-pluralsight.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-salesforce.png b/media/articles/dashboard/sso-integrations/create-save-salesforce.png
new file mode 100644
index 0000000000..1dc9687f31
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-salesforce.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-sentry.png b/media/articles/dashboard/sso-integrations/create-save-sentry.png
new file mode 100644
index 0000000000..55ffc4e0da
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-sentry.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-sharepoint.png b/media/articles/dashboard/sso-integrations/create-save-sharepoint.png
new file mode 100644
index 0000000000..af1fc0b335
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-sharepoint.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-slack.png b/media/articles/dashboard/sso-integrations/create-save-slack.png
new file mode 100644
index 0000000000..e5ee1fe936
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-slack.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-springcm.png b/media/articles/dashboard/sso-integrations/create-save-springcm.png
new file mode 100644
index 0000000000..7bcb96d4fb
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-springcm.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-sprout-video.png b/media/articles/dashboard/sso-integrations/create-save-sprout-video.png
new file mode 100644
index 0000000000..d79326a945
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-sprout-video.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-tableau-online.png b/media/articles/dashboard/sso-integrations/create-save-tableau-online.png
new file mode 100644
index 0000000000..b61325565b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-tableau-online.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-tableau-server.png b/media/articles/dashboard/sso-integrations/create-save-tableau-server.png
new file mode 100644
index 0000000000..ad6b286417
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-tableau-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-workday.png b/media/articles/dashboard/sso-integrations/create-save-workday.png
new file mode 100644
index 0000000000..61d3c2d8ac
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-workday.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-workpath.png b/media/articles/dashboard/sso-integrations/create-save-workpath.png
new file mode 100644
index 0000000000..a42f629843
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-workpath.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-zendesk.png b/media/articles/dashboard/sso-integrations/create-save-zendesk.png
new file mode 100644
index 0000000000..0c0faebaa9
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-zendesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-save-zoom.png b/media/articles/dashboard/sso-integrations/create-save-zoom.png
new file mode 100644
index 0000000000..82e5eebb73
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-save-zoom.png differ
diff --git a/media/articles/dashboard/sso-integrations/create-select-service.png b/media/articles/dashboard/sso-integrations/create-select-service.png
new file mode 100644
index 0000000000..55a923a7c8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create-select-service.png differ
diff --git a/media/articles/dashboard/sso-integrations/create.png b/media/articles/dashboard/sso-integrations/create.png
new file mode 100644
index 0000000000..274a0584bd
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/create.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png
new file mode 100644
index 0000000000..739dc7965d
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png
new file mode 100644
index 0000000000..1b68dbd05f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png
new file mode 100644
index 0000000000..af0eb40690
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png
new file mode 100644
index 0000000000..1a971103a9
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png
new file mode 100644
index 0000000000..543d8dcc5f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png
new file mode 100644
index 0000000000..9f80210efb
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png differ
diff --git a/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-list.png b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-list.png
new file mode 100644
index 0000000000..5b8e995d81
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-list.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-ad-rms.png b/media/articles/dashboard/sso-integrations/settings-ad-rms.png
new file mode 100644
index 0000000000..c927cb182f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-ad-rms.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-ad-rms.png b/media/articles/dashboard/sso-integrations/settings-connections-ad-rms.png
new file mode 100644
index 0000000000..df9bfd05c7
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-ad-rms.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-adobe-sign.png b/media/articles/dashboard/sso-integrations/settings-connections-adobe-sign.png
new file mode 100644
index 0000000000..4c39a664f8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-adobe-sign.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-box.png b/media/articles/dashboard/sso-integrations/settings-connections-box.png
new file mode 100644
index 0000000000..f8722260d4
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-box.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-cisco-webex.png b/media/articles/dashboard/sso-integrations/settings-connections-cisco-webex.png
new file mode 100644
index 0000000000..8e80a2af0e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-cisco-webex.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-cloudbees.png b/media/articles/dashboard/sso-integrations/settings-connections-cloudbees.png
new file mode 100644
index 0000000000..440c5a7bb2
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-cloudbees.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-concur.png b/media/articles/dashboard/sso-integrations/settings-connections-concur.png
new file mode 100644
index 0000000000..313117a302
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-concur.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-datadog.png b/media/articles/dashboard/sso-integrations/settings-connections-datadog.png
new file mode 100644
index 0000000000..20d3e268cf
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-datadog.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-dropbox.png b/media/articles/dashboard/sso-integrations/settings-connections-dropbox.png
new file mode 100644
index 0000000000..324350d28a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-dropbox.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-dynamics-crm.png b/media/articles/dashboard/sso-integrations/settings-connections-dynamics-crm.png
new file mode 100644
index 0000000000..271d7c0c0f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-dynamics-crm.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-egencia.png b/media/articles/dashboard/sso-integrations/settings-connections-egencia.png
new file mode 100644
index 0000000000..b464d64863
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-egencia.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-egnyte.png b/media/articles/dashboard/sso-integrations/settings-connections-egnyte.png
new file mode 100644
index 0000000000..fd30d72823
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-egnyte.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-eloqua.png b/media/articles/dashboard/sso-integrations/settings-connections-eloqua.png
new file mode 100644
index 0000000000..06bc4eb173
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-eloqua.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-freshdesk.png b/media/articles/dashboard/sso-integrations/settings-connections-freshdesk.png
new file mode 100644
index 0000000000..cde6238313
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-freshdesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-g-suite.png b/media/articles/dashboard/sso-integrations/settings-connections-g-suite.png
new file mode 100644
index 0000000000..a7d7f0920a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-g-suite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-cloud.png b/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-cloud.png
new file mode 100644
index 0000000000..2992d325e3
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-cloud.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-server.png b/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-server.png
new file mode 100644
index 0000000000..26cc878864
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-github-enterprise-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-heroku.png b/media/articles/dashboard/sso-integrations/settings-connections-heroku.png
new file mode 100644
index 0000000000..51706b02a5
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-heroku.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-hosted-graphite.png b/media/articles/dashboard/sso-integrations/settings-connections-hosted-graphite.png
new file mode 100644
index 0000000000..6de30eb655
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-hosted-graphite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-litmos.png b/media/articles/dashboard/sso-integrations/settings-connections-litmos.png
new file mode 100644
index 0000000000..ec054038dc
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-litmos.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-new-relic.png b/media/articles/dashboard/sso-integrations/settings-connections-new-relic.png
new file mode 100644
index 0000000000..c5250ea9f2
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-new-relic.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-office-365.png b/media/articles/dashboard/sso-integrations/settings-connections-office-365.png
new file mode 100644
index 0000000000..6be7504a54
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-office-365.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-pluralsight.png b/media/articles/dashboard/sso-integrations/settings-connections-pluralsight.png
new file mode 100644
index 0000000000..5925372495
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-pluralsight.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-salesforce.png b/media/articles/dashboard/sso-integrations/settings-connections-salesforce.png
new file mode 100644
index 0000000000..6514b362a7
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-salesforce.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-sentry.png b/media/articles/dashboard/sso-integrations/settings-connections-sentry.png
new file mode 100644
index 0000000000..210a30e2d8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-sentry.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-sharepoint.png b/media/articles/dashboard/sso-integrations/settings-connections-sharepoint.png
new file mode 100644
index 0000000000..d6d2f47f41
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-sharepoint.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-slack.png b/media/articles/dashboard/sso-integrations/settings-connections-slack.png
new file mode 100644
index 0000000000..acc8871836
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-slack.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-springcm.png b/media/articles/dashboard/sso-integrations/settings-connections-springcm.png
new file mode 100644
index 0000000000..a5f092c620
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-springcm.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-sprout-video.png b/media/articles/dashboard/sso-integrations/settings-connections-sprout-video.png
new file mode 100644
index 0000000000..e74b43911c
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-sprout-video.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-tableau-online.png b/media/articles/dashboard/sso-integrations/settings-connections-tableau-online.png
new file mode 100644
index 0000000000..8875717b69
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-tableau-online.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-tableau-server.png b/media/articles/dashboard/sso-integrations/settings-connections-tableau-server.png
new file mode 100644
index 0000000000..00b5d0b691
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-tableau-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-workday.png b/media/articles/dashboard/sso-integrations/settings-connections-workday.png
new file mode 100644
index 0000000000..bb6ae57e66
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-workday.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-workpath.png b/media/articles/dashboard/sso-integrations/settings-connections-workpath.png
new file mode 100644
index 0000000000..48d4cf92f0
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-workpath.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-zendesk.png b/media/articles/dashboard/sso-integrations/settings-connections-zendesk.png
new file mode 100644
index 0000000000..1ef53fd44a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-zendesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-connections-zoom.png b/media/articles/dashboard/sso-integrations/settings-connections-zoom.png
new file mode 100644
index 0000000000..e212e7ea3b
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-connections-zoom.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-egencia.png b/media/articles/dashboard/sso-integrations/settings-egencia.png
new file mode 100644
index 0000000000..2b456e9318
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-egencia.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-egnyte.png b/media/articles/dashboard/sso-integrations/settings-egnyte.png
new file mode 100644
index 0000000000..51573f309e
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-egnyte.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-eloqua.png b/media/articles/dashboard/sso-integrations/settings-eloqua.png
new file mode 100644
index 0000000000..fe50295978
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-eloqua.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-freshdesk.png b/media/articles/dashboard/sso-integrations/settings-freshdesk.png
new file mode 100644
index 0000000000..39c6bbb79f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-freshdesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-g-suite.png b/media/articles/dashboard/sso-integrations/settings-g-suite.png
new file mode 100644
index 0000000000..1b0b33650d
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-g-suite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-github-enterprise-cloud.png b/media/articles/dashboard/sso-integrations/settings-github-enterprise-cloud.png
new file mode 100644
index 0000000000..e4aa1c088d
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-github-enterprise-cloud.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-github-enterprise-server.png b/media/articles/dashboard/sso-integrations/settings-github-enterprise-server.png
new file mode 100644
index 0000000000..8e2a3d7075
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-github-enterprise-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-heroku.png b/media/articles/dashboard/sso-integrations/settings-heroku.png
new file mode 100644
index 0000000000..dc70c84b44
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-heroku.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-hosted-graphite.png b/media/articles/dashboard/sso-integrations/settings-hosted-graphite.png
new file mode 100644
index 0000000000..c9844f2b47
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-hosted-graphite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-litmos.png b/media/articles/dashboard/sso-integrations/settings-litmos.png
new file mode 100644
index 0000000000..2291710c4a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-litmos.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-salesforce.png b/media/articles/dashboard/sso-integrations/settings-salesforce.png
new file mode 100644
index 0000000000..3860fab765
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-salesforce.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-sentry.png b/media/articles/dashboard/sso-integrations/settings-sentry.png
new file mode 100644
index 0000000000..472a864a54
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-sentry.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-sharepoint.png b/media/articles/dashboard/sso-integrations/settings-sharepoint.png
new file mode 100644
index 0000000000..2beb35aa81
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-sharepoint.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-slack.png b/media/articles/dashboard/sso-integrations/settings-slack.png
new file mode 100644
index 0000000000..dac9fd51da
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-slack.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-springcm.png b/media/articles/dashboard/sso-integrations/settings-springcm.png
new file mode 100644
index 0000000000..4b0808b5f7
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-springcm.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-sprout-video.png b/media/articles/dashboard/sso-integrations/settings-sprout-video.png
new file mode 100644
index 0000000000..971e613702
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-sprout-video.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tableau-online.png b/media/articles/dashboard/sso-integrations/settings-tableau-online.png
new file mode 100644
index 0000000000..5b9e6e7a7c
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tableau-online.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tableau-server.png b/media/articles/dashboard/sso-integrations/settings-tableau-server.png
new file mode 100644
index 0000000000..34b9ee9339
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tableau-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-ad-rms.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-ad-rms.png
new file mode 100644
index 0000000000..8c14d8b646
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-ad-rms.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-adobe-sign.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-adobe-sign.png
new file mode 100644
index 0000000000..af82805c5c
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-adobe-sign.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-box.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-box.png
new file mode 100644
index 0000000000..58eaf98396
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-box.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cisco-webex.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cisco-webex.png
new file mode 100644
index 0000000000..3eb97624bc
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cisco-webex.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cloudbees.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cloudbees.png
new file mode 100644
index 0000000000..9e8209c15c
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-cloudbees.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-concur.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-concur.png
new file mode 100644
index 0000000000..4e28a06b05
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-concur.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-datadog.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-datadog.png
new file mode 100644
index 0000000000..62cd46e3de
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-datadog.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dropbox.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dropbox.png
new file mode 100644
index 0000000000..dc1f6e0270
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dropbox.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dynamics-crm.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dynamics-crm.png
new file mode 100644
index 0000000000..cf108c1618
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-dynamics-crm.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egencia.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egencia.png
new file mode 100644
index 0000000000..3c3f1b156a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egencia.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egnyte.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egnyte.png
new file mode 100644
index 0000000000..3623f0e720
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-egnyte.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-eloqua.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-eloqua.png
new file mode 100644
index 0000000000..2a0d166e72
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-eloqua.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-freshdesk.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-freshdesk.png
new file mode 100644
index 0000000000..75124266bd
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-freshdesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-g-suite.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-g-suite.png
new file mode 100644
index 0000000000..d11c6d94fa
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-g-suite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-cloud.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-cloud.png
new file mode 100644
index 0000000000..3699481c9f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-cloud.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-server.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-server.png
new file mode 100644
index 0000000000..eb3596dbf0
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-github-enterprise-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-heroku.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-heroku.png
new file mode 100644
index 0000000000..ccf1601dd6
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-heroku.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-hosted-graphite.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-hosted-graphite.png
new file mode 100644
index 0000000000..a66728d479
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-hosted-graphite.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-litmos.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-litmos.png
new file mode 100644
index 0000000000..eba26e0be8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-litmos.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-new-relic.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-new-relic.png
new file mode 100644
index 0000000000..00be5cb883
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-new-relic.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-office-365.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-office-365.png
new file mode 100644
index 0000000000..dba55697b8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-office-365.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-pluralsight.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-pluralsight.png
new file mode 100644
index 0000000000..5dfdb9ad26
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-pluralsight.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-salesforce.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-salesforce.png
new file mode 100644
index 0000000000..bc7296f2f3
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-salesforce.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sentry.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sentry.png
new file mode 100644
index 0000000000..de540b971a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sentry.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sharepoint.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sharepoint.png
new file mode 100644
index 0000000000..90b3664f8a
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sharepoint.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-slack.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-slack.png
new file mode 100644
index 0000000000..28022c1788
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-slack.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-springcm.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-springcm.png
new file mode 100644
index 0000000000..1d462e1978
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-springcm.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sprout-video.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sprout-video.png
new file mode 100644
index 0000000000..4dd4a73002
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-sprout-video.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-online.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-online.png
new file mode 100644
index 0000000000..cbf6a6cada
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-online.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-server.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-server.png
new file mode 100644
index 0000000000..148661f947
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-tableau-server.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workday.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workday.png
new file mode 100644
index 0000000000..749634af9f
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workday.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workpath.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workpath.png
new file mode 100644
index 0000000000..ce47dba098
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-workpath.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zendesk.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zendesk.png
new file mode 100644
index 0000000000..cc55650428
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zendesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zoom.png b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zoom.png
new file mode 100644
index 0000000000..662d99fc37
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-tutorial-clientid-zoom.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-workday.png b/media/articles/dashboard/sso-integrations/settings-workday.png
new file mode 100644
index 0000000000..0af4ca42f0
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-workday.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-workpath.png b/media/articles/dashboard/sso-integrations/settings-workpath.png
new file mode 100644
index 0000000000..9a075afdc1
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-workpath.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-zendesk.png b/media/articles/dashboard/sso-integrations/settings-zendesk.png
new file mode 100644
index 0000000000..e278af4239
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-zendesk.png differ
diff --git a/media/articles/dashboard/sso-integrations/settings-zoom.png b/media/articles/dashboard/sso-integrations/settings-zoom.png
new file mode 100644
index 0000000000..fc960ad6f8
Binary files /dev/null and b/media/articles/dashboard/sso-integrations/settings-zoom.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-advanced-device-user-code.png b/media/articles/dashboard/tenants/tenant-settings-advanced-device-user-code.png
new file mode 100644
index 0000000000..009f4dc958
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-advanced-device-user-code.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-advanced-login-session-management.png b/media/articles/dashboard/tenants/tenant-settings-advanced-login-session-management.png
new file mode 100644
index 0000000000..8bf71ba536
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-advanced-login-session-management.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke-confirm.png b/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke-confirm.png
new file mode 100644
index 0000000000..218a5cdfaf
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke-confirm.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke.png b/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke.png
new file mode 100644
index 0000000000..8965b4e73e
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-confirm.png b/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-confirm.png
new file mode 100644
index 0000000000..3e7f7e3488
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-confirm.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-revoke-confirm.png b/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-revoke-confirm.png
new file mode 100644
index 0000000000..3314b1e344
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-revoke-confirm.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings-signing-keys.png b/media/articles/dashboard/tenants/tenant-settings-signing-keys.png
new file mode 100644
index 0000000000..4ccbc7cbed
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings-signing-keys.png differ
diff --git a/media/articles/dashboard/tenants/tenant-settings.png b/media/articles/dashboard/tenants/tenant-settings.png
new file mode 100644
index 0000000000..6c86a523c7
Binary files /dev/null and b/media/articles/dashboard/tenants/tenant-settings.png differ
diff --git a/media/articles/dashboard/users-roles/users-list.png b/media/articles/dashboard/users-roles/users-list.png
new file mode 100644
index 0000000000..9dcc5e7815
Binary files /dev/null and b/media/articles/dashboard/users-roles/users-list.png differ
diff --git a/media/articles/email/providers/aws-keys.png b/media/articles/email/providers/aws-keys.png
deleted file mode 100644
index 4bd591b7a6..0000000000
Binary files a/media/articles/email/providers/aws-keys.png and /dev/null differ
diff --git a/media/articles/email/providers/email-mandrill-monitoring.png b/media/articles/email/providers/email-mandrill-monitoring.png
deleted file mode 100644
index e03d6c038b..0000000000
Binary files a/media/articles/email/providers/email-mandrill-monitoring.png and /dev/null differ
diff --git a/media/articles/email/providers/email-sendgrid-monitoring.png b/media/articles/email/providers/email-sendgrid-monitoring.png
deleted file mode 100644
index 24e88879a5..0000000000
Binary files a/media/articles/email/providers/email-sendgrid-monitoring.png and /dev/null differ
diff --git a/media/articles/email/providers/enter-keys.png b/media/articles/email/providers/enter-keys.png
deleted file mode 100644
index 4a88242fb9..0000000000
Binary files a/media/articles/email/providers/enter-keys.png and /dev/null differ
diff --git a/media/articles/email/providers/enter-smtp-data.png b/media/articles/email/providers/enter-smtp-data.png
deleted file mode 100644
index 86b1db47a3..0000000000
Binary files a/media/articles/email/providers/enter-smtp-data.png and /dev/null differ
diff --git a/media/articles/email/providers/mandrill-key.png b/media/articles/email/providers/mandrill-key.png
deleted file mode 100644
index 05b38a6f9c..0000000000
Binary files a/media/articles/email/providers/mandrill-key.png and /dev/null differ
diff --git a/media/articles/email/providers/mandrill-keygen.png b/media/articles/email/providers/mandrill-keygen.png
deleted file mode 100644
index 4d82feffda..0000000000
Binary files a/media/articles/email/providers/mandrill-keygen.png and /dev/null differ
diff --git a/media/articles/email/providers/sendgrid-dashboard.png b/media/articles/email/providers/sendgrid-dashboard.png
deleted file mode 100644
index 0251f47e4f..0000000000
Binary files a/media/articles/email/providers/sendgrid-dashboard.png and /dev/null differ
diff --git a/media/articles/email/providers/sendgrid-key.png b/media/articles/email/providers/sendgrid-key.png
deleted file mode 100644
index 62de0ffa68..0000000000
Binary files a/media/articles/email/providers/sendgrid-key.png and /dev/null differ
diff --git a/media/articles/email/providers/sendgrid-permissions.png b/media/articles/email/providers/sendgrid-permissions.png
deleted file mode 100644
index 5a67066bdd..0000000000
Binary files a/media/articles/email/providers/sendgrid-permissions.png and /dev/null differ
diff --git a/media/articles/email/providers/sendgrid-test.png b/media/articles/email/providers/sendgrid-test.png
deleted file mode 100644
index e5eb933abe..0000000000
Binary files a/media/articles/email/providers/sendgrid-test.png and /dev/null differ
diff --git a/media/articles/email/providers/ses-smtp.png b/media/articles/email/providers/ses-smtp.png
deleted file mode 100644
index 3459485bd9..0000000000
Binary files a/media/articles/email/providers/ses-smtp.png and /dev/null differ
diff --git a/media/articles/email/providers/ses-verify.png b/media/articles/email/providers/ses-verify.png
deleted file mode 100644
index 08285c556c..0000000000
Binary files a/media/articles/email/providers/ses-verify.png and /dev/null differ
diff --git a/media/articles/email/providers/sparkpost-api-key-creation.png b/media/articles/email/providers/sparkpost-api-key-creation.png
deleted file mode 100644
index fc51a36460..0000000000
Binary files a/media/articles/email/providers/sparkpost-api-key-creation.png and /dev/null differ
diff --git a/media/articles/email/providers/sparkpost-message-events.png b/media/articles/email/providers/sparkpost-message-events.png
deleted file mode 100644
index 71ab139b3e..0000000000
Binary files a/media/articles/email/providers/sparkpost-message-events.png and /dev/null differ
diff --git a/media/articles/email/providers/sparkpost-set-key.png b/media/articles/email/providers/sparkpost-set-key.png
deleted file mode 100644
index c4503b2fc4..0000000000
Binary files a/media/articles/email/providers/sparkpost-set-key.png and /dev/null differ
diff --git a/media/articles/email/providers/token-generator.png b/media/articles/email/providers/token-generator.png
deleted file mode 100644
index 3a856290ea..0000000000
Binary files a/media/articles/email/providers/token-generator.png and /dev/null differ
diff --git a/media/articles/errors/depnotes-legacy-lock-context-data.png b/media/articles/errors/depnotes-legacy-lock-context-data.png
deleted file mode 100755
index 375fee53b0..0000000000
Binary files a/media/articles/errors/depnotes-legacy-lock-context-data.png and /dev/null differ
diff --git a/media/articles/errors/depnotes-logs.png b/media/articles/errors/depnotes-logs.png
deleted file mode 100755
index b77cb3ad23..0000000000
Binary files a/media/articles/errors/depnotes-logs.png and /dev/null differ
diff --git a/media/articles/errors/depnotes-mgt-api-ssodata.png b/media/articles/errors/depnotes-mgt-api-ssodata.png
deleted file mode 100755
index 2d18544703..0000000000
Binary files a/media/articles/errors/depnotes-mgt-api-ssodata.png and /dev/null differ
diff --git a/media/articles/errors/libraries/management-api-logs.png b/media/articles/errors/libraries/management-api-logs.png
deleted file mode 100755
index 40220f3c63..0000000000
Binary files a/media/articles/errors/libraries/management-api-logs.png and /dev/null differ
diff --git a/media/articles/errors/libraries/management-api-set-token.png b/media/articles/errors/libraries/management-api-set-token.png
deleted file mode 100755
index c89aa498df..0000000000
Binary files a/media/articles/errors/libraries/management-api-set-token.png and /dev/null differ
diff --git a/media/articles/extensions/account-link/account-linking-extension.png b/media/articles/extensions/account-link/account-linking-extension.png
new file mode 100644
index 0000000000..3b59122ac8
Binary files /dev/null and b/media/articles/extensions/account-link/account-linking-extension.png differ
diff --git a/media/articles/extensions/appinsights/appinsights-properties.png b/media/articles/extensions/appinsights/appinsights-properties.png
deleted file mode 100755
index 856b26df26..0000000000
Binary files a/media/articles/extensions/appinsights/appinsights-properties.png and /dev/null differ
diff --git a/media/articles/extensions/appinsights/conf-appinsights.png b/media/articles/extensions/appinsights/conf-appinsights.png
deleted file mode 100755
index 19d89ba87b..0000000000
Binary files a/media/articles/extensions/appinsights/conf-appinsights.png and /dev/null differ
diff --git a/media/articles/extensions/appinsights/ext-mgmt-appinsights.png b/media/articles/extensions/appinsights/ext-mgmt-appinsights.png
deleted file mode 100755
index d25f626ca1..0000000000
Binary files a/media/articles/extensions/appinsights/ext-mgmt-appinsights.png and /dev/null differ
diff --git a/media/articles/extensions/appinsights/new-appinsights.png b/media/articles/extensions/appinsights/new-appinsights.png
deleted file mode 100755
index 448c0e12d9..0000000000
Binary files a/media/articles/extensions/appinsights/new-appinsights.png and /dev/null differ
diff --git a/media/articles/extensions/appinsights/view-cron-details.png b/media/articles/extensions/appinsights/view-cron-details.png
deleted file mode 100755
index 93dbc970be..0000000000
Binary files a/media/articles/extensions/appinsights/view-cron-details.png and /dev/null differ
diff --git a/media/articles/extensions/appinsights/view-cron-jobs.png b/media/articles/extensions/appinsights/view-cron-jobs.png
deleted file mode 100755
index 789c937d1b..0000000000
Binary files a/media/articles/extensions/appinsights/view-cron-jobs.png and /dev/null differ
diff --git a/media/articles/extensions/authorization/apikey-config.png b/media/articles/extensions/authorization/apikey-config.png
new file mode 100644
index 0000000000..b74f74bb66
Binary files /dev/null and b/media/articles/extensions/authorization/apikey-config.png differ
diff --git a/media/articles/extensions/bitbucket-deploy/encryption.png b/media/articles/extensions/bitbucket-deploy/encryption.png
new file mode 100644
index 0000000000..5ff8374465
Binary files /dev/null and b/media/articles/extensions/bitbucket-deploy/encryption.png differ
diff --git a/media/articles/extensions/custom-social-connections.png b/media/articles/extensions/custom-social-connections.png
deleted file mode 100644
index 9ab1c1f20d..0000000000
Binary files a/media/articles/extensions/custom-social-connections.png and /dev/null differ
diff --git a/media/articles/extensions/delegated-admin/dashboard-configuration.png b/media/articles/extensions/delegated-admin/dashboard-configuration.png
deleted file mode 100755
index af05198b61..0000000000
Binary files a/media/articles/extensions/delegated-admin/dashboard-configuration.png and /dev/null differ
diff --git a/media/articles/extensions/delegated-admin/install-extension.png b/media/articles/extensions/delegated-admin/install-extension.png
old mode 100755
new mode 100644
index 33e45b43d2..6da8ed99e2
Binary files a/media/articles/extensions/delegated-admin/install-extension.png and b/media/articles/extensions/delegated-admin/install-extension.png differ
diff --git a/media/articles/extensions/deploy-cli/deploy-cli-app-list.png b/media/articles/extensions/deploy-cli/deploy-cli-app-list.png
new file mode 100644
index 0000000000..2417ab0b7d
Binary files /dev/null and b/media/articles/extensions/deploy-cli/deploy-cli-app-list.png differ
diff --git a/media/articles/extensions/deploy-cli/deploy-cli-enable-permissions.png b/media/articles/extensions/deploy-cli/deploy-cli-enable-permissions.png
new file mode 100644
index 0000000000..50ced29550
Binary files /dev/null and b/media/articles/extensions/deploy-cli/deploy-cli-enable-permissions.png differ
diff --git a/media/articles/extensions/deploy-cli/deploy-cli-find-extension.png b/media/articles/extensions/deploy-cli/deploy-cli-find-extension.png
new file mode 100644
index 0000000000..32ae30db9e
Binary files /dev/null and b/media/articles/extensions/deploy-cli/deploy-cli-find-extension.png differ
diff --git a/media/articles/extensions/deploy-cli/deploy-cli-install-extension.png b/media/articles/extensions/deploy-cli/deploy-cli-install-extension.png
new file mode 100644
index 0000000000..f16b4dbe21
Binary files /dev/null and b/media/articles/extensions/deploy-cli/deploy-cli-install-extension.png differ
diff --git a/media/articles/extensions/deploy-extensions/excluded-rules.png b/media/articles/extensions/deploy-extensions/excluded-rules.png
new file mode 100644
index 0000000000..5be4349019
Binary files /dev/null and b/media/articles/extensions/deploy-extensions/excluded-rules.png differ
diff --git a/media/articles/extensions/deploy-extensions/mappings.png b/media/articles/extensions/deploy-extensions/mappings.png
new file mode 100644
index 0000000000..87af9b8801
Binary files /dev/null and b/media/articles/extensions/deploy-extensions/mappings.png differ
diff --git a/media/articles/extensions/extend-extensions.svg b/media/articles/extensions/extend-extensions.svg
new file mode 100644
index 0000000000..b7b42c3af9
--- /dev/null
+++ b/media/articles/extensions/extend-extensions.svg
@@ -0,0 +1,102 @@
+
+
+    
+    Extensions
+    Created with Sketch.
+    
+        
+    
+    
+        
+            
+                
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                
+                
+                    1
+                
+                
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/extensions/github-deploy/encryption.png b/media/articles/extensions/github-deploy/encryption.png
new file mode 100644
index 0000000000..5ff8374465
Binary files /dev/null and b/media/articles/extensions/github-deploy/encryption.png differ
diff --git a/media/articles/extensions/gitlab-deploy/encryption.png b/media/articles/extensions/gitlab-deploy/encryption.png
new file mode 100644
index 0000000000..5ff8374465
Binary files /dev/null and b/media/articles/extensions/gitlab-deploy/encryption.png differ
diff --git a/media/articles/extensions/gitlab-deploy/gitlab-add-webhook.png b/media/articles/extensions/gitlab-deploy/gitlab-add-webhook.png
old mode 100755
new mode 100644
index 54b688336c..137d4853f6
Binary files a/media/articles/extensions/gitlab-deploy/gitlab-add-webhook.png and b/media/articles/extensions/gitlab-deploy/gitlab-add-webhook.png differ
diff --git a/media/articles/extensions/gitlab-deploy/gitlab-settings-menu.png b/media/articles/extensions/gitlab-deploy/gitlab-settings-menu.png
old mode 100755
new mode 100644
index 226531248b..99dc4f1ede
Binary files a/media/articles/extensions/gitlab-deploy/gitlab-settings-menu.png and b/media/articles/extensions/gitlab-deploy/gitlab-settings-menu.png differ
diff --git a/media/articles/extensions/gitlab-deploy/install-extension.png b/media/articles/extensions/gitlab-deploy/install-extension.png
old mode 100755
new mode 100644
index 6ed6fe0e34..48419ac379
Binary files a/media/articles/extensions/gitlab-deploy/install-extension.png and b/media/articles/extensions/gitlab-deploy/install-extension.png differ
diff --git a/media/articles/extensions/gitlab-deploy/new-access-token.png b/media/articles/extensions/gitlab-deploy/new-access-token.png
old mode 100755
new mode 100644
index 062320068b..d1406d5b83
Binary files a/media/articles/extensions/gitlab-deploy/new-access-token.png and b/media/articles/extensions/gitlab-deploy/new-access-token.png differ
diff --git a/media/articles/extensions/installed-custom-social-extension.png b/media/articles/extensions/installed-custom-social-extension.png
deleted file mode 100644
index a46de729f4..0000000000
Binary files a/media/articles/extensions/installed-custom-social-extension.png and /dev/null differ
diff --git a/media/articles/extensions/installed-management-api-webhook-extension.png b/media/articles/extensions/installed-management-api-webhook-extension.png
deleted file mode 100644
index b32b8c3605..0000000000
Binary files a/media/articles/extensions/installed-management-api-webhook-extension.png and /dev/null differ
diff --git a/media/articles/extensions/installing-custom-social-connections.png b/media/articles/extensions/installing-custom-social-connections.png
deleted file mode 100755
index 70cec450ae..0000000000
Binary files a/media/articles/extensions/installing-custom-social-connections.png and /dev/null differ
diff --git a/media/articles/extensions/new-custom-social-connection.png b/media/articles/extensions/new-custom-social-connection.png
deleted file mode 100755
index 5f23785a4e..0000000000
Binary files a/media/articles/extensions/new-custom-social-connection.png and /dev/null differ
diff --git a/media/articles/extensions/papertrail/auth0-logs-at-papertrail-01.png b/media/articles/extensions/papertrail/auth0-logs-at-papertrail-01.png
deleted file mode 100755
index b1875ad3bf..0000000000
Binary files a/media/articles/extensions/papertrail/auth0-logs-at-papertrail-01.png and /dev/null differ
diff --git a/media/articles/extensions/papertrail/auth0-logs-at-papertrail-02.png b/media/articles/extensions/papertrail/auth0-logs-at-papertrail-02.png
deleted file mode 100755
index ea02ffd4b2..0000000000
Binary files a/media/articles/extensions/papertrail/auth0-logs-at-papertrail-02.png and /dev/null differ
diff --git a/media/articles/extensions/papertrail/papertrail-existing-system.png b/media/articles/extensions/papertrail/papertrail-existing-system.png
deleted file mode 100755
index b657c19b2c..0000000000
Binary files a/media/articles/extensions/papertrail/papertrail-existing-system.png and /dev/null differ
diff --git a/media/articles/extensions/papertrail/papertrail-new-system-01.png b/media/articles/extensions/papertrail/papertrail-new-system-01.png
deleted file mode 100755
index 9315a92b6c..0000000000
Binary files a/media/articles/extensions/papertrail/papertrail-new-system-01.png and /dev/null differ
diff --git a/media/articles/extensions/papertrail/papertrail-new-system-02.png b/media/articles/extensions/papertrail/papertrail-new-system-02.png
deleted file mode 100755
index 848fced3da..0000000000
Binary files a/media/articles/extensions/papertrail/papertrail-new-system-02.png and /dev/null differ
diff --git a/media/articles/extensions/sso-dashboard/change-settings.png b/media/articles/extensions/sso-dashboard/change-settings.png
index 1995ee1348..161c87de61 100644
Binary files a/media/articles/extensions/sso-dashboard/change-settings.png and b/media/articles/extensions/sso-dashboard/change-settings.png differ
diff --git a/media/articles/extensions/sso-dashboard/new-app.png b/media/articles/extensions/sso-dashboard/new-app.png
index 69b532121f..7f7a8a5b7e 100644
Binary files a/media/articles/extensions/sso-dashboard/new-app.png and b/media/articles/extensions/sso-dashboard/new-app.png differ
diff --git a/media/articles/extensions/user-import-export/export-users.png b/media/articles/extensions/user-import-export/export-users.png
index 40ad7d7e35..c5252f8006 100644
Binary files a/media/articles/extensions/user-import-export/export-users.png and b/media/articles/extensions/user-import-export/export-users.png differ
diff --git a/media/articles/extensions/visual-studio-ts/encryption.png b/media/articles/extensions/visual-studio-ts/encryption.png
new file mode 100644
index 0000000000..5ff8374465
Binary files /dev/null and b/media/articles/extensions/visual-studio-ts/encryption.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-auth-code-pkce.png b/media/articles/flows/concepts/auth-sequence-auth-code-pkce.png
new file mode 100644
index 0000000000..64aa96774c
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-auth-code-pkce.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-auth-code.png b/media/articles/flows/concepts/auth-sequence-auth-code.png
new file mode 100755
index 0000000000..23e9997f28
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-auth-code.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-client-credentials.png b/media/articles/flows/concepts/auth-sequence-client-credentials.png
new file mode 100644
index 0000000000..78d5e76368
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-client-credentials.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-device-auth.png b/media/articles/flows/concepts/auth-sequence-device-auth.png
new file mode 100644
index 0000000000..5a3dff1c3a
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-device-auth.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-hybrid.png b/media/articles/flows/concepts/auth-sequence-hybrid.png
new file mode 100755
index 0000000000..577d17481b
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-hybrid.png differ
diff --git a/media/articles/flows/concepts/auth-sequence-implicit-form-post.png b/media/articles/flows/concepts/auth-sequence-implicit-form-post.png
new file mode 100644
index 0000000000..5ac3e3a1dc
Binary files /dev/null and b/media/articles/flows/concepts/auth-sequence-implicit-form-post.png differ
diff --git a/media/articles/flows/concepts/device-browser-flow.png b/media/articles/flows/concepts/device-browser-flow.png
new file mode 100644
index 0000000000..8b2a48f19c
Binary files /dev/null and b/media/articles/flows/concepts/device-browser-flow.png differ
diff --git a/media/articles/flows/concepts/device.png b/media/articles/flows/concepts/device.png
new file mode 100644
index 0000000000..7a299230e0
Binary files /dev/null and b/media/articles/flows/concepts/device.png differ
diff --git a/media/articles/flows/guides/device-auth/confirm-device.png b/media/articles/flows/guides/device-auth/confirm-device.png
new file mode 100755
index 0000000000..aef4845ed7
Binary files /dev/null and b/media/articles/flows/guides/device-auth/confirm-device.png differ
diff --git a/media/articles/flows/guides/device-auth/enter-user-code.png b/media/articles/flows/guides/device-auth/enter-user-code.png
new file mode 100755
index 0000000000..96e2b06513
Binary files /dev/null and b/media/articles/flows/guides/device-auth/enter-user-code.png differ
diff --git a/media/articles/flows/guides/device-auth/request-device-activation.png b/media/articles/flows/guides/device-auth/request-device-activation.png
new file mode 100755
index 0000000000..13b699ab62
Binary files /dev/null and b/media/articles/flows/guides/device-auth/request-device-activation.png differ
diff --git a/media/articles/flows/guides/device-auth/user-auth.png b/media/articles/flows/guides/device-auth/user-auth.png
new file mode 100755
index 0000000000..d616c03295
Binary files /dev/null and b/media/articles/flows/guides/device-auth/user-auth.png differ
diff --git a/media/articles/flows/guides/device-auth/user-confirmation.png b/media/articles/flows/guides/device-auth/user-confirmation.png
new file mode 100755
index 0000000000..2602e848fe
Binary files /dev/null and b/media/articles/flows/guides/device-auth/user-confirmation.png differ
diff --git a/media/articles/getting-started/auth0-dashboard.png b/media/articles/getting-started/auth0-dashboard.png
index d6c451bd6f..d9fa504a66 100644
Binary files a/media/articles/getting-started/auth0-dashboard.png and b/media/articles/getting-started/auth0-dashboard.png differ
diff --git a/media/articles/getting-started/client-types.png b/media/articles/getting-started/client-types.png
index 9278b3b951..be03becef8 100644
Binary files a/media/articles/getting-started/client-types.png and b/media/articles/getting-started/client-types.png differ
diff --git a/media/articles/getting-started/overview.png b/media/articles/getting-started/overview.png
deleted file mode 100755
index dde3732450..0000000000
Binary files a/media/articles/getting-started/overview.png and /dev/null differ
diff --git a/media/articles/hooks/extend-hooks.svg b/media/articles/hooks/extend-hooks.svg
new file mode 100644
index 0000000000..3ba61e8ace
--- /dev/null
+++ b/media/articles/hooks/extend-hooks.svg
@@ -0,0 +1,104 @@
+
+
+    
+    Hooks
+    Created with Sketch.
+    
+    
+        
+            
+                
+                    
+                        
+                        
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                            
+                            
+                        
+                        
+                            
+                            
+                        
+                        
+                        
+                            
+                            
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                            
+                            
+                        
+                        
+                        
+                        
+                        
+                    
+                
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/hosted-pages/consent-dialog.png b/media/articles/hosted-pages/consent-dialog.png
index 782d88e26b..71a2a7fba2 100644
Binary files a/media/articles/hosted-pages/consent-dialog.png and b/media/articles/hosted-pages/consent-dialog.png differ
diff --git a/media/articles/hosted-pages/create-new-tenant.png b/media/articles/hosted-pages/create-new-tenant.png
index 50f692349a..d3b81524db 100644
Binary files a/media/articles/hosted-pages/create-new-tenant.png and b/media/articles/hosted-pages/create-new-tenant.png differ
diff --git a/media/articles/hosted-pages/hlp-lock-passwordless.png b/media/articles/hosted-pages/hlp-lock-passwordless.png
old mode 100755
new mode 100644
index 54efc4802e..819fa72761
Binary files a/media/articles/hosted-pages/hlp-lock-passwordless.png and b/media/articles/hosted-pages/hlp-lock-passwordless.png differ
diff --git a/media/articles/identity-labs/lab-01-callback-url-config.png b/media/articles/identity-labs/lab-01-callback-url-config.png
new file mode 100644
index 0000000000..ed2f896d16
Binary files /dev/null and b/media/articles/identity-labs/lab-01-callback-url-config.png differ
diff --git a/media/articles/identity-labs/lab-01-id-token-in-jwt-io.png b/media/articles/identity-labs/lab-01-id-token-in-jwt-io.png
new file mode 100644
index 0000000000..33801eacc6
Binary files /dev/null and b/media/articles/identity-labs/lab-01-id-token-in-jwt-io.png differ
diff --git a/media/articles/identity-labs/lab-01-logout-url-config.png b/media/articles/identity-labs/lab-01-logout-url-config.png
new file mode 100644
index 0000000000..3957f193e4
Binary files /dev/null and b/media/articles/identity-labs/lab-01-logout-url-config.png differ
diff --git a/media/articles/identity-labs/lab-01-network-trace-01.png b/media/articles/identity-labs/lab-01-network-trace-01.png
new file mode 100644
index 0000000000..081a180815
Binary files /dev/null and b/media/articles/identity-labs/lab-01-network-trace-01.png differ
diff --git a/media/articles/identity-labs/lab-01-network-trace-02.png b/media/articles/identity-labs/lab-01-network-trace-02.png
new file mode 100644
index 0000000000..b6ac2cee36
Binary files /dev/null and b/media/articles/identity-labs/lab-01-network-trace-02.png differ
diff --git a/media/articles/identity-labs/lab-01-network-trace-03.png b/media/articles/identity-labs/lab-01-network-trace-03.png
new file mode 100644
index 0000000000..cfe37e8b5b
Binary files /dev/null and b/media/articles/identity-labs/lab-01-network-trace-03.png differ
diff --git a/media/articles/identity-labs/lab-01-network-trace-04.png b/media/articles/identity-labs/lab-01-network-trace-04.png
new file mode 100644
index 0000000000..3f190b51cb
Binary files /dev/null and b/media/articles/identity-labs/lab-01-network-trace-04.png differ
diff --git a/media/articles/identity-labs/lab-01-starter-app-rendered.png b/media/articles/identity-labs/lab-01-starter-app-rendered.png
new file mode 100644
index 0000000000..8bfeea9368
Binary files /dev/null and b/media/articles/identity-labs/lab-01-starter-app-rendered.png differ
diff --git a/media/articles/identity-labs/lab-02-api-allow-offline.png b/media/articles/identity-labs/lab-02-api-allow-offline.png
new file mode 100644
index 0000000000..f30faa2147
Binary files /dev/null and b/media/articles/identity-labs/lab-02-api-allow-offline.png differ
diff --git a/media/articles/identity-labs/lab-02-api-consent-initial.png b/media/articles/identity-labs/lab-02-api-consent-initial.png
new file mode 100644
index 0000000000..51039d6254
Binary files /dev/null and b/media/articles/identity-labs/lab-02-api-consent-initial.png differ
diff --git a/media/articles/identity-labs/lab-02-api-token-expiration.png b/media/articles/identity-labs/lab-02-api-token-expiration.png
new file mode 100644
index 0000000000..afcbc92849
Binary files /dev/null and b/media/articles/identity-labs/lab-02-api-token-expiration.png differ
diff --git a/media/articles/identity-labs/lab-02-client-secret-config.png b/media/articles/identity-labs/lab-02-client-secret-config.png
new file mode 100644
index 0000000000..85d23293ae
Binary files /dev/null and b/media/articles/identity-labs/lab-02-client-secret-config.png differ
diff --git a/media/articles/identity-labs/lab-02-starter-app-rendered.png b/media/articles/identity-labs/lab-02-starter-app-rendered.png
new file mode 100644
index 0000000000..5bbff67fa7
Binary files /dev/null and b/media/articles/identity-labs/lab-02-starter-app-rendered.png differ
diff --git a/media/articles/identity-labs/lab-03-access-token-audience.png b/media/articles/identity-labs/lab-03-access-token-audience.png
new file mode 100644
index 0000000000..a8a86b1374
Binary files /dev/null and b/media/articles/identity-labs/lab-03-access-token-audience.png differ
diff --git a/media/articles/identity-labs/lab-03-allow-offline-access.png b/media/articles/identity-labs/lab-03-allow-offline-access.png
new file mode 100644
index 0000000000..7e56df0f20
Binary files /dev/null and b/media/articles/identity-labs/lab-03-allow-offline-access.png differ
diff --git a/media/articles/identity-labs/lab-03-call-api-button.png b/media/articles/identity-labs/lab-03-call-api-button.png
new file mode 100644
index 0000000000..ebb6da7890
Binary files /dev/null and b/media/articles/identity-labs/lab-03-call-api-button.png differ
diff --git a/media/articles/identity-labs/lab-03-call-api-debug-area.png b/media/articles/identity-labs/lab-03-call-api-debug-area.png
new file mode 100644
index 0000000000..8e6dfacea1
Binary files /dev/null and b/media/articles/identity-labs/lab-03-call-api-debug-area.png differ
diff --git a/media/articles/identity-labs/lab-03-choose-device-and-run.png b/media/articles/identity-labs/lab-03-choose-device-and-run.png
new file mode 100644
index 0000000000..dd7323769e
Binary files /dev/null and b/media/articles/identity-labs/lab-03-choose-device-and-run.png differ
diff --git a/media/articles/identity-labs/lab-03-first-debug-area.png b/media/articles/identity-labs/lab-03-first-debug-area.png
new file mode 100644
index 0000000000..15dc9f9956
Binary files /dev/null and b/media/articles/identity-labs/lab-03-first-debug-area.png differ
diff --git a/media/articles/identity-labs/lab-03-first-run.png b/media/articles/identity-labs/lab-03-first-run.png
new file mode 100644
index 0000000000..5faf9200e4
Binary files /dev/null and b/media/articles/identity-labs/lab-03-first-run.png differ
diff --git a/media/articles/identity-labs/lab-03-login-confirmation.png b/media/articles/identity-labs/lab-03-login-confirmation.png
new file mode 100644
index 0000000000..8120e2f096
Binary files /dev/null and b/media/articles/identity-labs/lab-03-login-confirmation.png differ
diff --git a/media/articles/identity-labs/lab-03-plist.png b/media/articles/identity-labs/lab-03-plist.png
new file mode 100644
index 0000000000..c245b116fe
Binary files /dev/null and b/media/articles/identity-labs/lab-03-plist.png differ
diff --git a/media/articles/identity-labs/lab-03-project-settings-info-tab.png b/media/articles/identity-labs/lab-03-project-settings-info-tab.png
new file mode 100644
index 0000000000..7c664fcbb8
Binary files /dev/null and b/media/articles/identity-labs/lab-03-project-settings-info-tab.png differ
diff --git a/media/articles/identity-labs/lab-03-refresh-token-button.png b/media/articles/identity-labs/lab-03-refresh-token-button.png
new file mode 100644
index 0000000000..ea86fdebc5
Binary files /dev/null and b/media/articles/identity-labs/lab-03-refresh-token-button.png differ
diff --git a/media/articles/identity-labs/lab-04-consent-link-showing.png b/media/articles/identity-labs/lab-04-consent-link-showing.png
new file mode 100644
index 0000000000..b09002bea6
Binary files /dev/null and b/media/articles/identity-labs/lab-04-consent-link-showing.png differ
diff --git a/media/articles/identity-labs/lab-04-consent-prompt.png b/media/articles/identity-labs/lab-04-consent-prompt.png
new file mode 100644
index 0000000000..44dc6c780c
Binary files /dev/null and b/media/articles/identity-labs/lab-04-consent-prompt.png differ
diff --git a/media/articles/identity-labs/lab-04-expenses-data-showing.png b/media/articles/identity-labs/lab-04-expenses-data-showing.png
new file mode 100644
index 0000000000..f806335273
Binary files /dev/null and b/media/articles/identity-labs/lab-04-expenses-data-showing.png differ
diff --git a/media/articles/identity-labs/lab-04-expenses-link-showing.png b/media/articles/identity-labs/lab-04-expenses-link-showing.png
new file mode 100644
index 0000000000..e90cb0a29f
Binary files /dev/null and b/media/articles/identity-labs/lab-04-expenses-link-showing.png differ
diff --git a/media/articles/identity-labs/lab-04-initial-load.png b/media/articles/identity-labs/lab-04-initial-load.png
new file mode 100644
index 0000000000..2f42afaaf6
Binary files /dev/null and b/media/articles/identity-labs/lab-04-initial-load.png differ
diff --git a/media/articles/identity-labs/lab-04-login-button-showing.png b/media/articles/identity-labs/lab-04-login-button-showing.png
new file mode 100644
index 0000000000..58b7a6ed99
Binary files /dev/null and b/media/articles/identity-labs/lab-04-login-button-showing.png differ
diff --git a/media/articles/identity-labs/lab-04-login-complete.png b/media/articles/identity-labs/lab-04-login-complete.png
new file mode 100644
index 0000000000..6ca44c708d
Binary files /dev/null and b/media/articles/identity-labs/lab-04-login-complete.png differ
diff --git a/media/articles/identity-labs/lab-04-revoke-app.png b/media/articles/identity-labs/lab-04-revoke-app.png
new file mode 100644
index 0000000000..6d19d4f21f
Binary files /dev/null and b/media/articles/identity-labs/lab-04-revoke-app.png differ
diff --git a/media/articles/identity-labs/lab-04-silent-auth-request.png b/media/articles/identity-labs/lab-04-silent-auth-request.png
new file mode 100644
index 0000000000..53298c7a13
Binary files /dev/null and b/media/articles/identity-labs/lab-04-silent-auth-request.png differ
diff --git a/media/articles/identity-labs/lab-04-token-ep-post.png b/media/articles/identity-labs/lab-04-token-ep-post.png
new file mode 100644
index 0000000000..be6651d790
Binary files /dev/null and b/media/articles/identity-labs/lab-04-token-ep-post.png differ
diff --git a/media/articles/identity-labs/lab-04-token-ep-response.png b/media/articles/identity-labs/lab-04-token-ep-response.png
new file mode 100644
index 0000000000..02b05e3ee1
Binary files /dev/null and b/media/articles/identity-labs/lab-04-token-ep-response.png differ
diff --git a/media/articles/integrations/aws/addons.png b/media/articles/integrations/aws/addons.png
deleted file mode 100644
index 62a9e7a474..0000000000
Binary files a/media/articles/integrations/aws/addons.png and /dev/null differ
diff --git a/media/articles/integrations/aws/aws-configure-provider.png b/media/articles/integrations/aws/aws-configure-provider.png
deleted file mode 100644
index 36b9d0f557..0000000000
Binary files a/media/articles/integrations/aws/aws-configure-provider.png and /dev/null differ
diff --git a/media/articles/integrations/aws/aws-iam-configure-provider.png b/media/articles/integrations/aws/aws-iam-configure-provider.png
new file mode 100644
index 0000000000..1f1b4919a0
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-configure-provider.png differ
diff --git a/media/articles/integrations/aws/aws-iam-create-role-policies.png b/media/articles/integrations/aws/aws-iam-create-role-policies.png
new file mode 100644
index 0000000000..38120e1637
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-create-role-policies.png differ
diff --git a/media/articles/integrations/aws/aws-iam-create-role-review.png b/media/articles/integrations/aws/aws-iam-create-role-review.png
new file mode 100644
index 0000000000..5db70a1032
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-create-role-review.png differ
diff --git a/media/articles/integrations/aws/aws-iam-create-role-tags.png b/media/articles/integrations/aws/aws-iam-create-role-tags.png
new file mode 100644
index 0000000000..a7fcda9883
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-create-role-tags.png differ
diff --git a/media/articles/integrations/aws/aws-iam-create-role.png b/media/articles/integrations/aws/aws-iam-create-role.png
new file mode 100644
index 0000000000..975eb10cde
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-create-role.png differ
diff --git a/media/articles/integrations/aws/aws-iam-identity-providers.png b/media/articles/integrations/aws/aws-iam-identity-providers.png
new file mode 100644
index 0000000000..607849e252
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-identity-providers.png differ
diff --git a/media/articles/integrations/aws/aws-iam-roles.png b/media/articles/integrations/aws/aws-iam-roles.png
new file mode 100644
index 0000000000..332c458b73
Binary files /dev/null and b/media/articles/integrations/aws/aws-iam-roles.png differ
diff --git a/media/articles/integrations/aws/create-provider-confirm.png b/media/articles/integrations/aws/create-provider-confirm.png
deleted file mode 100644
index 56a142dab4..0000000000
Binary files a/media/articles/integrations/aws/create-provider-confirm.png and /dev/null differ
diff --git a/media/articles/integrations/aws/create-provider.png b/media/articles/integrations/aws/create-provider.png
deleted file mode 100644
index e7182207b7..0000000000
Binary files a/media/articles/integrations/aws/create-provider.png and /dev/null differ
diff --git a/media/articles/integrations/aws/iam-new-role.png b/media/articles/integrations/aws/iam-new-role.png
deleted file mode 100644
index 218aa9b508..0000000000
Binary files a/media/articles/integrations/aws/iam-new-role.png and /dev/null differ
diff --git a/media/articles/integrations/aws/iam-review-role.png b/media/articles/integrations/aws/iam-review-role.png
deleted file mode 100644
index b42d60a9b4..0000000000
Binary files a/media/articles/integrations/aws/iam-review-role.png and /dev/null differ
diff --git a/media/articles/integrations/aws/select-role-type.png b/media/articles/integrations/aws/select-role-type.png
deleted file mode 100644
index 0b13d31616..0000000000
Binary files a/media/articles/integrations/aws/select-role-type.png and /dev/null differ
diff --git a/media/articles/integrations/aws/select-saml-provider-to-trust.png b/media/articles/integrations/aws/select-saml-provider-to-trust.png
deleted file mode 100644
index 9a8a07b054..0000000000
Binary files a/media/articles/integrations/aws/select-saml-provider-to-trust.png and /dev/null differ
diff --git a/media/articles/integrations/marketing/import-export-fields.png b/media/articles/integrations/marketing/import-export-fields.png
old mode 100755
new mode 100644
index f5201ba66e..8675651a86
Binary files a/media/articles/integrations/marketing/import-export-fields.png and b/media/articles/integrations/marketing/import-export-fields.png differ
diff --git a/media/articles/integrations/marketing/import-export-set-format.png b/media/articles/integrations/marketing/import-export-set-format.png
old mode 100755
new mode 100644
index 47f3506304..e5bf75ae14
Binary files a/media/articles/integrations/marketing/import-export-set-format.png and b/media/articles/integrations/marketing/import-export-set-format.png differ
diff --git a/media/articles/ios/swift/add-capability.png b/media/articles/ios/swift/add-capability.png
new file mode 100644
index 0000000000..aef68e4605
Binary files /dev/null and b/media/articles/ios/swift/add-capability.png differ
diff --git a/media/articles/ios/swift/authz-dialog.png b/media/articles/ios/swift/authz-dialog.png
new file mode 100644
index 0000000000..63e271a770
Binary files /dev/null and b/media/articles/ios/swift/authz-dialog.png differ
diff --git a/media/articles/jwt/client-credentials-grant.png b/media/articles/jwt/client-credentials-grant.png
new file mode 100644
index 0000000000..c3ddf86957
Binary files /dev/null and b/media/articles/jwt/client-credentials-grant.png differ
diff --git a/media/articles/jwt/jwt-diagram.png b/media/articles/jwt/jwt-diagram.png
deleted file mode 100644
index 4cafba7c03..0000000000
Binary files a/media/articles/jwt/jwt-diagram.png and /dev/null differ
diff --git a/media/articles/learn-identity/learn-identity-intro.jpg b/media/articles/learn-identity/learn-identity-intro.jpg
new file mode 100644
index 0000000000..efcf8596ba
Binary files /dev/null and b/media/articles/learn-identity/learn-identity-intro.jpg differ
diff --git a/media/articles/learn-identity/learn-identity-og-image.jpg b/media/articles/learn-identity/learn-identity-og-image.jpg
new file mode 100644
index 0000000000..fddb9e0481
Binary files /dev/null and b/media/articles/learn-identity/learn-identity-og-image.jpg differ
diff --git a/media/articles/libraries/lock/customization/allowForgotPassword.png b/media/articles/libraries/lock/customization/allowForgotPassword.png
deleted file mode 100644
index a33a318560..0000000000
Binary files a/media/articles/libraries/lock/customization/allowForgotPassword.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/closable.png b/media/articles/libraries/lock/customization/closable.png
deleted file mode 100644
index 45df5fdf74..0000000000
Binary files a/media/articles/libraries/lock/customization/closable.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/connections.png b/media/articles/libraries/lock/customization/connections.png
deleted file mode 100644
index 516ce83f56..0000000000
Binary files a/media/articles/libraries/lock/customization/connections.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/container.png b/media/articles/libraries/lock/customization/container.png
deleted file mode 100644
index a87281a125..0000000000
Binary files a/media/articles/libraries/lock/customization/container.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/defaultADUsernameFromEmailPrefix.png b/media/articles/libraries/lock/customization/defaultADUsernameFromEmailPrefix.png
deleted file mode 100644
index 57812be5e5..0000000000
Binary files a/media/articles/libraries/lock/customization/defaultADUsernameFromEmailPrefix.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/dict.png b/media/articles/libraries/lock/customization/dict.png
deleted file mode 100644
index e9ce9c0c72..0000000000
Binary files a/media/articles/libraries/lock/customization/dict.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/disableSignupAction.png b/media/articles/libraries/lock/customization/disableSignupAction.png
deleted file mode 100644
index bece10fd0d..0000000000
Binary files a/media/articles/libraries/lock/customization/disableSignupAction.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/gravatar.png b/media/articles/libraries/lock/customization/gravatar.png
deleted file mode 100644
index 89fcba541e..0000000000
Binary files a/media/articles/libraries/lock/customization/gravatar.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/icon.png b/media/articles/libraries/lock/customization/icon.png
deleted file mode 100644
index bf5aa8f355..0000000000
Binary files a/media/articles/libraries/lock/customization/icon.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/language.png b/media/articles/libraries/lock/customization/language.png
deleted file mode 100644
index 7992cd06ed..0000000000
Binary files a/media/articles/libraries/lock/customization/language.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/languageDictionary.png b/media/articles/libraries/lock/customization/languageDictionary.png
deleted file mode 100644
index 73a9038bc2..0000000000
Binary files a/media/articles/libraries/lock/customization/languageDictionary.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-additionalsignupfields.png b/media/articles/libraries/lock/customization/lock-additionalsignupfields.png
deleted file mode 100755
index 5ee4af4800..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-additionalsignupfields.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-allowedconnections-social.png b/media/articles/libraries/lock/customization/lock-allowedconnections-social.png
deleted file mode 100755
index 79a8b7a3e2..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-allowedconnections-social.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-allowedconnections-usernamepassword.png b/media/articles/libraries/lock/customization/lock-allowedconnections-usernamepassword.png
deleted file mode 100755
index c41b7bd5a0..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-allowedconnections-usernamepassword.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-allowforgotpassword.png b/media/articles/libraries/lock/customization/lock-allowforgotpassword.png
deleted file mode 100755
index 6791c65bf4..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-allowforgotpassword.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-allowlogin.png b/media/articles/libraries/lock/customization/lock-allowlogin.png
deleted file mode 100755
index 36d94c4749..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-allowlogin.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-allowsignup.png b/media/articles/libraries/lock/customization/lock-allowsignup.png
deleted file mode 100755
index e6abed8b40..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-allowsignup.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-avatar.png b/media/articles/libraries/lock/customization/lock-avatar.png
deleted file mode 100755
index 7040e80392..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-avatar.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-closable.png b/media/articles/libraries/lock/customization/lock-closable.png
deleted file mode 100755
index 69dbebf8c7..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-closable.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-container.png b/media/articles/libraries/lock/customization/lock-container.png
deleted file mode 100755
index bb3de9f137..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-container.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-default.png b/media/articles/libraries/lock/customization/lock-default.png
deleted file mode 100755
index 8a48aa6e95..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-default.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-labeledsubmitbutton.png b/media/articles/libraries/lock/customization/lock-labeledsubmitbutton.png
deleted file mode 100755
index 3e5a04490e..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-labeledsubmitbutton.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-language.png b/media/articles/libraries/lock/customization/lock-language.png
deleted file mode 100755
index 06aa39da6d..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-language.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-languagedictionary.png b/media/articles/libraries/lock/customization/lock-languagedictionary.png
deleted file mode 100755
index 5d325fda1b..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-languagedictionary.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-logo.png b/media/articles/libraries/lock/customization/lock-logo.png
deleted file mode 100755
index abe405c1d0..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-logo.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-primarycolor.png b/media/articles/libraries/lock/customization/lock-primarycolor.png
deleted file mode 100755
index 89d6cde574..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-primarycolor.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-default_limited.png b/media/articles/libraries/lock/customization/lock-socialbuttonstyle-default_limited.png
deleted file mode 100755
index 552b911c59..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-default_limited.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_default.png b/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_default.png
deleted file mode 100755
index a20d860bc4..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_default.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_limited.png b/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_limited.png
deleted file mode 100755
index f2ea1ad6be..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-socialbuttonstyle-small_limited.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/lock-usernamestyle.png b/media/articles/libraries/lock/customization/lock-usernamestyle.png
deleted file mode 100644
index 7c0871861e..0000000000
Binary files a/media/articles/libraries/lock/customization/lock-usernamestyle.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/popup.png b/media/articles/libraries/lock/customization/popup.png
deleted file mode 100644
index fc90d3053f..0000000000
Binary files a/media/articles/libraries/lock/customization/popup.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/popupOptions.png b/media/articles/libraries/lock/customization/popupOptions.png
deleted file mode 100644
index 53fcf68355..0000000000
Binary files a/media/articles/libraries/lock/customization/popupOptions.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/rememberLastLogin.png b/media/articles/libraries/lock/customization/rememberLastLogin.png
deleted file mode 100644
index 15b3f5d8eb..0000000000
Binary files a/media/articles/libraries/lock/customization/rememberLastLogin.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/socialBigButtons.png b/media/articles/libraries/lock/customization/socialBigButtons.png
deleted file mode 100644
index 6843f50830..0000000000
Binary files a/media/articles/libraries/lock/customization/socialBigButtons.png and /dev/null differ
diff --git a/media/articles/libraries/lock/customization/usernameStyle.png b/media/articles/libraries/lock/customization/usernameStyle.png
deleted file mode 100644
index d89b83115b..0000000000
Binary files a/media/articles/libraries/lock/customization/usernameStyle.png and /dev/null differ
diff --git a/media/articles/libraries/lock/legacy-lock-api-off.png b/media/articles/libraries/lock/legacy-lock-api-off.png
deleted file mode 100755
index aa73b5110a..0000000000
Binary files a/media/articles/libraries/lock/legacy-lock-api-off.png and /dev/null differ
diff --git a/media/articles/libraries/lock/lock-10.png b/media/articles/libraries/lock/lock-10.png
deleted file mode 100644
index 94492b9e57..0000000000
Binary files a/media/articles/libraries/lock/lock-10.png and /dev/null differ
diff --git a/media/articles/libraries/lock/ui-customization/gradient-theme.png b/media/articles/libraries/lock/ui-customization/gradient-theme.png
deleted file mode 100644
index 67930b0f5e..0000000000
Binary files a/media/articles/libraries/lock/ui-customization/gradient-theme.png and /dev/null differ
diff --git a/media/articles/libraries/lock/ui-customization/lock-add-btn.png b/media/articles/libraries/lock/ui-customization/lock-add-btn.png
deleted file mode 100644
index 9fcec6c4f4..0000000000
Binary files a/media/articles/libraries/lock/ui-customization/lock-add-btn.png and /dev/null differ
diff --git a/media/articles/libraries/lock/ui-customization/reflex-theme.png b/media/articles/libraries/lock/ui-customization/reflex-theme.png
deleted file mode 100644
index 4a76081822..0000000000
Binary files a/media/articles/libraries/lock/ui-customization/reflex-theme.png and /dev/null differ
diff --git a/media/articles/libraries/lock/ui-customization/windows-auth-button.png b/media/articles/libraries/lock/ui-customization/windows-auth-button.png
deleted file mode 100644
index 568a8ac633..0000000000
Binary files a/media/articles/libraries/lock/ui-customization/windows-auth-button.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default-social.png b/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default-social.png
deleted file mode 100755
index 4be83fb7d1..0000000000
Binary files a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default-social.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png b/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png
deleted file mode 100755
index 47e2e7c6c5..0000000000
Binary files a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small-social.png b/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small-social.png
deleted file mode 100755
index 045ad93211..0000000000
Binary files a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small-social.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small.png b/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small.png
deleted file mode 100755
index 3ed8a45d1a..0000000000
Binary files a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-small.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/gif/popup.gif b/media/articles/libraries/lock/v10/gif/popup.gif
deleted file mode 100644
index be76cdd00e..0000000000
Binary files a/media/articles/libraries/lock/v10/gif/popup.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/gif/redirect.gif b/media/articles/libraries/lock/v10/gif/redirect.gif
deleted file mode 100644
index b214a8d719..0000000000
Binary files a/media/articles/libraries/lock/v10/gif/redirect.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/gif/social-popup.gif b/media/articles/libraries/lock/v10/gif/social-popup.gif
deleted file mode 100644
index ce5accfcf1..0000000000
Binary files a/media/articles/libraries/lock/v10/gif/social-popup.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/gif/social-redirect.gif b/media/articles/libraries/lock/v10/gif/social-redirect.gif
deleted file mode 100644
index d409ab57e9..0000000000
Binary files a/media/articles/libraries/lock/v10/gif/social-redirect.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v10/widget-popup.gif b/media/articles/libraries/lock/v10/widget-popup.gif
deleted file mode 100644
index 57f417c170..0000000000
Binary files a/media/articles/libraries/lock/v10/widget-popup.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png b/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png
new file mode 100755
index 0000000000..4296e1d995
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png b/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png
new file mode 100755
index 0000000000..c7a46b54a3
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png b/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png
new file mode 100755
index 0000000000..b517a544e7
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png b/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png
new file mode 100755
index 0000000000..66dd933576
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowlogin.png b/media/articles/libraries/lock/v11/customization/lock-allowlogin.png
new file mode 100755
index 0000000000..0120283937
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowlogin.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png b/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png
new file mode 100755
index 0000000000..e6daa7af49
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-allowsignup.png b/media/articles/libraries/lock/v11/customization/lock-allowsignup.png
new file mode 100755
index 0000000000..bb68cccd38
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-allowsignup.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-avatar.png b/media/articles/libraries/lock/v11/customization/lock-avatar.png
new file mode 100755
index 0000000000..36c90e3d8e
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-avatar.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-closable.png b/media/articles/libraries/lock/v11/customization/lock-closable.png
new file mode 100755
index 0000000000..a3007a49d0
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-closable.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-container.png b/media/articles/libraries/lock/v11/customization/lock-container.png
new file mode 100755
index 0000000000..3dee0c621b
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-container.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-language.png b/media/articles/libraries/lock/v11/customization/lock-language.png
new file mode 100755
index 0000000000..c8c972f4fa
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-language.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png b/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png
new file mode 100755
index 0000000000..10773d00ab
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png b/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png
new file mode 100755
index 0000000000..343b9b477a
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-theme-logo.png b/media/articles/libraries/lock/v11/customization/lock-theme-logo.png
new file mode 100755
index 0000000000..32e2ceabc0
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-theme-logo.png differ
diff --git a/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png b/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png
new file mode 100755
index 0000000000..ffb84fa79f
Binary files /dev/null and b/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png differ
diff --git a/media/articles/libraries/lock/v9/WidgetRedirect.gif b/media/articles/libraries/lock/v9/WidgetRedirect.gif
deleted file mode 100644
index 686b55a374..0000000000
Binary files a/media/articles/libraries/lock/v9/WidgetRedirect.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/custom-error.png b/media/articles/libraries/lock/v9/custom-error.png
deleted file mode 100644
index a8757a62e1..0000000000
Binary files a/media/articles/libraries/lock/v9/custom-error.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/i18n-image.gif b/media/articles/libraries/lock/v9/i18n-image.gif
deleted file mode 100644
index 7cd473ee28..0000000000
Binary files a/media/articles/libraries/lock/v9/i18n-image.gif and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/lock-landing.png b/media/articles/libraries/lock/v9/lock-landing.png
deleted file mode 100644
index 9d836848e0..0000000000
Binary files a/media/articles/libraries/lock/v9/lock-landing.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/lock-signup.png b/media/articles/libraries/lock/v9/lock-signup.png
deleted file mode 100644
index ad8be6d40f..0000000000
Binary files a/media/articles/libraries/lock/v9/lock-signup.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/mode-1.png b/media/articles/libraries/lock/v9/mode-1.png
deleted file mode 100644
index 880d462733..0000000000
Binary files a/media/articles/libraries/lock/v9/mode-1.png and /dev/null differ
diff --git a/media/articles/libraries/lock/v9/mode-2.png b/media/articles/libraries/lock/v9/mode-2.png
deleted file mode 100644
index edfcba2b93..0000000000
Binary files a/media/articles/libraries/lock/v9/mode-2.png and /dev/null differ
diff --git a/media/articles/lifecycle/rules-conf-values.png b/media/articles/lifecycle/rules-conf-values.png
index 66a0560728..a0ef91b32a 100755
Binary files a/media/articles/lifecycle/rules-conf-values.png and b/media/articles/lifecycle/rules-conf-values.png differ
diff --git a/media/articles/lifecycle/rules-create-first.png b/media/articles/lifecycle/rules-create-first.png
new file mode 100644
index 0000000000..3dc1539f83
Binary files /dev/null and b/media/articles/lifecycle/rules-create-first.png differ
diff --git a/media/articles/lifecycle/rules-enter-name.png b/media/articles/lifecycle/rules-enter-name.png
new file mode 100644
index 0000000000..87920fe8b5
Binary files /dev/null and b/media/articles/lifecycle/rules-enter-name.png differ
diff --git a/media/articles/lifecycle/rules-rule-code.png b/media/articles/lifecycle/rules-rule-code.png
new file mode 100644
index 0000000000..1a620a16af
Binary files /dev/null and b/media/articles/lifecycle/rules-rule-code.png differ
diff --git a/media/articles/lifecycle/rules-template-empty.png b/media/articles/lifecycle/rules-template-empty.png
new file mode 100644
index 0000000000..eaeb1ad7fc
Binary files /dev/null and b/media/articles/lifecycle/rules-template-empty.png differ
diff --git a/media/articles/link-accounts/account-linking-spa.png b/media/articles/link-accounts/account-linking-spa.png
new file mode 100644
index 0000000000..712c669076
Binary files /dev/null and b/media/articles/link-accounts/account-linking-spa.png differ
diff --git a/media/articles/link-accounts/account-linking-webapp-small.png b/media/articles/link-accounts/account-linking-webapp-small.png
new file mode 100644
index 0000000000..a871c15d2a
Binary files /dev/null and b/media/articles/link-accounts/account-linking-webapp-small.png differ
diff --git a/media/articles/link-accounts/regular-web-app-initial-login.png b/media/articles/link-accounts/regular-web-app-initial-login.png
deleted file mode 100644
index 404d686e74..0000000000
Binary files a/media/articles/link-accounts/regular-web-app-initial-login.png and /dev/null differ
diff --git a/media/articles/link-accounts/regular-web-app-suggest-linking.png b/media/articles/link-accounts/regular-web-app-suggest-linking.png
deleted file mode 100644
index 7497a0e554..0000000000
Binary files a/media/articles/link-accounts/regular-web-app-suggest-linking.png and /dev/null differ
diff --git a/media/articles/link-accounts/regular-web-app-user-settings.png b/media/articles/link-accounts/regular-web-app-user-settings.png
deleted file mode 100644
index 531821617e..0000000000
Binary files a/media/articles/link-accounts/regular-web-app-user-settings.png and /dev/null differ
diff --git a/media/articles/link-accounts/spa-initial-login.png b/media/articles/link-accounts/spa-initial-login.png
deleted file mode 100755
index a3eda72583..0000000000
Binary files a/media/articles/link-accounts/spa-initial-login.png and /dev/null differ
diff --git a/media/articles/login/spa/image1.png b/media/articles/login/spa/image1.png
new file mode 100644
index 0000000000..6d49ac1c0d
Binary files /dev/null and b/media/articles/login/spa/image1.png differ
diff --git a/media/articles/login/spa/image2.png b/media/articles/login/spa/image2.png
new file mode 100644
index 0000000000..dc71901638
Binary files /dev/null and b/media/articles/login/spa/image2.png differ
diff --git a/media/articles/login/spa/image3.png b/media/articles/login/spa/image3.png
new file mode 100644
index 0000000000..418c344734
Binary files /dev/null and b/media/articles/login/spa/image3.png differ
diff --git a/media/articles/login/spa/image4.png b/media/articles/login/spa/image4.png
new file mode 100644
index 0000000000..98835f85cf
Binary files /dev/null and b/media/articles/login/spa/image4.png differ
diff --git a/media/articles/login/spa/image5.png b/media/articles/login/spa/image5.png
new file mode 100644
index 0000000000..08e6aaf54e
Binary files /dev/null and b/media/articles/login/spa/image5.png differ
diff --git a/media/articles/login/spa/image6.png b/media/articles/login/spa/image6.png
new file mode 100644
index 0000000000..771c307147
Binary files /dev/null and b/media/articles/login/spa/image6.png differ
diff --git a/media/articles/login/spa/image7.png b/media/articles/login/spa/image7.png
new file mode 100644
index 0000000000..6cbbbed4d0
Binary files /dev/null and b/media/articles/login/spa/image7.png differ
diff --git a/media/articles/login/spa/image8.png b/media/articles/login/spa/image8.png
new file mode 100644
index 0000000000..b60c87d206
Binary files /dev/null and b/media/articles/login/spa/image8.png differ
diff --git a/media/articles/login/spa/image9.png b/media/articles/login/spa/image9.png
new file mode 100644
index 0000000000..132164bdf1
Binary files /dev/null and b/media/articles/login/spa/image9.png differ
diff --git a/media/articles/logout/signing-out-scenario1.png b/media/articles/logout/signing-out-scenario1.png
new file mode 100644
index 0000000000..83939c5387
Binary files /dev/null and b/media/articles/logout/signing-out-scenario1.png differ
diff --git a/media/articles/logout/signing-out-scenario2.png b/media/articles/logout/signing-out-scenario2.png
new file mode 100644
index 0000000000..e7a4f4b064
Binary files /dev/null and b/media/articles/logout/signing-out-scenario2.png differ
diff --git a/media/articles/logout/single-sign-out.png b/media/articles/logout/single-sign-out.png
new file mode 100644
index 0000000000..7d4fd1cae6
Binary files /dev/null and b/media/articles/logout/single-sign-out.png differ
diff --git a/media/articles/logs/dashboard-logs.png b/media/articles/logs/dashboard-logs.png
index 0b1292d065..d941ab0f29 100644
Binary files a/media/articles/logs/dashboard-logs.png and b/media/articles/logs/dashboard-logs.png differ
diff --git a/media/articles/logs/datadog/tutorial-1.png b/media/articles/logs/datadog/tutorial-1.png
new file mode 100644
index 0000000000..74aa7cf463
Binary files /dev/null and b/media/articles/logs/datadog/tutorial-1.png differ
diff --git a/media/articles/logs/datadog/tutorial-2.png b/media/articles/logs/datadog/tutorial-2.png
new file mode 100644
index 0000000000..4ced402c3c
Binary files /dev/null and b/media/articles/logs/datadog/tutorial-2.png differ
diff --git a/media/articles/logs/datadog/tutorial-3.png b/media/articles/logs/datadog/tutorial-3.png
new file mode 100644
index 0000000000..229280b7c8
Binary files /dev/null and b/media/articles/logs/datadog/tutorial-3.png differ
diff --git a/media/articles/logs/datadog/tutorial-4.png b/media/articles/logs/datadog/tutorial-4.png
new file mode 100644
index 0000000000..748dbd28ef
Binary files /dev/null and b/media/articles/logs/datadog/tutorial-4.png differ
diff --git a/media/articles/logs/health/health-errors.png b/media/articles/logs/health/health-errors.png
new file mode 100644
index 0000000000..be9ea79956
Binary files /dev/null and b/media/articles/logs/health/health-errors.png differ
diff --git a/media/articles/logs/health/pause-a-stream.png b/media/articles/logs/health/pause-a-stream.png
new file mode 100644
index 0000000000..20ddeed7c0
Binary files /dev/null and b/media/articles/logs/health/pause-a-stream.png differ
diff --git a/media/articles/logs/http-event-stream.png b/media/articles/logs/http-event-stream.png
new file mode 100644
index 0000000000..5f6ec0969b
Binary files /dev/null and b/media/articles/logs/http-event-stream.png differ
diff --git a/media/articles/logs/log-event-filter.png b/media/articles/logs/log-event-filter.png
new file mode 100644
index 0000000000..a46b76fba7
Binary files /dev/null and b/media/articles/logs/log-event-filter.png differ
diff --git a/media/articles/logs/log-stream-to-slack-diagram.png b/media/articles/logs/log-stream-to-slack-diagram.png
new file mode 100644
index 0000000000..17ddd90c7d
Binary files /dev/null and b/media/articles/logs/log-stream-to-slack-diagram.png differ
diff --git a/media/articles/logs/log-stream-to-slack-message.png b/media/articles/logs/log-stream-to-slack-message.png
new file mode 100644
index 0000000000..a71a99f46b
Binary files /dev/null and b/media/articles/logs/log-stream-to-slack-message.png differ
diff --git a/media/articles/logs/tenant-logs-migration.png b/media/articles/logs/tenant-logs-migration.png
new file mode 100644
index 0000000000..915ad7c30d
Binary files /dev/null and b/media/articles/logs/tenant-logs-migration.png differ
diff --git a/media/articles/mfa/01-guide-vonage-dashboard-sms-api-test.png b/media/articles/mfa/01-guide-vonage-dashboard-sms-api-test.png
new file mode 100644
index 0000000000..d0fed31ae8
Binary files /dev/null and b/media/articles/mfa/01-guide-vonage-dashboard-sms-api-test.png differ
diff --git a/media/articles/mfa/02-guide-auth0-add-new-hook.png b/media/articles/mfa/02-guide-auth0-add-new-hook.png
new file mode 100644
index 0000000000..caac621526
Binary files /dev/null and b/media/articles/mfa/02-guide-auth0-add-new-hook.png differ
diff --git a/media/articles/mfa/03-guide-auth0-edit-new-sms-hook.png b/media/articles/mfa/03-guide-auth0-edit-new-sms-hook.png
new file mode 100644
index 0000000000..5ea638c1f5
Binary files /dev/null and b/media/articles/mfa/03-guide-auth0-edit-new-sms-hook.png differ
diff --git a/media/articles/mfa/04-guide-auth0-add-hook-secrets.png b/media/articles/mfa/04-guide-auth0-add-hook-secrets.png
new file mode 100644
index 0000000000..d29cc0e3b9
Binary files /dev/null and b/media/articles/mfa/04-guide-auth0-add-hook-secrets.png differ
diff --git a/media/articles/mfa/05-guide-auth0-add-nexmo-module.png b/media/articles/mfa/05-guide-auth0-add-nexmo-module.png
new file mode 100644
index 0000000000..3b509142ad
Binary files /dev/null and b/media/articles/mfa/05-guide-auth0-add-nexmo-module.png differ
diff --git a/media/articles/mfa/06-guide-auth0-run-sms-hook.png b/media/articles/mfa/06-guide-auth0-run-sms-hook.png
new file mode 100644
index 0000000000..5e8a6b7acf
Binary files /dev/null and b/media/articles/mfa/06-guide-auth0-run-sms-hook.png differ
diff --git a/media/articles/mfa/07-guide-auth0-activate-sms-factor.png b/media/articles/mfa/07-guide-auth0-activate-sms-factor.png
new file mode 100644
index 0000000000..78e502ad9c
Binary files /dev/null and b/media/articles/mfa/07-guide-auth0-activate-sms-factor.png differ
diff --git a/media/articles/mfa/08-guide-test-sms-verification.png b/media/articles/mfa/08-guide-test-sms-verification.png
new file mode 100644
index 0000000000..acaac0c6b0
Binary files /dev/null and b/media/articles/mfa/08-guide-test-sms-verification.png differ
diff --git a/media/articles/mfa/09-guide-login-sms-error-message.png b/media/articles/mfa/09-guide-login-sms-error-message.png
new file mode 100644
index 0000000000..43ba7552b3
Binary files /dev/null and b/media/articles/mfa/09-guide-login-sms-error-message.png differ
diff --git a/media/articles/mfa/10-guide-auth0-log-sms-error.png b/media/articles/mfa/10-guide-auth0-log-sms-error.png
new file mode 100644
index 0000000000..950198029d
Binary files /dev/null and b/media/articles/mfa/10-guide-auth0-log-sms-error.png differ
diff --git a/media/articles/mfa/11-guide-auth0-log-sms-error-details.png b/media/articles/mfa/11-guide-auth0-log-sms-error-details.png
new file mode 100644
index 0000000000..43283b0c12
Binary files /dev/null and b/media/articles/mfa/11-guide-auth0-log-sms-error-details.png differ
diff --git a/media/articles/mfa/android-passphrase.png b/media/articles/mfa/android-passphrase.png
deleted file mode 100644
index 9f8d5c4050..0000000000
Binary files a/media/articles/mfa/android-passphrase.png and /dev/null differ
diff --git a/media/articles/mfa/change-provider.png b/media/articles/mfa/change-provider.png
deleted file mode 100644
index 877276192f..0000000000
Binary files a/media/articles/mfa/change-provider.png and /dev/null differ
diff --git a/media/articles/mfa/choose-mfa.png b/media/articles/mfa/choose-mfa.png
deleted file mode 100644
index 6aafcfd0ec..0000000000
Binary files a/media/articles/mfa/choose-mfa.png and /dev/null differ
diff --git a/media/articles/mfa/disable-google-auth-duo.png b/media/articles/mfa/disable-google-auth-duo.png
deleted file mode 100644
index bf14324c58..0000000000
Binary files a/media/articles/mfa/disable-google-auth-duo.png and /dev/null differ
diff --git a/media/articles/mfa/disable-guardian.png b/media/articles/mfa/disable-guardian.png
deleted file mode 100644
index a894e3424a..0000000000
Binary files a/media/articles/mfa/disable-guardian.png and /dev/null differ
diff --git a/media/articles/mfa/duo-settings.png b/media/articles/mfa/duo-settings.png
new file mode 100755
index 0000000000..56b574d6b5
Binary files /dev/null and b/media/articles/mfa/duo-settings.png differ
diff --git a/media/articles/mfa/email-settings.png b/media/articles/mfa/email-settings.png
new file mode 100755
index 0000000000..045c36a002
Binary files /dev/null and b/media/articles/mfa/email-settings.png differ
diff --git a/media/articles/mfa/enrollment-email.png b/media/articles/mfa/enrollment-email.png
deleted file mode 100755
index ef618627d8..0000000000
Binary files a/media/articles/mfa/enrollment-email.png and /dev/null differ
diff --git a/media/articles/mfa/google-auth-scan-code.png b/media/articles/mfa/google-auth-scan-code.png
new file mode 100755
index 0000000000..5ad5892c86
Binary files /dev/null and b/media/articles/mfa/google-auth-scan-code.png differ
diff --git a/media/articles/mfa/google-code.png b/media/articles/mfa/google-code.png
deleted file mode 100644
index 50e864f70f..0000000000
Binary files a/media/articles/mfa/google-code.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-both.png b/media/articles/mfa/guardian-both.png
deleted file mode 100755
index 8a234953e6..0000000000
Binary files a/media/articles/mfa/guardian-both.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-code.png b/media/articles/mfa/guardian-code.png
deleted file mode 100644
index 804231af7c..0000000000
Binary files a/media/articles/mfa/guardian-code.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-dashboard.png b/media/articles/mfa/guardian-dashboard.png
deleted file mode 100755
index fa3daac41a..0000000000
Binary files a/media/articles/mfa/guardian-dashboard.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-download.png b/media/articles/mfa/guardian-download.png
new file mode 100755
index 0000000000..47f0b24e7c
Binary files /dev/null and b/media/articles/mfa/guardian-download.png differ
diff --git a/media/articles/mfa/guardian-enter-code.png b/media/articles/mfa/guardian-enter-code.png
deleted file mode 100644
index 0b25a3666a..0000000000
Binary files a/media/articles/mfa/guardian-enter-code.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-functionality.png b/media/articles/mfa/guardian-functionality.png
new file mode 100644
index 0000000000..d8d86b24aa
Binary files /dev/null and b/media/articles/mfa/guardian-functionality.png differ
diff --git a/media/articles/mfa/guardian-logo-and-name-settings.png b/media/articles/mfa/guardian-logo-and-name-settings.png
deleted file mode 100755
index cbf4be6150..0000000000
Binary files a/media/articles/mfa/guardian-logo-and-name-settings.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-mfa-hosted-page.png b/media/articles/mfa/guardian-mfa-hosted-page.png
deleted file mode 100755
index fd78a9ab95..0000000000
Binary files a/media/articles/mfa/guardian-mfa-hosted-page.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-otp-code.png b/media/articles/mfa/guardian-otp-code.png
deleted file mode 100644
index 3f7e1ba57e..0000000000
Binary files a/media/articles/mfa/guardian-otp-code.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-push-enabled.png b/media/articles/mfa/guardian-push-enabled.png
deleted file mode 100755
index 6559d1830f..0000000000
Binary files a/media/articles/mfa/guardian-push-enabled.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-recover-code.png b/media/articles/mfa/guardian-recover-code.png
deleted file mode 100644
index 49dfa21db2..0000000000
Binary files a/media/articles/mfa/guardian-recover-code.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-send-enrollment-email.png b/media/articles/mfa/guardian-send-enrollment-email.png
deleted file mode 100755
index 6b56f9e77e..0000000000
Binary files a/media/articles/mfa/guardian-send-enrollment-email.png and /dev/null differ
diff --git a/media/articles/mfa/guardian-settings.png b/media/articles/mfa/guardian-settings.png
new file mode 100755
index 0000000000..73cca15723
Binary files /dev/null and b/media/articles/mfa/guardian-settings.png differ
diff --git a/media/articles/mfa/log-example.png b/media/articles/mfa/log-example.png
deleted file mode 100644
index 947f7bd7c6..0000000000
Binary files a/media/articles/mfa/log-example.png and /dev/null differ
diff --git a/media/articles/mfa/logs.png b/media/articles/mfa/logs.png
deleted file mode 100644
index e8ce750ca8..0000000000
Binary files a/media/articles/mfa/logs.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-dashboard.png b/media/articles/mfa/mfa-dashboard.png
new file mode 100644
index 0000000000..615f990762
Binary files /dev/null and b/media/articles/mfa/mfa-dashboard.png differ
diff --git a/media/articles/mfa/mfa-email.png b/media/articles/mfa/mfa-email.png
new file mode 100644
index 0000000000..705dcc98ab
Binary files /dev/null and b/media/articles/mfa/mfa-email.png differ
diff --git a/media/articles/mfa/mfa-home.png b/media/articles/mfa/mfa-home.png
deleted file mode 100644
index 544b50bc21..0000000000
Binary files a/media/articles/mfa/mfa-home.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-01.png b/media/articles/mfa/mfa-native/mfa-native-01.png
deleted file mode 100644
index 95e29d8781..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-01.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-02.png b/media/articles/mfa/mfa-native/mfa-native-02.png
deleted file mode 100644
index 3abfa96b7c..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-02.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-03.png b/media/articles/mfa/mfa-native/mfa-native-03.png
deleted file mode 100644
index 425405acb2..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-03.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-04.png b/media/articles/mfa/mfa-native/mfa-native-04.png
deleted file mode 100644
index 414e68d10d..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-04.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-05.png b/media/articles/mfa/mfa-native/mfa-native-05.png
deleted file mode 100644
index 8f74cb2347..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-05.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-06.png b/media/articles/mfa/mfa-native/mfa-native-06.png
deleted file mode 100644
index 750c87f0f0..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-06.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-07.png b/media/articles/mfa/mfa-native/mfa-native-07.png
deleted file mode 100644
index 4c2060ca75..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-07.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-08.png b/media/articles/mfa/mfa-native/mfa-native-08.png
deleted file mode 100644
index a7043a1234..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-08.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-09.png b/media/articles/mfa/mfa-native/mfa-native-09.png
deleted file mode 100644
index 847878ca8c..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-09.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-10.png b/media/articles/mfa/mfa-native/mfa-native-10.png
deleted file mode 100644
index 61d4e2573e..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-10.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-native/mfa-native-11.png b/media/articles/mfa/mfa-native/mfa-native-11.png
deleted file mode 100644
index 29602cefab..0000000000
Binary files a/media/articles/mfa/mfa-native/mfa-native-11.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-otp-login.png b/media/articles/mfa/mfa-otp-login.png
new file mode 100644
index 0000000000..4abf6f866d
Binary files /dev/null and b/media/articles/mfa/mfa-otp-login.png differ
diff --git a/media/articles/mfa/mfa-otp-setup.png b/media/articles/mfa/mfa-otp-setup.png
new file mode 100644
index 0000000000..735a6e6e2d
Binary files /dev/null and b/media/articles/mfa/mfa-otp-setup.png differ
diff --git a/media/articles/mfa/mfa-phone-settings.png b/media/articles/mfa/mfa-phone-settings.png
new file mode 100644
index 0000000000..5a0e72c0ce
Binary files /dev/null and b/media/articles/mfa/mfa-phone-settings.png differ
diff --git a/media/articles/mfa/mfa-phone-templates.png b/media/articles/mfa/mfa-phone-templates.png
new file mode 100644
index 0000000000..1a73ed025f
Binary files /dev/null and b/media/articles/mfa/mfa-phone-templates.png differ
diff --git a/media/articles/mfa/mfa-phone-twilio.png b/media/articles/mfa/mfa-phone-twilio.png
new file mode 100644
index 0000000000..97da93e261
Binary files /dev/null and b/media/articles/mfa/mfa-phone-twilio.png differ
diff --git a/media/articles/mfa/mfa-provider.png b/media/articles/mfa/mfa-provider.png
deleted file mode 100644
index 9271c0a380..0000000000
Binary files a/media/articles/mfa/mfa-provider.png and /dev/null differ
diff --git a/media/articles/mfa/mfa-sms-voice.png b/media/articles/mfa/mfa-sms-voice.png
new file mode 100644
index 0000000000..9ec762df54
Binary files /dev/null and b/media/articles/mfa/mfa-sms-voice.png differ
diff --git a/media/articles/mfa/mfa-sms.png b/media/articles/mfa/mfa-sms.png
new file mode 100644
index 0000000000..5cc6f4eeb7
Binary files /dev/null and b/media/articles/mfa/mfa-sms.png differ
diff --git a/media/articles/mfa/mfa-success.png b/media/articles/mfa/mfa-success.png
new file mode 100755
index 0000000000..63b7187e5d
Binary files /dev/null and b/media/articles/mfa/mfa-success.png differ
diff --git a/media/articles/mfa/mfa-template.png b/media/articles/mfa/mfa-template.png
deleted file mode 100644
index 8594fc02eb..0000000000
Binary files a/media/articles/mfa/mfa-template.png and /dev/null differ
diff --git a/media/articles/mfa/push-notification-config.png b/media/articles/mfa/push-notification-config.png
index 44039295bf..22672906dc 100644
Binary files a/media/articles/mfa/push-notification-config.png and b/media/articles/mfa/push-notification-config.png differ
diff --git a/media/articles/mfa/recovery-code.png b/media/articles/mfa/recovery-code.png
new file mode 100755
index 0000000000..98de5a382e
Binary files /dev/null and b/media/articles/mfa/recovery-code.png differ
diff --git a/media/articles/mfa/reset-google-mfa.png b/media/articles/mfa/reset-google-mfa.png
deleted file mode 100644
index 57b5cad61d..0000000000
Binary files a/media/articles/mfa/reset-google-mfa.png and /dev/null differ
diff --git a/media/articles/mfa/sign-up.png b/media/articles/mfa/sign-up.png
deleted file mode 100644
index c8c06c6686..0000000000
Binary files a/media/articles/mfa/sign-up.png and /dev/null differ
diff --git a/media/articles/mfa/signup.png b/media/articles/mfa/signup.png
new file mode 100755
index 0000000000..ed3f61635e
Binary files /dev/null and b/media/articles/mfa/signup.png differ
diff --git a/media/articles/mfa/sms-config.png b/media/articles/mfa/sms-config.png
deleted file mode 100644
index 1be46cf5a6..0000000000
Binary files a/media/articles/mfa/sms-config.png and /dev/null differ
diff --git a/media/articles/mfa/sms-screenshot.png b/media/articles/mfa/sms-screenshot.png
deleted file mode 100755
index 81d5279523..0000000000
Binary files a/media/articles/mfa/sms-screenshot.png and /dev/null differ
diff --git a/media/articles/mfa/sms.png b/media/articles/mfa/sms.png
deleted file mode 100644
index 5df9f82a4d..0000000000
Binary files a/media/articles/mfa/sms.png and /dev/null differ
diff --git a/media/articles/mfa/step-up-flow.png b/media/articles/mfa/step-up-flow.png
index b76a77da1f..38e30fe437 100644
Binary files a/media/articles/mfa/step-up-flow.png and b/media/articles/mfa/step-up-flow.png differ
diff --git a/media/articles/mfa/toggle-duo.png b/media/articles/mfa/toggle-duo.png
deleted file mode 100644
index 128e1f8fcd..0000000000
Binary files a/media/articles/mfa/toggle-duo.png and /dev/null differ
diff --git a/media/articles/mfa/toggle-google-auth.png b/media/articles/mfa/toggle-google-auth.png
deleted file mode 100644
index 42ce7b79b8..0000000000
Binary files a/media/articles/mfa/toggle-google-auth.png and /dev/null differ
diff --git a/media/articles/mfa/yubi-1.png b/media/articles/mfa/yubi-1.png
deleted file mode 100644
index 973ac15993..0000000000
Binary files a/media/articles/mfa/yubi-1.png and /dev/null differ
diff --git a/media/articles/mfa/yubi-2.png b/media/articles/mfa/yubi-2.png
deleted file mode 100644
index 28b1b610f1..0000000000
Binary files a/media/articles/mfa/yubi-2.png and /dev/null differ
diff --git a/media/articles/mfa/yubi-3.png b/media/articles/mfa/yubi-3.png
deleted file mode 100644
index 0f94e70ee2..0000000000
Binary files a/media/articles/mfa/yubi-3.png and /dev/null differ
diff --git a/media/articles/mfa/yubi-4.png b/media/articles/mfa/yubi-4.png
deleted file mode 100644
index 9749512191..0000000000
Binary files a/media/articles/mfa/yubi-4.png and /dev/null differ
diff --git a/media/articles/mfa/yubi-5.png b/media/articles/mfa/yubi-5.png
deleted file mode 100644
index 57a46d0d77..0000000000
Binary files a/media/articles/mfa/yubi-5.png and /dev/null differ
diff --git a/media/articles/mfa/yubico-mfa.png b/media/articles/mfa/yubico-mfa.png
deleted file mode 100644
index d8937eaa35..0000000000
Binary files a/media/articles/mfa/yubico-mfa.png and /dev/null differ
diff --git a/media/articles/microsites/login-screen-default-mobile.png b/media/articles/microsites/login-screen-default-mobile.png
new file mode 100644
index 0000000000..cccc310261
Binary files /dev/null and b/media/articles/microsites/login-screen-default-mobile.png differ
diff --git a/media/articles/microsites/login-screen-default-web.png b/media/articles/microsites/login-screen-default-web.png
new file mode 100644
index 0000000000..4750ef4177
Binary files /dev/null and b/media/articles/microsites/login-screen-default-web.png differ
diff --git a/media/articles/microsites/manage-users.png b/media/articles/microsites/manage-users.png
new file mode 100644
index 0000000000..01c32bf271
Binary files /dev/null and b/media/articles/microsites/manage-users.png differ
diff --git a/media/articles/microsites/overview-flow-add-login-native-mobile-app.png b/media/articles/microsites/overview-flow-add-login-native-mobile-app.png
new file mode 100755
index 0000000000..f19f204ce1
Binary files /dev/null and b/media/articles/microsites/overview-flow-add-login-native-mobile-app.png differ
diff --git a/media/articles/microsites/overview-flow-add-login-regular-web-app.png b/media/articles/microsites/overview-flow-add-login-regular-web-app.png
new file mode 100755
index 0000000000..566ba02fbd
Binary files /dev/null and b/media/articles/microsites/overview-flow-add-login-regular-web-app.png differ
diff --git a/media/articles/microsites/overview-flow-add-login-single-page-app-pkce.png b/media/articles/microsites/overview-flow-add-login-single-page-app-pkce.png
new file mode 100644
index 0000000000..6b036f5871
Binary files /dev/null and b/media/articles/microsites/overview-flow-add-login-single-page-app-pkce.png differ
diff --git a/media/articles/microsites/overview-flow-add-login-single-page-app.png b/media/articles/microsites/overview-flow-add-login-single-page-app.png
new file mode 100644
index 0000000000..567de019ff
Binary files /dev/null and b/media/articles/microsites/overview-flow-add-login-single-page-app.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-device-app.png b/media/articles/microsites/overview-flow-call-api-device-app.png
new file mode 100644
index 0000000000..829e7db32b
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-device-app.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-m2m-app.png b/media/articles/microsites/overview-flow-call-api-m2m-app.png
new file mode 100755
index 0000000000..a06f57ea0b
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-m2m-app.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-native-mobile-app.png b/media/articles/microsites/overview-flow-call-api-native-mobile-app.png
new file mode 100755
index 0000000000..0ed300546c
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-native-mobile-app.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-regular-web-app.png b/media/articles/microsites/overview-flow-call-api-regular-web-app.png
new file mode 100755
index 0000000000..a54eed878d
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-regular-web-app.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-single-page-app-pkce.png b/media/articles/microsites/overview-flow-call-api-single-page-app-pkce.png
new file mode 100644
index 0000000000..859d681bbc
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-single-page-app-pkce.png differ
diff --git a/media/articles/microsites/overview-flow-call-api-single-page-app.png b/media/articles/microsites/overview-flow-call-api-single-page-app.png
new file mode 100644
index 0000000000..5207284ac9
Binary files /dev/null and b/media/articles/microsites/overview-flow-call-api-single-page-app.png differ
diff --git a/media/articles/microsites/overview-flow-protect-api.png b/media/articles/microsites/overview-flow-protect-api.png
new file mode 100644
index 0000000000..15f0ed538d
Binary files /dev/null and b/media/articles/microsites/overview-flow-protect-api.png differ
diff --git a/media/articles/migrations/apiv1-log-example.png b/media/articles/migrations/apiv1-log-example.png
new file mode 100644
index 0000000000..5dd6dbc1c2
Binary files /dev/null and b/media/articles/migrations/apiv1-log-example.png differ
diff --git a/media/articles/migrations/apiv1-log-query.png b/media/articles/migrations/apiv1-log-query.png
new file mode 100644
index 0000000000..85bb460c7b
Binary files /dev/null and b/media/articles/migrations/apiv1-log-query.png differ
diff --git a/media/articles/migrations/apiv1-toggle.png b/media/articles/migrations/apiv1-toggle.png
new file mode 100644
index 0000000000..b3e1ce69c5
Binary files /dev/null and b/media/articles/migrations/apiv1-toggle.png differ
diff --git a/media/articles/migrations/facebook-context.png b/media/articles/migrations/facebook-context.png
new file mode 100644
index 0000000000..ffbfc62024
Binary files /dev/null and b/media/articles/migrations/facebook-context.png differ
diff --git a/media/articles/migrations/node-auth-ext-buttons.png b/media/articles/migrations/node-auth-ext-buttons.png
new file mode 100644
index 0000000000..0b6645b513
Binary files /dev/null and b/media/articles/migrations/node-auth-ext-buttons.png differ
diff --git a/media/articles/migrations/node-auth-ext-config.png b/media/articles/migrations/node-auth-ext-config.png
new file mode 100644
index 0000000000..b6b805b980
Binary files /dev/null and b/media/articles/migrations/node-auth-ext-config.png differ
diff --git a/media/articles/migrations/node-hidden-secret-error.png b/media/articles/migrations/node-hidden-secret-error.png
new file mode 100644
index 0000000000..d0e01525e3
Binary files /dev/null and b/media/articles/migrations/node-hidden-secret-error.png differ
diff --git a/media/articles/migrations/node-runtime1.png b/media/articles/migrations/node-runtime1.png
index 68d1ab7cba..4872733e1e 100644
Binary files a/media/articles/migrations/node-runtime1.png and b/media/articles/migrations/node-runtime1.png differ
diff --git a/media/articles/migrations/node-runtime2.png b/media/articles/migrations/node-runtime2.png
index 5e943a89ec..1849261efb 100644
Binary files a/media/articles/migrations/node-runtime2.png and b/media/articles/migrations/node-runtime2.png differ
diff --git a/media/articles/native-platforms/android/login-android.png b/media/articles/native-platforms/android/login-android.png
index 37ed4e6e6a..7eb0456117 100644
Binary files a/media/articles/native-platforms/android/login-android.png and b/media/articles/native-platforms/android/login-android.png differ
diff --git a/media/articles/native-platforms/ios-swift/ios-device-settings.png b/media/articles/native-platforms/ios-swift/ios-device-settings.png
new file mode 100644
index 0000000000..2c4f13d3b4
Binary files /dev/null and b/media/articles/native-platforms/ios-swift/ios-device-settings.png differ
diff --git a/media/articles/native-platforms/ios-swift/ios-xcode-capabilities.png b/media/articles/native-platforms/ios-swift/ios-xcode-capabilities.png
new file mode 100644
index 0000000000..40fc700acf
Binary files /dev/null and b/media/articles/native-platforms/ios-swift/ios-xcode-capabilities.png differ
diff --git a/media/articles/native-platforms/ios-swift/lock_centralized_login.png b/media/articles/native-platforms/ios-swift/lock_centralized_login.png
deleted file mode 100644
index c5724c83e9..0000000000
Binary files a/media/articles/native-platforms/ios-swift/lock_centralized_login.png and /dev/null differ
diff --git a/media/articles/native-platforms/ios-swift/login-ios.png b/media/articles/native-platforms/ios-swift/login-ios.png
new file mode 100644
index 0000000000..ddadddfcec
Binary files /dev/null and b/media/articles/native-platforms/ios-swift/login-ios.png differ
diff --git a/media/articles/native-platforms/windows-uwp-csharp/lock-widget-screenshot.png b/media/articles/native-platforms/windows-uwp-csharp/lock-widget-screenshot.png
deleted file mode 100644
index 07dcb85cde..0000000000
Binary files a/media/articles/native-platforms/windows-uwp-csharp/lock-widget-screenshot.png and /dev/null differ
diff --git a/media/articles/native-platforms/windows-uwp-csharp/universal-login.png b/media/articles/native-platforms/windows-uwp-csharp/universal-login.png
new file mode 100644
index 0000000000..13eeab2219
Binary files /dev/null and b/media/articles/native-platforms/windows-uwp-csharp/universal-login.png differ
diff --git a/media/articles/native-platforms/wpf-winforms/legacy/wpf-winforms-step1.png b/media/articles/native-platforms/wpf-winforms/legacy/wpf-winforms-step1.png
deleted file mode 100644
index 23388d5ced..0000000000
Binary files a/media/articles/native-platforms/wpf-winforms/legacy/wpf-winforms-step1.png and /dev/null differ
diff --git a/media/articles/native-platforms/wpf-winforms/universal-login.png b/media/articles/native-platforms/wpf-winforms/universal-login.png
new file mode 100644
index 0000000000..13eeab2219
Binary files /dev/null and b/media/articles/native-platforms/wpf-winforms/universal-login.png differ
diff --git a/media/articles/native-platforms/wpf-winforms/wpf-winforms-step1.png b/media/articles/native-platforms/wpf-winforms/wpf-winforms-step1.png
deleted file mode 100644
index febbacd67c..0000000000
Binary files a/media/articles/native-platforms/wpf-winforms/wpf-winforms-step1.png and /dev/null differ
diff --git a/media/articles/native-platforms/xamarin/lock-widget-screenshot-android.png b/media/articles/native-platforms/xamarin/lock-widget-screenshot-android.png
deleted file mode 100644
index 0718a58de3..0000000000
Binary files a/media/articles/native-platforms/xamarin/lock-widget-screenshot-android.png and /dev/null differ
diff --git a/media/articles/native-platforms/xamarin/lock-widget-screenshot-ios.png b/media/articles/native-platforms/xamarin/lock-widget-screenshot-ios.png
deleted file mode 100644
index cae66b5bd6..0000000000
Binary files a/media/articles/native-platforms/xamarin/lock-widget-screenshot-ios.png and /dev/null differ
diff --git a/media/articles/policies/entity-limit-reached.png b/media/articles/policies/entity-limit-reached.png
new file mode 100644
index 0000000000..3b9c29aaf4
Binary files /dev/null and b/media/articles/policies/entity-limit-reached.png differ
diff --git a/media/articles/private-cloud/one-jumphost.png b/media/articles/private-cloud/one-jumphost.png
new file mode 100644
index 0000000000..b8de1ed593
Binary files /dev/null and b/media/articles/private-cloud/one-jumphost.png differ
diff --git a/media/articles/private-cloud/two-jumphosts.png b/media/articles/private-cloud/two-jumphosts.png
new file mode 100644
index 0000000000..5c318d888b
Binary files /dev/null and b/media/articles/private-cloud/two-jumphosts.png differ
diff --git a/media/articles/private-cloud/zones/zones-1.png b/media/articles/private-cloud/zones/zones-1.png
new file mode 100644
index 0000000000..3235e23ce0
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-1.png differ
diff --git a/media/articles/private-cloud/zones/zones-2.png b/media/articles/private-cloud/zones/zones-2.png
new file mode 100644
index 0000000000..1f547ec66a
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-2.png differ
diff --git a/media/articles/private-cloud/zones/zones-3.png b/media/articles/private-cloud/zones/zones-3.png
new file mode 100644
index 0000000000..7a10dfdd0e
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-3.png differ
diff --git a/media/articles/private-cloud/zones/zones-4.png b/media/articles/private-cloud/zones/zones-4.png
new file mode 100644
index 0000000000..1518829363
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-4.png differ
diff --git a/media/articles/private-cloud/zones/zones-5.png b/media/articles/private-cloud/zones/zones-5.png
new file mode 100644
index 0000000000..89401eda83
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-5.png differ
diff --git a/media/articles/private-cloud/zones/zones-6.png b/media/articles/private-cloud/zones/zones-6.png
new file mode 100644
index 0000000000..b23d4a8a7b
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-6.png differ
diff --git a/media/articles/private-cloud/zones/zones-7.png b/media/articles/private-cloud/zones/zones-7.png
new file mode 100644
index 0000000000..e1a7811bb7
Binary files /dev/null and b/media/articles/private-cloud/zones/zones-7.png differ
diff --git a/media/articles/protocols/saml-adfs/adfs-saml-properties.png b/media/articles/protocols/saml-adfs/adfs-saml-properties.png
new file mode 100644
index 0000000000..6d696342e3
Binary files /dev/null and b/media/articles/protocols/saml-adfs/adfs-saml-properties.png differ
diff --git a/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png b/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png
new file mode 100644
index 0000000000..656ceb1d5a
Binary files /dev/null and b/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png differ
diff --git a/media/articles/protocols/saml/github-cloud/client-addons.png b/media/articles/protocols/saml/github-cloud/client-addons.png
new file mode 100755
index 0000000000..b83826a88b
Binary files /dev/null and b/media/articles/protocols/saml/github-cloud/client-addons.png differ
diff --git a/media/articles/protocols/saml/github-cloud/usage.png b/media/articles/protocols/saml/github-cloud/usage.png
new file mode 100644
index 0000000000..47642f3804
Binary files /dev/null and b/media/articles/protocols/saml/github-cloud/usage.png differ
diff --git a/media/articles/protocols/saml/github-server/client-addons.png b/media/articles/protocols/saml/github-server/client-addons.png
new file mode 100755
index 0000000000..b83826a88b
Binary files /dev/null and b/media/articles/protocols/saml/github-server/client-addons.png differ
diff --git a/media/articles/protocols/saml/github-server/usage.png b/media/articles/protocols/saml/github-server/usage.png
new file mode 100644
index 0000000000..47642f3804
Binary files /dev/null and b/media/articles/protocols/saml/github-server/usage.png differ
diff --git a/media/articles/rules/birthday.png b/media/articles/rules/birthday.png
new file mode 100755
index 0000000000..720ac0c997
Binary files /dev/null and b/media/articles/rules/birthday.png differ
diff --git a/media/articles/rules/core-fields.png b/media/articles/rules/core-fields.png
new file mode 100755
index 0000000000..516cb04b76
Binary files /dev/null and b/media/articles/rules/core-fields.png differ
diff --git a/media/articles/rules/edit-onfido-rule.png b/media/articles/rules/edit-onfido-rule.png
new file mode 100644
index 0000000000..1e72338791
Binary files /dev/null and b/media/articles/rules/edit-onfido-rule.png differ
diff --git a/media/articles/rules/enable-onfido-redirect-rule.png b/media/articles/rules/enable-onfido-redirect-rule.png
new file mode 100644
index 0000000000..466eb3840d
Binary files /dev/null and b/media/articles/rules/enable-onfido-redirect-rule.png differ
diff --git a/media/articles/rules/extend-rules.svg b/media/articles/rules/extend-rules.svg
new file mode 100644
index 0000000000..2cf64ea602
--- /dev/null
+++ b/media/articles/rules/extend-rules.svg
@@ -0,0 +1,115 @@
+
+
+    
+    Rules
+    Created with Sketch.
+    
+        
+    
+    
+        
+            
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                    
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                    
+                        
+                        
+                    
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+                
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/rules/onfido-metadata-example.png b/media/articles/rules/onfido-metadata-example.png
new file mode 100644
index 0000000000..8f7c97cddb
Binary files /dev/null and b/media/articles/rules/onfido-metadata-example.png differ
diff --git a/media/articles/rules/onfido-verification-login1.png b/media/articles/rules/onfido-verification-login1.png
new file mode 100644
index 0000000000..d3426960ea
Binary files /dev/null and b/media/articles/rules/onfido-verification-login1.png differ
diff --git a/media/articles/rules/onfido-verify-identity.png b/media/articles/rules/onfido-verify-identity.png
new file mode 100644
index 0000000000..ba045e2c81
Binary files /dev/null and b/media/articles/rules/onfido-verify-identity.png differ
diff --git a/media/articles/rules/onfido-verify-success.png b/media/articles/rules/onfido-verify-success.png
new file mode 100644
index 0000000000..2dd6bc826f
Binary files /dev/null and b/media/articles/rules/onfido-verify-success.png differ
diff --git a/media/articles/rules/rule-choose-add-country-template.png b/media/articles/rules/rule-choose-add-country-template.png
index dae2f116a7..9f460fa5e4 100644
Binary files a/media/articles/rules/rule-choose-add-country-template.png and b/media/articles/rules/rule-choose-add-country-template.png differ
diff --git a/media/articles/rules/rule-create-add-country-country.png b/media/articles/rules/rule-create-add-country-country.png
index 6b0885e213..f8fc95aeb7 100644
Binary files a/media/articles/rules/rule-create-add-country-country.png and b/media/articles/rules/rule-create-add-country-country.png differ
diff --git a/media/articles/rules/rules-best-practice-dashboard.png b/media/articles/rules/rules-best-practice-dashboard.png
new file mode 100644
index 0000000000..1303c9e0ad
Binary files /dev/null and b/media/articles/rules/rules-best-practice-dashboard.png differ
diff --git a/media/articles/rules/rules-best-practice-pipeline.png b/media/articles/rules/rules-best-practice-pipeline.png
new file mode 100644
index 0000000000..c47bbd1ffb
Binary files /dev/null and b/media/articles/rules/rules-best-practice-pipeline.png differ
diff --git a/media/articles/saml/identity-providers/okta/admin-settings.png b/media/articles/saml/identity-providers/okta/admin-settings.png
deleted file mode 100644
index 250f003123..0000000000
Binary files a/media/articles/saml/identity-providers/okta/admin-settings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/clients.png b/media/articles/saml/identity-providers/okta/clients.png
deleted file mode 100644
index 6cdb29bbc5..0000000000
Binary files a/media/articles/saml/identity-providers/okta/clients.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/config-info.png b/media/articles/saml/identity-providers/okta/config-info.png
deleted file mode 100644
index 429d2dfd50..0000000000
Binary files a/media/articles/saml/identity-providers/okta/config-info.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/configure-new-connection.png b/media/articles/saml/identity-providers/okta/configure-new-connection.png
deleted file mode 100644
index 134d532da9..0000000000
Binary files a/media/articles/saml/identity-providers/okta/configure-new-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/configured-connection.png b/media/articles/saml/identity-providers/okta/configured-connection.png
deleted file mode 100644
index 1caebc8335..0000000000
Binary files a/media/articles/saml/identity-providers/okta/configured-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/create-new-app.png b/media/articles/saml/identity-providers/okta/create-new-app.png
deleted file mode 100644
index 3bd1da2a65..0000000000
Binary files a/media/articles/saml/identity-providers/okta/create-new-app.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/create-new-connection.png b/media/articles/saml/identity-providers/okta/create-new-connection.png
deleted file mode 100644
index c29237019f..0000000000
Binary files a/media/articles/saml/identity-providers/okta/create-new-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/enable-connection.png b/media/articles/saml/identity-providers/okta/enable-connection.png
deleted file mode 100644
index 376b4654d5..0000000000
Binary files a/media/articles/saml/identity-providers/okta/enable-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/enable-idp-connection.png b/media/articles/saml/identity-providers/okta/enable-idp-connection.png
deleted file mode 100644
index 3e6402562b..0000000000
Binary files a/media/articles/saml/identity-providers/okta/enable-idp-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/enterprise-connections.png b/media/articles/saml/identity-providers/okta/enterprise-connections.png
deleted file mode 100644
index 57255bcc8a..0000000000
Binary files a/media/articles/saml/identity-providers/okta/enterprise-connections.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/new-app-integration.png b/media/articles/saml/identity-providers/okta/new-app-integration.png
deleted file mode 100644
index 6860f42aa0..0000000000
Binary files a/media/articles/saml/identity-providers/okta/new-app-integration.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-admin-dashboard.png b/media/articles/saml/identity-providers/okta/okta-admin-dashboard.png
deleted file mode 100644
index a2cd6553c8..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-admin-dashboard.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-dashboard.png b/media/articles/saml/identity-providers/okta/okta-dashboard.png
deleted file mode 100644
index ce23c36eab..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-dashboard.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-support.png b/media/articles/saml/identity-providers/okta/okta-support.png
deleted file mode 100644
index bd16f63d20..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-support.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/saml-general-settings.png b/media/articles/saml/identity-providers/okta/saml-general-settings.png
deleted file mode 100644
index 5202492103..0000000000
Binary files a/media/articles/saml/identity-providers/okta/saml-general-settings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/saml-settings.png b/media/articles/saml/identity-providers/okta/saml-settings.png
deleted file mode 100644
index 9c36c4940e..0000000000
Binary files a/media/articles/saml/identity-providers/okta/saml-settings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/test.png b/media/articles/saml/identity-providers/okta/test.png
deleted file mode 100644
index 2d78859883..0000000000
Binary files a/media/articles/saml/identity-providers/okta/test.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/view-setup-instructions.png b/media/articles/saml/identity-providers/okta/view-setup-instructions.png
deleted file mode 100644
index 3f7cc22202..0000000000
Binary files a/media/articles/saml/identity-providers/okta/view-setup-instructions.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/auth0-instructions.png b/media/articles/saml/identity-providers/onelogin/auth0-instructions.png
deleted file mode 100755
index 1921966f3b..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/auth0-instructions.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/auth0-new-samlp.png b/media/articles/saml/identity-providers/onelogin/auth0-new-samlp.png
deleted file mode 100755
index 3b3390da07..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/auth0-new-samlp.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/auth0-set-values.png b/media/articles/saml/identity-providers/onelogin/auth0-set-values.png
deleted file mode 100755
index 2bbb930c8d..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/auth0-set-values.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/auth0-try-conn.png b/media/articles/saml/identity-providers/onelogin/auth0-try-conn.png
deleted file mode 100755
index 333fb21624..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/auth0-try-conn.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/auth0-try-result.png b/media/articles/saml/identity-providers/onelogin/auth0-try-result.png
deleted file mode 100755
index 6a702f4664..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/auth0-try-result.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/custom-attr-01.png b/media/articles/saml/identity-providers/onelogin/custom-attr-01.png
deleted file mode 100755
index 8c4c821c4a..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/custom-attr-01.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/custom-attr-02.png b/media/articles/saml/identity-providers/onelogin/custom-attr-02.png
deleted file mode 100755
index 62c6ff468f..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/custom-attr-02.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/custom-attr-03.png b/media/articles/saml/identity-providers/onelogin/custom-attr-03.png
deleted file mode 100755
index 5195e09338..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/custom-attr-03.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/custom-attr-04.png b/media/articles/saml/identity-providers/onelogin/custom-attr-04.png
deleted file mode 100755
index 2b233d2540..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/custom-attr-04.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/custom-attr-05.png b/media/articles/saml/identity-providers/onelogin/custom-attr-05.png
deleted file mode 100755
index b52a438b1c..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/custom-attr-05.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/edit-mappings.png b/media/articles/saml/identity-providers/onelogin/edit-mappings.png
deleted file mode 100644
index 45d449cbf9..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/edit-mappings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/idp-initiated-sso.png b/media/articles/saml/identity-providers/onelogin/idp-initiated-sso.png
deleted file mode 100755
index 067e889c41..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/idp-initiated-sso.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-add-app.png b/media/articles/saml/identity-providers/onelogin/onelogin-add-app.png
deleted file mode 100755
index 1697d98b21..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-add-app.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-copy-values.png b/media/articles/saml/identity-providers/onelogin/onelogin-copy-values.png
deleted file mode 100755
index 5934edd4e6..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-copy-values.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-download-cert.png b/media/articles/saml/identity-providers/onelogin/onelogin-download-cert.png
deleted file mode 100755
index 4d11179a77..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-download-cert.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-save-app.png b/media/articles/saml/identity-providers/onelogin/onelogin-save-app.png
deleted file mode 100755
index f3e0a329a9..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-save-app.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-search-app.png b/media/articles/saml/identity-providers/onelogin/onelogin-search-app.png
deleted file mode 100755
index c8e9802bc4..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-search-app.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/onelogin-set-values.png b/media/articles/saml/identity-providers/onelogin/onelogin-set-values.png
deleted file mode 100755
index 2c701cc9fc..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/onelogin-set-values.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/user-with-mappings.png b/media/articles/saml/identity-providers/onelogin/user-with-mappings.png
deleted file mode 100755
index fb2583b6f0..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/user-with-mappings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/onelogin/user-without-mappings.png b/media/articles/saml/identity-providers/onelogin/user-without-mappings.png
deleted file mode 100755
index 7b156a5302..0000000000
Binary files a/media/articles/saml/identity-providers/onelogin/user-without-mappings.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-1.png b/media/articles/saml/identity-providers/ping7/ping-1.png
deleted file mode 100644
index 927d14dca8..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-1.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-10.png b/media/articles/saml/identity-providers/ping7/ping-10.png
deleted file mode 100644
index 533d89f1ae..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-10.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-11.png b/media/articles/saml/identity-providers/ping7/ping-11.png
deleted file mode 100644
index ebb94c8bc5..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-11.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-12.png b/media/articles/saml/identity-providers/ping7/ping-12.png
deleted file mode 100644
index d6cc0eb6b3..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-12.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-13.png b/media/articles/saml/identity-providers/ping7/ping-13.png
deleted file mode 100644
index f34b408c55..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-13.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-14.png b/media/articles/saml/identity-providers/ping7/ping-14.png
deleted file mode 100644
index ea0b3d2adc..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-14.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-15.png b/media/articles/saml/identity-providers/ping7/ping-15.png
deleted file mode 100644
index 9ca642dc66..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-15.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-16.png b/media/articles/saml/identity-providers/ping7/ping-16.png
deleted file mode 100644
index a14fd45cd1..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-16.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-17.png b/media/articles/saml/identity-providers/ping7/ping-17.png
deleted file mode 100644
index bdd31faed8..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-17.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-18.png b/media/articles/saml/identity-providers/ping7/ping-18.png
deleted file mode 100644
index 9a63b3a53c..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-18.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-19.png b/media/articles/saml/identity-providers/ping7/ping-19.png
deleted file mode 100644
index 90022bd41f..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-19.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-2.png b/media/articles/saml/identity-providers/ping7/ping-2.png
deleted file mode 100644
index 0111663fb3..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-2.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-3.png b/media/articles/saml/identity-providers/ping7/ping-3.png
deleted file mode 100644
index 830a6a69df..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-3.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-4.png b/media/articles/saml/identity-providers/ping7/ping-4.png
deleted file mode 100644
index 36c3339abc..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-4.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-5.png b/media/articles/saml/identity-providers/ping7/ping-5.png
deleted file mode 100644
index 572025ec46..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-5.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-6.png b/media/articles/saml/identity-providers/ping7/ping-6.png
deleted file mode 100644
index 64a8c65434..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-6.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-7.png b/media/articles/saml/identity-providers/ping7/ping-7.png
deleted file mode 100644
index 9bf44c9c9f..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-7.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-8.png b/media/articles/saml/identity-providers/ping7/ping-8.png
deleted file mode 100644
index 82c0c84a86..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-8.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ping7/ping-9.png b/media/articles/saml/identity-providers/ping7/ping-9.png
deleted file mode 100644
index 5adfe1592d..0000000000
Binary files a/media/articles/saml/identity-providers/ping7/ping-9.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-1.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-1.png
deleted file mode 100644
index 02892d1c4f..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-1.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-10.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-10.png
deleted file mode 100644
index 86ce60e507..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-10.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-2.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-2.png
deleted file mode 100644
index 4b6700b557..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-2.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-3.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-3.png
deleted file mode 100644
index 3a62e31756..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-3.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-4.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-4.png
deleted file mode 100644
index 69e6013263..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-4.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-5.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-5.png
deleted file mode 100644
index f5e937eb82..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-5.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-6.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-6.png
deleted file mode 100644
index b2822584c3..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-6.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-7.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-7.png
deleted file mode 100644
index 20ad4de41a..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-7.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/salesforce/salesforceidp-9.png b/media/articles/saml/identity-providers/salesforce/salesforceidp-9.png
deleted file mode 100644
index d2b4522bc2..0000000000
Binary files a/media/articles/saml/identity-providers/salesforce/salesforceidp-9.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-attributes.png b/media/articles/saml/identity-providers/siteminder/siteminder-attributes.png
deleted file mode 100644
index 7ac1ff026b..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-attributes.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-encryption.png b/media/articles/saml/identity-providers/siteminder/siteminder-encryption.png
deleted file mode 100644
index 2419b7ee1e..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-encryption.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-general.png b/media/articles/saml/identity-providers/siteminder/siteminder-general.png
deleted file mode 100644
index 9d80031101..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-general.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-nameids.png b/media/articles/saml/identity-providers/siteminder/siteminder-nameids.png
deleted file mode 100644
index 2e254f6084..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-nameids.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-slo.png b/media/articles/saml/identity-providers/siteminder/siteminder-slo.png
deleted file mode 100644
index 2b3725bfbb..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-slo.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-sso.png b/media/articles/saml/identity-providers/siteminder/siteminder-sso.png
deleted file mode 100644
index 35e5a068c8..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-sso.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/siteminder/siteminder-users.png b/media/articles/saml/identity-providers/siteminder/siteminder-users.png
deleted file mode 100644
index 1f73fdad6e..0000000000
Binary files a/media/articles/saml/identity-providers/siteminder/siteminder-users.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/allowed-callback-urls.png b/media/articles/saml/identity-providers/ssocircle/allowed-callback-urls.png
deleted file mode 100755
index fd8a5ca82c..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/allowed-callback-urls.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/config-service-provider.png b/media/articles/saml/identity-providers/ssocircle/config-service-provider.png
deleted file mode 100755
index 5878c7760b..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/config-service-provider.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/configure-ssocircle-connection.png b/media/articles/saml/identity-providers/ssocircle/configure-ssocircle-connection.png
deleted file mode 100755
index 1cb9f7d759..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/configure-ssocircle-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png b/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png
deleted file mode 100755
index f6d944f014..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/create-new-client.png b/media/articles/saml/identity-providers/ssocircle/create-new-client.png
deleted file mode 100755
index 1c0fefa3fd..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/create-new-client.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/enable-connection.png b/media/articles/saml/identity-providers/ssocircle/enable-connection.png
deleted file mode 100755
index c53770b145..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/enable-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/hello-saml.png b/media/articles/saml/identity-providers/ssocircle/hello-saml.png
deleted file mode 100644
index 7f534154bb..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/hello-saml.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/is-admin.png b/media/articles/saml/identity-providers/ssocircle/is-admin.png
deleted file mode 100755
index 1a2d5154a9..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/is-admin.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/lock.png b/media/articles/saml/identity-providers/ssocircle/lock.png
deleted file mode 100644
index d9d5afd7f9..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/lock.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/login.png b/media/articles/saml/identity-providers/ssocircle/login.png
deleted file mode 100755
index 0cfa3dce3c..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/login.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/manage-provider-metadata.png b/media/articles/saml/identity-providers/ssocircle/manage-provider-metadata.png
deleted file mode 100755
index 6ad2266cba..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/manage-provider-metadata.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/metadata-snippet1.png b/media/articles/saml/identity-providers/ssocircle/metadata-snippet1.png
deleted file mode 100755
index 549055bc94..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/metadata-snippet1.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/metadata-snippet2.png b/media/articles/saml/identity-providers/ssocircle/metadata-snippet2.png
deleted file mode 100755
index 9a2f526d9f..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/metadata-snippet2.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/metadata-snippet3.png b/media/articles/saml/identity-providers/ssocircle/metadata-snippet3.png
deleted file mode 100755
index 2e61d8814f..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/metadata-snippet3.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/metadata-success.png b/media/articles/saml/identity-providers/ssocircle/metadata-success.png
deleted file mode 100755
index 1f9dcea85f..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/metadata-success.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/metadata-xml.png b/media/articles/saml/identity-providers/ssocircle/metadata-xml.png
deleted file mode 100755
index 4f05a1ac38..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/metadata-xml.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/saml-config-info.png b/media/articles/saml/identity-providers/ssocircle/saml-config-info.png
deleted file mode 100755
index 8272f823b8..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/saml-config-info.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/saml-consent.png b/media/articles/saml/identity-providers/ssocircle/saml-consent.png
deleted file mode 100755
index 40297edca5..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/saml-consent.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/set-up-client.png b/media/articles/saml/identity-providers/ssocircle/set-up-client.png
deleted file mode 100755
index b31e74ce18..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/set-up-client.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/test-connection.png b/media/articles/saml/identity-providers/ssocircle/test-connection.png
deleted file mode 100755
index 841e248a00..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/test-connection.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/ssocircle/user-profile.png b/media/articles/saml/identity-providers/ssocircle/user-profile.png
deleted file mode 100755
index ce661f93fc..0000000000
Binary files a/media/articles/saml/identity-providers/ssocircle/user-profile.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/addon-settings.png b/media/articles/scenarios/github-enterprise/addon-settings.png
deleted file mode 100755
index 6228300411..0000000000
Binary files a/media/articles/scenarios/github-enterprise/addon-settings.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/addon-usage.png b/media/articles/scenarios/github-enterprise/addon-usage.png
deleted file mode 100755
index 8adc2f2324..0000000000
Binary files a/media/articles/scenarios/github-enterprise/addon-usage.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/addons.png b/media/articles/scenarios/github-enterprise/addons.png
deleted file mode 100755
index a53bd63ff1..0000000000
Binary files a/media/articles/scenarios/github-enterprise/addons.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/auth-certificate.png b/media/articles/scenarios/github-enterprise/auth-certificate.png
deleted file mode 100755
index 2654d1721f..0000000000
Binary files a/media/articles/scenarios/github-enterprise/auth-certificate.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/auth-settings.png b/media/articles/scenarios/github-enterprise/auth-settings.png
deleted file mode 100755
index f54407f939..0000000000
Binary files a/media/articles/scenarios/github-enterprise/auth-settings.png and /dev/null differ
diff --git a/media/articles/scenarios/github-enterprise/clients.png b/media/articles/scenarios/github-enterprise/clients.png
deleted file mode 100755
index 70cd096afe..0000000000
Binary files a/media/articles/scenarios/github-enterprise/clients.png and /dev/null differ
diff --git a/media/articles/server-apis/authorize-m2m-for-api.png b/media/articles/server-apis/authorize-m2m-for-api.png
new file mode 100644
index 0000000000..803cb9c49c
Binary files /dev/null and b/media/articles/server-apis/authorize-m2m-for-api.png differ
diff --git a/media/articles/server-apis/configure-permissions.png b/media/articles/server-apis/configure-permissions.png
new file mode 100644
index 0000000000..dc9a192d2c
Binary files /dev/null and b/media/articles/server-apis/configure-permissions.png differ
diff --git a/media/articles/server-apis/configure-scopes.png b/media/articles/server-apis/configure-scopes.png
deleted file mode 100644
index bb0154bc9e..0000000000
Binary files a/media/articles/server-apis/configure-scopes.png and /dev/null differ
diff --git a/media/articles/server-apis/create-api.png b/media/articles/server-apis/create-api.png
index 27056cfd3d..bad32c1053 100644
Binary files a/media/articles/server-apis/create-api.png and b/media/articles/server-apis/create-api.png differ
diff --git a/media/articles/services/Auth0-Services-Advanced.pdf b/media/articles/services/Auth0-Services-Advanced.pdf
new file mode 100644
index 0000000000..4c1d113497
Binary files /dev/null and b/media/articles/services/Auth0-Services-Advanced.pdf differ
diff --git a/media/articles/services/Auth0-Services-Basic.pdf b/media/articles/services/Auth0-Services-Basic.pdf
new file mode 100644
index 0000000000..abd90bc5a5
Binary files /dev/null and b/media/articles/services/Auth0-Services-Basic.pdf differ
diff --git a/media/articles/services/Auth0-Services-Custom-Implementation.pdf b/media/articles/services/Auth0-Services-Custom-Implementation.pdf
new file mode 100644
index 0000000000..97b28fcc92
Binary files /dev/null and b/media/articles/services/Auth0-Services-Custom-Implementation.pdf differ
diff --git a/media/articles/services/Auth0-Services-Discovery-Workshop.pdf b/media/articles/services/Auth0-Services-Discovery-Workshop.pdf
new file mode 100644
index 0000000000..c0f84a3d37
Binary files /dev/null and b/media/articles/services/Auth0-Services-Discovery-Workshop.pdf differ
diff --git a/media/articles/services/Auth0-Services-HealthCheck.pdf b/media/articles/services/Auth0-Services-HealthCheck.pdf
new file mode 100644
index 0000000000..bc1180293d
Binary files /dev/null and b/media/articles/services/Auth0-Services-HealthCheck.pdf differ
diff --git a/media/articles/services/Auth0-Services-Premier-Success.pdf b/media/articles/services/Auth0-Services-Premier-Success.pdf
new file mode 100644
index 0000000000..92b4d75429
Binary files /dev/null and b/media/articles/services/Auth0-Services-Premier-Success.pdf differ
diff --git a/media/articles/services/Auth0-Services-Standard.pdf b/media/articles/services/Auth0-Services-Standard.pdf
new file mode 100644
index 0000000000..d32605d69e
Binary files /dev/null and b/media/articles/services/Auth0-Services-Standard.pdf differ
diff --git a/media/articles/services/file_type_icons-04.png b/media/articles/services/file_type_icons-04.png
new file mode 100644
index 0000000000..cd2a23977e
Binary files /dev/null and b/media/articles/services/file_type_icons-04.png differ
diff --git a/media/articles/sessions/cookie-fresh-interaction.png b/media/articles/sessions/cookie-fresh-interaction.png
new file mode 100644
index 0000000000..1c62fc5841
Binary files /dev/null and b/media/articles/sessions/cookie-fresh-interaction.png differ
diff --git a/media/articles/sessions/cookie-return-interaction.png b/media/articles/sessions/cookie-return-interaction.png
new file mode 100644
index 0000000000..a393449c20
Binary files /dev/null and b/media/articles/sessions/cookie-return-interaction.png differ
diff --git a/media/articles/sessions/initial-authentication.png b/media/articles/sessions/initial-authentication.png
new file mode 100644
index 0000000000..dcd05cb386
Binary files /dev/null and b/media/articles/sessions/initial-authentication.png differ
diff --git a/media/articles/sessions/maintain-auth0-session.png b/media/articles/sessions/maintain-auth0-session.png
new file mode 100644
index 0000000000..01cfda7178
Binary files /dev/null and b/media/articles/sessions/maintain-auth0-session.png differ
diff --git a/media/articles/sessions/prompt-user-extend-session.png b/media/articles/sessions/prompt-user-extend-session.png
new file mode 100644
index 0000000000..c98b0c304c
Binary files /dev/null and b/media/articles/sessions/prompt-user-extend-session.png differ
diff --git a/media/articles/sessions/seamless-sso.png b/media/articles/sessions/seamless-sso.png
new file mode 100644
index 0000000000..bceaa221f8
Binary files /dev/null and b/media/articles/sessions/seamless-sso.png differ
diff --git a/media/articles/sessions/use-case-storezero.png b/media/articles/sessions/use-case-storezero.png
new file mode 100644
index 0000000000..a650ee405a
Binary files /dev/null and b/media/articles/sessions/use-case-storezero.png differ
diff --git a/media/articles/sessions/user-explicitly-logs-out-of-app.png b/media/articles/sessions/user-explicitly-logs-out-of-app.png
new file mode 100644
index 0000000000..15f8085827
Binary files /dev/null and b/media/articles/sessions/user-explicitly-logs-out-of-app.png differ
diff --git a/media/articles/sessions/user-returns-to-initial-app.png b/media/articles/sessions/user-returns-to-initial-app.png
new file mode 100644
index 0000000000..9063c8872a
Binary files /dev/null and b/media/articles/sessions/user-returns-to-initial-app.png differ
diff --git a/media/articles/sso/integrations/sentry.png b/media/articles/sso/integrations/sentry.png
new file mode 100644
index 0000000000..eb0acfaa09
Binary files /dev/null and b/media/articles/sso/integrations/sentry.png differ
diff --git a/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png b/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png
index 8873d09beb..def04c31a8 100644
Binary files a/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png and b/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png differ
diff --git a/media/articles/sso/single-sign-on/clients-dashboard.png b/media/articles/sso/single-sign-on/clients-dashboard.png
index 592c73d75d..d0f86d3ead 100644
Binary files a/media/articles/sso/single-sign-on/clients-dashboard.png and b/media/articles/sso/single-sign-on/clients-dashboard.png differ
diff --git a/media/articles/sso/sso-session-mgmt-1.png b/media/articles/sso/sso-session-mgmt-1.png
new file mode 100644
index 0000000000..b03bdb1605
Binary files /dev/null and b/media/articles/sso/sso-session-mgmt-1.png differ
diff --git a/media/articles/sso/sso-session-mgmt-2.png b/media/articles/sso/sso-session-mgmt-2.png
new file mode 100644
index 0000000000..2f79cd4d98
Binary files /dev/null and b/media/articles/sso/sso-session-mgmt-2.png differ
diff --git a/media/articles/support/customer-reason.png b/media/articles/support/customer-reason.png
new file mode 100644
index 0000000000..dc658aa089
Binary files /dev/null and b/media/articles/support/customer-reason.png differ
diff --git a/media/articles/support/follow-up.png b/media/articles/support/follow-up.png
new file mode 100644
index 0000000000..809c59dbd3
Binary files /dev/null and b/media/articles/support/follow-up.png differ
diff --git a/media/articles/support/issue-types.png b/media/articles/support/issue-types.png
old mode 100755
new mode 100644
index 7da5f06594..295f040a1f
Binary files a/media/articles/support/issue-types.png and b/media/articles/support/issue-types.png differ
diff --git a/media/articles/support/open-ticket.png b/media/articles/support/open-ticket.png
old mode 100755
new mode 100644
index aa55a8c2ae..36bb6affd4
Binary files a/media/articles/support/open-ticket.png and b/media/articles/support/open-ticket.png differ
diff --git a/media/articles/support/pre-deployment-tests/choose-applications.png b/media/articles/support/pre-deployment-tests/choose-applications.png
new file mode 100644
index 0000000000..575161c6aa
Binary files /dev/null and b/media/articles/support/pre-deployment-tests/choose-applications.png differ
diff --git a/media/articles/support/pre-deployment-tests/choose-clients.png b/media/articles/support/pre-deployment-tests/choose-clients.png
deleted file mode 100644
index 68a2a060ee..0000000000
Binary files a/media/articles/support/pre-deployment-tests/choose-clients.png and /dev/null differ
diff --git a/media/articles/support/pre-deployment-tests/results.png b/media/articles/support/pre-deployment-tests/results.png
index c5e28bf6aa..86fb83a45f 100644
Binary files a/media/articles/support/pre-deployment-tests/results.png and b/media/articles/support/pre-deployment-tests/results.png differ
diff --git a/media/articles/support/pre-deployment-tests/tenants-tests.png b/media/articles/support/pre-deployment-tests/tenants-tests.png
index 1b7df8b606..96a8f364ee 100644
Binary files a/media/articles/support/pre-deployment-tests/tenants-tests.png and b/media/articles/support/pre-deployment-tests/tenants-tests.png differ
diff --git a/media/articles/support/pre-deployment-tests/tenants.png b/media/articles/support/pre-deployment-tests/tenants.png
index 5ab9bc6744..10b292166c 100644
Binary files a/media/articles/support/pre-deployment-tests/tenants.png and b/media/articles/support/pre-deployment-tests/tenants.png differ
diff --git a/media/articles/support/select-ticket.png b/media/articles/support/select-ticket.png
old mode 100755
new mode 100644
index a2e9f710f5..47f9ba4f41
Binary files a/media/articles/support/select-ticket.png and b/media/articles/support/select-ticket.png differ
diff --git a/media/articles/support/subscriptions/account-dropdown.png b/media/articles/support/subscriptions/account-dropdown.png
index f905e0798c..b827a4a725 100755
Binary files a/media/articles/support/subscriptions/account-dropdown.png and b/media/articles/support/subscriptions/account-dropdown.png differ
diff --git a/media/articles/support/subscriptions/billing.png b/media/articles/support/subscriptions/billing.png
index d2e7a87b93..82cbf31eaf 100755
Binary files a/media/articles/support/subscriptions/billing.png and b/media/articles/support/subscriptions/billing.png differ
diff --git a/media/articles/support/subscriptions/subscription.png b/media/articles/support/subscriptions/subscription.png
index 3f1a264c77..c9a6e97b89 100755
Binary files a/media/articles/support/subscriptions/subscription.png and b/media/articles/support/subscriptions/subscription.png differ
diff --git a/media/articles/support/subscriptions/upgrades.png b/media/articles/support/subscriptions/upgrades.png
index 909d585e59..68b3e7c387 100755
Binary files a/media/articles/support/subscriptions/upgrades.png and b/media/articles/support/subscriptions/upgrades.png differ
diff --git a/media/articles/support/update-ticket.png b/media/articles/support/update-ticket.png
old mode 100755
new mode 100644
index 3a11e08db0..5e2de4e432
Binary files a/media/articles/support/update-ticket.png and b/media/articles/support/update-ticket.png differ
diff --git a/media/articles/tokens/in-memory-token-storage.png b/media/articles/tokens/in-memory-token-storage.png
new file mode 100644
index 0000000000..f861df8bc2
Binary files /dev/null and b/media/articles/tokens/in-memory-token-storage.png differ
diff --git a/media/articles/tokens/non-rotating-tokens.png b/media/articles/tokens/non-rotating-tokens.png
new file mode 100644
index 0000000000..aa534efa99
Binary files /dev/null and b/media/articles/tokens/non-rotating-tokens.png differ
diff --git a/media/articles/tokens/reuse-detection1.png b/media/articles/tokens/reuse-detection1.png
new file mode 100644
index 0000000000..c1ab4f281f
Binary files /dev/null and b/media/articles/tokens/reuse-detection1.png differ
diff --git a/media/articles/tokens/reuse-detection2.png b/media/articles/tokens/reuse-detection2.png
new file mode 100644
index 0000000000..7dfa845785
Binary files /dev/null and b/media/articles/tokens/reuse-detection2.png differ
diff --git a/media/articles/tokens/rotating-tokens.png b/media/articles/tokens/rotating-tokens.png
new file mode 100644
index 0000000000..1dd6f4e469
Binary files /dev/null and b/media/articles/tokens/rotating-tokens.png differ
diff --git a/media/articles/tokens/rt-and-at.png b/media/articles/tokens/rt-and-at.png
new file mode 100644
index 0000000000..a8b5aa5bd0
Binary files /dev/null and b/media/articles/tokens/rt-and-at.png differ
diff --git a/media/articles/tokens/rtr-state-diagram.png b/media/articles/tokens/rtr-state-diagram.png
new file mode 100644
index 0000000000..71f9243bd1
Binary files /dev/null and b/media/articles/tokens/rtr-state-diagram.png differ
diff --git a/media/articles/topics/extend-extensibility.svg b/media/articles/topics/extend-extensibility.svg
new file mode 100644
index 0000000000..852f5992f8
--- /dev/null
+++ b/media/articles/topics/extend-extensibility.svg
@@ -0,0 +1,94 @@
+
+
+    
+    Extensibility
+    Created with Sketch.
+    
+    
+        
+            
+                
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                        
+                        
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                        
+                        
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                    
+                
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/tutorials/rapleaf-salesforce.png b/media/articles/tutorials/rapleaf-salesforce.png
index 789abcd827..7821847252 100644
Binary files a/media/articles/tutorials/rapleaf-salesforce.png and b/media/articles/tutorials/rapleaf-salesforce.png differ
diff --git a/media/articles/tutorials/save-as-har-with-content.png b/media/articles/tutorials/save-as-har-with-content.png
deleted file mode 100644
index 94cbc22073..0000000000
Binary files a/media/articles/tutorials/save-as-har-with-content.png and /dev/null differ
diff --git a/media/articles/tutorials/tenant-settings/device-flow-user-code-format.png b/media/articles/tutorials/tenant-settings/device-flow-user-code-format.png
new file mode 100644
index 0000000000..9de2188475
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/device-flow-user-code-format.png differ
diff --git a/media/articles/tutorials/tenant-settings/login-logout.png b/media/articles/tutorials/tenant-settings/login-logout.png
new file mode 100644
index 0000000000..34a6528279
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/login-logout.png differ
diff --git a/media/articles/tutorials/tenant-settings/logout-urls.png b/media/articles/tutorials/tenant-settings/logout-urls.png
deleted file mode 100644
index 95ad600e92..0000000000
Binary files a/media/articles/tutorials/tenant-settings/logout-urls.png and /dev/null differ
diff --git a/media/articles/tutorials/tenant-settings/session-timeout.png b/media/articles/tutorials/tenant-settings/session-timeout.png
index 40fe6d7632..100aade8ff 100644
Binary files a/media/articles/tutorials/tenant-settings/session-timeout.png and b/media/articles/tutorials/tenant-settings/session-timeout.png differ
diff --git a/media/articles/tutorials/tenant-settings/tenant-advanced-extensibility.png b/media/articles/tutorials/tenant-settings/tenant-advanced-extensibility.png
new file mode 100644
index 0000000000..8dbd0e6c7a
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/tenant-advanced-extensibility.png differ
diff --git a/media/articles/tutorials/tenant-settings/tenant-advanced-migrations.png b/media/articles/tutorials/tenant-settings/tenant-advanced-migrations.png
new file mode 100644
index 0000000000..96e4e27e44
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/tenant-advanced-migrations.png differ
diff --git a/media/articles/tutorials/tenant-settings/tenant-advanced-settings.png b/media/articles/tutorials/tenant-settings/tenant-advanced-settings.png
new file mode 100644
index 0000000000..0328adde1b
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/tenant-advanced-settings.png differ
diff --git a/media/articles/universal-login/experience-picker.png b/media/articles/universal-login/experience-picker.png
new file mode 100644
index 0000000000..0f7fa716a4
Binary files /dev/null and b/media/articles/universal-login/experience-picker.png differ
diff --git a/media/articles/universal-login/idp-domains.png b/media/articles/universal-login/idp-domains.png
new file mode 100644
index 0000000000..698604a1b9
Binary files /dev/null and b/media/articles/universal-login/idp-domains.png differ
diff --git a/media/articles/universal-login/languages.png b/media/articles/universal-login/languages.png
new file mode 100644
index 0000000000..86542398e7
Binary files /dev/null and b/media/articles/universal-login/languages.png differ
diff --git a/media/articles/universal-login/login.png b/media/articles/universal-login/login.png
new file mode 100644
index 0000000000..dc1d09acde
Binary files /dev/null and b/media/articles/universal-login/login.png differ
diff --git a/media/articles/universal-login/new-ul-mfa1.png b/media/articles/universal-login/new-ul-mfa1.png
new file mode 100644
index 0000000000..2c6fc8422e
Binary files /dev/null and b/media/articles/universal-login/new-ul-mfa1.png differ
diff --git a/media/articles/universal-login/new-ul-mfa2.png b/media/articles/universal-login/new-ul-mfa2.png
new file mode 100644
index 0000000000..76e0ee5e55
Binary files /dev/null and b/media/articles/universal-login/new-ul-mfa2.png differ
diff --git a/media/articles/universal-login/page-templates-footer.png b/media/articles/universal-login/page-templates-footer.png
new file mode 100644
index 0000000000..3eb768107f
Binary files /dev/null and b/media/articles/universal-login/page-templates-footer.png differ
diff --git a/media/articles/universal-login/page-templates-layout.png b/media/articles/universal-login/page-templates-layout.png
new file mode 100644
index 0000000000..f53d9aa856
Binary files /dev/null and b/media/articles/universal-login/page-templates-layout.png differ
diff --git a/media/articles/universal-login/password-reset.png b/media/articles/universal-login/password-reset.png
new file mode 100644
index 0000000000..dcb1af8fe3
Binary files /dev/null and b/media/articles/universal-login/password-reset.png differ
diff --git a/media/articles/universal-login/settings.png b/media/articles/universal-login/settings.png
new file mode 100644
index 0000000000..76e453c417
Binary files /dev/null and b/media/articles/universal-login/settings.png differ
diff --git a/media/articles/universal-login/text-customization/accept-invitation.png b/media/articles/universal-login/text-customization/accept-invitation.png
new file mode 100644
index 0000000000..9c79dcfd38
Binary files /dev/null and b/media/articles/universal-login/text-customization/accept-invitation.png differ
diff --git a/media/articles/universal-login/text-customization/consent.png b/media/articles/universal-login/text-customization/consent.png
new file mode 100644
index 0000000000..d92a3b1c40
Binary files /dev/null and b/media/articles/universal-login/text-customization/consent.png differ
diff --git a/media/articles/universal-login/text-customization/device-code-activation-allowed.png b/media/articles/universal-login/text-customization/device-code-activation-allowed.png
new file mode 100644
index 0000000000..b27d558126
Binary files /dev/null and b/media/articles/universal-login/text-customization/device-code-activation-allowed.png differ
diff --git a/media/articles/universal-login/text-customization/device-code-activation-denied.png b/media/articles/universal-login/text-customization/device-code-activation-denied.png
new file mode 100644
index 0000000000..ce34dea04b
Binary files /dev/null and b/media/articles/universal-login/text-customization/device-code-activation-denied.png differ
diff --git a/media/articles/universal-login/text-customization/device-code-activation.png b/media/articles/universal-login/text-customization/device-code-activation.png
new file mode 100644
index 0000000000..bb92e1bf1f
Binary files /dev/null and b/media/articles/universal-login/text-customization/device-code-activation.png differ
diff --git a/media/articles/universal-login/text-customization/device-code-confirmation.png b/media/articles/universal-login/text-customization/device-code-confirmation.png
new file mode 100644
index 0000000000..61edcebe59
Binary files /dev/null and b/media/articles/universal-login/text-customization/device-code-confirmation.png differ
diff --git a/media/articles/universal-login/text-customization/email-otp-challenge.png b/media/articles/universal-login/text-customization/email-otp-challenge.png
new file mode 100644
index 0000000000..f36c7f940c
Binary files /dev/null and b/media/articles/universal-login/text-customization/email-otp-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/email-verification-result.png b/media/articles/universal-login/text-customization/email-verification-result.png
new file mode 100644
index 0000000000..79afab7fdd
Binary files /dev/null and b/media/articles/universal-login/text-customization/email-verification-result.png differ
diff --git a/media/articles/universal-login/text-customization/login-email-verification.png b/media/articles/universal-login/text-customization/login-email-verification.png
new file mode 100644
index 0000000000..15e74118df
Binary files /dev/null and b/media/articles/universal-login/text-customization/login-email-verification.png differ
diff --git a/media/articles/universal-login/text-customization/login-id.png b/media/articles/universal-login/text-customization/login-id.png
new file mode 100644
index 0000000000..da16d5679f
Binary files /dev/null and b/media/articles/universal-login/text-customization/login-id.png differ
diff --git a/media/articles/universal-login/text-customization/login-password.png b/media/articles/universal-login/text-customization/login-password.png
new file mode 100644
index 0000000000..391e339b5a
Binary files /dev/null and b/media/articles/universal-login/text-customization/login-password.png differ
diff --git a/media/articles/universal-login/text-customization/login.png b/media/articles/universal-login/text-customization/login.png
new file mode 100644
index 0000000000..27d2f310f5
Binary files /dev/null and b/media/articles/universal-login/text-customization/login.png differ
diff --git a/media/articles/universal-login/text-customization/logout.png b/media/articles/universal-login/text-customization/logout.png
new file mode 100644
index 0000000000..20590499ac
Binary files /dev/null and b/media/articles/universal-login/text-customization/logout.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-begin-enroll-options.png b/media/articles/universal-login/text-customization/mfa-begin-enroll-options.png
new file mode 100644
index 0000000000..522336e8bd
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-begin-enroll-options.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-country-codes.png b/media/articles/universal-login/text-customization/mfa-country-codes.png
new file mode 100644
index 0000000000..5fdf7af058
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-country-codes.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-detect-browser-capabilities.png b/media/articles/universal-login/text-customization/mfa-detect-browser-capabilities.png
new file mode 100644
index 0000000000..a20e37645c
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-detect-browser-capabilities.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-email-challenge.png b/media/articles/universal-login/text-customization/mfa-email-challenge.png
new file mode 100644
index 0000000000..f10acff9b9
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-email-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-email-list.png b/media/articles/universal-login/text-customization/mfa-email-list.png
new file mode 100644
index 0000000000..c3a9f3e1a0
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-email-list.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-enroll-result.png b/media/articles/universal-login/text-customization/mfa-enroll-result.png
new file mode 100644
index 0000000000..c81c8c69b5
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-enroll-result.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-login-options.png b/media/articles/universal-login/text-customization/mfa-login-options.png
new file mode 100644
index 0000000000..3415fa640a
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-login-options.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-otp-challenge.png b/media/articles/universal-login/text-customization/mfa-otp-challenge.png
new file mode 100644
index 0000000000..fc4990deaf
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-otp-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-otp-enrollment-code.png b/media/articles/universal-login/text-customization/mfa-otp-enrollment-code.png
new file mode 100644
index 0000000000..3c4069e843
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-otp-enrollment-code.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-otp-enrollment-qr.png b/media/articles/universal-login/text-customization/mfa-otp-enrollment-qr.png
new file mode 100644
index 0000000000..03394a8a45
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-otp-enrollment-qr.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-phone-challenge.png b/media/articles/universal-login/text-customization/mfa-phone-challenge.png
new file mode 100644
index 0000000000..18e3df2d46
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-phone-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-phone-enrollment.png b/media/articles/universal-login/text-customization/mfa-phone-enrollment.png
new file mode 100644
index 0000000000..cde0635044
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-phone-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-challenge-code.png b/media/articles/universal-login/text-customization/mfa-push-challenge-code.png
new file mode 100644
index 0000000000..d0c3c76559
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-challenge-code.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-challenge-push.png b/media/articles/universal-login/text-customization/mfa-push-challenge-push.png
new file mode 100644
index 0000000000..b0418ba914
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-challenge-push.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-enrollment-code.png b/media/articles/universal-login/text-customization/mfa-push-enrollment-code.png
new file mode 100644
index 0000000000..673c38c18e
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-enrollment-code.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-enrollment-qr.png b/media/articles/universal-login/text-customization/mfa-push-enrollment-qr.png
new file mode 100644
index 0000000000..4bf373a388
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-enrollment-qr.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-list.png b/media/articles/universal-login/text-customization/mfa-push-list.png
new file mode 100644
index 0000000000..12cdb7d7ad
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-list.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-success.png b/media/articles/universal-login/text-customization/mfa-push-success.png
new file mode 100644
index 0000000000..6b9ef762f2
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-success.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-push-welcome.png b/media/articles/universal-login/text-customization/mfa-push-welcome.png
new file mode 100644
index 0000000000..8936504152
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-push-welcome.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-recovery-code-challenge.png b/media/articles/universal-login/text-customization/mfa-recovery-code-challenge.png
new file mode 100644
index 0000000000..449cdd41f5
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-recovery-code-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-recovery-code-enrollment.png b/media/articles/universal-login/text-customization/mfa-recovery-code-enrollment.png
new file mode 100644
index 0000000000..da115eaf91
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-recovery-code-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-sms-challenge.png b/media/articles/universal-login/text-customization/mfa-sms-challenge.png
new file mode 100644
index 0000000000..c917efb4d5
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-sms-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-sms-enrollment.png b/media/articles/universal-login/text-customization/mfa-sms-enrollment.png
new file mode 100644
index 0000000000..1789f9618e
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-sms-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-sms-list.png b/media/articles/universal-login/text-customization/mfa-sms-list.png
new file mode 100644
index 0000000000..4e21a59266
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-sms-list.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-voice-challenge.png b/media/articles/universal-login/text-customization/mfa-voice-challenge.png
new file mode 100644
index 0000000000..1f84f163f0
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-voice-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-voice-enrollment.png b/media/articles/universal-login/text-customization/mfa-voice-enrollment.png
new file mode 100644
index 0000000000..966993166e
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-voice-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-change-key-nickname.png b/media/articles/universal-login/text-customization/mfa-webauth-change-key-nickname.png
new file mode 100644
index 0000000000..3d10cc03dd
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-change-key-nickname.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-error.png b/media/articles/universal-login/text-customization/mfa-webauth-error.png
new file mode 100644
index 0000000000..3d10cc03dd
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-error.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-platform-challenge.png b/media/articles/universal-login/text-customization/mfa-webauth-platform-challenge.png
new file mode 100644
index 0000000000..660009d356
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-platform-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-platform-enrollment.png b/media/articles/universal-login/text-customization/mfa-webauth-platform-enrollment.png
new file mode 100644
index 0000000000..985aba8f3c
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-platform-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-roaming-challenge.png b/media/articles/universal-login/text-customization/mfa-webauth-roaming-challenge.png
new file mode 100644
index 0000000000..0e3408fedc
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-roaming-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauth-roaming-enrollment.png b/media/articles/universal-login/text-customization/mfa-webauth-roaming-enrollment.png
new file mode 100644
index 0000000000..857af6262c
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauth-roaming-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-change-key-nickname.png b/media/articles/universal-login/text-customization/mfa-webauthn-change-key-nickname.png
new file mode 100644
index 0000000000..3dd3f68ef9
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-change-key-nickname.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-enrollment-success.png b/media/articles/universal-login/text-customization/mfa-webauthn-enrollment-success.png
new file mode 100644
index 0000000000..e721da0ded
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-enrollment-success.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-error.png b/media/articles/universal-login/text-customization/mfa-webauthn-error.png
new file mode 100644
index 0000000000..e131faeb8a
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-error.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-guidance-challenge.png b/media/articles/universal-login/text-customization/mfa-webauthn-guidance-challenge.png
new file mode 100644
index 0000000000..3b6994fbd9
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-guidance-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-guidance-enrollment.png b/media/articles/universal-login/text-customization/mfa-webauthn-guidance-enrollment.png
new file mode 100644
index 0000000000..f84bfabd05
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-guidance-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-login-faster.png b/media/articles/universal-login/text-customization/mfa-webauthn-login-faster.png
new file mode 100644
index 0000000000..3c6a3ce92a
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-login-faster.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-not-available-error.png b/media/articles/universal-login/text-customization/mfa-webauthn-not-available-error.png
new file mode 100644
index 0000000000..20417854f6
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-not-available-error.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-platform-challenge.png b/media/articles/universal-login/text-customization/mfa-webauthn-platform-challenge.png
new file mode 100644
index 0000000000..06e3a304f6
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-platform-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-platform-enrollment.png b/media/articles/universal-login/text-customization/mfa-webauthn-platform-enrollment.png
new file mode 100644
index 0000000000..8b13a4491f
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-platform-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-roaming-challenge.png b/media/articles/universal-login/text-customization/mfa-webauthn-roaming-challenge.png
new file mode 100644
index 0000000000..9a52a236e5
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-roaming-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/mfa-webauthn-roaming-enrollment.png b/media/articles/universal-login/text-customization/mfa-webauthn-roaming-enrollment.png
new file mode 100644
index 0000000000..cb93d4bfcb
Binary files /dev/null and b/media/articles/universal-login/text-customization/mfa-webauthn-roaming-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/organization-picker-rev2.png b/media/articles/universal-login/text-customization/organization-picker-rev2.png
new file mode 100644
index 0000000000..8ddabeabde
Binary files /dev/null and b/media/articles/universal-login/text-customization/organization-picker-rev2.png differ
diff --git a/media/articles/universal-login/text-customization/organization-picker.png b/media/articles/universal-login/text-customization/organization-picker.png
new file mode 100644
index 0000000000..658dc7de35
Binary files /dev/null and b/media/articles/universal-login/text-customization/organization-picker.png differ
diff --git a/media/articles/universal-login/text-customization/organization-selection.png b/media/articles/universal-login/text-customization/organization-selection.png
new file mode 100644
index 0000000000..22d073ab31
Binary files /dev/null and b/media/articles/universal-login/text-customization/organization-selection.png differ
diff --git a/media/articles/universal-login/text-customization/passkey-enrollment-local.png b/media/articles/universal-login/text-customization/passkey-enrollment-local.png
new file mode 100644
index 0000000000..4032739def
Binary files /dev/null and b/media/articles/universal-login/text-customization/passkey-enrollment-local.png differ
diff --git a/media/articles/universal-login/text-customization/passkey-enrollment.png b/media/articles/universal-login/text-customization/passkey-enrollment.png
new file mode 100644
index 0000000000..c141b6cf47
Binary files /dev/null and b/media/articles/universal-login/text-customization/passkey-enrollment.png differ
diff --git a/media/articles/universal-login/text-customization/redeem-ticket.png b/media/articles/universal-login/text-customization/redeem-ticket.png
new file mode 100644
index 0000000000..13a12e68e6
Binary files /dev/null and b/media/articles/universal-login/text-customization/redeem-ticket.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-email.png b/media/articles/universal-login/text-customization/reset-password-email.png
new file mode 100644
index 0000000000..34a159c717
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-email.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-error.png b/media/articles/universal-login/text-customization/reset-password-error.png
new file mode 100644
index 0000000000..0192b4bf99
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-error.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-email-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-email-challenge.png
new file mode 100644
index 0000000000..5dfba78b9f
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-email-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-otp-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-otp-challenge.png
new file mode 100644
index 0000000000..6eba7c75ad
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-otp-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-phone-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-phone-challenge.png
new file mode 100644
index 0000000000..4fe7eea4e4
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-phone-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-push-challenge-push.png b/media/articles/universal-login/text-customization/reset-password-mfa-push-challenge-push.png
new file mode 100644
index 0000000000..e8d5bcd61c
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-push-challenge-push.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-recovery-code-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-recovery-code-challenge.png
new file mode 100644
index 0000000000..e3cdee6139
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-recovery-code-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-sms-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-sms-challenge.png
new file mode 100644
index 0000000000..c4da4c43f7
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-sms-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-voice-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-voice-challenge.png
new file mode 100644
index 0000000000..ff33dd28a3
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-voice-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-platform-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-platform-challenge.png
new file mode 100644
index 0000000000..4ae7622112
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-platform-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-roaming-challenge.png b/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-roaming-challenge.png
new file mode 100644
index 0000000000..37d5e5b390
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-mfa-webauthn-roaming-challenge.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-request.png b/media/articles/universal-login/text-customization/reset-password-request.png
new file mode 100644
index 0000000000..207116f116
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-request.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password-success.png b/media/articles/universal-login/text-customization/reset-password-success.png
new file mode 100644
index 0000000000..5cbc827ab0
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password-success.png differ
diff --git a/media/articles/universal-login/text-customization/reset-password.png b/media/articles/universal-login/text-customization/reset-password.png
new file mode 100644
index 0000000000..5614f9f83b
Binary files /dev/null and b/media/articles/universal-login/text-customization/reset-password.png differ
diff --git a/media/articles/universal-login/text-customization/signup-id.png b/media/articles/universal-login/text-customization/signup-id.png
new file mode 100644
index 0000000000..c7766a1342
Binary files /dev/null and b/media/articles/universal-login/text-customization/signup-id.png differ
diff --git a/media/articles/universal-login/text-customization/signup-password.png b/media/articles/universal-login/text-customization/signup-password.png
new file mode 100644
index 0000000000..b902cf00a6
Binary files /dev/null and b/media/articles/universal-login/text-customization/signup-password.png differ
diff --git a/media/articles/universal-login/text-customization/signup.png b/media/articles/universal-login/text-customization/signup.png
new file mode 100644
index 0000000000..f4ee2c4e1b
Binary files /dev/null and b/media/articles/universal-login/text-customization/signup.png differ
diff --git a/media/articles/universal-login/text-customization/status.png b/media/articles/universal-login/text-customization/status.png
new file mode 100644
index 0000000000..6762363eb4
Binary files /dev/null and b/media/articles/universal-login/text-customization/status.png differ
diff --git a/media/articles/user-profile/user-picture.png b/media/articles/user-profile/user-picture.png
index 9999048766..e67ff59a48 100644
Binary files a/media/articles/user-profile/user-picture.png and b/media/articles/user-profile/user-picture.png differ
diff --git a/media/articles/user-profile/user1.png b/media/articles/user-profile/user1.png
index e62b13eca2..0881f7d734 100644
Binary files a/media/articles/user-profile/user1.png and b/media/articles/user-profile/user1.png differ
diff --git a/media/articles/user-profile/user4.png b/media/articles/user-profile/user4.png
index 33a5878b3b..6a1d47b417 100644
Binary files a/media/articles/user-profile/user4.png and b/media/articles/user-profile/user4.png differ
diff --git a/media/articles/user-profile/user5.png b/media/articles/user-profile/user5.png
new file mode 100644
index 0000000000..aea7bf77e4
Binary files /dev/null and b/media/articles/user-profile/user5.png differ
diff --git a/media/articles/user-profile/user6.png b/media/articles/user-profile/user6.png
new file mode 100644
index 0000000000..c79a49c290
Binary files /dev/null and b/media/articles/user-profile/user6.png differ
diff --git a/media/articles/users/dashboard.png b/media/articles/users/dashboard.png
index 8197931e3c..5e52823b9d 100644
Binary files a/media/articles/users/dashboard.png and b/media/articles/users/dashboard.png differ
diff --git a/media/articles/users/user-profile.png b/media/articles/users/user-profile.png
index e7ea8f9d40..4d37f204c6 100644
Binary files a/media/articles/users/user-profile.png and b/media/articles/users/user-profile.png differ
diff --git a/media/articles/users/users-tab.png b/media/articles/users/users-tab.png
index 01d72a419f..a14074318b 100644
Binary files a/media/articles/users/users-tab.png and b/media/articles/users/users-tab.png differ
diff --git a/media/articles/videos/get-started/get-started.png b/media/articles/videos/get-started/get-started.png
new file mode 100644
index 0000000000..58ef00b057
Binary files /dev/null and b/media/articles/videos/get-started/get-started.png differ
diff --git a/media/connections/37signals.jpg b/media/connections/37signals.jpg
deleted file mode 100644
index 2ac009829c..0000000000
Binary files a/media/connections/37signals.jpg and /dev/null differ
diff --git a/media/connections/37signals.png b/media/connections/37signals.png
deleted file mode 100644
index f30f1bcd8e..0000000000
Binary files a/media/connections/37signals.png and /dev/null differ
diff --git a/media/connections/ad.png b/media/connections/ad.png
new file mode 100644
index 0000000000..dfe7a48863
Binary files /dev/null and b/media/connections/ad.png differ
diff --git a/media/connections/adfs.png b/media/connections/adfs.png
new file mode 100644
index 0000000000..c6ebbeffc2
Binary files /dev/null and b/media/connections/adfs.png differ
diff --git a/media/connections/amazon.png b/media/connections/amazon.png
index eabfbf852e..02e3678e64 100644
Binary files a/media/connections/amazon.png and b/media/connections/amazon.png differ
diff --git a/media/connections/apple.png b/media/connections/apple.png
new file mode 100644
index 0000000000..de610ca8d9
Binary files /dev/null and b/media/connections/apple.png differ
diff --git a/media/connections/aws.png b/media/connections/aws.png
new file mode 100644
index 0000000000..69829240de
Binary files /dev/null and b/media/connections/aws.png differ
diff --git a/media/connections/azure.png b/media/connections/azure.png
index f2eecc852e..74d816863b 100644
Binary files a/media/connections/azure.png and b/media/connections/azure.png differ
diff --git a/media/connections/baidu.png b/media/connections/baidu.png
index 3b2ffa1858..92b762e49f 100644
Binary files a/media/connections/baidu.png and b/media/connections/baidu.png differ
diff --git a/media/connections/basecamp.png b/media/connections/basecamp.png
index 6350ad680a..2b0f0d1260 100644
Binary files a/media/connections/basecamp.png and b/media/connections/basecamp.png differ
diff --git a/media/connections/bitbucket.png b/media/connections/bitbucket.png
index 95f97ea353..e76b8b2892 100644
Binary files a/media/connections/bitbucket.png and b/media/connections/bitbucket.png differ
diff --git a/media/connections/box.png b/media/connections/box.png
index ddfb3909d8..b3cf9d7d77 100644
Binary files a/media/connections/box.png and b/media/connections/box.png differ
diff --git a/media/connections/clever.png b/media/connections/clever.png
new file mode 100644
index 0000000000..7dc4d967c2
Binary files /dev/null and b/media/connections/clever.png differ
diff --git a/media/connections/dashboard-tenant-edit_view-advanced_migrations_azure-adfs.png b/media/connections/dashboard-tenant-edit_view-advanced_migrations_azure-adfs.png
new file mode 100644
index 0000000000..34bd4cbbb5
Binary files /dev/null and b/media/connections/dashboard-tenant-edit_view-advanced_migrations_azure-adfs.png differ
diff --git a/media/connections/digitalocean.png b/media/connections/digitalocean.png
new file mode 100644
index 0000000000..13a0b42e05
Binary files /dev/null and b/media/connections/digitalocean.png differ
diff --git a/media/connections/discord.png b/media/connections/discord.png
new file mode 100644
index 0000000000..9aaddd93c0
Binary files /dev/null and b/media/connections/discord.png differ
diff --git a/media/connections/dribbble.png b/media/connections/dribbble.png
new file mode 100644
index 0000000000..48ff631772
Binary files /dev/null and b/media/connections/dribbble.png differ
diff --git a/media/connections/dropbox.png b/media/connections/dropbox.png
index a6c9eb5988..968e64a29c 100644
Binary files a/media/connections/dropbox.png and b/media/connections/dropbox.png differ
diff --git a/media/connections/dwolla.png b/media/connections/dwolla.png
index b4c6e3fc53..9fec132914 100644
Binary files a/media/connections/dwolla.png and b/media/connections/dwolla.png differ
diff --git a/media/connections/evernote.png b/media/connections/evernote.png
index 47b365b194..2ca0b34c36 100644
Binary files a/media/connections/evernote.png and b/media/connections/evernote.png differ
diff --git a/media/connections/evernote.svg b/media/connections/evernote.svg
deleted file mode 100644
index 0bc868d619..0000000000
--- a/media/connections/evernote.svg
+++ /dev/null
@@ -1,43 +0,0 @@
-
-
-
-
-evernote_logo_4c
-Created with Sketch.
-
-	
-		
-			
-			
-			
-				
-					
-				
-			
-			
-				
-					
-				
-			
-			
-		
-	
-
-
diff --git a/media/connections/exact.png b/media/connections/exact.png
index 457ef25b0c..2f1d76ff16 100644
Binary files a/media/connections/exact.png and b/media/connections/exact.png differ
diff --git a/media/connections/facebook.png b/media/connections/facebook.png
index d87aad9d81..b749aaeb74 100644
Binary files a/media/connections/facebook.png and b/media/connections/facebook.png differ
diff --git a/media/connections/figma.png b/media/connections/figma.png
new file mode 100644
index 0000000000..e9e73c9b67
Binary files /dev/null and b/media/connections/figma.png differ
diff --git a/media/connections/fitbit.png b/media/connections/fitbit.png
index f632eab127..8cd852434e 100644
Binary files a/media/connections/fitbit.png and b/media/connections/fitbit.png differ
diff --git a/media/connections/github.png b/media/connections/github.png
index 1ae9253d93..2059bafe96 100644
Binary files a/media/connections/github.png and b/media/connections/github.png differ
diff --git a/media/connections/google.png b/media/connections/google.png
index 688a857a10..315650f644 100644
Binary files a/media/connections/google.png and b/media/connections/google.png differ
diff --git a/media/connections/google.svg b/media/connections/google.svg
deleted file mode 100644
index 30dda79ca0..0000000000
--- a/media/connections/google.svg
+++ /dev/null
@@ -1,51 +0,0 @@
-
-
-
-
-
-	
-		
-		
-		
-		
-	
-	
-	
-		
-		
-		
-		
-	
-	
-	
-		
-		
-		
-		
-		
-		
-	
-	
-	
-		
-		
-		
-		
-	
-	
-	
-		
-		
-		
-		
-	
-	
-	
-		
-		
-		
-		
-	
-	
-
-
\ No newline at end of file
diff --git a/media/connections/gsuite.png b/media/connections/gsuite.png
new file mode 100644
index 0000000000..01ef9fe315
Binary files /dev/null and b/media/connections/gsuite.png differ
diff --git a/media/connections/imgur.png b/media/connections/imgur.png
new file mode 100644
index 0000000000..350450570d
Binary files /dev/null and b/media/connections/imgur.png differ
diff --git a/media/connections/ipaddress.png b/media/connections/ipaddress.png
new file mode 100644
index 0000000000..e35c41ad39
Binary files /dev/null and b/media/connections/ipaddress.png differ
diff --git a/media/connections/ldap.png b/media/connections/ldap.png
index 22d0dca094..dfe7a48863 100644
Binary files a/media/connections/ldap.png and b/media/connections/ldap.png differ
diff --git a/media/connections/line.png b/media/connections/line.png
new file mode 100644
index 0000000000..1cb5350dc8
Binary files /dev/null and b/media/connections/line.png differ
diff --git a/media/connections/linkedin.png b/media/connections/linkedin.png
index 0824b22b9a..794f55a2a6 100644
Binary files a/media/connections/linkedin.png and b/media/connections/linkedin.png differ
diff --git a/media/connections/microsoft.png b/media/connections/microsoft.png
new file mode 100644
index 0000000000..b82fc37326
Binary files /dev/null and b/media/connections/microsoft.png differ
diff --git a/media/connections/oidc.png b/media/connections/oidc.png
new file mode 100644
index 0000000000..2b2127bbf9
Binary files /dev/null and b/media/connections/oidc.png differ
diff --git a/media/connections/okta.png b/media/connections/okta.png
new file mode 100644
index 0000000000..f9957b1767
Binary files /dev/null and b/media/connections/okta.png differ
diff --git a/media/connections/paypal.png b/media/connections/paypal.png
index a0fa6494df..7cea938381 100644
Binary files a/media/connections/paypal.png and b/media/connections/paypal.png differ
diff --git a/media/connections/pingfederate.png b/media/connections/pingfederate.png
index 6ed76c6760..191b957742 100644
Binary files a/media/connections/pingfederate.png and b/media/connections/pingfederate.png differ
diff --git a/media/connections/pinterest.png b/media/connections/pinterest.png
new file mode 100644
index 0000000000..28e50ef480
Binary files /dev/null and b/media/connections/pinterest.png differ
diff --git a/media/connections/planning-center.png b/media/connections/planning-center.png
index 87f41c7ec8..2d9998267b 100644
Binary files a/media/connections/planning-center.png and b/media/connections/planning-center.png differ
diff --git a/media/connections/quickbooks.png b/media/connections/quickbooks.png
new file mode 100644
index 0000000000..665c2b782b
Binary files /dev/null and b/media/connections/quickbooks.png differ
diff --git a/media/connections/renren.png b/media/connections/renren.png
index 4cd012bc8f..94056a0b21 100644
Binary files a/media/connections/renren.png and b/media/connections/renren.png differ
diff --git a/media/connections/salesforce.png b/media/connections/salesforce.png
index 85e654c3ae..44c1dccf42 100644
Binary files a/media/connections/salesforce.png and b/media/connections/salesforce.png differ
diff --git a/media/connections/saml.png b/media/connections/saml.png
index f52aa8580c..2b2127bbf9 100644
Binary files a/media/connections/saml.png and b/media/connections/saml.png differ
diff --git a/media/connections/shop.png b/media/connections/shop.png
new file mode 100644
index 0000000000..737591d657
Binary files /dev/null and b/media/connections/shop.png differ
diff --git a/media/connections/shopify.png b/media/connections/shopify.png
index 5068b8a88f..dbcd47684c 100644
Binary files a/media/connections/shopify.png and b/media/connections/shopify.png differ
diff --git a/media/connections/slack.png b/media/connections/slack.png
new file mode 100644
index 0000000000..e009aba0cb
Binary files /dev/null and b/media/connections/slack.png differ
diff --git a/media/connections/spotify.png b/media/connections/spotify.png
new file mode 100644
index 0000000000..ce8ac5ab7f
Binary files /dev/null and b/media/connections/spotify.png differ
diff --git a/media/connections/stripe.png b/media/connections/stripe.png
new file mode 100644
index 0000000000..403314f4c7
Binary files /dev/null and b/media/connections/stripe.png differ
diff --git a/media/connections/twitch.png b/media/connections/twitch.png
new file mode 100644
index 0000000000..73140fd33e
Binary files /dev/null and b/media/connections/twitch.png differ
diff --git a/media/connections/twitter.png b/media/connections/twitter.png
index 499b200dc5..2e91c6776d 100644
Binary files a/media/connections/twitter.png and b/media/connections/twitter.png differ
diff --git a/media/connections/vimeo.png b/media/connections/vimeo.png
new file mode 100644
index 0000000000..c16df29979
Binary files /dev/null and b/media/connections/vimeo.png differ
diff --git a/media/connections/vkontake.png b/media/connections/vkontake.png
deleted file mode 100644
index a4595e1856..0000000000
Binary files a/media/connections/vkontake.png and /dev/null differ
diff --git a/media/connections/vkontakte.png b/media/connections/vkontakte.png
index eecb7e3757..1e1e22e9b1 100644
Binary files a/media/connections/vkontakte.png and b/media/connections/vkontakte.png differ
diff --git a/media/connections/weibo.png b/media/connections/weibo.png
index a03be4a066..c690548b02 100644
Binary files a/media/connections/weibo.png and b/media/connections/weibo.png differ
diff --git a/media/connections/wordpress.png b/media/connections/wordpress.png
index 47ec42880b..427f5bcf13 100644
Binary files a/media/connections/wordpress.png and b/media/connections/wordpress.png differ
diff --git a/media/connections/yahoo.png b/media/connections/yahoo.png
index 9bd64072af..0f388cc5ea 100644
Binary files a/media/connections/yahoo.png and b/media/connections/yahoo.png differ
diff --git a/media/connections/yammer.png b/media/connections/yammer.png
index 494a24eeb9..969cff7165 100644
Binary files a/media/connections/yammer.png and b/media/connections/yammer.png differ
diff --git a/media/connections/yandex.png b/media/connections/yandex.png
index faa3f1abfa..040385ce5c 100644
Binary files a/media/connections/yandex.png and b/media/connections/yandex.png differ
diff --git a/media/platforms/angular.png b/media/platforms/angular.png
index 0702b6a076..c510293918 100644
Binary files a/media/platforms/angular.png and b/media/platforms/angular.png differ
diff --git a/media/platforms/device.svg b/media/platforms/device.svg
new file mode 100644
index 0000000000..8f57940f73
--- /dev/null
+++ b/media/platforms/device.svg
@@ -0,0 +1,18 @@
+
+
+    
+    DeviceIcon
+    Created with Sketch.
+    
+        
+            
+                
+                
+                    
+                    
+                
+                
+            
+        
+    
+
diff --git a/media/platforms/django.png b/media/platforms/django.png
new file mode 100644
index 0000000000..a1e6166ad8
Binary files /dev/null and b/media/platforms/django.png differ
diff --git a/media/platforms/nginx-plus.png b/media/platforms/nginx-plus.png
new file mode 100644
index 0000000000..4987638523
Binary files /dev/null and b/media/platforms/nginx-plus.png differ
diff --git a/media/platforms/relay.svg b/media/platforms/relay.svg
deleted file mode 100644
index 83b535f023..0000000000
--- a/media/platforms/relay.svg
+++ /dev/null
@@ -1 +0,0 @@
-
\ No newline at end of file
diff --git a/media/quickstarts/universal-login.png b/media/quickstarts/universal-login.png
new file mode 100644
index 0000000000..4b2fc8a47b
Binary files /dev/null and b/media/quickstarts/universal-login.png differ
diff --git a/opslevel.yml b/opslevel.yml
new file mode 100644
index 0000000000..87df927241
--- /dev/null
+++ b/opslevel.yml
@@ -0,0 +1,5 @@
+---
+version: 1
+repository:
+  owner: dx_product_experience
+  tags:
diff --git a/package.json b/package.json
index 444725ed94..620ba339e3 100644
--- a/package.json
+++ b/package.json
@@ -6,22 +6,26 @@
   "scripts": {
     "heroku-prebuild": "bash prebuild.sh",
     "heroku-postbuild": "bash postbuild.sh",
-    "precommit": "lint-staged"
+    "precommit": "lint-staged",
+    "clean-redirects": "npx jscodeshift -t codemods/clean-redirects-config.js config/redirects.js"
   },
   "lint-staged": {
     "*.md": "markdownlint"
   },
   "engines": {
-    "node": "8.9.4",
-    "yarn": "1.3.2"
+    "node": "14.17",
+    "yarn": "^1.4.0"
   },
   "devDependencies": {
     "commander": "^2.8.1",
     "husky": "^0.13.3",
     "imagemin": "^4.0.0",
     "imagemin-optipng": "^4.3.0",
+    "jscodeshift": "^0.13.0",
     "lint-staged": "^3.4.2",
-    "markdownlint": "^0.4.1",
-    "markdownlint-cli": "^0.3.1"
-  }
+    "markdownlint": "^0.13.0",
+    "markdownlint-cli": "^0.15.0",
+    "prettier": "^2.4.1"
+  },
+  "dependencies": {}
 }
diff --git a/postbuild.sh b/postbuild.sh
index e0f7f2b5af..2bd92283b0 100644
--- a/postbuild.sh
+++ b/postbuild.sh
@@ -18,3 +18,17 @@ if [ "$GIT_SSH_KEY" != "" ]; then
   # Clear that sensitive key data from the environment
   export GIT_SSH_KEY=0
 fi
+
+# Clean up Artifactory npm setup
+if [ ! -z "$NPM_REGISTRY_TOKEN" ] &&  [ ! -z "$NPM_REGISTRY_USER" ] && [ ! -z "$NPM_REGISTRY_URL" ] && [ ! -z "$NPM_REGISTRY_AUTH" ]; then
+  echo "Cleaning up NPM config" >&1
+
+  # Now that npm has finished running, we shouldn't need the registry config anymore.
+  # Remove the files that we created.
+  rm -f ~/.npmrc
+
+  # Clear that sensitive key data from the environment
+  export NPM_REGISTRY_TOKEN=0
+  echo "... done."
+  echo "" >&1
+fi
\ No newline at end of file
diff --git a/prebuild.sh b/prebuild.sh
index c9a2e118b9..3280c62311 100644
--- a/prebuild.sh
+++ b/prebuild.sh
@@ -29,6 +29,7 @@ fi
 
 
 echo "Moving content into docs folder"
+rm -rf "./docs/"
 mkdir -p "./docs/"
 shopt -s extglob
 mv !(docs) docs
@@ -38,8 +39,24 @@ git clone ssh://git@github.com/auth0/auth0-docs.git auth0-docs-repo
 
 echo "Moving docs site into root folder"
 shopt -s dotglob
+rm -rf "./.github"
 mv auth0-docs-repo/* .
 rm -rf auth0-docs-repo
 shopt -u dotglob
 
-echo "Docs site successfully setup."
+commitHash=$(git rev-parse --short HEAD)
+echo "Docs site successfully setup. auth0-docs commit: $commitHash"
+
+# Setup Artifactory npm registry and permissions
+if [ ! -z "$NPM_REGISTRY_TOKEN" ] &&  [ ! -z "$NPM_REGISTRY_USER" ] && [ ! -z "$NPM_REGISTRY_URL" ] && [ ! -z "$NPM_REGISTRY_AUTH" ]; then
+  echo "Detected NPM Registry. Adding Artifactory config..." >&1
+  echo "registry=$NPM_REGISTRY_URL" > ~/.npmrc
+  curl -s -u $NPM_REGISTRY_USER:$NPM_REGISTRY_TOKEN $NPM_REGISTRY_AUTH >> ~/.npmrc
+  success=$?
+  if [ $success -ne 0 ]; then
+    echo "... failed!"
+  else
+    echo "... done."
+  fi
+  echo "" >&1
+fi
diff --git a/scripts/check-version.sh b/scripts/check-version.sh
new file mode 100755
index 0000000000..92a80085f8
--- /dev/null
+++ b/scripts/check-version.sh
@@ -0,0 +1,56 @@
+#!/bin/bash
+
+# URL of the webpage
+URL="https://auth0.com/docs"
+
+# Slack webhook URL
+WEBHOOK_URL="https://hooks.slack.com/triggers/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"
+
+# Function to send Slack notification with the version as a data variable
+send_slack_notification() {
+    local version="$1"
+    curl -s -X POST -H 'Content-type: application/json' --data "{
+        \"version\": \"${version}\"
+    }" "$WEBHOOK_URL"
+}
+
+# Directory to store the current version file
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+VERSION_FILE="${SCRIPT_DIR}/tmp/current_version.txt"
+
+# Ensure the tmp directory exists
+mkdir -p "${SCRIPT_DIR}/tmp"
+
+# Read the current version from the file, if it exists
+if [ -f "$VERSION_FILE" ]; then
+    current_version=$(cat "$VERSION_FILE")
+else
+    current_version=""
+fi
+
+# Bypass cache by using cache-control headers and appending a unique query string
+cache_bypass=$(date +%s)
+response=$(curl -s -H "Cache-Control: no-cache, no-store, must-revalidate" \
+                    -H "Pragma: no-cache" \
+                    -H "Expires: 0" \
+                    "${URL}?nocache=${cache_bypass}")
+
+# Print the response for debugging
+echo "Response from URL: $response"
+
+# Extract the new version from the response
+new_version=$(echo "$response" | sed -n 's/.*"CONTENT_PACKAGE_VERSION":"\([^"]*\)".*/\1/p')
+
+# Print the new version for debugging
+echo "Extracted new version: $new_version"
+
+# Compare with stored version
+if [ "$new_version" != "$current_version" ]; then
+    echo "Package version updated: $new_version"
+    # Send Slack notification with the version
+    send_slack_notification "$new_version"
+    # Update the current version in the file
+    echo "$new_version" > "$VERSION_FILE"
+else
+    echo "Package version has not changed."
+fi
\ No newline at end of file
diff --git a/snippets/api-auth/hs256/csharp.md b/snippets/api-auth/hs256/csharp.md
index 4127a082ff..de552c9b9d 100644
--- a/snippets/api-auth/hs256/csharp.md
+++ b/snippets/api-auth/hs256/csharp.md
@@ -6,24 +6,20 @@ title: C#
 public class Startup
 {
   public void ConfigureServices(IServiceCollection services)
-  {
-    services.AddMvc();
-    
+  { 
     // 1. Add Authentication Services
-    services.AddAuthentication(options =>
-    {
-        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
-        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
-
-    }).AddJwtBearer(options =>
-    {
-      options.TokenValidationParameters = new TokenValidationParameters
+    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
+      .AddJwtBearer(options =>
       {
-          ValidIssuer = "https://${'<%= tenantDomain %>'}/",
-          ValidAudience = "${'<%= api.identifier %>'}",
-          IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("${'<%= api.signing_secret %>'}"))
-      };
-    });
+        options.TokenValidationParameters = new TokenValidationParameters
+        {
+            ValidIssuer = "https://${'<%= tenantDomain %>'}/",
+            ValidAudience = "${'<%= api.identifier %>'}",
+            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("${'<%= api.signing_secret %>'}"))
+        };
+      });
+
+    services.AddControllers();
   }
 
   public void Configure(IApplicationBuilder app, IHostingEnvironment env)
@@ -39,14 +35,15 @@ public class Startup
 
     app.UseStaticFiles();
 
-    // 2. Enable authentication middleware
+    app.UseRouting();
+
+    // 2. Enable authentication and authorization middleware
     app.UseAuthentication();
+    app.UseAuthorization();
 
-    app.UseMvc(routes =>
+    app.UseEndpoints(endpoints =>
     {
-        routes.MapRoute(
-            name: "default",
-            template: "{controller=Home}/{action=Index}/{id?}");
+        endpoints.MapControllers();
     });
   }
 }
diff --git a/snippets/api-auth/rs256/php.md b/snippets/api-auth/rs256/php.md
index 7727545588..fdef56ed6e 100644
--- a/snippets/api-auth/rs256/php.md
+++ b/snippets/api-auth/rs256/php.md
@@ -9,7 +9,7 @@ use Auth0\SDK\Helpers\Cache\FileSystemCacheHandler;
 $verifier = new JWTVerifier([
     'valid_audiences' => ['${"<%= api.identifier %>"}'],
     'authorized_iss' => ['https://${"<%= tenantDomain %>"}'],
-    'cache' => new FileSystemCacheHandler() // This parameter is optional. By default no cache is used to fetch the Json Web Keys.
+    'cache' => new FileSystemCacheHandler() // This parameter is optional. By default no cache is used to fetch the JSON Web Keys.
 ]);
 
 $decoded = $verifier->verifyAndDecode($token);
diff --git a/snippets/application-platforms/angular2/dependencies.md b/snippets/application-platforms/angular2/dependencies.md
deleted file mode 100644
index 88f2e32257..0000000000
--- a/snippets/application-platforms/angular2/dependencies.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```bash
-# installation with npm
-npm install --save auth0-js
-
-# installation with yarn
-yarn add auth0-js
-```
-
-The **auth0.js** library can also be retrieved from Auth0's CDN.
-
-```html
-
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/angular2/setup.md b/snippets/application-platforms/angular2/setup.md
deleted file mode 100644
index 868aed6200..0000000000
--- a/snippets/application-platforms/angular2/setup.md
+++ /dev/null
@@ -1,65 +0,0 @@
-```ts
-// src/app/auth/auth.service.ts
-
-import { Injectable } from '@angular/core';
-import { Router } from '@angular/router';
-import { filter } from 'rxjs/operators';
-import auth0 from 'auth0-js';
-
-@Injectable()
-export class AuthService {
-
-  auth0 = new auth0.WebAuth({
-    clientID: '${account.clientId}',
-    domain: '${account.namespace}',
-    responseType: 'token id_token',
-    audience: 'https://${account.namespace}/userinfo',
-    redirectUri: 'http://localhost:3000/callback',      
-    scope: 'openid'
-  });
-
-  constructor(public router: Router) {}
-
-  public login(): void {
-    this.auth0.authorize();
-  }
-
-  public handleAuthentication(): void {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        this.setSession(authResult);
-        this.router.navigate(['/home']);
-      } else if (err) {
-        this.router.navigate(['/home']);
-        console.log(err);
-      }
-    });
-  }
-
-  private setSession(authResult): void {
-    // Set the time that the access token will expire at
-    const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  public logout(): void {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // Go back to the home route
-    this.router.navigate(['/']);
-  }
-
-  public isAuthenticated(): boolean {
-    // Check whether the current time is past the
-    // access token's expiry time
-    const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-
-}
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/angular2/use.md b/snippets/application-platforms/angular2/use.md
deleted file mode 100644
index 9590230a6a..0000000000
--- a/snippets/application-platforms/angular2/use.md
+++ /dev/null
@@ -1,56 +0,0 @@
-```ts
-// src/app/app.component.ts
-
-import { Component } from '@angular/core';
-import { AuthService } from './auth/auth.service';
-
-@Component({
-  selector: 'app-root',
-  templateUrl: './app.component.html',
-  styleUrls: ['./app.component.css']
-})
-export class AppComponent {
-
-  constructor(public auth: AuthService) {
-    auth.handleAuthentication();
-  }
-
-}
-```
-
-```html
-
-
-
-
-
        
-  
-
        
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/angularjs/dependencies.md b/snippets/application-platforms/angularjs/dependencies.md
deleted file mode 100644
index 773d151623..0000000000
--- a/snippets/application-platforms/angularjs/dependencies.md
+++ /dev/null
@@ -1,49 +0,0 @@
-Install the dependencies with Bower or npm.
-
-**Bower**
-
-```bash
-bower install auth0-lock angular-lock angular-jwt
-```
-
-```html
-
-
-...
-
-
-
-
-
-
-
-
-
-
-
-...
-```
-
-**npm**
-
-```bash
-npm install angular-lock angular-jwt
-```
-
-```html
-
-
-...
-
-
-
-
-
-
-
-
-
-
-
-...
-```
diff --git a/snippets/application-platforms/angularjs/setup.md b/snippets/application-platforms/angularjs/setup.md
deleted file mode 100644
index 98c78d4406..0000000000
--- a/snippets/application-platforms/angularjs/setup.md
+++ /dev/null
@@ -1,64 +0,0 @@
-```js
-// app/auth/auth.service.js
-
-(function () {
-
-  'use strict';
-
-  angular
-    .module('app')
-    .service('authService', authService);
-
-  authService.$inject = ['$state', 'angularAuth0', '$timeout'];
-
-  function authService($state, angularAuth0, $timeout) {
-
-    function login() {
-      angularAuth0.authorize();
-    }
-    
-    function handleAuthentication() {
-      angularAuth0.parseHash(function(err, authResult) {
-        if (authResult && authResult.accessToken && authResult.idToken) {
-          setSession(authResult);
-          $state.go('home');
-        } else if (err) {
-          $timeout(function() {
-            $state.go('home');
-          });
-          console.log(err);
-        }
-      });
-    }
-
-    function setSession(authResult) {
-      // Set the time that the access token will expire at
-      let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-      localStorage.setItem('access_token', authResult.accessToken);
-      localStorage.setItem('id_token', authResult.idToken);
-      localStorage.setItem('expires_at', expiresAt);
-    }
-    
-    function logout() {
-      // Remove tokens and expiry time from localStorage
-      localStorage.removeItem('access_token');
-      localStorage.removeItem('id_token');
-      localStorage.removeItem('expires_at');
-    }
-    
-    function isAuthenticated() {
-      // Check whether the current time is past the 
-      // access token's expiry time
-      let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-      return new Date().getTime() < expiresAt;
-    }
-
-    return {
-      login: login,
-      handleAuthentication: handleAuthentication,
-      logout: logout,
-      isAuthenticated: isAuthenticated
-    }
-  }
-})();
-```
diff --git a/snippets/application-platforms/angularjs/use.md b/snippets/application-platforms/angularjs/use.md
deleted file mode 100644
index e80bec7c2d..0000000000
--- a/snippets/application-platforms/angularjs/use.md
+++ /dev/null
@@ -1,61 +0,0 @@
-```html
-
-
-
-```
-
-```js
-// app/navbar/navbar.directive.js
-
-(function() {
-  
-  'use strict';
-  
-  angular
-    .module('app')
-    .directive('navbar', navbar);
-    
-  function navbar() {
-    return {
-      templateUrl: 'app/navbar/navbar.html',
-      controller: navbarController,
-      controllerAs: 'vm'
-    }
-  }
-
-  navbarController.$inject = ['authService'];
-    
-  function navbarController(authService) {
-    var vm = this;
-    vm.auth = authService;
-  }
-  
-})();
-```
diff --git a/snippets/application-platforms/aurelia/dependencies.md b/snippets/application-platforms/aurelia/dependencies.md
deleted file mode 100644
index 8828d47c99..0000000000
--- a/snippets/application-platforms/aurelia/dependencies.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```bash
-# installation with npm
-npm install --save auth0-js
-
-# installation with yarn
-yarn add auth0-js
-```
-
-The **auth0.js** library can also be retrieved from Auth0's CDN.
-
-```html
-
-```
diff --git a/snippets/application-platforms/aurelia/setup.md b/snippets/application-platforms/aurelia/setup.md
deleted file mode 100644
index 0a91a8dbfc..0000000000
--- a/snippets/application-platforms/aurelia/setup.md
+++ /dev/null
@@ -1,69 +0,0 @@
-```js
-// src/auth-service.js
-
-import auth0 from 'auth0-js';
-import { inject } from 'aurelia-framework';
-import { Router } from 'aurelia-router';
-import EventEmitter from 'EventEmitter';
-
-@inject(Router)
-export class AuthService {
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:8080/callback',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  authNotifier = new EventEmitter();
-
-  constructor(Router) {
-    this.router = Router;
-  }
-
-  login() {
-    this.auth0.authorize();
-  }
-
-  handleAuthentication() {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-        this.router.navigate('home');
-        this.authNotifier.emit('authChange', { authenticated: true });
-      } else if (err) {
-        console.log(err);
-      }
-    });
-  }
-
-  setSession(authResult) {
-    // Set the time that the access token will expire at
-    let expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  logout() {
-    // Clear access token and ID token from local storage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    this.router.navigate('home');
-    this.authNotifier.emit('authChange', false);
-  }
-
-  isAuthenticated() {
-    // Check whether the current time is past the
-    // access token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-}
-
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/aurelia/use.md b/snippets/application-platforms/aurelia/use.md
deleted file mode 100644
index 27ed5ef687..0000000000
--- a/snippets/application-platforms/aurelia/use.md
+++ /dev/null
@@ -1,31 +0,0 @@
-```html
-
-
-
-```
-
-```js
-// src/app.js
-
-import { PLATFORM } from 'aurelia-pal';
-import { inject } from 'aurelia-framework';
-import { AuthService } from './auth-service';
-
-@inject(AuthService)
-export class App {
-  constructor(AuthService) {
-    this.auth = AuthService;
-    this.authenticated = this.auth.isAuthenticated();
-    this.auth.authNotifier.on('authChange', authState => {
-      this.authenticated = authState.authenticated;
-    });
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/cyclejs/configure.md b/snippets/application-platforms/cyclejs/configure.md
deleted file mode 100644
index 948aaa33a1..0000000000
--- a/snippets/application-platforms/cyclejs/configure.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```js
-// app/index.js
-
-const ProtectedComponent = protect(Component, {
-    auth0ShowParams: {
-        authParams: { scope: "openid nickname" },
-        responseType: "token"
-    }
-});
-```
diff --git a/snippets/application-platforms/cyclejs/dependencies.md b/snippets/application-platforms/cyclejs/dependencies.md
deleted file mode 100644
index 4cefe4a9ec..0000000000
--- a/snippets/application-platforms/cyclejs/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install cyclejs-auth0
-```
diff --git a/snippets/application-platforms/cyclejs/logout.md b/snippets/application-platforms/cyclejs/logout.md
deleted file mode 100644
index 9d64a08bc5..0000000000
--- a/snippets/application-platforms/cyclejs/logout.md
+++ /dev/null
@@ -1,14 +0,0 @@
-```js
-// app/index.js
-
-function main(sources) {
-    const logoutAction$ = sources
-        .DOM
-        .select(".logout")
-        .events("click")
-
-    return {
-        auth0: logoutAction$.mapTo({ action: "logout" })
-    }
-}
-```
diff --git a/snippets/application-platforms/cyclejs/query.md b/snippets/application-platforms/cyclejs/query.md
deleted file mode 100644
index d02d7786a4..0000000000
--- a/snippets/application-platforms/cyclejs/query.md
+++ /dev/null
@@ -1,24 +0,0 @@
-```js
-// app/index.js
-
-function Component(sources) {
-    const tokens$ = sources.props.tokens$; //the token$ added by the protect function
-
-    const userProfile$ = sources
-        .auth0
-        .select("getUserInfo") //read to response of the lock to the getProfile method call
-
-    return {
-        auth0: tokens$
-            .filter(tokens => !!tokens) //filter empty tokens
-            //send the getUserInfo action to the auth0 driver
-            .map(tokens => ({ action: "getUserInfo", params: tokens.accessToken })),
-
-        DOM: userProfile$ //displays the user profile once fetched
-            .map(user => p([
-                "Welcome",
-                span(".nickname", user.nickname)
-            ]))
-    };
-}
-```
diff --git a/snippets/application-platforms/cyclejs/securize.md b/snippets/application-platforms/cyclejs/securize.md
deleted file mode 100644
index 160180af15..0000000000
--- a/snippets/application-platforms/cyclejs/securize.md
+++ /dev/null
@@ -1,17 +0,0 @@
-```js
-const ProtectedComponent = protect(Component, {
-    decorators: {
-        HTTP: (request, token) => {
-            return {
-                ...request,
-                headers: {
-                    ...request.headers,
-                    //Will add the Authorization header to
-                    //any of the http request sent by the component
-                    "Authorization": "Bearer " + token
-                }
-            }
-        }
-    }
-});
-```
diff --git a/snippets/application-platforms/cyclejs/setup.md b/snippets/application-platforms/cyclejs/setup.md
deleted file mode 100644
index a1cf0ac131..0000000000
--- a/snippets/application-platforms/cyclejs/setup.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```js
-// app/index.js
-
-import {makeAuth0Driver, protect} from "cyclejs-auth0";
-
-function main(sources) {
-    //your application's code
-}
-
-const drivers = {
-    auth0: makeAuth0Driver('<%= account.clientId %>', '<%= account.namespace %>')
-}
-```
diff --git a/snippets/application-platforms/cyclejs/use.md b/snippets/application-platforms/cyclejs/use.md
deleted file mode 100644
index 127a2f4cff..0000000000
--- a/snippets/application-platforms/cyclejs/use.md
+++ /dev/null
@@ -1,14 +0,0 @@
-```js
-// app/index.js
-
-function main(sources) {
-    const ProtectedTodos = protect(Todos); //here we wrap the Todos component in the protect function
-    const protectedTodosInstance = ProtectedTodos(sources);
-
-    return {
-        DOM: protectedTodosInstance.DOM,
-        HTTP: protectedTodosInstance.HTTP
-        //...
-    }
-}
-```
diff --git a/snippets/application-platforms/jquery/dependencies.md b/snippets/application-platforms/jquery/dependencies.md
deleted file mode 100644
index 5983ee3a06..0000000000
--- a/snippets/application-platforms/jquery/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/application-platforms/jquery/setup.md b/snippets/application-platforms/jquery/setup.md
deleted file mode 100644
index a111604787..0000000000
--- a/snippets/application-platforms/jquery/setup.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```js
-$(document).ready(function() {
-  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
-    auth: { 
-      params: { 
-        scope: 'openid email' 
-      }
-    }
-  });
-});
-```
diff --git a/snippets/application-platforms/jquery/use.md b/snippets/application-platforms/jquery/use.md
deleted file mode 100644
index f9d1a62530..0000000000
--- a/snippets/application-platforms/jquery/use.md
+++ /dev/null
@@ -1,16 +0,0 @@
-```js
-// app.js
-
-var userProfile;
-
-$('.btn-login').click(function(e) {
-  e.preventDefault();
-  lock.show();
-});
-```
-
-```html
-
-
-
-```
diff --git a/snippets/application-platforms/react/dependencies.md b/snippets/application-platforms/react/dependencies.md
deleted file mode 100644
index 8828d47c99..0000000000
--- a/snippets/application-platforms/react/dependencies.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```bash
-# installation with npm
-npm install --save auth0-js
-
-# installation with yarn
-yarn add auth0-js
-```
-
-The **auth0.js** library can also be retrieved from Auth0's CDN.
-
-```html
-
-```
diff --git a/snippets/application-platforms/react/setup.md b/snippets/application-platforms/react/setup.md
deleted file mode 100644
index 44ce6606dc..0000000000
--- a/snippets/application-platforms/react/setup.md
+++ /dev/null
@@ -1,68 +0,0 @@
-```js
-// src/Auth/Auth.js
-
-import { EventEmitter } from 'events';
-import history from '../history';
-import auth0 from 'auth0-js';
-
-export default class Auth extends EventEmitter {
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:3000',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  constructor() {
-    super();
-    this.login = this.login.bind(this);
-    this.logout = this.logout.bind(this);
-    this.handleAuthentication = this.handleAuthentication.bind(this);
-    this.isAuthenticated = this.isAuthenticated.bind(this);
-  }
-
-  login() {
-    this.auth0.authorize();
-  }
-
-  handleAuthentication() {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult);
-        history.replace('/home');
-      } else if (err) {
-        history.replace('/home');
-        console.log(err);
-      }
-    });
-  }
-
-  setSession(authResult) {
-    // Set the time that the access token will expire at
-    let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-    // navigate to the home route
-    history.replace('/home');
-  }
-
-  logout() {
-    // Clear access token and ID token from local storage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    // navigate to the home route
-    history.replace('/home');
-  }
-
-  isAuthenticated() {
-    // Check whether the current time is past the 
-    // access token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'));
-    return new Date().getTime() < expiresAt;
-  }
-}
-```
diff --git a/snippets/application-platforms/react/use.md b/snippets/application-platforms/react/use.md
deleted file mode 100644
index 017717743a..0000000000
--- a/snippets/application-platforms/react/use.md
+++ /dev/null
@@ -1,68 +0,0 @@
-```js
-// src/App.js
-
-import React, { Component } from 'react';
-import { Navbar, Button } from 'react-bootstrap';
-import './App.css';
-
-class App extends Component {
-  goTo(route) {
-    this.props.history.replace(`<%= "/${route}" %>`)
-  }
-
-  login() {
-    this.props.auth.login();
-  }
-
-  logout() {
-    this.props.auth.logout();
-  }
-
-  render() {
-    const { isAuthenticated } = this.props.auth;
-
-    return (
-      
        
-        
-          
-            
-              Auth0 - React
-            
-            
-            {
-              !isAuthenticated() && (
-                  
-                )
-            }
-            {
-              isAuthenticated() && (
-                  
-                )
-            }
-          
-        
-      
        
-    );
-  }
-}
-
-export default App;
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/socket-io/dependencies.md b/snippets/application-platforms/socket-io/dependencies.md
deleted file mode 100644
index 4b4db9befc..0000000000
--- a/snippets/application-platforms/socket-io/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/application-platforms/socket-io/setup.md b/snippets/application-platforms/socket-io/setup.md
deleted file mode 100644
index 65467dcab9..0000000000
--- a/snippets/application-platforms/socket-io/setup.md
+++ /dev/null
@@ -1,6 +0,0 @@
-```js
-var lock = null;
-$(document).ready(function() {
-   lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-});
-```
diff --git a/snippets/application-platforms/socket-io/use.md b/snippets/application-platforms/socket-io/use.md
deleted file mode 100644
index f73b9c9c85..0000000000
--- a/snippets/application-platforms/socket-io/use.md
+++ /dev/null
@@ -1,32 +0,0 @@
-```js
-var userProfile;
-var userToken = localStorage.getItem('userToken');
-var accessToken = localStorage.getItem('accessToken');
-
-lock.on('authenticated', function(authResult) {
-    lock.getUserInfo(authResult.accessToken, function(error, profile) {
-        if (error) {
-            // Handle error
-            return;
-        }
-        localStorage.setItem('userToken', authResult.idToken);
-        localStorage.setItem('accessToken', authResult.accessToken);
-        userProfile = profile;
-        userToken = authResult.idToken;
-    });
-});
-
-if (userToken && accessToken) {
-    lock.getUserInfo(accessToken, function (err, profile) {
-        if (err) {
-            return alert('There was an error getting the profile: ' + err.message);
-        }        
-        userProfile = profile;
-    });
-}
-
-$('#login button').click(function(e){
-  e.preventDefault();
-  lock.show();
-});
-```
diff --git a/snippets/application-platforms/vanillajs/dependencies.md b/snippets/application-platforms/vanillajs/dependencies.md
deleted file mode 100644
index 8828d47c99..0000000000
--- a/snippets/application-platforms/vanillajs/dependencies.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```bash
-# installation with npm
-npm install --save auth0-js
-
-# installation with yarn
-yarn add auth0-js
-```
-
-The **auth0.js** library can also be retrieved from Auth0's CDN.
-
-```html
-
-```
diff --git a/snippets/application-platforms/vanillajs/setup.md b/snippets/application-platforms/vanillajs/setup.md
deleted file mode 100644
index 28c026e9fc..0000000000
--- a/snippets/application-platforms/vanillajs/setup.md
+++ /dev/null
@@ -1,93 +0,0 @@
-```js
-// app.js
-
-window.addEventListener('load', function() {
-
-  var webAuth = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: window.location.href,
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  });
-
-  var loginStatus = document.querySelector('.container h4');
-  var loginView = document.getElementById('login-view');
-  var homeView = document.getElementById('home-view');
-
-  // buttons and event listeners
-  var homeViewBtn = document.getElementById('btn-home-view');
-  var loginBtn = document.getElementById('btn-login');
-  var logoutBtn = document.getElementById('btn-logout');
-
-  homeViewBtn.addEventListener('click', function() {
-    homeView.style.display = 'inline-block';
-    loginView.style.display = 'none';
-  });
-
-  loginBtn.addEventListener('click', function(e) {
-    e.preventDefault();
-    webAuth.authorize();
-  });
-
-  logoutBtn.addEventListener('click', logout);
-
-  function setSession(authResult) {
-    // Set the time that the access token will expire at
-    var expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    );
-    localStorage.setItem('access_token', authResult.accessToken);
-    localStorage.setItem('id_token', authResult.idToken);
-    localStorage.setItem('expires_at', expiresAt);
-  }
-
-  function logout() {
-    // Remove tokens and expiry time from localStorage
-    localStorage.removeItem('access_token');
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('expires_at');
-    displayButtons();
-  }
-
-  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;
-  }
-
-
-  function handleAuthentication() {
-    webAuth.parseHash(function(err, authResult) {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        window.location.hash = '';
-        setSession(authResult);
-        loginBtn.style.display = 'none';
-        homeView.style.display = 'inline-block';
-      } else if (err) {
-        homeView.style.display = 'inline-block';
-        console.log(err);
-        alert(
-          'Error: ' + err.error + '. Check the console for further details.'
-        );
-      }
-      displayButtons();
-    });
-  }
-
-  function displayButtons() {
-    if (isAuthenticated()) {
-      loginBtn.style.display = 'none';
-      logoutBtn.style.display = 'inline-block';
-      loginStatus.innerHTML = 'You are logged in!';
-    } else {
-      loginBtn.style.display = 'inline-block';
-      logoutBtn.style.display = 'none';
-      loginStatus.innerHTML =
-        'You are not logged in! Please log in to continue.';
-    }
-  }
-});
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/vanillajs/use.md b/snippets/application-platforms/vanillajs/use.md
deleted file mode 100644
index b789038069..0000000000
--- a/snippets/application-platforms/vanillajs/use.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```js
-// ...
-webAuth.authorize();
-```
diff --git a/snippets/application-platforms/vuejs/dependencies.md b/snippets/application-platforms/vuejs/dependencies.md
deleted file mode 100644
index 88f2e32257..0000000000
--- a/snippets/application-platforms/vuejs/dependencies.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```bash
-# installation with npm
-npm install --save auth0-js
-
-# installation with yarn
-yarn add auth0-js
-```
-
-The **auth0.js** library can also be retrieved from Auth0's CDN.
-
-```html
-
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/vuejs/setup.md b/snippets/application-platforms/vuejs/setup.md
deleted file mode 100644
index 0def407a0a..0000000000
--- a/snippets/application-platforms/vuejs/setup.md
+++ /dev/null
@@ -1,75 +0,0 @@
-```js
-// src/Auth/AuthService.js
-
-import auth0 from 'auth0-js'
-import { AUTH_CONFIG } from './auth0-variables'
-import EventEmitter from 'EventEmitter'
-import router from './../router'
-
-export default class AuthService {
-
-  authenticated = this.isAuthenticated()
-  authNotifier = new EventEmitter()
-
-  constructor () {
-    this.login = this.login.bind(this)
-    this.setSession = this.setSession.bind(this)
-    this.logout = this.logout.bind(this)
-    this.isAuthenticated = this.isAuthenticated.bind(this)
-  }
-
-  auth0 = new auth0.WebAuth({
-    domain: '${account.namespace}',
-    clientID: '${account.clientId}',
-    redirectUri: 'http://localhost:8080/callback',
-    audience: 'https://${account.namespace}/userinfo',
-    responseType: 'token id_token',
-    scope: 'openid'
-  })
-
-  login () {
-    this.auth0.authorize()
-  }
-
-  handleAuthentication () {
-    this.auth0.parseHash((err, authResult) => {
-      if (authResult && authResult.accessToken && authResult.idToken) {
-        this.setSession(authResult)
-        router.replace('home')
-      } else if (err) {
-        router.replace('home')
-        console.log(err)
-      }
-    })
-  }
-
-  setSession (authResult) {
-    // Set the time that the access token will expire at
-    let expiresAt = JSON.stringify(
-      authResult.expiresIn * 1000 + new Date().getTime()
-    )
-    localStorage.setItem('access_token', authResult.accessToken)
-    localStorage.setItem('id_token', authResult.idToken)
-    localStorage.setItem('expires_at', expiresAt)
-    this.authNotifier.emit('authChange', { authenticated: true })
-  }
-
-  logout () {
-    // Clear access token and ID token from local storage
-    localStorage.removeItem('access_token')
-    localStorage.removeItem('id_token')
-    localStorage.removeItem('expires_at')
-    this.userProfile = null
-    this.authNotifier.emit('authChange', false)
-    // navigate to the home route
-    router.replace('home')
-  }
-
-  isAuthenticated () {
-    // Check whether the current time is past the
-    // access token's expiry time
-    let expiresAt = JSON.parse(localStorage.getItem('expires_at'))
-    return new Date().getTime() < expiresAt
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/application-platforms/vuejs/use.md b/snippets/application-platforms/vuejs/use.md
deleted file mode 100644
index 322d840e07..0000000000
--- a/snippets/application-platforms/vuejs/use.md
+++ /dev/null
@@ -1,76 +0,0 @@
-```js
-// src/App.vue
-
-
-
-
-
-
-
-.btn-margin {
-  margin-top: 7px
-}
-```
diff --git a/snippets/native-platforms/android-facebook-login/facebook-app-credentials.md b/snippets/native-platforms/android-facebook-login/facebook-app-credentials.md
new file mode 100644
index 0000000000..3931510073
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-app-credentials.md
@@ -0,0 +1,8 @@
+Create two new resources in your Android application's `strings.xml` file to store them. The name of the keys must match the ones used below:
+
+```xml
+
+    {TENANT}
+    {CLIENT_ID}
+
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/android-facebook-login/facebook-button-config.md b/snippets/native-platforms/android-facebook-login/facebook-button-config.md
new file mode 100644
index 0000000000..9f24f58785
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-button-config.md
@@ -0,0 +1,52 @@
+You will make use of a small interface to handle our internal callbacks.
+
+In the sample, the method was named `performLogin` and the interface `SimpleCallback`. Go ahead and add both.
+
+```java
+private void performLogin(@NonNull final AccessToken accessToken) {
+  // TODO
+}
+
+private interface SimpleCallback {
+    void onResult(@NonNull T result);
+
+    void onError(@NonNull Throwable cause);
+}
+```
+
+Now, call the method from the Facebook login callback's `onSuccess` method.
+
+```java
+@Override
+public void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+
+    setContentView(R.layout.activity_login);
+
+    Auth0 account = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+    auth0Client = new AuthenticationAPIClient(account);
+
+    fbCallbackManager = CallbackManager.Factory.create();
+
+    LoginButton loginButton = findViewById(R.id.login_button);
+    loginButton.setPermissions(FACEBOOK_PERMISSIONS);
+    loginButton.registerCallback(fbCallbackManager, new FacebookCallback() {
+        @Override
+        public void onSuccess(LoginResult result) {
+            //1. Logged in to Facebook
+            AccessToken accessToken = result.getAccessToken();
+            performLogin(accessToken);
+        }
+
+        @Override
+        public void onCancel() {
+            //User closed the dialog. Safe to ignore
+        }
+
+        @Override
+        public void onError(FacebookException error) {
+            //Handle Facebook authentication error
+        }
+    });
+}
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/android-facebook-login/facebook-button-permissions.md b/snippets/native-platforms/android-facebook-login/facebook-button-permissions.md
new file mode 100644
index 0000000000..a10abb8bb2
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-button-permissions.md
@@ -0,0 +1,5 @@
+Set the requested permissions to `public_profile` and `email`. This way, the user email will also be included as part of the response, provided the access request is accepted by the user.
+
+```java
+loginButton.setPermissions(Arrays.asList("public_profile", "email"));
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/android-facebook-login/facebook-fetch-profile.md b/snippets/native-platforms/android-facebook-login/facebook-fetch-profile.md
new file mode 100644
index 0000000000..0f8c1165ab
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-fetch-profile.md
@@ -0,0 +1,25 @@
+```java
+private void fetchUserProfile(String token, String userId, final SimpleCallback callback) {
+    Bundle params = new Bundle();
+    params.putString("access_token", token);
+    params.putString("fields", "first_name,last_name,email");
+
+    GraphRequest request = new GraphRequest();
+    request.setParameters(params);
+    request.setGraphPath(userId);
+    request.setCallback(new GraphRequest.Callback() {
+        @Override
+        public void onCompleted(GraphResponse response) {
+            FacebookRequestError error = response.getError();
+            if (error != null) {
+                //Failed to fetch user profile
+                callback.onError(error.getException());
+                return;
+            }
+            //Handle back the profile as received
+            callback.onResult(response.getRawResponse());
+        }
+    });
+    request.executeAsync();
+}
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/android-facebook-login/facebook-fetch-session-token.md b/snippets/native-platforms/android-facebook-login/facebook-fetch-session-token.md
new file mode 100644
index 0000000000..9b282de219
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-fetch-session-token.md
@@ -0,0 +1,33 @@
+The sample uses the Facebook SDK's `GraphRequest` class to perform this request.
+
+```java
+private void fetchSessionToken(String token, final SimpleCallback callback) {
+    Bundle params = new Bundle();
+    params.putString("grant_type", "fb_attenuate_token");
+    params.putString("fb_exchange_token", token);
+    params.putString("client_id", getString(R.string.facebook_app_id));
+
+    GraphRequest request = new GraphRequest();
+    request.setParameters(params);
+    request.setGraphPath("oauth/access_token");
+    request.setCallback(new GraphRequest.Callback() {
+        @Override
+        public void onCompleted(GraphResponse response) {
+            FacebookRequestError error = response.getError();
+            if (error != null) {
+                //Failed to fetch session token
+                callback.onError(error.getException());
+                return;
+            }
+            try {
+                String fbSessionToken = response.getJSONObject().getString("access_token");
+                callback.onResult(fbSessionToken);
+            } catch (JSONException e) {
+                //Failed to parse session token
+                callback.onError(e);
+            }
+        }
+    });
+    request.executeAsync();
+}
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/android-facebook-login/facebook-install-auth0-sdk.md b/snippets/native-platforms/android-facebook-login/facebook-install-auth0-sdk.md
new file mode 100644
index 0000000000..5780a8ed31
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-install-auth0-sdk.md
@@ -0,0 +1,25 @@
+In your Android application, add this line to the `app/build.gradle` file:
+
+```gradle
+dependencies {
+    implementation 'com.auth0.android:auth0:1.+'
+}
+```
+
+Now is time to run the Gradle Sync task to refresh the project and its dependencies.
+
+::: panel Web Authentication
+If your application does not plan to make use of the Web Authentication module provided by the SDK, you will need to remove the unused activity from the `AndroidManifest.xml` file to prevent Manifest Placeholder issues. This can be achieved by adding an activity declaration and annotating it with `tools:node="remove"`.
+
+```xml
+
+  
+   
+  
+
+```
+
+However, if you do plan to support Web Authentication, head over [here](/libraries/auth0-android#authentication-via-universal-login) to learn how to declare the Manifest Placeholders.
+:::
diff --git a/snippets/native-platforms/android-facebook-login/facebook-token-exchange.md b/snippets/native-platforms/android-facebook-login/facebook-token-exchange.md
new file mode 100644
index 0000000000..2253165145
--- /dev/null
+++ b/snippets/native-platforms/android-facebook-login/facebook-token-exchange.md
@@ -0,0 +1,105 @@
+The SDK must be instantiated before use. Define a field at the class level and initialize it on the `onCreate` method. Note how the credentials defined in the step above are passed to the `Auth0` constructor and then a new instance of the `AuthenticationAPIClient` is created with it.
+
+```java
+private AuthenticationAPIClient auth0Client;
+
+@Override
+public void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+
+    setContentView(R.layout.activity_login);
+
+    Auth0 account = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+    auth0Client = new AuthenticationAPIClient(account);
+
+    //...
+}
+```
+
+Create the method that will hold the logic to exchange the two obtained artifacts for Auth0 user credentials. In the sample, this method is named `exchangeTokens`.
+
+The API client declares the method `loginWithNativeSocialToken` that receives a token and a subject type. The former corresponds to the session token, and the latter indicates what type of connection the backend will attempt to authenticate with. For native Facebook Login, you will use the following value:
+
+```
+"http://auth0.com/oauth/token-type/facebook-info-session-access-token"
+```
+
+Other values that need to be configured are the user profile (using the `user_profile` key) and the scope you request the Auth0 tokens contain.
+
+
+```java
+private void exchangeTokens(@NonNull String sessionToken, @NonNull String userProfile, @NonNull final SimpleCallback callback) {
+    Map params = new HashMap<>();
+    params.put("user_profile", userProfile);
+
+    auth0Client.loginWithNativeSocialToken(sessionToken, "http://auth0.com/oauth/token-type/facebook-info-session-access-token")
+            .setScope("openid email profile offline_access")
+            .addAuthenticationParameters(params)
+            .start(new BaseCallback() {
+                @Override
+                public void onSuccess(Credentials credentials) {
+                    callback.onResult(credentials);
+                }
+
+                @Override
+                public void onFailure(AuthenticationException error) {
+                    callback.onError(error);
+                }
+            });
+}
+```
+
+::: note
+It's a good practice to keep all the values that you know won't change as constants at the top of the class. The sample makes use of constants for the subject token type, the Facebook permissions, and the Auth0 scopes. 
+You can read more about Auth0 scopes in the dedicated article.
+:::
+
+
+Now that every step is defined in its own method, it's time to put everything together inside the `performLogin` method.
+
+```java
+private void performLogin(@NonNull final AccessToken accessToken) {
+    final String token = accessToken.getToken();
+    fetchSessionToken(token, new SimpleCallback() {
+        @Override
+        public void onResult(@NonNull final String sessionToken) {
+            //2. Obtained the Facebook session token
+            fetchUserProfile(token, accessToken.getUserId(), new SimpleCallback() {
+
+                @Override
+                public void onResult(@NonNull String jsonProfile) {
+                    //3. Obtained the Facebook user profile
+                    exchangeTokens(sessionToken, jsonProfile, new SimpleCallback() {
+
+                        @Override
+                        public void onResult(@NonNull Credentials credentials) {
+                            /*
+                            *  4. Logged in!
+                            *     Use access token to call API
+                            *     or consume ID token locally
+                            */
+                        }
+
+                        @Override
+                        public void onError(@NonNull Throwable cause) {
+                            //Handle token exchange error
+                        }
+                    });
+                }
+
+                @Override
+                public void onError(@NonNull Throwable cause) {
+                    //Handle profile request error
+                }
+            });
+        }
+
+        @Override
+        public void onError(@NonNull Throwable cause) {
+            //Handle session token request error
+        }
+    });
+}
+```
+
+If everything went well, you should now be able to authenticate natively with the Facebook Login SDK. This means that if the Facebook app is installed on the device, the authentication will be handled via the application and not a browser app.
diff --git a/snippets/native-platforms/cordova/setup.md b/snippets/native-platforms/cordova/setup.md
index 6eea16aa45..8f08cdba8b 100644
--- a/snippets/native-platforms/cordova/setup.md
+++ b/snippets/native-platforms/cordova/setup.md
@@ -1,4 +1,4 @@
-## Add Cordova Plugins
+### Add Cordova Plugins
 
 You must install the `SafariViewController` plugin from Cordova to be able to show the login page. The downloadable sample project already has this plugin added, but if you are adding Auth0 to your own application, install the plugin via the command line.
 
@@ -13,6 +13,8 @@ The `CustomURLScheme` plugin from Cordova is also required to handle redirects p
 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
+## Integrate Auth0 in your Application
+
+### Modify config.xml
 
 Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
\ No newline at end of file
diff --git a/snippets/native-platforms/cordova/use.md b/snippets/native-platforms/cordova/use.md
index b8429055f4..4df23083f6 100644
--- a/snippets/native-platforms/cordova/use.md
+++ b/snippets/native-platforms/cordova/use.md
@@ -1,11 +1,10 @@
+
 ```js
+// src/App.js
+
 var Auth0 = require('auth0-js');
 var Auth0Cordova = require('@auth0/cordova');
 
-function getAllBySelector(arg) {
-  return document.querySelectorAll(arg);
-}
-
 function getBySelector(arg) {
   return document.querySelector(arg);
 }
@@ -14,8 +13,30 @@ function getById(id) {
   return document.getElementById(id);
 }
 
-function getAllByClassName(className) {
-  return document.getElementsByClassName(className);
+function getRedirectUrl() {
+  var returnTo = env.PACKAGE_ID + '://${account.namespace}/cordova/' + env.PACKAGE_ID + '/callback';
+  var url = 'https://${account.namespace}/v2/logout?client_id=${account.clientId}&returnTo=' + returnTo;
+  return url;
+}
+
+function openUrl(url) {
+  SafariViewController.isAvailable(function (available) {
+    if (available) {
+      SafariViewController.show({
+            url: url
+          },
+          function(result) {
+            if (result.event === 'loaded') {
+              SafariViewController.hide();
+            }
+          },
+          function(msg) {
+            console.log("KO: " + JSON.stringify(msg));
+          })
+    } else {
+      window.open(url, '_system');
+    }
+  })
 }
 
 function App() {
@@ -108,6 +129,8 @@ App.prototype.login = function(e) {
 
 App.prototype.logout = function(e) {
   localStorage.removeItem('access_token');
+  var url = getRedirectUrl();
+  openUrl(url);
   this.resumeApp();
 };
 
@@ -143,4 +166,4 @@ App.prototype.render = function() {
 };
 
 module.exports = App;
-```
\ No newline at end of file
+```
diff --git a/snippets/native-platforms/ionic3/use.md b/snippets/native-platforms/ionic3/use.md
index 3e0a5ca47c..b7a3b28554 100644
--- a/snippets/native-platforms/ionic3/use.md
+++ b/snippets/native-platforms/ionic3/use.md
@@ -48,10 +48,10 @@ export class AuthService {
       if (err) {
         throw err;
       }
-      // Set access token
+      // Set Access Token
       this.storage.set('access_token', authResult.accessToken);
       this.accessToken = authResult.accessToken;
-      // Set access token expiration
+      // Set Access Token expiration
       const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
       this.storage.set('expires_at', expiresAt);
       // Set logged in
@@ -78,4 +78,4 @@ export class AuthService {
     this.loggedIn = false;
   }
 }
-```
\ No newline at end of file
+```
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-app-credentials.md b/snippets/native-platforms/ios-facebook-login/facebook-app-credentials.md
new file mode 100644
index 0000000000..7919d1b259
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-app-credentials.md
@@ -0,0 +1,16 @@
+Go ahead and add an `Auth0.plist` file to your iOS application's main bundle to store them.
+
+```xml
+
+
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-button-config.md b/snippets/native-platforms/ios-facebook-login/facebook-button-config.md
new file mode 100644
index 0000000000..cc38450ced
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-button-config.md
@@ -0,0 +1,27 @@
+In the sample, the method was named `login(with:)`.
+
+```swift
+fileprivate func login(with accessToken: FacebookLogin.AccessToken) {
+    // TODO
+}
+```
+
+Call this method from the Facebook Login Button delegate `loginButton(_:didCompleteWith:error:)` method, as shown below:
+
+```swift
+extension ViewController: LoginButtonDelegate {
+
+    func loginButton(_ loginButton: FBLoginButton, didCompleteWith result: LoginManagerLoginResult?, error: Error?) {
+        guard error == nil, let accessToken = result?.token else {
+            return print(error ?? "Facebook access token is nil")
+        }
+
+        login(with: accessToken) // 👈🏻
+    }
+
+    func loginButtonDidLogOut(_ loginButton: FBLoginButton) {
+        print("Logged out")
+    }
+
+}
+```
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-button-permissions.md b/snippets/native-platforms/ios-facebook-login/facebook-button-permissions.md
new file mode 100644
index 0000000000..08e41c172f
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-button-permissions.md
@@ -0,0 +1,5 @@
+Set the requested permissions to `.publicProfile` and `.email`. This way, the user email will also be included as part of the response, provided the access request is accepted by the user.
+
+```swift
+let loginButton = FBLoginButton(permissions: [.publicProfile, .email])
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-fetch-profile.md b/snippets/native-platforms/ios-facebook-login/facebook-fetch-profile.md
new file mode 100644
index 0000000000..179af006be
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-fetch-profile.md
@@ -0,0 +1,9 @@
+```swift
+private func fetchProfile(userId: String, accessToken: String) -> AnyPublisher<[String: Any], URLError> {
+    var components = URLComponents(string: "\(fbAPIURL)/\(userId)")!
+    components.queryItems = [URLQueryItem(name: "access_token", value: accessToken),
+                             URLQueryItem(name: "fields", value: "first_name,last_name,email")]
+
+    return fetch(url: components.url!)
+}
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-fetch-session-token.md b/snippets/native-platforms/ios-facebook-login/facebook-fetch-session-token.md
new file mode 100644
index 0000000000..f6c29c3fd7
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-fetch-session-token.md
@@ -0,0 +1,24 @@
+The sample uses URLSession with [Combine](https://developer.apple.com/documentation/combine) to perform this request.
+
+```swift
+private let fbAPIURL = "https://graph.facebook.com/v6.0"
+
+private func fetch(url: URL) -> AnyPublisher<[String: Any], URLError> {
+    URLSession.shared.dataTaskPublisher(for: url)
+        .subscribe(on: DispatchQueue.global(qos: .userInitiated)) // Execute the request on a background thread
+        .receive(on: DispatchQueue.main) // Execute the sink callbacks on the main thread
+        .compactMap { try? JSONSerialization.jsonObject(with: $0.data) as? [String: Any] } // Get a JSON dictionary
+        .eraseToAnyPublisher()
+}
+
+private func fetchSessionAccessToken(appId: String, accessToken: String) -> AnyPublisher {
+    var components = URLComponents(string: "\(fbAPIURL)/oauth/access_token")!
+    components.queryItems = [URLQueryItem(name: "grant_type", value: "fb_attenuate_token"),
+                             URLQueryItem(name: "fb_exchange_token", value: accessToken),
+                             URLQueryItem(name: "client_id", value: appId)]
+
+    return fetch(url: components.url!)
+        .compactMap { $0["access_token"] as? String } // Get the Session Access Token
+        .eraseToAnyPublisher()
+}
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-install-auth0-sdk.md b/snippets/native-platforms/ios-facebook-login/facebook-install-auth0-sdk.md
new file mode 100644
index 0000000000..3769c664be
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-install-auth0-sdk.md
@@ -0,0 +1,49 @@
+### 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).
+:::
+
+::: panel Web Authentication
+If your iOS application plans to support Web Authentication, head over [here](/libraries/auth0-swift#web-based-auth-ios-only-) to learn how to configure the Callback and Logout URLs, and set up the Custom URL Scheme.
+:::
diff --git a/snippets/native-platforms/ios-facebook-login/facebook-token-exchange.md b/snippets/native-platforms/ios-facebook-login/facebook-token-exchange.md
new file mode 100644
index 0000000000..6a4fa9a625
--- /dev/null
+++ b/snippets/native-platforms/ios-facebook-login/facebook-token-exchange.md
@@ -0,0 +1,36 @@
+With the SDK installed, it's time to go back to the first method you added and tie everything together. 
+
+Add logic in the method to execute the requests you prepared in the previous steps. Then, pass the resulting Session Access Token and user profile to the SDK method `login(facebookSessionAccessToken:profile:)`. Don't forget to import the SDK first, with `import Auth0`.
+
+```swift
+fileprivate func login(with accessToken: FacebookLogin.AccessToken) {
+    // Get the request publishers
+    let sessionAccessTokenPublisher = fetchSessionAccessToken(appId: accessToken.appID,
+                                                              accessToken: accessToken.tokenString)
+    let profilePublisher = fetchProfile(userId: accessToken.userID, accessToken: accessToken.tokenString)
+
+    // Start both requests in parallel and wait until all finish
+    _ = Publishers
+        .Zip(sessionAccessTokenPublisher, profilePublisher)
+        .sink(receiveCompletion: { completion in
+            if case .failure(let error) = completion {
+                print(error)
+            }
+        }, receiveValue: { sessionAccessToken, profile in
+            // Perform the token exchange
+            Auth0
+                .authentication()
+                .login(facebookSessionAccessToken: sessionAccessToken, profile: profile)
+                .start { result in
+                    switch result {
+                    case .success(let credentials): print(credentials) // Auth0 user credentials 🎉
+                    case .failure(let error): print(error)
+                }
+            }
+        })
+}
+```
+
+::: note
+To learn more about the `Credentials` object, check out [its source](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift).
+:::
diff --git a/snippets/native-platforms/ios-swift/use.md b/snippets/native-platforms/ios-swift/use.md
index 69e1bb9f08..1fa4783242 100644
--- a/snippets/native-platforms/ios-swift/use.md
+++ b/snippets/native-platforms/ios-swift/use.md
@@ -5,8 +5,8 @@ Auth0
     .webAuth()
     .scope("openid profile")
     .audience("https://${account.namespace}/userinfo")
-    .start {
-        switch $0 {
+    .start { result in
+        switch result {
         case .failure(let error):
             // Handle the error
             print("Error: \(error)")
diff --git a/snippets/native-platforms/phonegap/dependencies.md b/snippets/native-platforms/phonegap/dependencies.md
deleted file mode 100644
index cdc38988b5..0000000000
--- a/snippets/native-platforms/phonegap/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-phonegap plugin add cordova-plugin-inappbrowser
-```
diff --git a/snippets/native-platforms/reactnative/setup.md b/snippets/native-platforms/reactnative/setup.md
deleted file mode 100644
index 264735c22a..0000000000
--- a/snippets/native-platforms/reactnative/setup.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```js
-import Auth0 from 'react-native-auth0';
-const auth0 = new Auth0({ domain: '${account.namespace}', clientId: '${account.clientId}' });
-```
diff --git a/snippets/native-platforms/reactnative/use.md b/snippets/native-platforms/reactnative/use.md
deleted file mode 100644
index 3ea8cb96b2..0000000000
--- a/snippets/native-platforms/reactnative/use.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```js
-auth0
-    .webAuth
-    .authorize({scope: 'openid profile email', audience: 'https://${account.namespace}/userinfo'})
-    .then(credentials =>
-      console.log(credentials)
-      // Successfully authenticated
-      // Store the accessToken
-    )
-    .catch(error => console.log(error));
-```
diff --git a/snippets/native-platforms/wpf-winforms/setup.md b/snippets/native-platforms/wpf-winforms/setup.md
index cf159d471c..8191bcc18a 100644
--- a/snippets/native-platforms/wpf-winforms/setup.md
+++ b/snippets/native-platforms/wpf-winforms/setup.md
@@ -3,9 +3,11 @@
 
 using Auth0.OidcClient;
 
-var client = new Auth0Client(new Auth0ClientOptions
+Auth0ClientOptions clientOptions = new Auth0ClientOptions
 {
     Domain = "${account.namespace}",
     ClientId = "${account.clientId}"
-});
+};
+client = new Auth0Client(clientOptions);
+clientOptions.PostLogoutRedirectUri = clientOptions.RedirectUri;
 ```
diff --git a/snippets/native-platforms/xamarin/dependencies.md b/snippets/native-platforms/xamarin/dependencies.md
index a08b4ec761..10c16887f3 100644
--- a/snippets/native-platforms/xamarin/dependencies.md
+++ b/snippets/native-platforms/xamarin/dependencies.md
@@ -1,12 +1,12 @@
-If you are using Visual Studio 2017, simply open the Package Manager Console (View -> Other Windows -> Package Manager Console), and install the package:
+If you are using Visual Studio, simply open the Package Manager Console (View -> Other Windows -> Package Manager Console), and install the package:
 
-For Android:
+**For Android:**
 
 ```text
-Install-Package Auth0.OidcClient.Android
+Install-Package Auth0.OidcClient.AndroidX
 ```
 
-For iOS:
+**For iOS:**
 
 ```text
 Install-Package Auth0.OidcClient.iOS
@@ -15,5 +15,5 @@ Install-Package Auth0.OidcClient.iOS
 Alternatively, if you are using Visual Studio for Mac, please perform the following steps:
 
   1. With the project loaded in Visual Studio for Mac, Ctrl+click (or right click) on the **Packages** folder of the project in the **Solution Pad**, and select **Add Packages...**
-  2. The **Add Packages** dialog will appear. Search and locate the package called `Auth0.OidcClient.Android` or `Auth0.OidcClient.iOS` depending on your platform.
+  2. The **Add Packages** dialog will appear. Search and locate the package called `Auth0.OidcClient.AndroidX` or `Auth0.OidcClient.iOS` depending on your platform.
   3. Tick the checkbox next to the package to select it, and click the **Add Package** button
\ No newline at end of file
diff --git a/snippets/native-platforms/xamarin/setup.md b/snippets/native-platforms/xamarin/setup.md
index 424e804c89..59c2df8db5 100644
--- a/snippets/native-platforms/xamarin/setup.md
+++ b/snippets/native-platforms/xamarin/setup.md
@@ -1,25 +1,9 @@
-For Android:
-
 ```cs
 using Auth0.OidcClient;
 
 var client = new Auth0Client(new Auth0ClientOptions
 {
     Domain = "${account.namespace}",
-    ClientId = "${account.clientId}",
-    Activity = this
-});
-```
-
-For iOS:
-
-```csharp
-using Auth0.OidcClient;
-
-var client = new Auth0Client(new Auth0ClientOptions
-{
-    Domain = "${account.namespace}",
-    ClientId = "${account.clientId}",
-    Controller = this // The instance of your UIViewController from which you are calling this code
-});
-```
+    ClientId = "${account.clientId}"
+}, this);
+```
\ No newline at end of file
diff --git a/snippets/server-apis/aspnet-webapi/dependencies.md b/snippets/server-apis/aspnet-webapi/dependencies.md
deleted file mode 100644
index cf64e4e847..0000000000
--- a/snippets/server-apis/aspnet-webapi/dependencies.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```Powershell
-Install-Package WebApi.JsonWebToken
-Install-Package Auth0-ASPNET
-```
diff --git a/snippets/server-apis/aspnet-webapi/setup.md b/snippets/server-apis/aspnet-webapi/setup.md
deleted file mode 100644
index 8e0177447e..0000000000
--- a/snippets/server-apis/aspnet-webapi/setup.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```xml
-
-
-```
diff --git a/snippets/server-apis/aspnet-webapi/use.md b/snippets/server-apis/aspnet-webapi/use.md
deleted file mode 100644
index 98fa26977f..0000000000
--- a/snippets/server-apis/aspnet-webapi/use.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```cs
-var clientID = WebConfigurationManager.AppSettings["auth0:ClientId"];
-var clientSecret = WebConfigurationManager.AppSettings["auth0:ClientSecret"];
-
-config.MessageHandlers.Add(new JsonWebTokenValidationHandler()
-{
-    Audience = clientID,
-    SymmetricKey = clientSecret,
-    IsSecretBase64Encoded = false
-});
-```
diff --git a/snippets/server-apis/falcor/setup.md b/snippets/server-apis/falcor/setup.md
index 1a0a499aaf..fc2c7615a9 100644
--- a/snippets/server-apis/falcor/setup.md
+++ b/snippets/server-apis/falcor/setup.md
@@ -9,11 +9,11 @@ const falcorExpress = require('falcor-express');
 const Router = require('falcor-router');
 
 // Authentication middleware. When used, the
-// access token must exist and be verified against
+// Access Token must exist and be verified against
 // the Auth0 JSON Web Key Set
 const authenticate = jwt({
   // Dynamically provide a signing key
-  // based on the kid in the header and 
+  // based on the kid in the header and
   // the singing keys provided by the JWKS endpoint.
   secret: jwksRsa.expressJwtSecret({
     cache: true,
@@ -51,4 +51,4 @@ const checkJwt = jwt({
   issuer: `https://${process.env.AUTH0_DOMAIN}/`,
   algorithms: ['RS256']
 });
-```
\ No newline at end of file
+```
diff --git a/snippets/server-apis/java-spring-security/dependencies-gradle.md b/snippets/server-apis/java-spring-security/dependencies-gradle.md
index 088d348b2c..ca19b93476 100644
--- a/snippets/server-apis/java-spring-security/dependencies-gradle.md
+++ b/snippets/server-apis/java-spring-security/dependencies-gradle.md
@@ -1,3 +1,3 @@
 ```groovy
-compile 'com.auth0:auth0-spring-security-api:1.0.0-rc.3'
+compile 'com.auth0:auth0-spring-security-api:1.1.0'
 ```
\ No newline at end of file
diff --git a/snippets/server-apis/java-spring-security/dependencies.md b/snippets/server-apis/java-spring-security/dependencies.md
index 292372f5e9..69a5336f55 100644
--- a/snippets/server-apis/java-spring-security/dependencies.md
+++ b/snippets/server-apis/java-spring-security/dependencies.md
@@ -2,6 +2,6 @@
 
   com.auth0
   auth0-spring-security-api
-  1.0.0-rc.3
+  1.1.0
 
 ```
\ No newline at end of file
diff --git a/snippets/server-apis/php-laravel/dependencies.md b/snippets/server-apis/php-laravel/dependencies.md
deleted file mode 100644
index 74571265ed..0000000000
--- a/snippets/server-apis/php-laravel/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-composer require auth0/login:"~5.0"
-```
diff --git a/snippets/server-apis/php-laravel/setup.md b/snippets/server-apis/php-laravel/setup.md
deleted file mode 100644
index e2b37f8061..0000000000
--- a/snippets/server-apis/php-laravel/setup.md
+++ /dev/null
@@ -1,9 +0,0 @@
-```php
-// config/app.php
-
-'providers' => [
-    // ...
-     \Auth0\Login\LoginServiceProvider::class,
-
-],
-```
diff --git a/snippets/server-apis/php-laravel/use.md b/snippets/server-apis/php-laravel/use.md
deleted file mode 100644
index a31f0bc470..0000000000
--- a/snippets/server-apis/php-laravel/use.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```php
-Route::get('/user', function (Request $request) {
-    return $request->user();
-})->middleware('auth:api');
-```
diff --git a/snippets/server-apis/php/setup.md b/snippets/server-apis/php/setup.md
index e55bb1e26f..152426415b 100644
--- a/snippets/server-apis/php/setup.md
+++ b/snippets/server-apis/php/setup.md
@@ -9,7 +9,7 @@
   $router->before('GET', '/secured/.*', function() {
 
     // This method will exist if you're using apache
-    // If you're not, please go to the extras for a defintion of it.
+    // If you're not, please go to the extras for a definition of it.
     $requestHeaders = apache_request_headers();
     $authorizationHeader = $requestHeaders['Authorization'];
 
diff --git a/snippets/server-apis/python/use.md b/snippets/server-apis/python/use.md
index 275ed5871d..15a5fe5984 100644
--- a/snippets/server-apis/python/use.md
+++ b/snippets/server-apis/python/use.md
@@ -2,17 +2,30 @@
 # Controllers API
 
 # This doesn't need authentication
-@app.route("/api/public")
-@cross_origin(headers=['Content-Type', 'Authorization'])
+@APP.route("/api/public")
+@cross_origin(headers=["Content-Type", "Authorization"])
 def public():
     response = "Hello from a public endpoint! You don't need to be authenticated to see this."
     return jsonify(message=response)
 
-# This does need authentication
-@app.route("/api/private")
-@cross_origin(headers=['Content-Type', 'Authorization'])
+# This needs authentication
+@APP.route("/api/private")
+@cross_origin(headers=["Content-Type", "Authorization"])
 @requires_auth
 def private():
     response = "Hello from a private endpoint! You need to be authenticated to see this."
     return jsonify(message=response)
+
+# This needs authorization
+@APP.route("/api/private-scoped")
+@cross_origin(headers=["Content-Type", "Authorization"])
+@requires_auth
+def private_scoped():
+    if requires_scope("read:messages"):
+        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)
+    raise AuthError({
+        "code": "Unauthorized",
+        "description": "You don't have access to this resource"
+    }, 403)
 ```
diff --git a/snippets/server-apis/relay/dependencies.md b/snippets/server-apis/relay/dependencies.md
deleted file mode 100644
index 1100952535..0000000000
--- a/snippets/server-apis/relay/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install express-jwt express-graphql --save
-```
diff --git a/snippets/server-apis/relay/frontend.md b/snippets/server-apis/relay/frontend.md
deleted file mode 100644
index bd45765d77..0000000000
--- a/snippets/server-apis/relay/frontend.md
+++ /dev/null
@@ -1,14 +0,0 @@
-```js
-
-// server.js
-
-const token = localStorage.getItem('access_token');
-
-Relay.injectNetworkLayer(
-  new Relay.DefaultNetworkLayer('http://localhost:3000/graphql', {
-    headers: {
-      Authorization: 'Bearer ' + token
-    }
-  })
-);
-```
diff --git a/snippets/server-apis/relay/setup.md b/snippets/server-apis/relay/setup.md
deleted file mode 100644
index 6376bf7220..0000000000
--- a/snippets/server-apis/relay/setup.md
+++ /dev/null
@@ -1,29 +0,0 @@
-```js
-// server.js
-
-const express = require('express');
-const app = express();
-const graphqlHttp   = require('express-graphql');
-const jwt = require('express-jwt');
-const jwksRsa = require('jwks-rsa');
-
-// Authentication middleware. When used, the
-// access token must exist and be verified against
-// the Auth0 JSON Web Key Set
-const authenticate = jwt({
-  // Dynamically provide a signing key
-  // based on the kid in the header and 
-  // the singing 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: '${apiIdentifier}',
-  issuer: `https://${account.namespace}/`,
-  algorithms: ['RS256']
-});
-```
diff --git a/snippets/server-apis/relay/use.md b/snippets/server-apis/relay/use.md
deleted file mode 100644
index c2dc3ad382..0000000000
--- a/snippets/server-apis/relay/use.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```js
-app.use('/graphql', authenticate, graphqlHttp({schema: schema}));
-```
\ No newline at end of file
diff --git a/snippets/server-platforms/apache/setup.md b/snippets/server-platforms/apache/setup.md
index 6a7a71eedb..b0e71776f9 100644
--- a/snippets/server-platforms/apache/setup.md
+++ b/snippets/server-platforms/apache/setup.md
@@ -1,4 +1,6 @@
 ```
+# mods-available/auth_openidc.conf
+
 OIDCProviderMetadataURL https://${account.namespace}/.well-known/openid-configuration
 OIDCClientID ${account.clientId}
 OIDCClientSecret 'YOUR_CLIENT_SECRET'
diff --git a/snippets/server-platforms/apache/use.md b/snippets/server-platforms/apache/use.md
index 227de2e4ff..2e638a3a69 100644
--- a/snippets/server-platforms/apache/use.md
+++ b/snippets/server-platforms/apache/use.md
@@ -1,4 +1,6 @@
 ```xml
+# mods-available/auth_openidc.conf
+
 
    AuthType openid-connect
    #Require valid-user
diff --git a/snippets/server-platforms/asp-classic/setup.md b/snippets/server-platforms/asp-classic/setup.md
deleted file mode 100644
index 59e1bd8139..0000000000
--- a/snippets/server-platforms/asp-classic/setup.md
+++ /dev/null
@@ -1,29 +0,0 @@
-```asp
-<%= '\<%@ Language="VBScript" %\>' %>
-<%= '\<% Option Explicit %\>' %>
-
-
-
-    
-    Testing Auth0 with Classic ASP
-
-
-  
-  
-  
-
-
-```
diff --git a/snippets/server-platforms/asp-classic/use.md b/snippets/server-platforms/asp-classic/use.md
deleted file mode 100644
index 50351c5676..0000000000
--- a/snippets/server-platforms/asp-classic/use.md
+++ /dev/null
@@ -1,58 +0,0 @@
-```asp
-<%= '\<%@ Language="VBScript" %\>' %>
-
-
-
-<%= '\<%' %>
-CLIENT_ID = "${account.clientId}"
-CLIENT_SECRET = "YOUR_CLIENT_SECRET"
-REDIRECT_URI = "${account.callback}"
-
-AUTHORIZATION_CODE = Request.querystring( "code" )
-
-access_token = GetAccessToken(CLIENT_ID, CLIENT_SECRET, REDIRECT_URI, AUTHORIZATION_CODE)
-
-set profile = GetUserProfile( access_token )
-
-'Here, you should save the profile in the session or somewhere'
-
-Response.Write "Hello, = " & profile.nickname
-
-Function GetUserProfile(access_token)
-
-  Set http = Server.CreateObject("MSXML2.ServerXMLHTTP")
-
-  http.open "GET", "https://${account.namespace}/userinfo?access_token=" & access_token, False
-
-  http.send
-
-  profile = http.responseText
-
-  Set GetUserProfile = JSON.parse(profile)
-
-  Set http = Nothing
-
-End Function
-
-Function GetAccessToken(client_id, client_secret, redirect_uri, authorization_code)
-
-  Set http = Server.CreateObject("MSXML2.ServerXMLHTTP")
-
-  http.open "POST", "https://${account.namespace}/oauth/token", False
-
-  http.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
-
-  http.send "client_id=" & client_id & "&client_secret=" & client_secret & "&redirect_uri=" & server.UrlEncode(redirect_uri) & "&code=" & authorization_code & "&grant_type=authorization_code"
-
-  result = http.responseText
-
-  Set http = Nothing
-
-  set jsonResult = JSON.parse(result)
-
-  GetAccessToken = jsonresult.access_token
-
-End Function
-
-<%= '%\>' %>
-```
diff --git a/snippets/server-platforms/aspnet/dependencies.md b/snippets/server-platforms/aspnet/dependencies.md
deleted file mode 100644
index 504fee32c5..0000000000
--- a/snippets/server-platforms/aspnet/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```powershell
-Install-Package Auth0-ASPNET
-```
diff --git a/snippets/server-platforms/aspnet/setup.md b/snippets/server-platforms/aspnet/setup.md
deleted file mode 100644
index 5ee0ced66b..0000000000
--- a/snippets/server-platforms/aspnet/setup.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```xml
-
-
-
-```
diff --git a/snippets/server-platforms/aspnet/use.md b/snippets/server-platforms/aspnet/use.md
deleted file mode 100644
index 41f09fb7f2..0000000000
--- a/snippets/server-platforms/aspnet/use.md
+++ /dev/null
@@ -1,19 +0,0 @@
-```html
-
-
-
-
-```
diff --git a/snippets/server-platforms/golang/dependencies.md b/snippets/server-platforms/golang/dependencies.md
index 6d88ad8563..0a27428184 100644
--- a/snippets/server-platforms/golang/dependencies.md
+++ b/snippets/server-platforms/golang/dependencies.md
@@ -1,5 +1,6 @@
 ```bash
-go get github.com/gorilla/mux
-go get github.com/gorilla/sessions
-go get golang.org/x/oauth2
+go get github.com/coreos/go-oidc \
+  github.com/gorilla/mux \
+  github.com/gorilla/sessions \
+  golang.org/x/oauth2
 ```
diff --git a/snippets/server-platforms/java-spring-security/customLoginJsp.md b/snippets/server-platforms/java-spring-security/customLoginJsp.md
index b669d747c4..4204623db7 100644
--- a/snippets/server-platforms/java-spring-security/customLoginJsp.md
+++ b/snippets/server-platforms/java-spring-security/customLoginJsp.md
@@ -47,7 +47,7 @@ ${'<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags"%>'
                         sso: true,
                         connection: '<%= "${connection}" %>',
                         // change scopes to whatever you like
-                        // claims are added to JWT id_token - openid profile gives everything
+                        // claims are added to JWT ID Token - openid profile gives everything
                         scope: 'openid user_id name nickname email picture',
                         state: '<%= "${state}" %>'
                     }, function (err) {
diff --git a/snippets/server-platforms/laravel/dependencies.md b/snippets/server-platforms/laravel/dependencies.md
deleted file mode 100644
index 1f0cbea5e2..0000000000
--- a/snippets/server-platforms/laravel/dependencies.md
+++ /dev/null
@@ -1 +0,0 @@
-To install this plugin run `composer require auth0/login:"~5.0"`
diff --git a/snippets/server-platforms/laravel/setup.md b/snippets/server-platforms/laravel/setup.md
deleted file mode 100644
index 110d374a88..0000000000
--- a/snippets/server-platforms/laravel/setup.md
+++ /dev/null
@@ -1,8 +0,0 @@
-```php
-// config/app.php
-
-'providers' => array(
-    // ...
-    Auth0\Login\LoginServiceProvider::class,
-);
-```
diff --git a/snippets/server-platforms/laravel/use.md b/snippets/server-platforms/laravel/use.md
deleted file mode 100644
index 3212a46c95..0000000000
--- a/snippets/server-platforms/laravel/use.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```html
-
-
-
-
-```
diff --git a/snippets/server-platforms/nginx-plus/logout.md b/snippets/server-platforms/nginx-plus/logout.md
new file mode 100644
index 0000000000..0a45eb1555
--- /dev/null
+++ b/snippets/server-platforms/nginx-plus/logout.md
@@ -0,0 +1,6 @@
+```
+# openid_connect_configuration.conf
+map $host $oidc_logout_redirect {
+    default "https://${account.namespace}/v2/logout";
+}
+```
diff --git a/snippets/server-platforms/nginx-plus/module.md b/snippets/server-platforms/nginx-plus/module.md
new file mode 100644
index 0000000000..df43ebb210
--- /dev/null
+++ b/snippets/server-platforms/nginx-plus/module.md
@@ -0,0 +1,3 @@
+```
+load_module modules/ngx_http_js_module.so;
+```
diff --git a/snippets/server-platforms/nginx-plus/setup.md b/snippets/server-platforms/nginx-plus/setup.md
new file mode 100644
index 0000000000..00efb6cc1c
--- /dev/null
+++ b/snippets/server-platforms/nginx-plus/setup.md
@@ -0,0 +1,6 @@
+```bash
+./configure.sh --auth_jwt_key request \
+  --client_id ${account.clientId} \
+  --pkce_enable \
+  https://${account.namespace}/.well-known/openid-configuration
+```
diff --git a/snippets/server-platforms/nginx-plus/token.md b/snippets/server-platforms/nginx-plus/token.md
new file mode 100644
index 0000000000..3467df0a04
--- /dev/null
+++ b/snippets/server-platforms/nginx-plus/token.md
@@ -0,0 +1,18 @@
+```
+# openid_connect.server_conf
+location = /_jwks_uri {
+    internal;
+    ...
+    proxy_set_header    Content-Length "";           
+    proxy_set_header    Accept-Encoding "gzip";          # this is required
+    ...
+}
+
+location = /_token {
+    internal;
+    ...
+    proxy_set_header    Content-Type "application/x-www-form-urlencoded";
+    proxy_set_header    Accept-Encoding "gzip";          # this is required
+    ...
+}
+```
diff --git a/snippets/server-platforms/nginx-plus/use.md b/snippets/server-platforms/nginx-plus/use.md
new file mode 100644
index 0000000000..902f43c7b8
--- /dev/null
+++ b/snippets/server-platforms/nginx-plus/use.md
@@ -0,0 +1,32 @@
+
+
+```
+# frontend.conf
+# auth_jwt_claim_set $claim_name https://namespace/key;
+
+server {
+    include conf.d/openid_connect.server_conf; # Authorization code flow and Relying Party processing
+    error_log /var/log/nginx/error.log debug;  # Reduce severity level as required
+
+    listen 8010; # Use SSL/TLS in production
+    
+    location / {
+        # This site is protected with OpenID Connect
+        auth_jwt "" token=$session_jwt;
+        error_page 401 = @do_oidc_flow;
+
+        #auth_jwt_key_file $oidc_jwt_keyfile; # Enable when using filename
+        auth_jwt_key_request /_jwks_uri; # Enable when using URL
+
+        # Successfully authenticated users are proxied to the backend,
+        # with 'sub' claim passed as HTTP header
+        proxy_set_header username $jwt_claim_sub;
+        proxy_set_header x-email $jwt_claim_email;
+        #proxy_set_header x-custom $claim_name;             # namespaced claim
+
+        proxy_pass http://my_backend; # The backend site/app
+
+        access_log /var/log/nginx/access.log main_jwt;
+    }
+}
+```
diff --git a/snippets/server-platforms/php/dependencies.md b/snippets/server-platforms/php/dependencies.md
deleted file mode 100644
index af0e04c6d9..0000000000
--- a/snippets/server-platforms/php/dependencies.md
+++ /dev/null
@@ -1,5 +0,0 @@
-To install dependencies, run the following
-
-```bash
-composer require auth0/auth0-php:"~5.0"
-```
diff --git a/snippets/server-platforms/php/install.md b/snippets/server-platforms/php/install.md
new file mode 100644
index 0000000000..b0ea28b88d
--- /dev/null
+++ b/snippets/server-platforms/php/install.md
@@ -0,0 +1,9 @@
+The Auth0 PHP SDK requires Composer, a tool for dependency management in 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.
+
+Run the following shell command within your project directory to install the Auth0 PHP 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 Auth0 PHP SDK. This will also create a `vendor/autoload.php` file used in the sample to load all necessary classes for your application to function. It's important you require this autoload file in your project for the SDK to work.
diff --git a/snippets/server-platforms/php/setup.md b/snippets/server-platforms/php/setup.md
deleted file mode 100644
index 6c87581587..0000000000
--- a/snippets/server-platforms/php/setup.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```php
-use Auth0\SDK\Auth0;
-
-$auth0 = new Auth0(array(
-    'domain'        => '${account.namespace}',
-    'client_id'     => '${account.clientId}',
-    'client_secret' => 'YOUR_CLIENT_SECRET',
-    'redirect_uri'  => '${account.callback}'
-));
-```
diff --git a/snippets/server-platforms/php/use.md b/snippets/server-platforms/php/use.md
deleted file mode 100644
index 4dd44f1a45..0000000000
--- a/snippets/server-platforms/php/use.md
+++ /dev/null
@@ -1,19 +0,0 @@
-```html
-
-
-
-
-```
diff --git a/snippets/server-platforms/rails/dependencies.md b/snippets/server-platforms/rails/dependencies.md
deleted file mode 100644
index 17a13e770d..0000000000
--- a/snippets/server-platforms/rails/dependencies.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```js
-gem 'omniauth', '~> 1.6.1'
-gem 'omniauth-auth0', '~> 2.0.0'
-```
diff --git a/snippets/server-platforms/rails/setup.md b/snippets/server-platforms/rails/setup.md
deleted file mode 100644
index 013b174330..0000000000
--- a/snippets/server-platforms/rails/setup.md
+++ /dev/null
@@ -1,15 +0,0 @@
-```ruby
-Rails.application.config.middleware.use OmniAuth::Builder do
-  provider(
-    :auth0,
-    '${account.clientId}',
-    'YOUR_CLIENT_SECRET',
-    '${account.namespace}',
-    callback_path: "/auth/oauth2/callback",
-    authorize_params: {
-      scope: 'openid profile',
-      audience: 'https://${account.namespace}/userinfo'
-    }
-  )
-end
-```
diff --git a/snippets/server-platforms/rails/use.md b/snippets/server-platforms/rails/use.md
deleted file mode 100644
index c7be83918d..0000000000
--- a/snippets/server-platforms/rails/use.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```html
-
-
-```
\ No newline at end of file
diff --git a/snippets/social/amazon/0.md b/snippets/social/amazon/0.md
new file mode 100644
index 0000000000..d9faa3aa0d
--- /dev/null
+++ b/snippets/social/amazon/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Amazon
+
+The Amazon social connection allows users to log in to your application using their Amazon profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/amazon/1.md b/snippets/social/amazon/1.md
new file mode 100644
index 0000000000..7c873908d6
--- /dev/null
+++ b/snippets/social/amazon/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for an Amazon portal account](http://login.amazon.com).
diff --git a/snippets/social/amazon/2.md b/snippets/social/amazon/2.md
new file mode 100644
index 0000000000..521aabcfa1
--- /dev/null
+++ b/snippets/social/amazon/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Amazon, you will:
+
+1. [Set up app on Amazon](#set-up-app-on-amazon)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection) 
diff --git a/snippets/social/amazon/3.md b/snippets/social/amazon/3.md
new file mode 100644
index 0000000000..aa12aa6e82
--- /dev/null
+++ b/snippets/social/amazon/3.md
@@ -0,0 +1,16 @@
+### Set up app on Amazon
+
+Register an app in the [Amazon Developer Portal](https://developer.amazon.com/) using Amazon's [Register for Login with Amazon](https://developer.amazon.com/docs/login-with-amazon/register-web.html) documentation. During this process, Amazon will generate a **API key** and **API secret key** for your application; make note of these.  After your application is created, you can find these on its **Application Details** view.
+
+When setting up your app, use the following values:
+
+| Field | Value to Provide |
+| - | - |
+| Allowed Javascript Origins | `https://${account.namespace}/` |
+| Allowed Return URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your return URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/amazon/4.md b/snippets/social/amazon/4.md
new file mode 100644
index 0000000000..72dfb9d440
--- /dev/null
+++ b/snippets/social/amazon/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Amazon social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API key** and **API secret key**.
diff --git a/snippets/social/amazon/5.md b/snippets/social/amazon/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/amazon/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/apple/0.md b/snippets/social/apple/0.md
new file mode 100644
index 0000000000..220b3307fd
--- /dev/null
+++ b/snippets/social/apple/0.md
@@ -0,0 +1,9 @@
+# Connect Web Apps to Apple
+ 
+The Apple social connection allows users to log in to your application using their Apple profile. The [Apple App Store Developer Guidelines](https://developer.apple.com/app-store/review/guidelines/#sign-in-with-apple) require that Sign In With Apple (SIWA) must be available in all applications that exclusively use third-party sign-in options, such as Facebook or Google.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
+
+::: note
+Apple does not currently provide a way to change the icon/logo displayed on the Apple login page.
+:::
diff --git a/snippets/social/apple/1.md b/snippets/social/apple/1.md
new file mode 100644
index 0000000000..fda2c63286
--- /dev/null
+++ b/snippets/social/apple/1.md
@@ -0,0 +1,7 @@
+## Prerequisites
+
+Before you begin, [sign up for an Apple Developer Program account](https://developer.apple.com/programs/), which is a paid account. A free trial is available if you are a member of the [iOS Developer University Program](https://developer.apple.com/support/compare-memberships/).
+
+::: note
+If you are using the Classic Universal Login flow or embedding `Lock.js` in your application, make sure you are using `Lock.js` version 11.16 or later. 
+:::
diff --git a/snippets/social/apple/2.md b/snippets/social/apple/2.md
new file mode 100644
index 0000000000..1cc4a1fb4e
--- /dev/null
+++ b/snippets/social/apple/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Apple, you will:
+
+1. [Set up app in Apple](#set-up-app-in-apple)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/apple/3.md b/snippets/social/apple/3.md
new file mode 100644
index 0000000000..237c3d9bd1
--- /dev/null
+++ b/snippets/social/apple/3.md
@@ -0,0 +1,23 @@
+## Set up app in Apple
+
+Set up an app in the [Apple Developer Portal](https://developer.apple.com) using Apple's [Sign in with Apple](https://developer.apple.com/sign-in-with-apple/get-started/) documentation. During this process, Apple will generate the following IDs and keys for your application; make note of these:
+
+* Services ID (Client ID)
+* Client Secret Signing Key 
+* Apple Team ID
+* Key ID
+
+When setting up your app, use the following values:
+
+| Field | Value to Provide |
+| - | - |
+| Bundle ID | `com.auth0` |
+| Services ID Identifier | Reverse domain name (e.g., `.com.auth0.travel0`) |
+| Web Domain | `https://${account.namespace}/` |
+| Return URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/apple/4.md b/snippets/social/apple/4.md
new file mode 100644
index 0000000000..be230ef55f
--- /dev/null
+++ b/snippets/social/apple/4.md
@@ -0,0 +1,16 @@
+### Create and enable connection in Auth0
+
+[Set up the Apple social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated IDs and keys:
+
+* Services ID (Client ID)
+* Client Secret Signing Key 
+* Apple Team ID
+* Key ID
+
+Besides the standard social connection settings, the Apple social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Client Secret Signing Key | The content of the file that you downloaded when registering the Key. The file has a '.p8' extension. |
+| Team ID | ID of the organization Apple approved to receive their development kit. Developer accounts are associated with an approved team. You can find your Team ID in the Apple Developer Portal under **Membership Details**. |
+| Key ID | ID of the key that Apple issued to allow your app to perform Sign in With Apple. You can find your Key ID in the Apple Developer Portal under **Certificates, Identifiers & Profiles**. |
diff --git a/snippets/social/apple/5.md b/snippets/social/apple/5.md
new file mode 100644
index 0000000000..67330003e1
--- /dev/null
+++ b/snippets/social/apple/5.md
@@ -0,0 +1,30 @@
+#### Management API
+
+Alternatively, you can set up the Apple social connection using the Management API.
+
+Make a `POST` call to the [Create a Connection endpoint](https://auth0.com/docs/api/management/v2/#!/Connections/post_connections). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CLIENT_ID`, `APPLE_TEAM_ID`, `APPLE_KEY_ID`, `APPLE_SERVICES_ID`, and `APPLE_CLIENT_SECRET_SIGNING_KEY` placeholder values with your Management API Access Token, Auth0 Client ID, Apple Team ID, Apple Key ID, Apple Services ID, and Apple Client Secret Signing Key values, respectively.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/connections",
+  "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\": \"My Apple Connection\", \"strategy\": \"apple\", \"enabled_clients\": [ { \"CLIENT_ID\" },{ \"CLIENT_ID\" } ], \"options\":{ \"team_id\": \"APPLE_TEAM_ID\", \"client_id\": \"APPLE_SERVICES_ID\", \"kid\": \"APPLE_KEY_ID\", \"app_secret\": \"APPLE_CLIENT_SECRET_SIGNING_KEY\", \"email\": true, \"name\": true} }"
+  }
+}
+```
+
+| Value | Description |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](https://auth0.com/docs/api/management/v2/tokens) with the scope `create:connections`. |
+| `CLIENT_ID` | Client ID of the application for which you want the connection enabled. You can find this on the settings page for your[Application](${manage_url}/#/applications) in the [Auth0 Dashboard](${manage_url}/). |
+| `APPLE_TEAM_ID` | Team ID of your Apple team. You can find this in the Apple Developer Portal under **Membership Details**. |
+| `APPLE_SERVICES_ID` | Services ID for your Apple application. You can find this in the Apple Developer Portal under **Certificates, Identifiers & Profiles**. |
+| `APPLE_CLIENT_SECRET_SIGNING_KEY` | Client Secret Signing Key for your Apple application. You can find this in the Apple Developer Portal under **Certificates, Identifiers & Profiles**. |
+| `APPLE_KEY_ID` | Key ID of the Client Secret Signing Key for your Apple application. You can find this in the Apple Developer Portal under **Certificates, Identifiers & Profiles**.|
diff --git a/snippets/social/apple/6.md b/snippets/social/apple/6.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/apple/6.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/auth0-oidc/0.md b/snippets/social/auth0-oidc/0.md
new file mode 100644
index 0000000000..1c503d5478
--- /dev/null
+++ b/snippets/social/auth0-oidc/0.md
@@ -0,0 +1,7 @@
+# Authenticate using OpenIDConnect to another Auth0 Tenant (Deprecated)
+
+::: warning
+This solution has been deprecated because it requires the use of a legacy version of the Auth0 User Profile. You should use the [OIDC Enterprise Connection](https://auth0.com/docs/connections/enterprise/oidc) instead.
+:::
+
+You can use an application on one Auth0 tenant (referred to below as the **OIDC Provider tenant**) as an identity provider in another Auth0 tenant (the **Relying Party tenant**).
diff --git a/snippets/social/auth0-oidc/1.md b/snippets/social/auth0-oidc/1.md
new file mode 100644
index 0000000000..70bd51777d
--- /dev/null
+++ b/snippets/social/auth0-oidc/1.md
@@ -0,0 +1,14 @@
+## Configure the OIDC Provider Auth0 Tenant
+
+1. Create an Application or edit an existing one. Set the application type to **Regular Web App**.
+2. Take note of your application's **Client ID** and **Client Secret**. You will need these to create the connection in the Relying Party tenant.
+3. Add the Relying Party tenant's login callback to the list of **Allowed Callback URLs**: `https://${account.namespace}/login/callback`
+
+::: panel Find your Auth0 domain name for redirects
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, plus `.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.auth0.com` and your redirect URI would be `https://exampleco-enterprises.auth0.com/login/callback`.
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
+
+4. Make sure that the **OIDC-Conformant** toggle in the **OAuth** tab under the application's **Advance Settings** is turned **off**.
+5. Make sure that the tenant has the **Legacy User Profile** toggle enabled under the **Migrations** section of the [Tenant Advanced Settings](${manage_url}/#/tenant/advanced). If you don't see this toggle for your tenant, please open a support case to request this feature to be enabled.
diff --git a/snippets/social/auth0-oidc/2.md b/snippets/social/auth0-oidc/2.md
new file mode 100644
index 0000000000..dac18fe240
--- /dev/null
+++ b/snippets/social/auth0-oidc/2.md
@@ -0,0 +1,37 @@
+## Configure the Relying Party Auth0 Tenant
+
+The Auth0-to-Auth0 connection is not yet supported in the Dashboard. You need to create the connection using the [Create a connection](https://auth0.com/docs/api/v2#!/Connections/post_connections) endpoint, which will require an [Management API V2 token](https://auth0.com/docs/api/management/v2/tokens) with `create:connections` scope.
+
+Here is a sample request:
+
+```sh
+curl -H "Content-Type: application/json" -H 'Authorization: Bearer {YOUR_API_V2_TOKEN}' -d @auth0-oidc-connection.json https://${account.namespace}/api/v2/connections
+```
+
+with the **auth0-oidc-connection.json** file containing:
+
+```js
+{
+  "name": "YOUR-AUTH0-CONNECTION-NAME",
+  "strategy": "auth0-oidc",
+  "options": {
+    "client_id": "OIDC_PROVIDER_CLIENT_ID",
+    "client_secret": "OIDC_PROVIDER_CLIENT_SECRET",
+    "domain": "OIDC_PROVIDER_AUTH0_DOMAIN",
+    "scope": "openid"
+  },
+  "enabled_clients":["${account.clientId}"]
+}
+```
+
+The required parameters for this connection are:
+
+| Parameter | Description |
+| - | - |
+| **name** | How the connection will be referenced in Auth0 or in your app |
+| **strategy** | Defines the protocol implemented by the provider. This should always be `auth0-oidc` |
+| **options.client_id** | The `clientID` of the target Application in the OIDC Provider Auth0 tenant |
+| **options.client_secret** | The `clientSecret` of the target Application in the OIDC Provider Auth0 tenant |
+| **options.domain** | The domain of the OIDC Provider Auth0 tenant |
+| **options.scope** 
        Optional | The scope parameters for which you wish to request consent (such as `profile`, `identities`, and so on) |
+| **enabled_clients** 
        Optional | An array containing the identifiers of the applications for which the connection is to be enabled. If the array is empty or the property is not specified, no applications are enabled |
diff --git a/snippets/social/auth0-oidc/3.md b/snippets/social/auth0-oidc/3.md
new file mode 100644
index 0000000000..84abcc840b
--- /dev/null
+++ b/snippets/social/auth0-oidc/3.md
@@ -0,0 +1,13 @@
+## Use the Auth0 connection
+
+You can use any of the standard Auth0 mechanisms (such as direct links, [Auth0 Lock](https://auth0.com/docs/libraries/lock), [auth0.js](https://auth0.com/docs/auth0js), and so on) to log in a user with the auth0-oidc connection.
+
+A direct link would look like:
+
+```text
+https://${account.namespace}/authorize/?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}&state=OPAQUE_VALUE&connection=YOUR-AUTH0-CONNECTION-NAME
+```
+
+To add a custom connection in Lock, you can add a custom button as described in [Adding a new UI element using JavaScript](https://auth0.com/docs/libraries/lock/v9/ui-customization#adding-a-new-ui-element-using-javascript) and use the direct link as the button `href`.
+
+The user will be redirected to the built-in login page of the OIDC Provider Auth0 tenant where they can choose their identity provider (from the enabled connections of the target Application) and enter their credentials.
diff --git a/snippets/social/baidu/0.md b/snippets/social/baidu/0.md
new file mode 100644
index 0000000000..4464484742
--- /dev/null
+++ b/snippets/social/baidu/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Baidu
+
+The Baidu social connection allows users to log in to your application using their Baidu profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/baidu/1.md b/snippets/social/baidu/1.md
new file mode 100644
index 0000000000..3d51070a8c
--- /dev/null
+++ b/snippets/social/baidu/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for an account on the Baidu integration portal](https://developer.baidu.com/dev).
diff --git a/snippets/social/baidu/2.md b/snippets/social/baidu/2.md
new file mode 100644
index 0000000000..67f82e9061
--- /dev/null
+++ b/snippets/social/baidu/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Baidu, you will:
+
+1. [Set up app in Baidu](#set-up-app-in-baidu)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/baidu/3.md b/snippets/social/baidu/3.md
new file mode 100644
index 0000000000..cd56e1243e
--- /dev/null
+++ b/snippets/social/baidu/3.md
@@ -0,0 +1,15 @@
+### Set up app in Baidu
+
+Create a new app in the [Baidu Integration portal](https://developer.baidu.com/dev). During this process, Baidu will generate an **API Key** and **Secret Key** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| ----- | ---------------- |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/baidu/4.md b/snippets/social/baidu/4.md
new file mode 100644
index 0000000000..e4d2cab439
--- /dev/null
+++ b/snippets/social/baidu/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Baidu social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API Key** and the **Secret Key**.
diff --git a/snippets/social/baidu/5.md b/snippets/social/baidu/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/baidu/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/basecamp/0.md b/snippets/social/basecamp/0.md
new file mode 100644
index 0000000000..1f02d7afc6
--- /dev/null
+++ b/snippets/social/basecamp/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Basecamp
+
+The Basecamp social connection allows users to log in to your application using their Basecamp (formerly 37signals) profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/basecamp/1.md b/snippets/social/basecamp/1.md
new file mode 100644
index 0000000000..c83b562ec1
--- /dev/null
+++ b/snippets/social/basecamp/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Basecamp account](https://basecamp.com/).
diff --git a/snippets/social/basecamp/2.md b/snippets/social/basecamp/2.md
new file mode 100644
index 0000000000..c690baa27e
--- /dev/null
+++ b/snippets/social/basecamp/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Basecamp, you will:
+
+1. [Set up app in Basecamp](#set-up-app-in-basecamp)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/basecamp/3.md b/snippets/social/basecamp/3.md
new file mode 100644
index 0000000000..cf4354c87b
--- /dev/null
+++ b/snippets/social/basecamp/3.md
@@ -0,0 +1,16 @@
+### Set up app in Basecamp
+
+Register an app in Basecamp and generate credentials for it in the [Basecamp Launchpad](https://integrate.37signals.com/). During this process, Basecamp will generate a **Client ID** and **Client Secret** for your application, which you can see on the Application Details page; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+| Products | Select the Basecamp products with which you want your app to integrate. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/basecamp/4.md b/snippets/social/basecamp/4.md
new file mode 100644
index 0000000000..3991e88cb7
--- /dev/null
+++ b/snippets/social/basecamp/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Basecamp social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and the **Client Secret**.
diff --git a/snippets/social/basecamp/5.md b/snippets/social/basecamp/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/basecamp/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/bitbucket/0.md b/snippets/social/bitbucket/0.md
new file mode 100644
index 0000000000..0df155e8aa
--- /dev/null
+++ b/snippets/social/bitbucket/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Bitbucket
+
+The Bitbucket social connection allows users to log in to your application using their Bitbucket profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/bitbucket/1.md b/snippets/social/bitbucket/1.md
new file mode 100644
index 0000000000..3bf20f294a
--- /dev/null
+++ b/snippets/social/bitbucket/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Bitbucket account](https://bitbucket.org/).
diff --git a/snippets/social/bitbucket/2.md b/snippets/social/bitbucket/2.md
new file mode 100644
index 0000000000..bc73ce8656
--- /dev/null
+++ b/snippets/social/bitbucket/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Bitbucket, you will:
+
+1. [Set up app in Bitbucket](#set-up-app-in-bitbucket)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/bitbucket/3.md b/snippets/social/bitbucket/3.md
new file mode 100644
index 0000000000..c2015be0b9
--- /dev/null
+++ b/snippets/social/bitbucket/3.md
@@ -0,0 +1,16 @@
+### Set up app in Bitbucket
+
+Set up an app using Atlassian's [OAuth on Bitbucket Cloud: Create a consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html#OAuthonBitbucketCloud-Createaconsumer) documentation. During this process, Bitbucket will generate a **Key** and **Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URL | `https://${account.namespace}/login/callback` |
+| Permissions | Select the permissions you want to enable for this connection. At minimum, you need `account:email` and `account:read`. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/bitbucket/4.md b/snippets/social/bitbucket/4.md
new file mode 100644
index 0000000000..2831038f81
--- /dev/null
+++ b/snippets/social/bitbucket/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Bitbucket social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the **Key** and the **Secret** generated.
diff --git a/snippets/social/bitbucket/5.md b/snippets/social/bitbucket/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/bitbucket/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/box/0.md b/snippets/social/box/0.md
new file mode 100644
index 0000000000..5d7acca6e4
--- /dev/null
+++ b/snippets/social/box/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Box
+
+The Box social connection allows users to log in to your application using their Box profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/box/1.md b/snippets/social/box/1.md
new file mode 100644
index 0000000000..2e428955b1
--- /dev/null
+++ b/snippets/social/box/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Box Developer account](https://developers.box.com/).
diff --git a/snippets/social/box/2.md b/snippets/social/box/2.md
new file mode 100644
index 0000000000..4202ad4bbc
--- /dev/null
+++ b/snippets/social/box/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Box, you will:
+
+1. [Set up app in Box](#set-up-app-in-box)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/box/3.md b/snippets/social/box/3.md
new file mode 100644
index 0000000000..31644fadbe
--- /dev/null
+++ b/snippets/social/box/3.md
@@ -0,0 +1,16 @@
+### Set up app in Box
+
+Set up an app using Box's [Custom Apps: Setup with OAuth 2.0](https://developer.box.com/guides/applications/custom-apps/oauth2-setup/) documentation. During this process, Box will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+| Application Scopes | Select the permissions you want to enable for this connection. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/box/4.md b/snippets/social/box/4.md
new file mode 100644
index 0000000000..92e4ae1d02
--- /dev/null
+++ b/snippets/social/box/4.md
@@ -0,0 +1,3 @@
+## Create and enable connection in Auth0
+
+[Set up the Box social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the **Client ID** and the **Client Secret** generated.
diff --git a/snippets/social/box/5.md b/snippets/social/box/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/box/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/clever/0.md b/snippets/social/clever/0.md
new file mode 100644
index 0000000000..550bee5827
--- /dev/null
+++ b/snippets/social/clever/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Clever
+
+
+For security reasons, Auth0 no longer integrates with Clever.
+
diff --git a/snippets/social/clever/1.md b/snippets/social/clever/1.md
new file mode 100644
index 0000000000..a7d46a3c4d
--- /dev/null
+++ b/snippets/social/clever/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Clever Developer Partner account](https://go.clever.com/developer-signup).
diff --git a/snippets/social/clever/2.md b/snippets/social/clever/2.md
new file mode 100644
index 0000000000..2a41b61b09
--- /dev/null
+++ b/snippets/social/clever/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Clever, you will:
+
+1. [Set up app in Clever](#set-up-app-in-clever)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/clever/3.md b/snippets/social/clever/3.md
new file mode 100644
index 0000000000..4f0b94ef83
--- /dev/null
+++ b/snippets/social/clever/3.md
@@ -0,0 +1,15 @@
+### Set up app in Clever
+
+Set up an app using Clever's [Getting Started](https://dev.clever.com/docs/classroom-getting-started) documentationumentation. During this process, Clever will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/clever/4.md b/snippets/social/clever/4.md
new file mode 100644
index 0000000000..5bbf150c9f
--- /dev/null
+++ b/snippets/social/clever/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Clever social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/clever/5.md b/snippets/social/clever/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/clever/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/digitalocean/0.md b/snippets/social/digitalocean/0.md
new file mode 100644
index 0000000000..dc40f0ffd1
--- /dev/null
+++ b/snippets/social/digitalocean/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to DigitalOcean
+
+The DigitalOcean social connection allows users to log in to your application using their DigitalOcean profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/digitalocean/1.md b/snippets/social/digitalocean/1.md
new file mode 100644
index 0000000000..449c87c050
--- /dev/null
+++ b/snippets/social/digitalocean/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a DigitalOcean Developer account](https://www.digitalocean.com/).
diff --git a/snippets/social/digitalocean/2.md b/snippets/social/digitalocean/2.md
new file mode 100644
index 0000000000..8f60834d44
--- /dev/null
+++ b/snippets/social/digitalocean/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to DigitalOcean, you will:
+
+1. [Set up app in DigitalOcean](#set-up-app-in-digitalocean)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/digitalocean/3.md b/snippets/social/digitalocean/3.md
new file mode 100644
index 0000000000..355a1547f6
--- /dev/null
+++ b/snippets/social/digitalocean/3.md
@@ -0,0 +1,15 @@
+### Set up app in DigitalOcean
+
+Set up an app using DigitalOcean's [Using OAuth Authentication with DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-use-oauth-authentication-with-digitalocean-as-a-user-or-developer#registering-developer-applications-with-digitalocean) documentationumentation. During this process, DigitalOcean will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/digitalocean/4.md b/snippets/social/digitalocean/4.md
new file mode 100644
index 0000000000..45112fcc4c
--- /dev/null
+++ b/snippets/social/digitalocean/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the DigitalOcean social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/digitalocean/5.md b/snippets/social/digitalocean/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/digitalocean/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/discord/0.md b/snippets/social/discord/0.md
new file mode 100644
index 0000000000..fa6670a5cb
--- /dev/null
+++ b/snippets/social/discord/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Discord
+
+The Discord social connection allows users to log in to your application using their Discord profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/discord/1.md b/snippets/social/discord/1.md
new file mode 100644
index 0000000000..dbbe8e3c77
--- /dev/null
+++ b/snippets/social/discord/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Discord Developer account](https://discord.com/developers).
diff --git a/snippets/social/discord/2.md b/snippets/social/discord/2.md
new file mode 100644
index 0000000000..81f3306b8f
--- /dev/null
+++ b/snippets/social/discord/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Discord, you will:
+
+1. [Set up app in Discord](#set-up-app-in-discord)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/discord/3.md b/snippets/social/discord/3.md
new file mode 100644
index 0000000000..b89c6c33bc
--- /dev/null
+++ b/snippets/social/discord/3.md
@@ -0,0 +1,16 @@
+### Set up app in Discord
+
+Set up an app in the [Discord Developer Portal](https://discord.com/developers/applications). During this process, Discord will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+| Scopes | Select `identify`. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/discord/4.md b/snippets/social/discord/4.md
new file mode 100644
index 0000000000..4040c4594b
--- /dev/null
+++ b/snippets/social/discord/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Discord social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/discord/5.md b/snippets/social/discord/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/discord/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/docomo/0.md b/snippets/social/docomo/0.md
new file mode 100644
index 0000000000..64585e0a55
--- /dev/null
+++ b/snippets/social/docomo/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Docomo dAccounts
+
+The Docomo social connection allows users to log in to your application using their Docomo dAccount profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/docomo/1.md b/snippets/social/docomo/1.md
new file mode 100644
index 0000000000..4939792808
--- /dev/null
+++ b/snippets/social/docomo/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a dAccount Connect Portal account](https://dac-g.apl01.spmode.ne.jp/VIEW_OC01/GOCA00004/).
diff --git a/snippets/social/docomo/2.md b/snippets/social/docomo/2.md
new file mode 100644
index 0000000000..1d1cb76fdc
--- /dev/null
+++ b/snippets/social/docomo/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Docomo dAccount, you will:
+
+1. [Set up app in Docomo dAccount](#set-up-app-in-docomo-daccount)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/docomo/3.md b/snippets/social/docomo/3.md
new file mode 100644
index 0000000000..a05d1dbb97
--- /dev/null
+++ b/snippets/social/docomo/3.md
@@ -0,0 +1,19 @@
+### Set up app in Docomo
+
+Set up an app following the steps on the [dAccount Connect Page](https://id.smt.docomo.ne.jp/src/dlogin/ctop_method.html).
+
+While setting up your app, use the following settings: 
+
+| Field | Value to enter |
+--------|----------------|
+| Service name (サービス名) | Application name. |
+| Service overview (サービス概要) | Brief description of your application. |
+| Access Token lifetime (アクセストークン有効期間 秒) | Lifetime of your Access Token in seconds. |
+| Redirect URI (リダイレクトURI) | `https://${account.namespace}/login/callback` |
+| Available scopes (利用可能スコープ) | Scopes for the information you are requesting for your app. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/docomo/4.md b/snippets/social/docomo/4.md
new file mode 100644
index 0000000000..088285fda3
--- /dev/null
+++ b/snippets/social/docomo/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Docomo dAccount social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/docomo/5.md b/snippets/social/docomo/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/docomo/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/dribbble/0.md b/snippets/social/dribbble/0.md
new file mode 100644
index 0000000000..2b7122b029
--- /dev/null
+++ b/snippets/social/dribbble/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Dribbble
+
+The Dribbble social connection allows users to log in to your application using their Dribbble profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/dribbble/1.md b/snippets/social/dribbble/1.md
new file mode 100644
index 0000000000..3dc2424dfb
--- /dev/null
+++ b/snippets/social/dribbble/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Dribbble account](https://dribbble.com/signup/new).
diff --git a/snippets/social/dribbble/2.md b/snippets/social/dribbble/2.md
new file mode 100644
index 0000000000..53c4b5c540
--- /dev/null
+++ b/snippets/social/dribbble/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Dribbble, you will:
+
+1. [Set up app in Dribbble](#set-up-app-in-dribbble)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/dribbble/3.md b/snippets/social/dribbble/3.md
new file mode 100644
index 0000000000..38b775183f
--- /dev/null
+++ b/snippets/social/dribbble/3.md
@@ -0,0 +1,15 @@
+### Set up app in Dribbble
+
+Set up an app in the [Dribbble Developer Portal](https://dribbble.com/session/new). During this process, Dribbble will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/dribbble/4.md b/snippets/social/dribbble/4.md
new file mode 100644
index 0000000000..8fc5423bbd
--- /dev/null
+++ b/snippets/social/dribbble/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Dribbble social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/dribbble/5.md b/snippets/social/dribbble/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/dribbble/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/dropbox/0.md b/snippets/social/dropbox/0.md
new file mode 100644
index 0000000000..17d59edc87
--- /dev/null
+++ b/snippets/social/dropbox/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Dropbox
+
+The Dropbox social connection allows users to log in to your application using their Dropbox profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/dropbox/1.md b/snippets/social/dropbox/1.md
new file mode 100644
index 0000000000..18d823dfc9
--- /dev/null
+++ b/snippets/social/dropbox/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Dropbox Developer account](https://www.dropbox.com/developers).
diff --git a/snippets/social/dropbox/2.md b/snippets/social/dropbox/2.md
new file mode 100644
index 0000000000..f644b72296
--- /dev/null
+++ b/snippets/social/dropbox/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Dropbox, you will:
+
+1. [Set up app in Dropbox](#set-up-app-in-dropbox)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/dropbox/3.md b/snippets/social/dropbox/3.md
new file mode 100644
index 0000000000..f02e1d6bd4
--- /dev/null
+++ b/snippets/social/dropbox/3.md
@@ -0,0 +1,18 @@
+### Set up app in Dropbox
+
+Set up an app using Dropbox's [App Console: Creating a Dropbox App](https://www.dropbox.com/developers/reference/getting-started#app%20console) documentation. During this process, Dropbox will generate an **App key** and **App secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Choose an API | **Dropbox API**. |
+| Choose the type of access you need | Appropriate options depending on your needs. |
+| App name | Your application name. |
+| Redirect URIs | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/dropbox/4.md b/snippets/social/dropbox/4.md
new file mode 100644
index 0000000000..9cfc7cbd39
--- /dev/null
+++ b/snippets/social/dropbox/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Dropbox social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **App key** and **App secret**.
diff --git a/snippets/social/dropbox/5.md b/snippets/social/dropbox/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/dropbox/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/dwolla/0.md b/snippets/social/dwolla/0.md
new file mode 100644
index 0000000000..1116ca9578
--- /dev/null
+++ b/snippets/social/dwolla/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Dwolla
+
+The Dwolla social connection allows users to log in to your application using their Dwolla profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/dwolla/1.md b/snippets/social/dwolla/1.md
new file mode 100644
index 0000000000..21f8c7cb89
--- /dev/null
+++ b/snippets/social/dwolla/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Dwolla Developer account](https://accounts-sandbox.dwolla.com/login).
diff --git a/snippets/social/dwolla/2.md b/snippets/social/dwolla/2.md
new file mode 100644
index 0000000000..7742724e76
--- /dev/null
+++ b/snippets/social/dwolla/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Dwolla, you will:
+
+1. [Set up app in Dwolla](#set-up-app-in-dwolla)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/dwolla/3.md b/snippets/social/dwolla/3.md
new file mode 100644
index 0000000000..1f6362db86
--- /dev/null
+++ b/snippets/social/dwolla/3.md
@@ -0,0 +1,15 @@
+### Set up app in Dwolla
+
+Set up an app using Dwolla's [OAuth: Creating an Application](https://developers.dwolla.com/guides/auth#creating-an-application) documentation. During this process, Dwolla will generate a **Key** and **Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| OAuth Redirect URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/dwolla/4.md b/snippets/social/dwolla/4.md
new file mode 100644
index 0000000000..13f324d0c5
--- /dev/null
+++ b/snippets/social/dwolla/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Dwolla social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Key** and **Secret**.
diff --git a/snippets/social/dwolla/5.md b/snippets/social/dwolla/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/dwolla/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/evernote-sandbox/0.md b/snippets/social/evernote-sandbox/0.md
new file mode 100644
index 0000000000..7455b71546
--- /dev/null
+++ b/snippets/social/evernote-sandbox/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Evernote Sandbox
+
+The Evernote Sandbox social connection allows users to log in to your application using their Evernote Sandbox profile, which is a separate instance of the Evernote service, designed as a safe environment for you to develop and test your applications.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/evernote-sandbox/1.md b/snippets/social/evernote-sandbox/1.md
new file mode 100644
index 0000000000..068a728470
--- /dev/null
+++ b/snippets/social/evernote-sandbox/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for and configure an account with Evernote](https://evernote.com/).
diff --git a/snippets/social/evernote-sandbox/2.md b/snippets/social/evernote-sandbox/2.md
new file mode 100644
index 0000000000..336d7dc2c9
--- /dev/null
+++ b/snippets/social/evernote-sandbox/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Evernote Sandbox, you will:
+
+1. [Request Evernote Sandbox credentials](#request-evernote-sandbox-credentials)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/evernote-sandbox/3.md b/snippets/social/evernote-sandbox/3.md
new file mode 100644
index 0000000000..40b01acf05
--- /dev/null
+++ b/snippets/social/evernote-sandbox/3.md
@@ -0,0 +1,7 @@
+### Request Evernote Sandbox credentials
+
+Request Evernote Sandbox credentials by logging in to the [Evernote Developers Portal](http://dev.evernote.com), clicking **Get an API Key**, and entering the required information. During this process, Evernote will generate a **Consumer Key** and **Consumer Secret** for you; make note of these.
+
+::: warning
+When you are ready to connect to Evernote's production environment, you will need to connect your app to Evernote's production environment. To learn how, see [Connect Apps to Evernote](https://auth0.com/docs/connections/social/evernote).
+:::
diff --git a/snippets/social/evernote-sandbox/4.md b/snippets/social/evernote-sandbox/4.md
new file mode 100644
index 0000000000..ccbbb211b6
--- /dev/null
+++ b/snippets/social/evernote-sandbox/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Evernote Sandbox social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Consumer Key** and **Consumer Secret**.
diff --git a/snippets/social/evernote-sandbox/5.md b/snippets/social/evernote-sandbox/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/evernote-sandbox/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/evernote/0.md b/snippets/social/evernote/0.md
new file mode 100644
index 0000000000..0175d1a9d3
--- /dev/null
+++ b/snippets/social/evernote/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Evernote
+
+The Evernote social connection allows users to log in to your application using their Evernote profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/evernote/1.md b/snippets/social/evernote/1.md
new file mode 100644
index 0000000000..0c57aa68b3
--- /dev/null
+++ b/snippets/social/evernote/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, set up a connection to Evernote's Sandbox. To learn how, see [Connect Apps to Evernote Sandbox](https://auth0.com/docs/connections/social/evernote-sandbox).
diff --git a/snippets/social/evernote/2.md b/snippets/social/evernote/2.md
new file mode 100644
index 0000000000..c83bf5824e
--- /dev/null
+++ b/snippets/social/evernote/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Evernote, you will:
+
+1. [Request that Evernote activate your API Key on production](#request-that-evernote-activate-your-api-key-on-production)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/evernote/3.md b/snippets/social/evernote/3.md
new file mode 100644
index 0000000000..4bc71d7cfd
--- /dev/null
+++ b/snippets/social/evernote/3.md
@@ -0,0 +1,3 @@
+### Request that Evernote activate your API Key on production
+
+When you [connected your app to Evernote Sandbox](https://auth0.com/docs/connections/social/evernote-sandbox), Evernote generated a **Consumer Key** and **Consumer Secret** for you. You now need to request that Evernote activate your **Consumer Key** on production. To do this, navigate to [Support Resources for Evernote Developers](https://dev.evernote.com/support/), click **Activate an API Key**, and enter the requested information.
diff --git a/snippets/social/evernote/4.md b/snippets/social/evernote/4.md
new file mode 100644
index 0000000000..5442befd19
--- /dev/null
+++ b/snippets/social/evernote/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Evernote social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Now that the **Consumer Key** and **Consumer Secret** generated when you [connected your app to Evernote Sandbox](https://auth0.com/docs/connections/social/evernote-sandbox) have been activated in production, you can use them in your configuration.
diff --git a/snippets/social/evernote/5.md b/snippets/social/evernote/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/evernote/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/exact/0.md b/snippets/social/exact/0.md
new file mode 100644
index 0000000000..b586c2c45c
--- /dev/null
+++ b/snippets/social/exact/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Exact
+
+The Exact social connection allows users to log in to your application using their Exact profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/exact/1.md b/snippets/social/exact/1.md
new file mode 100644
index 0000000000..1ad23091c4
--- /dev/null
+++ b/snippets/social/exact/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for an Exact Online App Center account](https://apps.exactonline.com/).
diff --git a/snippets/social/exact/2.md b/snippets/social/exact/2.md
new file mode 100644
index 0000000000..ae21694266
--- /dev/null
+++ b/snippets/social/exact/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Exact, you will:
+
+1. [Set up app in Exact](#set-up-app-in-exact)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/exact/3.md b/snippets/social/exact/3.md
new file mode 100644
index 0000000000..fbeeea345f
--- /dev/null
+++ b/snippets/social/exact/3.md
@@ -0,0 +1,15 @@
+### Set up app in Exact
+
+Set up an app using Exact's [Register a new app](https://support.exactonline.com/community/s/article/All-All-HNO-Tutorial-resources-eol-files-hlp-eol-app-center---user-eol-appcenter-user-registerapikey-u?language=en_GB) knowledge base article. You will need to log in to see this documentation. During this process, Exact will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/exact/4.md b/snippets/social/exact/4.md
new file mode 100644
index 0000000000..b8fc332e32
--- /dev/null
+++ b/snippets/social/exact/4.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the Exact social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
+
+Besides the standard social connection settings, the Exact social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Base URL | Region in which your application is registered with Exact. By default, we use `https://start.exactonline.nl`, but you can override this value. |
\ No newline at end of file
diff --git a/snippets/social/exact/5.md b/snippets/social/exact/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/exact/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/facebook/0.md b/snippets/social/facebook/0.md
new file mode 100644
index 0000000000..24f1e95d02
--- /dev/null
+++ b/snippets/social/facebook/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Facebook
+
+The Facebook social connection allows users to log in to your application using their Facebook profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/facebook/1.md b/snippets/social/facebook/1.md
new file mode 100644
index 0000000000..fa437a09a2
--- /dev/null
+++ b/snippets/social/facebook/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Facebook Developer account](https://developers.facebook.com/).
diff --git a/snippets/social/facebook/2.md b/snippets/social/facebook/2.md
new file mode 100644
index 0000000000..776622c113
--- /dev/null
+++ b/snippets/social/facebook/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Facebook, you will:
+
+1. [Set up app in Facebook](#set-up-app-in-facebook)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/facebook/3.md b/snippets/social/facebook/3.md
new file mode 100644
index 0000000000..98b46917b1
--- /dev/null
+++ b/snippets/social/facebook/3.md
@@ -0,0 +1,24 @@
+### Set up app in Facebook
+
+Create an app in the [Facebook Developer portal](https://developers.facebook.com/), and add **Facebook Login** to the app as a **Product**. During this process, Facebook will generate a **App ID** and **App Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| How are you using your app? | Select **For everything else**. |
+| Permissions and Features | Select the permissions your app will require. Only the `default` and `email` permissions do not require app review by Facebook. |
+
+While setting up the Facebook Login product, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Client OAuth Settings | Enable **Web OAuth Login** (web applications) or **Client OAuth Login** (native applications), depending on your app type. |
+| Valid OAuth Redirect URIs | `https://${account.namespace}/login/callback` |
+| Deauthorize Callback URL | Enter the URL you would like Facebook to call when a user does not consent to your app. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/facebook/4.md b/snippets/social/facebook/4.md
new file mode 100644
index 0000000000..fd0a05c197
--- /dev/null
+++ b/snippets/social/facebook/4.md
@@ -0,0 +1,16 @@
+### Create and enable connection in Auth0
+
+[Set up the Facebook social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **App ID** and the **App Secret**.
+
+Besides the standard social connection settings, the Facebook social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| User Data | Attributes of the Facebook user profile. |
+
+::: note
+Facebook allows you to create a copy of your application to use for testing purposes. A test application has its own unique **App ID** and **App Secret**. Because Auth0 only allows one Facebook connection to be configured per tenant, you have two options while testing in Auth0:
+
+* Use the testing application's **App ID** and **App Secret** in Auth0's social connection, and then change these values when you are ready to connect to the production application.
+* [Create another Auth0 tenant](https://auth0.com/docs/dashboard/guides/tenants/create-multiple-tenants) to use for testing purposes and [set up a test environment](https://auth0.com/docs/dev-lifecycle/setting-up-env#set-the-environment).
+:::
\ No newline at end of file
diff --git a/snippets/social/facebook/5.md b/snippets/social/facebook/5.md
new file mode 100644
index 0000000000..dd0880e089
--- /dev/null
+++ b/snippets/social/facebook/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social). After logging in, you'll be prompted to allow your app access. To do so, click **Install unlisted app**.
diff --git a/snippets/social/facebook/6.md b/snippets/social/facebook/6.md
new file mode 100644
index 0000000000..a51faab031
--- /dev/null
+++ b/snippets/social/facebook/6.md
@@ -0,0 +1,13 @@
+## Access Facebook's API
+
+Once a user successfully authenticates, Facebook will include an Access Token in the user profile it returns to Auth0. You can use this token to call Facebook's API.
+
+To get the Facebook Access Token, you must retrieve the full user's profile using the Auth0 Management API and extract the Access Token from the response. For detailed steps, see [Call an Identity Provider's API](https://auth0.com/docs/connections/calling-an-external-idp-api).
+
+Using the token, you can call Facebook's API following Facebook's documentation.
+
+Optional: Get a [Refresh Token](https://auth0.com/docs/tokens/guides/get-refresh-tokens) from Facebook to refresh your Access Token once it expires. To ensure your application is secure, pay close attention to the [restrictions on using Refresh Tokens](https://auth0.com/docs/tokens/concepts/refresh-tokens#restrictions-and-limitations).
+
+Facebook lets you select the minimum version of the Facebook API that is available to the application. This can be changed in the in the 'Settings/Advanced' section of your application in the Facebook developer portal. 
+
+Auth0 has been tested with version 3.2. We recommend setting that as the minimum version, but it could work with newer versions.
diff --git a/snippets/social/facebook/7.md b/snippets/social/facebook/7.md
new file mode 100644
index 0000000000..63edd824b0
--- /dev/null
+++ b/snippets/social/facebook/7.md
@@ -0,0 +1,3 @@
+## Facebook re-authentication
+
+Once users authenticate, they will be prompted to accept the permissions your app has requested. Once they authenticate and accept, they will not be expected to re-authenticate unless you force them to. To learn how to force re-authentication, see Facebook's [Re-Authentication](https://developers.facebook.com/docs/facebook-login/reauthentication) documentation.
diff --git a/snippets/social/figma/0.md b/snippets/social/figma/0.md
new file mode 100644
index 0000000000..dce623bcb9
--- /dev/null
+++ b/snippets/social/figma/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Figma
+
+The Figma social connection allows users to log in to your application using their Figma profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/figma/1.md b/snippets/social/figma/1.md
new file mode 100644
index 0000000000..3bd5b92bcc
--- /dev/null
+++ b/snippets/social/figma/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Figma Developer account](https://www.figma.com/login).
diff --git a/snippets/social/figma/2.md b/snippets/social/figma/2.md
new file mode 100644
index 0000000000..10a4207670
--- /dev/null
+++ b/snippets/social/figma/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Figma, you will:
+
+1. [Set up app in Figma](#set-up-app-in-figma)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/figma/3.md b/snippets/social/figma/3.md
new file mode 100644
index 0000000000..cb0431f38c
--- /dev/null
+++ b/snippets/social/figma/3.md
@@ -0,0 +1,15 @@
+### Set up app in Figma
+
+Set up an app using Figma's [Register an Application](https://www.figma.com/developers/api#register-oauth2) documentation. During this process, Figma will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/figma/4.md b/snippets/social/figma/4.md
new file mode 100644
index 0000000000..1839cbf822
--- /dev/null
+++ b/snippets/social/figma/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Figma social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/figma/5.md b/snippets/social/figma/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/figma/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/fitbit/0.md b/snippets/social/fitbit/0.md
new file mode 100644
index 0000000000..05f7023f84
--- /dev/null
+++ b/snippets/social/fitbit/0.md
@@ -0,0 +1,9 @@
+# Connect Apps to Fitbit
+
+The Fitbit social connection allows users to log in to your application using their Fitbit profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
+
+::: note
+New connections with Fitbit will use OAuth 2.0. Please see the following documentation on [Using OAuth 2.0](https://dev.fitbit.com/docs/oauth2/) with Fitbit.
+:::
diff --git a/snippets/social/fitbit/1.md b/snippets/social/fitbit/1.md
new file mode 100644
index 0000000000..7bf2fb9024
--- /dev/null
+++ b/snippets/social/fitbit/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Fitbit Developer account](https://dev.fitbit.com).
diff --git a/snippets/social/fitbit/2.md b/snippets/social/fitbit/2.md
new file mode 100644
index 0000000000..137d5e362b
--- /dev/null
+++ b/snippets/social/fitbit/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Fitbit, you will:
+
+1. [Set up app in Fitbit](#set-up-app-in-fitbit)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/fitbit/3.md b/snippets/social/fitbit/3.md
new file mode 100644
index 0000000000..ae2227d0a7
--- /dev/null
+++ b/snippets/social/fitbit/3.md
@@ -0,0 +1,18 @@
+### Set up app in Fitbit
+
+Set up an app in the [Fitbit Developer portal](https://dev.fitbit.com). During this process, Fitbit will generate a **API Key** and **API Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field  | Description |
+| - | - |
+| Application Website | `https://${account.namespace}` |
+| OAuth 2.0 Application Type | Select **Application** |
+| Callback URL | `https://${account.namespace}/login/callback` |
+| Default Access Type | The type of access granted to the app. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/fitbit/4.md b/snippets/social/fitbit/4.md
new file mode 100644
index 0000000000..dab6cf734c
--- /dev/null
+++ b/snippets/social/fitbit/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Fitbit social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API Key** and the **API Secret**.
diff --git a/snippets/social/fitbit/5.md b/snippets/social/fitbit/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/fitbit/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/github/0.md b/snippets/social/github/0.md
new file mode 100644
index 0000000000..502245a7b0
--- /dev/null
+++ b/snippets/social/github/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to GitHub
+
+The GitHub social connection allows users to log in to your application using their GitHub profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/github/1.md b/snippets/social/github/1.md
new file mode 100644
index 0000000000..f9ae4c0cac
--- /dev/null
+++ b/snippets/social/github/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a GitHub Developer account](https://github.com/settings/developers).
\ No newline at end of file
diff --git a/snippets/social/github/2.md b/snippets/social/github/2.md
new file mode 100644
index 0000000000..966200e991
--- /dev/null
+++ b/snippets/social/github/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to GitHub, you will:
+
+1. [Set up app in GitHub](#set-up-app-in-github)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/github/3.md b/snippets/social/github/3.md
new file mode 100644
index 0000000000..a47b8479b1
--- /dev/null
+++ b/snippets/social/github/3.md
@@ -0,0 +1,16 @@
+### Set up app in GitHub
+
+Register a new app in [GitHub Developer Settings: OAuth Apps](https://github.com/settings/developers#oauth-apps). During this process, GitHub will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Homepage URL | `https://${account.namespace}` |
+| Authorization callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/github/4.md b/snippets/social/github/4.md
new file mode 100644
index 0000000000..6c7a105232
--- /dev/null
+++ b/snippets/social/github/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the GitHub social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/github/5.md b/snippets/social/github/5.md
new file mode 100644
index 0000000000..dd0880e089
--- /dev/null
+++ b/snippets/social/github/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social). After logging in, you'll be prompted to allow your app access. To do so, click **Install unlisted app**.
diff --git a/snippets/social/github/6.md b/snippets/social/github/6.md
new file mode 100644
index 0000000000..13c858c0b5
--- /dev/null
+++ b/snippets/social/github/6.md
@@ -0,0 +1,3 @@
+## Troubleshooting
+
+If you are receiving `Access Denied` when calling the GitHub API, you probably have not requested the correct permissions for the user during login. To learn more, see [Add scopes/permissions to call Identity Provider's APIs](https://auth0.com/docs/connections/adding-scopes-for-an-external-idp).
\ No newline at end of file
diff --git a/snippets/social/goodreads/0.md b/snippets/social/goodreads/0.md
new file mode 100644
index 0000000000..1e81624286
--- /dev/null
+++ b/snippets/social/goodreads/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Goodreads
+
+The Goodreads social connection allows users to log in to your application using their Goodreads profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/goodreads/1.md b/snippets/social/goodreads/1.md
new file mode 100644
index 0000000000..a4d4448c0c
--- /dev/null
+++ b/snippets/social/goodreads/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Goodreads Developer account](https://www.goodreads.com/api).
diff --git a/snippets/social/goodreads/2.md b/snippets/social/goodreads/2.md
new file mode 100644
index 0000000000..e90ab88fc2
--- /dev/null
+++ b/snippets/social/goodreads/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Goodreads, you will:
+
+1. [Set up app in Goodreads](#set-up-app-in-goodreads)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/goodreads/3.md b/snippets/social/goodreads/3.md
new file mode 100644
index 0000000000..86f7adc90d
--- /dev/null
+++ b/snippets/social/goodreads/3.md
@@ -0,0 +1,15 @@
+### Set up app in Goodreads
+
+Request Goodreads credentials by logging in to the [Goodreads Developer portal](https://www.goodreads.com/api), clicking **Developer Key**, and entering the required information. During this process, Goodreads will generate a **Key** and **Secret** for you; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/goodreads/4.md b/snippets/social/goodreads/4.md
new file mode 100644
index 0000000000..1124e79502
--- /dev/null
+++ b/snippets/social/goodreads/4.md
@@ -0,0 +1,62 @@
+### Create and enable connection in Auth0
+
+Use the [/post_connections endpoint](https://auth0.com/docs/api/management/v2#!/Connections/post_connections) to create a custom `oauth1` connection for Goodreads.
+See [Add Generic OAuth1 Connections](https://auth0.com/docs/tutorials/adding-generic-oauth1-connection) for more information on the individual fields used in the sample payload to follow. For Goodreads, this is a sample payload to create the connection:
+
+```har
+ {
+     "method": "POST",
+     "url": "https://${account.namespace}/api/v2/connections",
+     "httpVersion": "HTTP/1.1",
+     "headers": [
+       {
+         "name": "Authorization",
+         "value": "Bearer YOUR_API_V2_TOKEN_HERE"
+       }
+     ],
+     "postData": {
+       "mimeType": "application/json",
+       "text": "{\"name\": \"custom-goodreads\",\"strategy\": \"oauth1\",\"enabled_clients\": [\"YOUR_ENABLED_CLIENT_ID\"],\"options\": {\"client_id\": \"YOUR_GOODREADS_KEY\",\"client_secret\": \"YOUR_GOODREADS_SECRET\",\"requestTokenURL\": \"http://www.goodreads.com/oauth/request_token\",\"accessTokenURL\": \"http://www.goodreads.com/oauth/access_token\",\"userAuthorizationURL\": \"http://www.goodreads.com/oauth/authorize\",\"scripts\": {\"fetchUserProfile\": \"function(token, tokenSecret, ctx, cb) {var OAuth = new require(\\\"oauth\\\").OAuth; var parser = require('xml2json'); var oauth = new OAuth(ctx.requestTokenURL, ctx.accessTokenURL, ctx.client_id, ctx.client_secret, \\\"1.0\\\", null, \\\"HMAC-SHA1\\\"); oauth.get(\\\"https://www.goodreads.com/api/auth_user\\\", token, tokenSecret, function(e, xml, r) { console.log(xml); if (e) return cb(e); if (r.statusCode !== 200) return cb(new Error(\\\"StatusCode: \\\" + r.statusCode)); try { var jsonResp = JSON.parse(parser.toJson(xml)); var user = jsonResp.GoodreadsResponse.user; cb(null, user); } catch (e) { console.log(e); cb(new UnauthorizedError(\\\"[+] fetchUserProfile: Goodreads fetch script failed. Check Webtask logs\\\")); } });}\"}}}"
+     }
+   }
+ ```
+
+::: note
+Replace `YOUR_API_V2_TOKEN_HERE` with a Management API v2 access token. For more information on how to get one see [Access Tokens for the Management API](https://auth0.com/docs/api/management/v2/tokens).
+:::
+
+This sample uses the following `fetchUserProfile` script, you can change it as you please:
+
+```js
+function(token, tokenSecret, ctx, cb) {
+    var OAuth = new require("oauth").OAuth;
+    var parser = require('xml2json');
+    var oauth = new OAuth(ctx.requestTokenURL, ctx.accessTokenURL, ctx.client_id, ctx.client_secret, "1.0", null, "HMAC-SHA1");
+    oauth.get("https://www.goodreads.com/api/auth_user", token, tokenSecret, function(e, xml, r) {
+        console.log(xml);
+        if (e) return cb(e);
+        if (r.statusCode !== 200) return cb(new Error("StatusCode: " + r.statusCode));
+        try {
+            var jsonResp = JSON.parse(parser.toJson(xml));
+            var user = jsonResp.GoodreadsResponse.user;
+            cb(null, user);
+        }
+        catch (e) {
+            console.log(e);
+            cb(new UnauthorizedError("[+] fetchUserProfile: Goodreads fetch script failed. Check Webtask logs"));
+        }
+    });
+}
+```
+
+::: panel-warning Goodreads returns limited user profile data
+If you have any [Rules](https://auth0.com/docs/rules) configured that rely on `user.email` for example, user authentication will likely fail - the sample Rule above currently only returns `user.id`, `user.name`, and `user.link` properties [from Goodreads' API](https://www.goodreads.com/api/index#auth.user). Please add appropriate error handling to any Rules or Hooks that may rely on other user-profile data that may be missing. You may use [our Real-time Webtask Logs extension](https://auth0.com/docs/extensions/realtime-webtask-logs) to help debug these sorts of issues further.
+:::
+
+If you do change the `fetchUserProfile` script, you can stringify the function easily for use in your `POST /api/v2/connections` payload as follows:
+
+```js
+JSON.stringify(`function(token, tokenSecret, ctx, cb) {
+    // fetch user profile
+}`);
+```
diff --git a/snippets/social/goodreads/5.md b/snippets/social/goodreads/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/goodreads/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/google/0.md b/snippets/social/google/0.md
new file mode 100644
index 0000000000..b6a1bd01de
--- /dev/null
+++ b/snippets/social/google/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Google
+
+The Google social connection allows users to log in to your application using their Google profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/google/1.md b/snippets/social/google/1.md
new file mode 100644
index 0000000000..5096d3696d
--- /dev/null
+++ b/snippets/social/google/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* [Sign up for a Google Developer account](https://console.developers.google.com/).
+* [Create a Google Project](https://support.google.com/googleapi/answer/6251787?ref_topic=7014522)
diff --git a/snippets/social/google/2.md b/snippets/social/google/2.md
new file mode 100644
index 0000000000..ee15a7efeb
--- /dev/null
+++ b/snippets/social/google/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Google, you will:
+
+1. [Create Google credentials](#create-google-credentials)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/google/3.md b/snippets/social/google/3.md
new file mode 100644
index 0000000000..97c39dd964
--- /dev/null
+++ b/snippets/social/google/3.md
@@ -0,0 +1,29 @@
+### Create Google credentials
+
+Configure your OAuth consent screen and create credentials in the [Google Developer Console](https://console.developers.google.com/apis/credentials) using Google's [Setting up OAuth 2.0](https://support.google.com/googleapi/answer/6158849) documentation. During this process, Google will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your OAuth consent screen, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| User Type | Select **External**. |
+| Application Type | Select **Public**. |
+| Authorized domains | `auth0.com` |
+
+::: warning
+If your application requests sensitive OAuth scopes or uses a custom image, [Google will limit it to 100 logins until the OAuth consent screen is verified](https://developers.google.com/apps-script/guides/client-verification). Verification can take several days. To learn more about sensitive scopes, see Google's [OAuth 2.0 Scopes for Google APIs](https://developers.google.com/identity/protocols/oauth2/scopes) documentation. To pass verification you will need to prove ownership of all Authorized domains you specify on Google's OAuth consent screen. If you're using custom domains, use your custom domain instead of `auth0.com`.
+:::
+
+While setting up your credentials, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Application type | Web application |
+| Authorized JavaScript origins | `https://${account.namespace}` |
+| Authorized redirect URIs | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/google/4.md b/snippets/social/google/4.md
new file mode 100644
index 0000000000..a186b1f000
--- /dev/null
+++ b/snippets/social/google/4.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the Google social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the **Client ID** and the **Client Secret** generated.
+
+Besides the standard social connection settings, the Google social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Allowed Mobile Client IDs | Client IDs of any mobile apps that are allowed to use the connection. |
diff --git a/snippets/social/google/5.md b/snippets/social/google/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/google/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/imgur/0.md b/snippets/social/imgur/0.md
new file mode 100644
index 0000000000..569ba657ba
--- /dev/null
+++ b/snippets/social/imgur/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Imgur
+
+The Imgur social connection allows users to log in to your application using their Imgur profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/imgur/1.md b/snippets/social/imgur/1.md
new file mode 100644
index 0000000000..b39bbdc491
--- /dev/null
+++ b/snippets/social/imgur/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for an Imgur account](https://imgur.com/register).
diff --git a/snippets/social/imgur/2.md b/snippets/social/imgur/2.md
new file mode 100644
index 0000000000..3291fbc6ff
--- /dev/null
+++ b/snippets/social/imgur/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Imgur, you will:
+
+1. [Set up app in Imgur](#set-up-app-in-imgur)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/imgur/3.md b/snippets/social/imgur/3.md
new file mode 100644
index 0000000000..91af07d632
--- /dev/null
+++ b/snippets/social/imgur/3.md
@@ -0,0 +1,15 @@
+### Set up app in Imgur
+
+Set up an app in the [Imgur Developer Portal](https://api.imgur.com/oauth2/addclient). During this process, Imgur will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/imgur/4.md b/snippets/social/imgur/4.md
new file mode 100644
index 0000000000..c21081dd78
--- /dev/null
+++ b/snippets/social/imgur/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Imgur social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/imgur/5.md b/snippets/social/imgur/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/imgur/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/line/0.md b/snippets/social/line/0.md
new file mode 100644
index 0000000000..8d045545f6
--- /dev/null
+++ b/snippets/social/line/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to LINE
+
+The LINE social connection allows users to log in to your application using their LINE profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/line/1.md b/snippets/social/line/1.md
new file mode 100644
index 0000000000..d41e109b5a
--- /dev/null
+++ b/snippets/social/line/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* [Sign up for a LINE account](https://www.linebiz.com/jp-en/other/).
+* Register your LINE account as a Developer. If you've never logged in to the [LINE Developer console](https://developers.line.biz/console/) before, do so; you'll automatically be asked to register as a developer and link your account.
diff --git a/snippets/social/line/2.md b/snippets/social/line/2.md
new file mode 100644
index 0000000000..b6c39421b9
--- /dev/null
+++ b/snippets/social/line/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to LINE, you will:
+
+1. [Set up channel in LINE](#set-up-app-in-line)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/line/3.md b/snippets/social/line/3.md
new file mode 100644
index 0000000000..10b7df0d14
--- /dev/null
+++ b/snippets/social/line/3.md
@@ -0,0 +1,17 @@
+### Set up channel in LINE
+
+Set up a provider and channel using LINE's [Create a Channel](https://developers.line.biz/en/docs/liff/getting-started/) documentation, then apply for email permissions using LINE'S [Integrating LINE Login with your web app: Applying for email permission](https://developers.line.biz/en/docs/line-login/integrate-line-login/#applying-for-email-permission) section. During this process, LINE will generate a **Channel ID** and **Channel Secret** for your application; make note of these.
+
+While setting up your channel, use the following values:
+
+| Field | Value to Provide |
+| - | - |
+| Application type | Enable **Web app**. |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
+
diff --git a/snippets/social/line/4.md b/snippets/social/line/4.md
new file mode 100644
index 0000000000..6d3e6f23c4
--- /dev/null
+++ b/snippets/social/line/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the LINE social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Channel ID** and **Channel Secret**.
diff --git a/snippets/social/line/5.md b/snippets/social/line/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/line/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/linkedin/0.md b/snippets/social/linkedin/0.md
new file mode 100644
index 0000000000..f1543914f6
--- /dev/null
+++ b/snippets/social/linkedin/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to LinkedIn
+
+The LinkedIn social connection allows users to log in to your application using their LinkedIn profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/linkedin/1.md b/snippets/social/linkedin/1.md
new file mode 100644
index 0000000000..3200f718bd
--- /dev/null
+++ b/snippets/social/linkedin/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a LinkedIn Developer account](https://www.linkedin.com/developers).
diff --git a/snippets/social/linkedin/2.md b/snippets/social/linkedin/2.md
new file mode 100644
index 0000000000..98cfaa9a0c
--- /dev/null
+++ b/snippets/social/linkedin/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to LinkedIn, you will:
+
+1. [Set up app in LinkedIn](#set-up-app-in-linkedin)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/linkedin/3.md b/snippets/social/linkedin/3.md
new file mode 100644
index 0000000000..3943e99097
--- /dev/null
+++ b/snippets/social/linkedin/3.md
@@ -0,0 +1,15 @@
+### Set up app in LinkedIn
+
+Set up an app in the [LinkedIn Developer portal](https://www.linkedin.com/developers/apps/new). During this process, LinkedIn will generate a **Client ID** and **Client Secret** for your application; make note of these. After your app is created, you can find these on its **Auth** view.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Authorized redirect URLs for your app | `https://${account.namespace}/login/callback`. After your app is created, you can find this on its **Auth** view. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::s
diff --git a/snippets/social/linkedin/4.md b/snippets/social/linkedin/4.md
new file mode 100644
index 0000000000..5c9edb7116
--- /dev/null
+++ b/snippets/social/linkedin/4.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the LinkedIn social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
+
+Besides the standard social connection settings, the LinkedIn social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Strategy Version | Version of the LinkedIn API you want to use. |
diff --git a/snippets/social/linkedin/5.md b/snippets/social/linkedin/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/linkedin/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/microsoft-account/0.md b/snippets/social/microsoft-account/0.md
new file mode 100644
index 0000000000..5fafec5840
--- /dev/null
+++ b/snippets/social/microsoft-account/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Microsoft Account
+
+The Microsoft social connection allows users to log in to your application using their Microsoft account profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/microsoft-account/1.md b/snippets/social/microsoft-account/1.md
new file mode 100644
index 0000000000..9d4b590fbf
--- /dev/null
+++ b/snippets/social/microsoft-account/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* [Sign up for an account on the Azure portal](https://azure.microsoft.com/en-us/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio)
+* [Create an Azure AD Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant)
diff --git a/snippets/social/microsoft-account/2.md b/snippets/social/microsoft-account/2.md
new file mode 100644
index 0000000000..5cd3524188
--- /dev/null
+++ b/snippets/social/microsoft-account/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Microsoft Account, you will:
+
+1. [Set up app in Microsoft Account](#set-up-app-in-microsoft-account)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/microsoft-account/3.md b/snippets/social/microsoft-account/3.md
new file mode 100644
index 0000000000..a2b987cd8e
--- /dev/null
+++ b/snippets/social/microsoft-account/3.md
@@ -0,0 +1,15 @@
+### Set up app in Microsoft Account
+
+Register an app in Azure using Microsoft's [Quickstart: Register an application with the Microsoft identity platform](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) documentation. During this process, Microsoft will generate an **Application (client) ID** and a **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/microsoft-account/4.md b/snippets/social/microsoft-account/4.md
new file mode 100644
index 0000000000..b1dc1474a7
--- /dev/null
+++ b/snippets/social/microsoft-account/4.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the Microsoft Account social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Application (client) ID** and **Application (client) Secret**.
+
+Besides the standard social connection settings, the Microsoft Account social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Strategy Version | Version of Microsoft API you want to use. |
diff --git a/snippets/social/microsoft-account/5.md b/snippets/social/microsoft-account/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/microsoft-account/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/paypal-sandbox/0.md b/snippets/social/paypal-sandbox/0.md
new file mode 100644
index 0000000000..bd684f9eab
--- /dev/null
+++ b/snippets/social/paypal-sandbox/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to PayPal Sandbox
+
+The PayPal Sandbox social connection allows users to log in to your application using their PayPal Sandbox profile, which is a separate instance of the PayPal service, designed to allow you to isolate customization and development work from your production environment until you’re ready to deploy changes. To learn more, see the [PayPal Sandbox Testing Guide](https://developer.paypal.com/docs/api-basics/sandbox/).
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/paypal-sandbox/1.md b/snippets/social/paypal-sandbox/1.md
new file mode 100644
index 0000000000..6d19784d48
--- /dev/null
+++ b/snippets/social/paypal-sandbox/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for and configure an account with PayPal](https://developer.paypal.com). Upon account creation, you will have access to a PayPal Sandbox.
diff --git a/snippets/social/paypal-sandbox/2.md b/snippets/social/paypal-sandbox/2.md
new file mode 100644
index 0000000000..4bc41452a4
--- /dev/null
+++ b/snippets/social/paypal-sandbox/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to PayPal Sandbox, you will:
+
+1. [Set up app in PayPal Sandbox](#set-up-app-in-paypal-sandbox)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/paypal-sandbox/3.md b/snippets/social/paypal-sandbox/3.md
new file mode 100644
index 0000000000..4749818d59
--- /dev/null
+++ b/snippets/social/paypal-sandbox/3.md
@@ -0,0 +1,16 @@
+### Set up app in PayPal Sandbox
+
+Create an app in PayPal Sandbox and generate credentials for it, using PayPal's [Get Credentials](https://developer.paypal.com/docs/api/overview/#get-credentials) documentation. During this process, PayPal will generate a **Client ID** and **Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Return URL | `https://${account.namespace}/login/callback` |
+| Log In with PayPal | Enable, then under **Advanced Options**, select **Full Name**, **Date of Birth**, **Timezone**, **Locale**, and **Language**. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your return URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/paypal-sandbox/4.md b/snippets/social/paypal-sandbox/4.md
new file mode 100644
index 0000000000..e475d4186e
--- /dev/null
+++ b/snippets/social/paypal-sandbox/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the PayPal Sandbox social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Secret**.
diff --git a/snippets/social/paypal-sandbox/5.md b/snippets/social/paypal-sandbox/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/paypal-sandbox/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/paypal/0.md b/snippets/social/paypal/0.md
new file mode 100644
index 0000000000..d981eaf9e3
--- /dev/null
+++ b/snippets/social/paypal/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to PayPal
+
+The PayPal social connection allows users to log in to your application using their PayPal profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/paypal/1.md b/snippets/social/paypal/1.md
new file mode 100644
index 0000000000..6d19784d48
--- /dev/null
+++ b/snippets/social/paypal/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for and configure an account with PayPal](https://developer.paypal.com). Upon account creation, you will have access to a PayPal Sandbox.
diff --git a/snippets/social/paypal/2.md b/snippets/social/paypal/2.md
new file mode 100644
index 0000000000..74c1cd22e0
--- /dev/null
+++ b/snippets/social/paypal/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to PayPal, you will:
+
+1. [Set up app in PayPal](#set-up-app-in-paypal)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/paypal/3.md b/snippets/social/paypal/3.md
new file mode 100644
index 0000000000..fe0e4085b5
--- /dev/null
+++ b/snippets/social/paypal/3.md
@@ -0,0 +1,20 @@
+### Set up app in PayPal
+
+::: warning
+By default, upon login, you will be editing your Sandbox account. Make sure you switch to your production account by moving the environment toggle to **Live**.
+:::
+
+Create an app in PayPal and generate credentials for it using [PayPal's Get Credentials](https://developer.paypal.com/docs/api/overview/#get-credentials) documentation. During this process, PayPal will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Return URL | `https://${account.namespace}/login/callback` |
+| Log In with PayPal | Enable, then under **Advanced Options**, select **Full Name**, **Date of Birth**, **Timezone**, **Locale**, and **Language**. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your return URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/paypal/4.md b/snippets/social/paypal/4.md
new file mode 100644
index 0000000000..f4ea59b708
--- /dev/null
+++ b/snippets/social/paypal/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the PayPal social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Secret**.
diff --git a/snippets/social/paypal/5.md b/snippets/social/paypal/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/paypal/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/pinterest/0.md b/snippets/social/pinterest/0.md
new file mode 100644
index 0000000000..d60e83d98b
--- /dev/null
+++ b/snippets/social/pinterest/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Pinterest
+
+The Pinterest social connection allows users to log in to your application using their Pinterest profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/pinterest/1.md b/snippets/social/pinterest/1.md
new file mode 100644
index 0000000000..64c924958b
--- /dev/null
+++ b/snippets/social/pinterest/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Pinterest account](https://www.pinterest.ca/).
diff --git a/snippets/social/pinterest/2.md b/snippets/social/pinterest/2.md
new file mode 100644
index 0000000000..f443a4845f
--- /dev/null
+++ b/snippets/social/pinterest/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Pinterest, you will:
+
+1. [Set up app in Pinterest](#set-up-app-in-pinterest)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/pinterest/3.md b/snippets/social/pinterest/3.md
new file mode 100644
index 0000000000..9ad014b076
--- /dev/null
+++ b/snippets/social/pinterest/3.md
@@ -0,0 +1,15 @@
+### Set up app in Pinterest
+
+Set up an app in the [Pinterest Developer Portal](https://developers.pinterest.com/apps/). During this process, Pinterest will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/pinterest/4.md b/snippets/social/pinterest/4.md
new file mode 100644
index 0000000000..5a21cbbbb9
--- /dev/null
+++ b/snippets/social/pinterest/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Pinterest social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/pinterest/5.md b/snippets/social/pinterest/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/pinterest/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/planning-center/0.md b/snippets/social/planning-center/0.md
new file mode 100644
index 0000000000..5764ce3d8c
--- /dev/null
+++ b/snippets/social/planning-center/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Planning Center
+
+The Planning Center social connection allows users to log in to your application using their Planning Center profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/planning-center/1.md b/snippets/social/planning-center/1.md
new file mode 100644
index 0000000000..a6365339e4
--- /dev/null
+++ b/snippets/social/planning-center/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Planning Center Developer account](https://api.planningcenteronline.com/).
diff --git a/snippets/social/planning-center/2.md b/snippets/social/planning-center/2.md
new file mode 100644
index 0000000000..e5e6d70477
--- /dev/null
+++ b/snippets/social/planning-center/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Planning Center, you will:
+
+1. [Set up app in Planning Center](#set-up-app-in-planning-center)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/planning-center/3.md b/snippets/social/planning-center/3.md
new file mode 100644
index 0000000000..c0aed386bd
--- /dev/null
+++ b/snippets/social/planning-center/3.md
@@ -0,0 +1,16 @@
+### Set up app in Planning Center
+
+Set up an app in the [Planning Center Developer portal](https://api.planningcenteronline.com/oauth/applications). During this process, Planning Center will generate a **Client ID** and **Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Application URL | `https://${account.namespace}` |
+| Authorization callback URLs | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/planning-center/4.md b/snippets/social/planning-center/4.md
new file mode 100644
index 0000000000..ec9f408613
--- /dev/null
+++ b/snippets/social/planning-center/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Planning Center social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client Id** and **Secret**.
diff --git a/snippets/social/planning-center/5.md b/snippets/social/planning-center/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/planning-center/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/quickbooks-online/0.md b/snippets/social/quickbooks-online/0.md
new file mode 100644
index 0000000000..48b409e79e
--- /dev/null
+++ b/snippets/social/quickbooks-online/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to QuickBooks Online
+
+The QuickBooks Online social connection allows users to log in to your application using their QuickBooks Online profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/quickbooks-online/1.md b/snippets/social/quickbooks-online/1.md
new file mode 100644
index 0000000000..229dceab8c
--- /dev/null
+++ b/snippets/social/quickbooks-online/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for an Intuit Developer account](https://accounts.intuit.com/signup.html).
diff --git a/snippets/social/quickbooks-online/2.md b/snippets/social/quickbooks-online/2.md
new file mode 100644
index 0000000000..ed96219d52
--- /dev/null
+++ b/snippets/social/quickbooks-online/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to QuickBooks Online, you will:
+
+1. [Set up app in QuickBooks Online](#set-up-app-in-quickbooks-online)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/quickbooks-online/3.md b/snippets/social/quickbooks-online/3.md
new file mode 100644
index 0000000000..b23668d826
--- /dev/null
+++ b/snippets/social/quickbooks-online/3.md
@@ -0,0 +1,15 @@
+### Set up app in QuickBooks Online
+
+Set up a QuickBooks Online application in the [Intuit Developer portal](https://developer.intuit.com/app/developer/myapps). During this process, Intuit will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/quickbooks-online/4.md b/snippets/social/quickbooks-online/4.md
new file mode 100644
index 0000000000..e2b5a1ea0a
--- /dev/null
+++ b/snippets/social/quickbooks-online/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the QuickBooks Online social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/quickbooks-online/5.md b/snippets/social/quickbooks-online/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/quickbooks-online/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/renren/0.md b/snippets/social/renren/0.md
new file mode 100644
index 0000000000..b9a5a3f51a
--- /dev/null
+++ b/snippets/social/renren/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to RenRen
+
+The RenRen social connection allows users to log in to your application using their RenRen profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/renren/1.md b/snippets/social/renren/1.md
new file mode 100644
index 0000000000..d8e2ccd07c
--- /dev/null
+++ b/snippets/social/renren/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a RenRen Developer account](http://app.renren.com/developers).
diff --git a/snippets/social/renren/2.md b/snippets/social/renren/2.md
new file mode 100644
index 0000000000..9df6a363a1
--- /dev/null
+++ b/snippets/social/renren/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to RenRen, you will:
+
+1. [Set up app in RenRen](#set-up-app-in-renren)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/renren/3.md b/snippets/social/renren/3.md
new file mode 100644
index 0000000000..13bbd0a333
--- /dev/null
+++ b/snippets/social/renren/3.md
@@ -0,0 +1,15 @@
+### Set up app in RenRen
+
+Create a new app in the [RenRen Integration portal](http://app.renren.com/developers). During this process, RenRen will generate an **API Key** and **Secret Key** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| ----- | ---------------- |
+| callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/renren/4.md b/snippets/social/renren/4.md
new file mode 100644
index 0000000000..f8c23f1ead
--- /dev/null
+++ b/snippets/social/renren/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the RenRen social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API Key** and **Secret Key**.
diff --git a/snippets/social/renren/5.md b/snippets/social/renren/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/renren/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/salesforce-community/0.md b/snippets/social/salesforce-community/0.md
new file mode 100644
index 0000000000..c69ed5eaad
--- /dev/null
+++ b/snippets/social/salesforce-community/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Salesforce Community
+
+The Salesforce Community social connection allows users to log in to your application using their Salesforce Community profile. Salesforce communities are branded spaces that allow employees, customers, and partners to connect. To learn more, see Salesforce's [Set Up and Manage Salesforce Communities](https://help.salesforce.com/articleView?id=networks_overview.htm&type=5) documentation.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/salesforce-community/1.md b/snippets/social/salesforce-community/1.md
new file mode 100644
index 0000000000..bb24044eff
--- /dev/null
+++ b/snippets/social/salesforce-community/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for and configure an account with Salesforce](https://www.salesforce.com/).
diff --git a/snippets/social/salesforce-community/2.md b/snippets/social/salesforce-community/2.md
new file mode 100644
index 0000000000..536f9ff526
--- /dev/null
+++ b/snippets/social/salesforce-community/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To connect your app to Salesforce Community, you will:
+
+1. [Get Salesforce credentials](#get-salesforce-credentials)
+2. [Find Salesforce Community's base path](#find-salesforce-communitys-base-path)
+3. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+4. [Test connection](#test-connection)
diff --git a/snippets/social/salesforce-community/3.md b/snippets/social/salesforce-community/3.md
new file mode 100644
index 0000000000..3f39743d06
--- /dev/null
+++ b/snippets/social/salesforce-community/3.md
@@ -0,0 +1,19 @@
+### Get Salesforce credentials
+
+If you have already set up a [Salesforce Sandbox](https://help.salesforce.com/articleView?id=deploy_sandboxes_intro.htm&type=5), set up your app in the Sandbox, and deployed the app to production, then you need to locate the app's production **Consumer Key** and **Consumer Secret**.
+
+Alternatively, if you are setting up a new app in production, you need to 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) documentation. During this process, Salesforce will generate a **Consumer Key** and **Consumer Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| API (Enable OAuth Settings) | Click `Enable OAuth Settings` |
+| Callback URL | `https://${account.namespace}/login/callback` |
+| Selected OAuth Scopes | Add `Access your basic information` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/salesforce-community/4.md b/snippets/social/salesforce-community/4.md
new file mode 100644
index 0000000000..29cd26e7bf
--- /dev/null
+++ b/snippets/social/salesforce-community/4.md
@@ -0,0 +1,5 @@
+### Find Salesforce Community's base path
+
+Salesforce Community base paths have the following format:
+`https://{communitydomain}.force.com/{communitybasepath}`
+For example, if the community name is `Trailblazers` and the community exists for customers, the base path would be `https://trailblazers.force.com/customers`.
diff --git a/snippets/social/salesforce-community/5.md b/snippets/social/salesforce-community/5.md
new file mode 100644
index 0000000000..a90687bdb5
--- /dev/null
+++ b/snippets/social/salesforce-community/5.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the Salesforce Community social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Consumer Key** and **Consumer Secret**, and the Salesforce Community base path.
+
+Besides the standard social connection settings, the Salesforce Community social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Community Base URL | Base path for the Salesforce Community. This is the section of the community's URL that follows the domain (example: https://{communitydomain}.force.com/{communitybasepath}). |
diff --git a/snippets/social/salesforce-community/6.md b/snippets/social/salesforce-community/6.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/salesforce-community/6.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/salesforce-community/7.md b/snippets/social/salesforce-community/7.md
new file mode 100644
index 0000000000..e78d1b3080
--- /dev/null
+++ b/snippets/social/salesforce-community/7.md
@@ -0,0 +1 @@
+## Additional Notes
diff --git a/snippets/social/salesforce-community/8.md b/snippets/social/salesforce-community/8.md
new file mode 100644
index 0000000000..e6e2539ebe
--- /dev/null
+++ b/snippets/social/salesforce-community/8.md
@@ -0,0 +1,12 @@
+### Salesforce Community Authorization URL
+
+When you authenticate users in a Salesforce Community, you use different endpoints than the regular Salesforce app. The authorization URL is the base path plus `/oauth2/authorize`. For example, if the community name is `Trailblazers` and the community exists for customers, the authorization URL would be:
+
+```text
+https://trailblazers.force.com/customers/oauth2/authorize?
+response_type=token&
+client_id=your_app_id&
+redirect_uri=your_redirect_uri
+```
+
+You only need to configure the base path for the social connection because Auth0 automatically passes all required OAuth2 parameters (e.g., `response_type`, `client_id`) and concatenates other elements to the base path (i.e., `oauth2/authorize`).
diff --git a/snippets/social/salesforce-sandbox/0.md b/snippets/social/salesforce-sandbox/0.md
new file mode 100644
index 0000000000..31c00cb4d2
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Salesforce Sandbox
+
+The Salesforce Sandbox social connection allows users to log in to your application using their Salesforce Sandbox profile, which is a separate instance of the Salesforce service, designed to allow you to isolate customization and development work from your production environment until you’re ready to deploy changes. To learn more, see Salesforce's [Sandboxes: Staging Environments for Customizing and Testing](https://help.salesforce.com/articleView?id=deploy_sandboxes_intro.htm&type=5) documentation.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/salesforce-sandbox/1.md b/snippets/social/salesforce-sandbox/1.md
new file mode 100644
index 0000000000..caa195b6ed
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* [Sign up for and configure an account with Salesforce](https://www.salesforce.com/).
+* [Create a Salesforce Sandbox](https://help.salesforce.com/articleView?id=data_sandbox_create.htm&type=5).
diff --git a/snippets/social/salesforce-sandbox/2.md b/snippets/social/salesforce-sandbox/2.md
new file mode 100644
index 0000000000..e2acedb5f1
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Salesforce Sandbox, you will:
+
+1. [Set up app in Salesforce Sandbox](#set-up-app-in-salesforce-sandbox)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/salesforce-sandbox/3.md b/snippets/social/salesforce-sandbox/3.md
new file mode 100644
index 0000000000..a1620cd7b6
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/3.md
@@ -0,0 +1,17 @@
+### Set up app in Salesforce Sandbox
+
+Create an app in Salesforce Sandbox and generate credentials for it, using Salesforce's [Create a Connected App](https://help.salesforce.com/articleView?id=connected_app_create.htm&type=0) documentation. During this process, Salesforce will generate a **Consumer Key** and **Consumer Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| API (Enable OAuth Settings) | Click `Enable OAuth Settings` |
+| Callback URL | `https://${account.namespace}/login/callback` |
+| Selected OAuth Scopes | Add `Access your basic information` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/salesforce-sandbox/4.md b/snippets/social/salesforce-sandbox/4.md
new file mode 100644
index 0000000000..82e5ff4027
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Salesforce Sandbox social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Consumer Key** and **Consumer Secret**.
diff --git a/snippets/social/salesforce-sandbox/5.md b/snippets/social/salesforce-sandbox/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/salesforce-sandbox/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/salesforce/0.md b/snippets/social/salesforce/0.md
new file mode 100644
index 0000000000..d888140ec9
--- /dev/null
+++ b/snippets/social/salesforce/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Salesforce
+
+The Salesforce social connection allows users to log in to your application using their Salesforce profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/salesforce/1.md b/snippets/social/salesforce/1.md
new file mode 100644
index 0000000000..bb24044eff
--- /dev/null
+++ b/snippets/social/salesforce/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for and configure an account with Salesforce](https://www.salesforce.com/).
diff --git a/snippets/social/salesforce/2.md b/snippets/social/salesforce/2.md
new file mode 100644
index 0000000000..daa69b86c2
--- /dev/null
+++ b/snippets/social/salesforce/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Salesforce, you will:
+
+1. [Get Salesforce credentials](#get-salesforce-credentials)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/salesforce/3.md b/snippets/social/salesforce/3.md
new file mode 100644
index 0000000000..3f39743d06
--- /dev/null
+++ b/snippets/social/salesforce/3.md
@@ -0,0 +1,19 @@
+### Get Salesforce credentials
+
+If you have already set up a [Salesforce Sandbox](https://help.salesforce.com/articleView?id=deploy_sandboxes_intro.htm&type=5), set up your app in the Sandbox, and deployed the app to production, then you need to locate the app's production **Consumer Key** and **Consumer Secret**.
+
+Alternatively, if you are setting up a new app in production, you need to 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) documentation. During this process, Salesforce will generate a **Consumer Key** and **Consumer Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| API (Enable OAuth Settings) | Click `Enable OAuth Settings` |
+| Callback URL | `https://${account.namespace}/login/callback` |
+| Selected OAuth Scopes | Add `Access your basic information` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/salesforce/4.md b/snippets/social/salesforce/4.md
new file mode 100644
index 0000000000..5befd03ebd
--- /dev/null
+++ b/snippets/social/salesforce/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Salesforce social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you use the generated **Consumer Key** and the **Consumer Secret**.
diff --git a/snippets/social/salesforce/5.md b/snippets/social/salesforce/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/salesforce/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/shop/0.md b/snippets/social/shop/0.md
new file mode 100644
index 0000000000..bb09f4ac9d
--- /dev/null
+++ b/snippets/social/shop/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Shop
+
+The Sign in with Shop social connection allows users to log in to your application using their Shop account.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
diff --git a/snippets/social/shop/1.md b/snippets/social/shop/1.md
new file mode 100644
index 0000000000..c01663f68f
--- /dev/null
+++ b/snippets/social/shop/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, sign up for a Shopify store with all necessary requirements fulfilled.
\ No newline at end of file
diff --git a/snippets/social/shop/2.md b/snippets/social/shop/2.md
new file mode 100644
index 0000000000..178683d99e
--- /dev/null
+++ b/snippets/social/shop/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Shop, you will:
+
+1. Set up app in Shop
+2. Create and enable connection in Auth0
+3. Test connection
\ No newline at end of file
diff --git a/snippets/social/shop/3.md b/snippets/social/shop/3.md
new file mode 100644
index 0000000000..64b271d4ad
--- /dev/null
+++ b/snippets/social/shop/3.md
@@ -0,0 +1,13 @@
+### Set up app in Shop
+
+In your Shopify store admin, open the Shop sales channel settings and activate your Sign in with Shop API client. Once activated, this will reveal your Client ID and Secret; make note of these.
+
+Add your Auth0 redirect URL: `https://${account.namespace}/login/callback`
+
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your return URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/shop/4.md b/snippets/social/shop/4.md
new file mode 100644
index 0000000000..1b7e99d4cd
--- /dev/null
+++ b/snippets/social/shop/4.md
@@ -0,0 +1,5 @@
+### Create and enable connection in Auth0
+
+Set up the Shop social connection in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
+
+Configure the integration with your Client ID and Client secret, choose whether to sync user profile attributes at each login, and select the Applications that should use this Connection.
\ No newline at end of file
diff --git a/snippets/social/shop/5.md b/snippets/social/shop/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/shop/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/shop/6.md b/snippets/social/shop/6.md
new file mode 100644
index 0000000000..4577d18022
--- /dev/null
+++ b/snippets/social/shop/6.md
@@ -0,0 +1,3 @@
+### Troubleshooting
+
+For more information check out [Sign in with Shop documentation](https://help.shopify.com/en/manual/online-sales-channels/shop/sign-in-features).
\ No newline at end of file
diff --git a/snippets/social/shopify/0.md b/snippets/social/shopify/0.md
new file mode 100644
index 0000000000..ef34649cc6
--- /dev/null
+++ b/snippets/social/shopify/0.md
@@ -0,0 +1,9 @@
+# Connect Apps to Shopify
+
+The Shopify social connection lets shop owners and administrators log in to your application using their Shopify profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
+
+::: note
+The Shopify social connection can only be associated with a single online store.
+:::
\ No newline at end of file
diff --git a/snippets/social/shopify/1.md b/snippets/social/shopify/1.md
new file mode 100644
index 0000000000..799a41dbf6
--- /dev/null
+++ b/snippets/social/shopify/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for the Shopify Partners program](https://www.shopify.com/partners).
diff --git a/snippets/social/shopify/2.md b/snippets/social/shopify/2.md
new file mode 100644
index 0000000000..3e9be7d667
--- /dev/null
+++ b/snippets/social/shopify/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Shopify, you will:
+
+1. [Set up app in Shopify](#set-up-app-in-shopify)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/shopify/3.md b/snippets/social/shopify/3.md
new file mode 100644
index 0000000000..ce3490f81b
--- /dev/null
+++ b/snippets/social/shopify/3.md
@@ -0,0 +1,16 @@
+### Set up app in Shopify
+
+Set up an app in Shopify using the instructions in Shopify's [Public Apps](https://help.shopify.com/en/api/getting-started/authentication/public-authentication#generate-credentials-from-your-partner-dashboard) documentation. During this process, Shopify will generate an **API key** and **API secret key** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| App URL | `https://${account.namespace}` |
+| Whitelisted redirection URL(s) | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/shopify/4.md b/snippets/social/shopify/4.md
new file mode 100644
index 0000000000..2f509e7a9b
--- /dev/null
+++ b/snippets/social/shopify/4.md
@@ -0,0 +1,9 @@
+### Create and enable connection in Auth0
+
+[Set up the Shopify social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API key** and **API secret key**.
+
+Besides the standard social connection settings, the Shopify social connection configuration includes the following:
+
+| Setting | Description | 
+|---------|-------------|
+| Shop Name | Name of your Shopify shop. Usually, this is the first part of your shop's URL (example: https://{shopname}.myshopify.com. |
diff --git a/snippets/social/shopify/5.md b/snippets/social/shopify/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/shopify/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/slack/0.md b/snippets/social/slack/0.md
new file mode 100644
index 0000000000..a725638808
--- /dev/null
+++ b/snippets/social/slack/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Slack
+
+The Slack social connection allows users to log in to your application using their Slack profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/slack/1.md b/snippets/social/slack/1.md
new file mode 100644
index 0000000000..1a6648707c
--- /dev/null
+++ b/snippets/social/slack/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Slack Developer account](https://slack.com/signin).
diff --git a/snippets/social/slack/2.md b/snippets/social/slack/2.md
new file mode 100644
index 0000000000..2514f0499d
--- /dev/null
+++ b/snippets/social/slack/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Slack, you will:
+
+1. [Set up app in Slack](#set-up-app-in-slack)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/slack/3.md b/snippets/social/slack/3.md
new file mode 100644
index 0000000000..6bcc151ea9
--- /dev/null
+++ b/snippets/social/slack/3.md
@@ -0,0 +1,11 @@
+### Set up app in Slack
+
+You'll need credentials to use Sign in with Slack. To retrieve your Client ID and secret, you'll need to [create a Slack App](https://api.slack.com/apps/new) if you haven't already.
+
+Once your app is created, copy and paste the **Client ID** and **Client Secret** into the Auth0 configuration screen. Next, click on **OAuth & Permissions** in the Features menu on the left, and add `https://${account.namespace}/login/callback` as a new **Redirect URL**
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/slack/4.md b/snippets/social/slack/4.md
new file mode 100644
index 0000000000..b681b53395
--- /dev/null
+++ b/snippets/social/slack/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Slack social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/slack/5.md b/snippets/social/slack/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/slack/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/spotify/0.md b/snippets/social/spotify/0.md
new file mode 100644
index 0000000000..375afdac41
--- /dev/null
+++ b/snippets/social/spotify/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Spotify
+
+The Spotify social connection allows users to log in to your application using their Spotify profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/spotify/1.md b/snippets/social/spotify/1.md
new file mode 100644
index 0000000000..99bd492c91
--- /dev/null
+++ b/snippets/social/spotify/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Spotify Developer account](https://developer.spotify.com/dashboard/).
diff --git a/snippets/social/spotify/2.md b/snippets/social/spotify/2.md
new file mode 100644
index 0000000000..142c0c8eec
--- /dev/null
+++ b/snippets/social/spotify/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect app to Spotify, you will:
+
+1. [Set up app in Spotify](#set-up-app-in-spotify)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/spotify/3.md b/snippets/social/spotify/3.md
new file mode 100644
index 0000000000..f394b310fd
--- /dev/null
+++ b/snippets/social/spotify/3.md
@@ -0,0 +1,15 @@
+### Set up app in Spotify
+
+Set up an app in the [Spotify Developer Dashboard](https://developer.spotify.com/dashboard/) using Spotify's [App Settings](https://developer.spotify.com/documentation/general/guides/app-settings/) documentation. During this process, Spotify will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/spotify/4.md b/snippets/social/spotify/4.md
new file mode 100644
index 0000000000..944c7ec5a7
--- /dev/null
+++ b/snippets/social/spotify/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Spotify social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/spotify/5.md b/snippets/social/spotify/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/spotify/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/stripe-connect/0.md b/snippets/social/stripe-connect/0.md
new file mode 100644
index 0000000000..5e919cd9f7
--- /dev/null
+++ b/snippets/social/stripe-connect/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Stripe Connect
+
+The Stripe Connect social connection allows users to log in to your application using their Stripe Connect profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/stripe-connect/1.md b/snippets/social/stripe-connect/1.md
new file mode 100644
index 0000000000..413e9cad82
--- /dev/null
+++ b/snippets/social/stripe-connect/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Stripe Developer account](https://dashboard.stripe.com/register).
diff --git a/snippets/social/stripe-connect/2.md b/snippets/social/stripe-connect/2.md
new file mode 100644
index 0000000000..ddd3296641
--- /dev/null
+++ b/snippets/social/stripe-connect/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Stripe Connect, you will:
+
+1. [Set up app in Stripe Connect](#set-up-app-in-stripe-connect)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/stripe-connect/3.md b/snippets/social/stripe-connect/3.md
new file mode 100644
index 0000000000..63a268de4e
--- /dev/null
+++ b/snippets/social/stripe-connect/3.md
@@ -0,0 +1,15 @@
+### Set up app in Stripe Connect
+
+Configure Connect settings in the [Stripe Developer Dashboard](https://dashboard.stripe.com/settings/applications). During this process, Stripe Connect will generate a **Client ID**; make note of this. Also make note of your **Secret API key**, which can be found on [Dashboard Home](https://dashboard.stripe.com/dashboard).
+
+While configuring Connect, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/stripe-connect/4.md b/snippets/social/stripe-connect/4.md
new file mode 100644
index 0000000000..0d19ae8cd5
--- /dev/null
+++ b/snippets/social/stripe-connect/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Stripe Connect social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Secret API Key**.
diff --git a/snippets/social/stripe-connect/5.md b/snippets/social/stripe-connect/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/stripe-connect/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/twitch/0.md b/snippets/social/twitch/0.md
new file mode 100644
index 0000000000..2841d4b84e
--- /dev/null
+++ b/snippets/social/twitch/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Twitch
+
+The Twitch social connection allows users to log in to your application using their Twitch profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/twitch/1.md b/snippets/social/twitch/1.md
new file mode 100644
index 0000000000..83aa8842fa
--- /dev/null
+++ b/snippets/social/twitch/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Twitch Developer account](https://dev.twitch.tv/login).
diff --git a/snippets/social/twitch/2.md b/snippets/social/twitch/2.md
new file mode 100644
index 0000000000..e59cec7270
--- /dev/null
+++ b/snippets/social/twitch/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Twitch, you will:
+
+1. [Set up app in Twitch](#set-up-app-in-twitch)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/twitch/3.md b/snippets/social/twitch/3.md
new file mode 100644
index 0000000000..fd45d03206
--- /dev/null
+++ b/snippets/social/twitch/3.md
@@ -0,0 +1,15 @@
+### Set up app in Twitch
+
+Set up an app in the [Twitch Developer portal](https://dev.twitch.tv/dashboard/apps/create) using Twitch's [Registration](https://dev.twitch.tv/docs/authentication#registration) documentation. During this process, Twitch will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/twitch/4.md b/snippets/social/twitch/4.md
new file mode 100644
index 0000000000..155dfc62ba
--- /dev/null
+++ b/snippets/social/twitch/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Twitch social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/twitch/5.md b/snippets/social/twitch/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/twitch/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/twitter/0.md b/snippets/social/twitter/0.md
new file mode 100644
index 0000000000..8515f06ac4
--- /dev/null
+++ b/snippets/social/twitter/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Twitter
+
+The Twitter social connection allows users to log in to your application using their Twitter profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/twitter/1.md b/snippets/social/twitter/1.md
new file mode 100644
index 0000000000..f25bbc0d8a
--- /dev/null
+++ b/snippets/social/twitter/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [apply for a Twitter Developer account](https://developer.twitter.com/en/apply-for-access/).
diff --git a/snippets/social/twitter/2.md b/snippets/social/twitter/2.md
new file mode 100644
index 0000000000..228976cf7f
--- /dev/null
+++ b/snippets/social/twitter/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Twitter, you will:
+
+1. [Set up app in Twitter](#set-up-app-in-twitter)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/twitter/3.md b/snippets/social/twitter/3.md
new file mode 100644
index 0000000000..cddc30ae18
--- /dev/null
+++ b/snippets/social/twitter/3.md
@@ -0,0 +1,18 @@
+### Set up app in Twitter
+
+Create a project and add a new app in the [Twitter Developer portal](https://developer.twitter.com/en/portal/). During this process, Twitter will generate an **API Key** and **API Secret Key** for your application; make note of these.
+
+While setting up your app, use the following values:
+
+| Field | Value to Provide |
+| - | - |
+| Enable 3-legged OAuth | Toggle the switch to enable. | 
+| Callback URLs | `https://${account.namespace}/login/callback` |
+| Website URL | `https://${account.namespace}` |
+| App permissions | Select the option that fitst your requirements. By default, your application will be granted **Read Only** permission. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/twitter/4.md b/snippets/social/twitter/4.md
new file mode 100644
index 0000000000..6bf664c226
--- /dev/null
+++ b/snippets/social/twitter/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Twitter social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **API Key** and **API Secret Key**.
diff --git a/snippets/social/twitter/5.md b/snippets/social/twitter/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/twitter/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/twitter/6.md b/snippets/social/twitter/6.md
new file mode 100644
index 0000000000..1f4f6a623f
--- /dev/null
+++ b/snippets/social/twitter/6.md
@@ -0,0 +1,13 @@
+## Access Twitter API
+
+Once a user successfully authenticates, Twitter will include an Access Token in the user profile it returns to Auth0. You can use this token to call Twitter's API.
+
+To get the Twitter Access Token, you must retrieve the full user's profile using the Auth0 Management API and extract the Access Token from the response. For detailed steps, see [Call an Identity Provider's API](https://auth0.com/docs/connections/calling-an-external-idp-api).
+
+Using the token, you can call Twitter's API following Twitter's documentation.
+
+Optional: Get a [Refresh Token](https://auth0.com/docs/tokens/guides/get-refresh-tokens) from Twitter to refresh your Access Token once it expires. To ensure your application is secure, pay close attention to the [restrictions on using Refresh Tokens](https://auth0.com/docs/tokens/concepts/refresh-tokens#restrictions-and-limitations).
+
+::: note
+Twitter allows you to use application-specific Access Tokens for many API calls without requiring user Access Tokens. When you create your app, a token is generated automatically and shown with the **API Key** and **API Secret Key** [Twitter Developer App Management](https://developer.twitter.com/en/apps). Using application-specific Access Tokens will limit your app to requests that do not require user context. To learn more, see [Twitter Developer Documentation: Application-Only Authentication](https://developer.twitter.com/en/docs/basics/authentication/overview/application-only.html).
+:::
diff --git a/snippets/social/twitter/7.md b/snippets/social/twitter/7.md
new file mode 100644
index 0000000000..1f43d046ac
--- /dev/null
+++ b/snippets/social/twitter/7.md
@@ -0,0 +1,3 @@
+## Troubleshooting
+
+If you are seeing errors, refer to the following troubleshooting steps.
diff --git a/snippets/social/twitter/8.md b/snippets/social/twitter/8.md
new file mode 100644
index 0000000000..447e2a1b45
--- /dev/null
+++ b/snippets/social/twitter/8.md
@@ -0,0 +1,14 @@
+### User's email address is missing from retrieved user profile
+
+Twitter connections do not retrieve the user's email address by default. However, you can add a rule to request the email address using the Access Token returned from Twitter *providing you supply a privacy policy and terms & conditions*.
+
+Auth0 provides a rule template to get email addresses from Twitter. To use it, [create a new rule](${manage_url}/#/rules/create) with the **Get Email Address from Twitter** template under the **Enrich Profile** section.
+
+If you are using Auth0 developer keys, this functionality will not work; you will need to use your Twitter **API Key** and **API Secret Key**.
+
+You must also explicitly request permission to retrieve user email addresses for your Twitter app:
+
+1. Log in to [Twitter Developer Project and App Management](https://developer.twitter.com/en/portal/projects-and-apps).
+2. Choose your project, and then your app settings.
+3. Click **Edit** next to **Authentication settings**, then toggle the switch to enable **Request email address from users**.
+4. Enter the appropriate links in the **Terms of service** and **Privacy policy** fields, then click **Save**.
diff --git a/snippets/social/vimeo/0.md b/snippets/social/vimeo/0.md
new file mode 100644
index 0000000000..afd62cc77a
--- /dev/null
+++ b/snippets/social/vimeo/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Vimeo
+
+The Vimeo social connection allows users to log in to your application using their Vimeo profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/vimeo/1.md b/snippets/social/vimeo/1.md
new file mode 100644
index 0000000000..081e3b9e97
--- /dev/null
+++ b/snippets/social/vimeo/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Vimeo Developer account](https://developer.vimeo.com/).
diff --git a/snippets/social/vimeo/2.md b/snippets/social/vimeo/2.md
new file mode 100644
index 0000000000..3db44bc29a
--- /dev/null
+++ b/snippets/social/vimeo/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Vimeo, you will:
+
+1. [Set up app in Vimeo](#set-up-app-in-vimeo)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/vimeo/3.md b/snippets/social/vimeo/3.md
new file mode 100644
index 0000000000..44e95d09e4
--- /dev/null
+++ b/snippets/social/vimeo/3.md
@@ -0,0 +1,15 @@
+### Set up app in Vimeo
+
+Set up an app in the [Vimeo Developer Portal](https://developer.vimeo.com/apps/new) using Vimeo's [Register your app](https://developer.vimeo.com/api/guides/start#register-your-app) documentation. During this process, Vimeo will generate a **Client Identifier** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your callback URL will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/vimeo/4.md b/snippets/social/vimeo/4.md
new file mode 100644
index 0000000000..30e1c4551a
--- /dev/null
+++ b/snippets/social/vimeo/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Vimeo social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client Identifier** and **Client Secret**.
diff --git a/snippets/social/vimeo/5.md b/snippets/social/vimeo/5.md
new file mode 100644
index 0000000000..c4a3a7f358
--- /dev/null
+++ b/snippets/social/vimeo/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
\ No newline at end of file
diff --git a/snippets/social/vkontakte/0.md b/snippets/social/vkontakte/0.md
new file mode 100644
index 0000000000..985cbfc013
--- /dev/null
+++ b/snippets/social/vkontakte/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to vKontakte
+
+The vKontakte social connection allows users to log in to your application using their vKontakte profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/vkontakte/1.md b/snippets/social/vkontakte/1.md
new file mode 100644
index 0000000000..f80f9e0695
--- /dev/null
+++ b/snippets/social/vkontakte/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a vKontakte Developer account](https://new.vk.com/dev).
diff --git a/snippets/social/vkontakte/2.md b/snippets/social/vkontakte/2.md
new file mode 100644
index 0000000000..394cc8ea27
--- /dev/null
+++ b/snippets/social/vkontakte/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to vKontakte, you will:
+
+1. [Set up app in vKontakte](#set-up-app-in-vkontakte)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/vkontakte/3.md b/snippets/social/vkontakte/3.md
new file mode 100644
index 0000000000..bcbab756e3
--- /dev/null
+++ b/snippets/social/vkontakte/3.md
@@ -0,0 +1,18 @@
+### Set up app in vKontakte
+
+Set up an app in the [vKontakte Developers portal](https://vk.com/apps?act=manage). During this process, vKontakte will generate an **Application ID** and **Secure Key** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Category | Select **Website**. |
+| Site address | `https://${account.namespace}` |
+| Base domain | `${account.namespace}` |
+| Authorized redirect URI | After you create your app, navigate to **Settings**, and enter `https://${account.namespace}/login/callback`. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/vkontakte/4.md b/snippets/social/vkontakte/4.md
new file mode 100644
index 0000000000..a0e446b470
--- /dev/null
+++ b/snippets/social/vkontakte/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the vKontakte social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Application ID** and **Secure Key**.
diff --git a/snippets/social/vkontakte/5.md b/snippets/social/vkontakte/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/vkontakte/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/weibo/0.md b/snippets/social/weibo/0.md
new file mode 100644
index 0000000000..7cb873f739
--- /dev/null
+++ b/snippets/social/weibo/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Weibo
+
+The Weibo social connection allows users to log in to your application using their Weibo profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/weibo/1.md b/snippets/social/weibo/1.md
new file mode 100644
index 0000000000..0c6bf0d4fa
--- /dev/null
+++ b/snippets/social/weibo/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Weibo Developer account](https://weibo.com/signup/signup.php?lang=en-us).
diff --git a/snippets/social/weibo/2.md b/snippets/social/weibo/2.md
new file mode 100644
index 0000000000..6854d037b8
--- /dev/null
+++ b/snippets/social/weibo/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To connect your app to Weibo, you will:
+
+1. [Set up app in Weibo](#set-up-app-in-weibo)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
+
diff --git a/snippets/social/weibo/3.md b/snippets/social/weibo/3.md
new file mode 100644
index 0000000000..dde7c1c838
--- /dev/null
+++ b/snippets/social/weibo/3.md
@@ -0,0 +1,15 @@
+### Set up app in Weibo
+
+Set up an app in the [Weibo Developer portal](https://open.weibo.com/apps/new). During this process, Weibo will generate an **App Key** and **App Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| 授权设置 (redirect URL) | After you create your app, navigate to **高级信息 (advanced information)**, click **编辑 (edit)** next to **授权设置 (redirect URL)**, and enter `https://${account.namespace}/login/callback`. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/weibo/4.md b/snippets/social/weibo/4.md
new file mode 100644
index 0000000000..1e9eda91f4
--- /dev/null
+++ b/snippets/social/weibo/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Weibo social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **App Key** and **App Secret**.
diff --git a/snippets/social/weibo/5.md b/snippets/social/weibo/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/weibo/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/wordpress/0.md b/snippets/social/wordpress/0.md
new file mode 100644
index 0000000000..022f64c265
--- /dev/null
+++ b/snippets/social/wordpress/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to WordPress
+
+The WordPress social connection allows users to log in to your application using their WordPress profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/wordpress/1.md b/snippets/social/wordpress/1.md
new file mode 100644
index 0000000000..ad09d94346
--- /dev/null
+++ b/snippets/social/wordpress/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a WordPress Developer account](http://developer.wordpress.com/).
diff --git a/snippets/social/wordpress/2.md b/snippets/social/wordpress/2.md
new file mode 100644
index 0000000000..1dbb248fd2
--- /dev/null
+++ b/snippets/social/wordpress/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to WordPress, you will:
+
+1. [Set up app in WordPress](#set-up-app-in-wordpress)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/wordpress/3.md b/snippets/social/wordpress/3.md
new file mode 100644
index 0000000000..8a2241a43a
--- /dev/null
+++ b/snippets/social/wordpress/3.md
@@ -0,0 +1,18 @@
+### Set up app in WordPress
+
+Set up an app in the [WordPress Developer Portal](https://developer.wordpress.com/apps/). During this process, WordPress will generate a **Client ID** and **Client Secret** for your application; make note of these. (To find these, from the **My Applications** dashboard, locate your application and click **Manage Application**.)
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Website URL | `https://${account.namespace}` |
+| Redirect URL | `https://${account.namespace}/login/callback` |
+| Javascript Origins | `https://${account.namespace}/`|
+| Type | Select **Web** as the client type|
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/wordpress/4.md b/snippets/social/wordpress/4.md
new file mode 100644
index 0000000000..87c1eaf9b1
--- /dev/null
+++ b/snippets/social/wordpress/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the WordPress social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**.
diff --git a/snippets/social/wordpress/5.md b/snippets/social/wordpress/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/wordpress/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/yahoo/0.md b/snippets/social/yahoo/0.md
new file mode 100644
index 0000000000..9c57508fbd
--- /dev/null
+++ b/snippets/social/yahoo/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Yahoo
+
+The Yahoo social connection allows users to log in to your application using their Yahoo profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/yahoo/1.md b/snippets/social/yahoo/1.md
new file mode 100644
index 0000000000..707d51de18
--- /dev/null
+++ b/snippets/social/yahoo/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* [Get a Yahoo User ID](https://login.yahoo.com)
+* [Sign up for a Yahoo Developer account](https://developer.yahoo.com/)
diff --git a/snippets/social/yahoo/2.md b/snippets/social/yahoo/2.md
new file mode 100644
index 0000000000..9fed53d4c7
--- /dev/null
+++ b/snippets/social/yahoo/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Yahoo, you will:
+
+1. [Set up app in Yahoo](#set-up-app-in-yahoo)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/yahoo/3.md b/snippets/social/yahoo/3.md
new file mode 100644
index 0000000000..3bde67d7a9
--- /dev/null
+++ b/snippets/social/yahoo/3.md
@@ -0,0 +1,16 @@
+### Set up app in Yahoo
+
+Set up an app in Yahoo using Yahoo's [Getting Started: Create an Application and Get OAuth 2.0 Credentials](https://developer.yahoo.com/oauth2/guide/openid_connect/getting_started.html#getting-started-setup) documentation. During this process, Yahoo will generate a **Client ID* (Consumer Key)** and **Client Secret (Consumer Secret)** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URI | `https://${account.namespace}/login/callback` |
+| API Permissions | Select **OpenID Connect Permissions**, then at minimum, **Email** (to ensure that Yahoo returns the user's email address). |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
diff --git a/snippets/social/yahoo/4.md b/snippets/social/yahoo/4.md
new file mode 100644
index 0000000000..6d5cbfbea6
--- /dev/null
+++ b/snippets/social/yahoo/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Yahoo social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the **Client ID (Consumer Key)** and the **Client Secret (Consumer Secret)** generated.
diff --git a/snippets/social/yahoo/5.md b/snippets/social/yahoo/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/yahoo/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/yammer/0.md b/snippets/social/yammer/0.md
new file mode 100644
index 0000000000..18e1518964
--- /dev/null
+++ b/snippets/social/yammer/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Yammer
+
+The Yammer social connection allows users to log in to your application using their Yammer profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/yammer/1.md b/snippets/social/yammer/1.md
new file mode 100644
index 0000000000..6e343d5329
--- /dev/null
+++ b/snippets/social/yammer/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Yammer Developer account](https://developer.yammer.com/).
diff --git a/snippets/social/yammer/2.md b/snippets/social/yammer/2.md
new file mode 100644
index 0000000000..b26e0f8a01
--- /dev/null
+++ b/snippets/social/yammer/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Yammer, you will:
+
+1. [Set up app in Yammer](#set-up-app-in-yammer)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/yammer/3.md b/snippets/social/yammer/3.md
new file mode 100644
index 0000000000..5bb93b35b6
--- /dev/null
+++ b/snippets/social/yammer/3.md
@@ -0,0 +1,16 @@
+### Set up app in Yammer
+
+Set up an app using Yammer's [App Registration](https://developer.yammer.com/docs/app-registration) documentation. During this process, Yammer will generate a **Client ID** and **Client Secret** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Redirect URL | `https://${account.namespace}/login/callback` |
+| JavaScript Origins | `https://${account.namespace}/` |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your redirect URL would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/yammer/4.md b/snippets/social/yammer/4.md
new file mode 100644
index 0000000000..9e77996b69
--- /dev/null
+++ b/snippets/social/yammer/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Yammer social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and the **Client Secret**.
diff --git a/snippets/social/yammer/5.md b/snippets/social/yammer/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/yammer/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/social/yandex/0.md b/snippets/social/yandex/0.md
new file mode 100644
index 0000000000..eab1b06b57
--- /dev/null
+++ b/snippets/social/yandex/0.md
@@ -0,0 +1,5 @@
+# Connect Apps to Yandex
+
+The Yandex social connection allows users to log in to your application using their Yandex profile.
+
+By default, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. Optionally, you can [disable user profile data synchronization](https://auth0.com/docs/users/configure-connection-sync-with-auth0) to allow for updating profile attributes from your application.
\ No newline at end of file
diff --git a/snippets/social/yandex/1.md b/snippets/social/yandex/1.md
new file mode 100644
index 0000000000..97e08dc5dc
--- /dev/null
+++ b/snippets/social/yandex/1.md
@@ -0,0 +1,3 @@
+## Prerequisites
+
+Before you begin, [sign up for a Yandex Developer account](https://developer.store.yandex.com/).
diff --git a/snippets/social/yandex/2.md b/snippets/social/yandex/2.md
new file mode 100644
index 0000000000..d40ba27ea1
--- /dev/null
+++ b/snippets/social/yandex/2.md
@@ -0,0 +1,7 @@
+## Steps
+
+To connect your app to Yandex, you will:
+
+1. [Set up app in Yandex](#set-up-app-in-yandex)
+2. [Create and enable connection in Auth0](#create-and-enable-connection-in-auth0)
+3. [Test connection](#test-connection)
diff --git a/snippets/social/yandex/3.md b/snippets/social/yandex/3.md
new file mode 100644
index 0000000000..fd9cc28464
--- /dev/null
+++ b/snippets/social/yandex/3.md
@@ -0,0 +1,16 @@
+### Set up app in Yandex
+
+Set up an app in Yandex using Yandex's [Application Registration](https://yandex.ru/dev/oauth/doc/dg/tasks/register-client-docpage/) documentation. During this process, Yandex will generate an **Application ID** and **Application Password** for your application; make note of these.
+
+While setting up your app, use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| Callback URI | `https://${account.namespace}/login/callback` |
+| Scopes | Select the appropriate options depending on your application's needs. |
+
+::: panel Find your Auth0 domain name
+If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, your regional subdomain (unless your tenant is in the US region and was created before June 2020), plus`.auth0.com`. For example, if your tenant name were `exampleco-enterprises`, your Auth0 domain name would be `exampleco-enterprises.us.auth0.com` and your callback URI would be `https://exampleco-enterprises.us.auth0.com/login/callback`. (If your tenant is in the US and was created before June 2020, then your domain name would be `https://exampleco-enterprises.auth0.com`.)
+
+If you are using [custom domains](https://auth0.com/docs/custom-domains), your redirect URI will have the following format: `https:///login/callback`.
+:::
\ No newline at end of file
diff --git a/snippets/social/yandex/4.md b/snippets/social/yandex/4.md
new file mode 100644
index 0000000000..dfb7807618
--- /dev/null
+++ b/snippets/social/yandex/4.md
@@ -0,0 +1,3 @@
+### Create and enable connection in Auth0
+
+[Set up the Yandex social connection](https://auth0.com/docs/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Application ID** and **Application Password**.
diff --git a/snippets/social/yandex/5.md b/snippets/social/yandex/5.md
new file mode 100644
index 0000000000..6a3c160d19
--- /dev/null
+++ b/snippets/social/yandex/5.md
@@ -0,0 +1,3 @@
+### Test connection
+
+You're ready to [test your connection](https://auth0.com/docs/dashboard/guides/connections/test-connections-social).
diff --git a/snippets/sso-integrations/ad-rms/0.md b/snippets/sso-integrations/ad-rms/0.md
new file mode 100644
index 0000000000..66438ddda5
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/0.md
@@ -0,0 +1,7 @@
+# Configure SSO Integration for AD RMS
+
+The AD RMS [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for AD RMS. Your users log in to AD RMS with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
+
+::: warning
+The steps in this guide are valid for Active Directory Rights Management Services 2008 and earlier.
+:::
diff --git a/snippets/sso-integrations/ad-rms/1.md b/snippets/sso-integrations/ad-rms/1.md
new file mode 100644
index 0000000000..72aebed1b1
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an AD RMS account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/ad-rms/2.md b/snippets/sso-integrations/ad-rms/2.md
new file mode 100644
index 0000000000..8e29cb11a2
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a AD RMS SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with AD RMS](#configure-integration-with-ad-rms)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/ad-rms/3.md b/snippets/sso-integrations/ad-rms/3.md
new file mode 100644
index 0000000000..3577063106
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **AD RMS**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/ad-rms/4.md b/snippets/sso-integrations/ad-rms/4.md
new file mode 100644
index 0000000000..319980aadd
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+           
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Rights Management Services URLURL of your Active Directory Rights Management Server.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of AD RMS.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/ad-rms/5.md b/snippets/sso-integrations/ad-rms/5.md
new file mode 100644
index 0000000000..ecd34397a0
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/5.md
@@ -0,0 +1,3 @@
+### Configure integration with AD RMS
+
+To configure the integration with AD RMS, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/ad-rms/6.md b/snippets/sso-integrations/ad-rms/6.md
new file mode 100644
index 0000000000..f10fc1229d
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/6.md
@@ -0,0 +1,12 @@
+#### AD RMS SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Add Federation Support to your AD RMS Cluster
+
+2. Enter your Auth0 **RMS URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`${account.namespace}/rms/SSO_CLIENT_ID`
+
+Make sure you validate the URL to verify connectivity.
\ No newline at end of file
diff --git a/snippets/sso-integrations/ad-rms/7.md b/snippets/sso-integrations/ad-rms/7.md
new file mode 100644
index 0000000000..78093e21ee
--- /dev/null
+++ b/snippets/sso-integrations/ad-rms/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to AD RMS. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/adobe-sign/0.md b/snippets/sso-integrations/adobe-sign/0.md
new file mode 100644
index 0000000000..15043d990d
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Adobe Sign
+
+The Adobe Sign [Single Sign-on (SSO)](/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Adobe Sign. Your users log in to Adobe Sign with Auth0 [identity providers](/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/adobe-sign/1.md b/snippets/sso-integrations/adobe-sign/1.md
new file mode 100644
index 0000000000..4950075247
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an Adobe Sign account.
+* [Set up a connection](/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/adobe-sign/2.md b/snippets/sso-integrations/adobe-sign/2.md
new file mode 100644
index 0000000000..e3f8bd1668
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure an Adobe Sign SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Adobe Sign](#configure-integration-with-adobe-sign)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/adobe-sign/3.md b/snippets/sso-integrations/adobe-sign/3.md
new file mode 100644
index 0000000000..30b16ea13e
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Adobe Sign**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/adobe-sign/4.md b/snippets/sso-integrations/adobe-sign/4.md
new file mode 100644
index 0000000000..bd3870bc64
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Custom DomainDomain of your Adobe Sign URL (https://{domain}.echosign.com).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Adobe Sign.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/adobe-sign/5.md b/snippets/sso-integrations/adobe-sign/5.md
new file mode 100644
index 0000000000..0dd34775a4
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Adobe Sign
+
+To configure the integration with Adobe Sign, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/adobe-sign/6.md b/snippets/sso-integrations/adobe-sign/6.md
new file mode 100644
index 0000000000..0e8f65d54d
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/6.md
@@ -0,0 +1,29 @@
+#### Adobe Sign SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to Adobe Sign as an administrator.
+
+2. Under **Account** > **Account Settings**, select the **SAML Settings**.
+
+3. Enter the **IdP Entity ID**:
+`urn:${account.namespace}`
+
+4. Enter the **IdP Login URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+5. Enter the **IdP Logout URL**:
+`https://${account.namespace}/logout`
+
+6. [Download your Auth0 signing certificate ](https://${account.namespace}/pem), and copy it into Adobe Sign.
diff --git a/snippets/sso-integrations/adobe-sign/7.md b/snippets/sso-integrations/adobe-sign/7.md
new file mode 100644
index 0000000000..695d995ce4
--- /dev/null
+++ b/snippets/sso-integrations/adobe-sign/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Adobe Sign. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/box/0.md b/snippets/sso-integrations/box/0.md
new file mode 100644
index 0000000000..176e697e87
--- /dev/null
+++ b/snippets/sso-integrations/box/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Box
+
+The Box [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Box. Your users log in to Box with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/box/1.md b/snippets/sso-integrations/box/1.md
new file mode 100644
index 0000000000..3c17870159
--- /dev/null
+++ b/snippets/sso-integrations/box/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a [Box Enterprise account](https://www.box.com/).
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/box/2.md b/snippets/sso-integrations/box/2.md
new file mode 100644
index 0000000000..ff691e4e27
--- /dev/null
+++ b/snippets/sso-integrations/box/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Box SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Box](#configure-integration-with-box)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/box/3.md b/snippets/sso-integrations/box/3.md
new file mode 100644
index 0000000000..4c7989cdaf
--- /dev/null
+++ b/snippets/sso-integrations/box/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Box**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/box/4.md b/snippets/sso-integrations/box/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/box/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/box/5.md b/snippets/sso-integrations/box/5.md
new file mode 100644
index 0000000000..588cf0d8c4
--- /dev/null
+++ b/snippets/sso-integrations/box/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Box
+
+To configure the integration with Box, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/box/6.md b/snippets/sso-integrations/box/6.md
new file mode 100644
index 0000000000..ea4a1b1d9b
--- /dev/null
+++ b/snippets/sso-integrations/box/6.md
@@ -0,0 +1,28 @@
+#### Box SSO integration
+
+::: warning
+The following steps only work for [Box Enterprise accounts](https://www.box.com/).
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Configuring SAML SSO with Box requires you to call their support team. They will ask for a few pieces of information:
+
+1. [Your Auth0 signing certificate](https://${account.namespace}/pem).
+
+2. The **EntityID**: `urn:${account.namespace}`.
+
+3. The identifier that maps to Box usernames. By default we use the `emailaddress` claim:
+`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
+
+4. The **Redirect URL**, which is the login endpoint in Auth0 (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+5. OPTIONAL: If you would like your Box user accounts to be created automatically, request that the Box support team enable automatic account provisioning for your account. To do so, you will need to provide the claims that we use for first name and last name. By default, we use `givenname` as the first name and `surname` as the last name.
+
+```text
+http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
+http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
+```
diff --git a/snippets/sso-integrations/box/7.md b/snippets/sso-integrations/box/7.md
new file mode 100644
index 0000000000..145df49dbe
--- /dev/null
+++ b/snippets/sso-integrations/box/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Box. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/cisco-webex/0.md b/snippets/sso-integrations/cisco-webex/0.md
new file mode 100644
index 0000000000..53321e637a
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Cisco WebEx
+
+The Cisco WebEx [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Cisco WebEx. Your users log in to Cisco WebEx with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/cisco-webex/1.md b/snippets/sso-integrations/cisco-webex/1.md
new file mode 100644
index 0000000000..49ab7b07a8
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Cisco WebEx account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/cisco-webex/2.md b/snippets/sso-integrations/cisco-webex/2.md
new file mode 100644
index 0000000000..24f58614c1
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Cisco WebEx SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Cisco WebEx](#configure-integration-with-cisco-webex)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/cisco-webex/3.md b/snippets/sso-integrations/cisco-webex/3.md
new file mode 100644
index 0000000000..261b61d472
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Cisco WebEx**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/cisco-webex/4.md b/snippets/sso-integrations/cisco-webex/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/cisco-webex/5.md b/snippets/sso-integrations/cisco-webex/5.md
new file mode 100644
index 0000000000..31545fbf49
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Cisco WebEx
+
+To configure the integration with Cisco WebEx, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/cisco-webex/6.md b/snippets/sso-integrations/cisco-webex/6.md
new file mode 100644
index 0000000000..96cfae83da
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/6.md
@@ -0,0 +1,34 @@
+#### Cisco WebEx SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/cisco-webex/7.md b/snippets/sso-integrations/cisco-webex/7.md
new file mode 100644
index 0000000000..67e933a05e
--- /dev/null
+++ b/snippets/sso-integrations/cisco-webex/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Cisco WebEx. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/cloudbees/0.md b/snippets/sso-integrations/cloudbees/0.md
new file mode 100644
index 0000000000..fd8dc7b3dd
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for CloudBees
+
+The CloudBees [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for CloudBees. Your users log in to CloudBees with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/cloudbees/1.md b/snippets/sso-integrations/cloudbees/1.md
new file mode 100644
index 0000000000..11e899a08a
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a CloudBees account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/cloudbees/2.md b/snippets/sso-integrations/cloudbees/2.md
new file mode 100644
index 0000000000..3b64cffc0a
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a CloudBees SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with CloudBees](#configure-integration-with-cloudbees)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/cloudbees/3.md b/snippets/sso-integrations/cloudbees/3.md
new file mode 100644
index 0000000000..dec36f08d6
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **CloudBees**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/cloudbees/4.md b/snippets/sso-integrations/cloudbees/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/cloudbees/5.md b/snippets/sso-integrations/cloudbees/5.md
new file mode 100644
index 0000000000..e94f28a559
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/5.md
@@ -0,0 +1,3 @@
+### Configure integration with CloudBees
+
+To configure the integration with CloudBees, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/cloudbees/6.md b/snippets/sso-integrations/cloudbees/6.md
new file mode 100644
index 0000000000..b1c5021d28
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/6.md
@@ -0,0 +1,26 @@
+#### CloudBees SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to CloudBees as an administrator.
+
+2. Select **Account > SSO Integration**.
+
+3. Enter the Remote login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`.
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget.
+
+4. [Download your Auth0 signing certificate ](https://${account.namespace}/pem), and copy it into CloudBees.
+
+5. [Verify your domain](https://support.cloudbees.com/hc/en-us/articles/360017607331-How-to-set-up-SSO-with-SAML-based-IdP-to-access-CloudBees-services-).
\ No newline at end of file
diff --git a/snippets/sso-integrations/cloudbees/7.md b/snippets/sso-integrations/cloudbees/7.md
new file mode 100644
index 0000000000..61a71a6dcb
--- /dev/null
+++ b/snippets/sso-integrations/cloudbees/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to CloudBees. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/concur/0.md b/snippets/sso-integrations/concur/0.md
new file mode 100644
index 0000000000..b013601012
--- /dev/null
+++ b/snippets/sso-integrations/concur/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Concur
+
+The Concur [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Concur. Your users log in to Concur with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/concur/1.md b/snippets/sso-integrations/concur/1.md
new file mode 100644
index 0000000000..4c0236d19d
--- /dev/null
+++ b/snippets/sso-integrations/concur/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Concur account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/concur/2.md b/snippets/sso-integrations/concur/2.md
new file mode 100644
index 0000000000..6393824d08
--- /dev/null
+++ b/snippets/sso-integrations/concur/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Concur SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Concur](#configure-integration-with-concur)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/concur/3.md b/snippets/sso-integrations/concur/3.md
new file mode 100644
index 0000000000..2d298405de
--- /dev/null
+++ b/snippets/sso-integrations/concur/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Concur****.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/concur/4.md b/snippets/sso-integrations/concur/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/concur/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/concur/5.md b/snippets/sso-integrations/concur/5.md
new file mode 100644
index 0000000000..297a411d9c
--- /dev/null
+++ b/snippets/sso-integrations/concur/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Concur
+
+To configure the integration with Concur, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/concur/6.md b/snippets/sso-integrations/concur/6.md
new file mode 100644
index 0000000000..eb5fe92502
--- /dev/null
+++ b/snippets/sso-integrations/concur/6.md
@@ -0,0 +1,26 @@
+#### Concur SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Concur requires you to contact their support team to setup SSO through SAML. [Download your Auth0 signing certificate](https://${account.namespace}/pem), and provide it to Concur.
+
+Once configured on their side, you can use any of the links below for SSO (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+:::note 
+Notice that Concur only supports IdP-Initiated SSO, so you must use any of the links above to initiate SSO.
+:::
+
+Optionally, you can specify a Logout URL:
+`https://${account.namespace}/logout`
diff --git a/snippets/sso-integrations/concur/7.md b/snippets/sso-integrations/concur/7.md
new file mode 100644
index 0000000000..518355c2e6
--- /dev/null
+++ b/snippets/sso-integrations/concur/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Concur. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/datadog/0.md b/snippets/sso-integrations/datadog/0.md
new file mode 100644
index 0000000000..e51a4090f9
--- /dev/null
+++ b/snippets/sso-integrations/datadog/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Datadog
+
+The Datadog [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Datadog. Your users log in to Datadog with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/datadog/1.md b/snippets/sso-integrations/datadog/1.md
new file mode 100644
index 0000000000..c6dcada3e9
--- /dev/null
+++ b/snippets/sso-integrations/datadog/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Datadog account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/datadog/2.md b/snippets/sso-integrations/datadog/2.md
new file mode 100644
index 0000000000..c1e9d6ff36
--- /dev/null
+++ b/snippets/sso-integrations/datadog/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Datadog SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Datadog](#configure-integration-with-datadog)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/datadog/3.md b/snippets/sso-integrations/datadog/3.md
new file mode 100644
index 0000000000..751b540b30
--- /dev/null
+++ b/snippets/sso-integrations/datadog/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Datadog**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/datadog/4.md b/snippets/sso-integrations/datadog/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/datadog/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/datadog/5.md b/snippets/sso-integrations/datadog/5.md
new file mode 100644
index 0000000000..29470ae31d
--- /dev/null
+++ b/snippets/sso-integrations/datadog/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Datadog
+
+To configure the integration with Datadog, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/datadog/6.md b/snippets/sso-integrations/datadog/6.md
new file mode 100644
index 0000000000..cecc313818
--- /dev/null
+++ b/snippets/sso-integrations/datadog/6.md
@@ -0,0 +1,34 @@
+#### Datadog SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/datadog/7.md b/snippets/sso-integrations/datadog/7.md
new file mode 100644
index 0000000000..1550ae3059
--- /dev/null
+++ b/snippets/sso-integrations/datadog/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Datadog. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/dropbox/0.md b/snippets/sso-integrations/dropbox/0.md
new file mode 100644
index 0000000000..928a693e3f
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Dropbox
+
+The Dropbox [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Dropbox. Your users log in to Dropbox with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/dropbox/1.md b/snippets/sso-integrations/dropbox/1.md
new file mode 100644
index 0000000000..241c7cae28
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a [Dropbox Business account](https://www.dropbox.com/business).
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/dropbox/2.md b/snippets/sso-integrations/dropbox/2.md
new file mode 100644
index 0000000000..4785ef34b6
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Dropbox SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Dropbox](#configure-integration-with-dropbox)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/dropbox/3.md b/snippets/sso-integrations/dropbox/3.md
new file mode 100644
index 0000000000..965dc0f958
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Dropbox**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/dropbox/4.md b/snippets/sso-integrations/dropbox/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/dropbox/5.md b/snippets/sso-integrations/dropbox/5.md
new file mode 100644
index 0000000000..d61e8282b8
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Dropbox
+
+To configure the integration with Dropbox, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/dropbox/6.md b/snippets/sso-integrations/dropbox/6.md
new file mode 100644
index 0000000000..216424d7f4
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/6.md
@@ -0,0 +1,20 @@
+#### Dropbox SSO integration
+
+::: warning
+The following steps only work for [Dropbox Business accounts](https://www.dropbox.com/business).
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to your Dropbox Business account as an administrator.
+
+2. Select the **Authentication** menu item on the left.
+
+3. Enable **Single-Sign-On**.
+
+4. Enter the **Login URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+5. [Download your Auth0 signing certificate](https://${account.namespace}/pem), and upload it to Dropbox as **X.509 certificate**.
diff --git a/snippets/sso-integrations/dropbox/7.md b/snippets/sso-integrations/dropbox/7.md
new file mode 100644
index 0000000000..b02eccebb1
--- /dev/null
+++ b/snippets/sso-integrations/dropbox/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Dropbox. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/dynamics-crm/0.md b/snippets/sso-integrations/dynamics-crm/0.md
new file mode 100644
index 0000000000..4c5bee3319
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Dynamics CRM
+
+The Dynamics CRM [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Dynamics CRM. Your users log in to Dynamics CRM with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/dynamics-crm/1.md b/snippets/sso-integrations/dynamics-crm/1.md
new file mode 100644
index 0000000000..bb3a7ac287
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Dynamics CRM account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/dynamics-crm/2.md b/snippets/sso-integrations/dynamics-crm/2.md
new file mode 100644
index 0000000000..3bd08b8b6d
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Dynamics CRM SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Dynamics CRM](#configure-integration-with-dynamics-crm)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/dynamics-crm/3.md b/snippets/sso-integrations/dynamics-crm/3.md
new file mode 100644
index 0000000000..ca01ca12e2
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Dynamics CRM**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/dynamics-crm/4.md b/snippets/sso-integrations/dynamics-crm/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/dynamics-crm/5.md b/snippets/sso-integrations/dynamics-crm/5.md
new file mode 100644
index 0000000000..00e8be2bbc
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Dynamics CRM
+
+To configure the integration with Dynamics CRM, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/dynamics-crm/6.md b/snippets/sso-integrations/dynamics-crm/6.md
new file mode 100644
index 0000000000..1daa024766
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/6.md
@@ -0,0 +1,34 @@
+#### Dynamics CRM SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/dynamics-crm/7.md b/snippets/sso-integrations/dynamics-crm/7.md
new file mode 100644
index 0000000000..44f5333d33
--- /dev/null
+++ b/snippets/sso-integrations/dynamics-crm/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Dynamics CRM. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/egencia/0.md b/snippets/sso-integrations/egencia/0.md
new file mode 100644
index 0000000000..f3eb4b8eb5
--- /dev/null
+++ b/snippets/sso-integrations/egencia/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Egencia
+
+The Egencia [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Egencia. Your users log in to Egencia with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/egencia/1.md b/snippets/sso-integrations/egencia/1.md
new file mode 100644
index 0000000000..2154d50530
--- /dev/null
+++ b/snippets/sso-integrations/egencia/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an Egencia account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/egencia/2.md b/snippets/sso-integrations/egencia/2.md
new file mode 100644
index 0000000000..304b58d320
--- /dev/null
+++ b/snippets/sso-integrations/egencia/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure an Egencia SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Egencia](#configure-integration-with-egencia)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/egencia/3.md b/snippets/sso-integrations/egencia/3.md
new file mode 100644
index 0000000000..55ad5c6cbe
--- /dev/null
+++ b/snippets/sso-integrations/egencia/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Egencia**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/egencia/4.md b/snippets/sso-integrations/egencia/4.md
new file mode 100644
index 0000000000..39e450a3f7
--- /dev/null
+++ b/snippets/sso-integrations/egencia/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        AudienceYour Egencia URL (https://{YOUR_ACCOUNT_NAME}.egencia.com).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Egencia.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/egencia/5.md b/snippets/sso-integrations/egencia/5.md
new file mode 100644
index 0000000000..54c055a006
--- /dev/null
+++ b/snippets/sso-integrations/egencia/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Egencia
+
+To configure the integration with Egencia, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/egencia/6.md b/snippets/sso-integrations/egencia/6.md
new file mode 100644
index 0000000000..08f5446c59
--- /dev/null
+++ b/snippets/sso-integrations/egencia/6.md
@@ -0,0 +1,34 @@
+#### Egencia SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/egencia/7.md b/snippets/sso-integrations/egencia/7.md
new file mode 100644
index 0000000000..bb57ef2c7d
--- /dev/null
+++ b/snippets/sso-integrations/egencia/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Egencia. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/egnyte/0.md b/snippets/sso-integrations/egnyte/0.md
new file mode 100644
index 0000000000..16f556e7c2
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Egnyte
+
+The Egnyte [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Egnyte. Your users log in to Egnyte with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/egnyte/1.md b/snippets/sso-integrations/egnyte/1.md
new file mode 100644
index 0000000000..8bb1c4ddea
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an Egnyte account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/egnyte/2.md b/snippets/sso-integrations/egnyte/2.md
new file mode 100644
index 0000000000..f62f1ded43
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure an Egnyte SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Egnyte](#configure-integration-with-egnyte)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/egnyte/3.md b/snippets/sso-integrations/egnyte/3.md
new file mode 100644
index 0000000000..bcc1411312
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Egnyte**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/egnyte/4.md b/snippets/sso-integrations/egnyte/4.md
new file mode 100644
index 0000000000..a7c8579f74
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Egnyte DomainDomain of your Egnyte URL (https://{domain}.egnyte.com).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Egnyte.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/egnyte/5.md b/snippets/sso-integrations/egnyte/5.md
new file mode 100644
index 0000000000..ed74954e79
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Egnyte
+
+To configure the integration with Egnyte, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/egnyte/6.md b/snippets/sso-integrations/egnyte/6.md
new file mode 100644
index 0000000000..07ded21f84
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/6.md
@@ -0,0 +1,38 @@
+#### Egnyte SSO integration
+
+:::note
+Important: SAML SSO is a feature included in only certain Egnyte plans.
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in as an Admin to Egnyte.
+
+2. Under **Configuration**, select the **Security** menu.
+
+3. Enable **Single Sign On (SAML 2.0) Authentication**.
+
+4. Select **Auth0** as the identity provider.
+
+5. Enter the **Identity Provider Login URL**:
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, you can add a connection parameter:
+
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+6. Enter the **Identity provider Entity ID**:
+`urn:${account.namespace}`
+
+7. [Download your Auth0 signing certificate ](https://${account.namespace}/pem), and copy it into Egnyte.
+
+8. Select **Email address** as the **Default user mapping**.
+
+:::note
+Make sure your individual users have **Web SSO** enabled in Egnyte.
+:::
diff --git a/snippets/sso-integrations/egnyte/7.md b/snippets/sso-integrations/egnyte/7.md
new file mode 100644
index 0000000000..1bdf3c1b28
--- /dev/null
+++ b/snippets/sso-integrations/egnyte/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Egnyte. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/eloqua/0.md b/snippets/sso-integrations/eloqua/0.md
new file mode 100644
index 0000000000..4172d6256e
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Eloqua
+
+The Eloqua [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Eloqua. Your users log in to Eloqua with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/eloqua/1.md b/snippets/sso-integrations/eloqua/1.md
new file mode 100644
index 0000000000..8d30525d72
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an Eloqua account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/eloqua/2.md b/snippets/sso-integrations/eloqua/2.md
new file mode 100644
index 0000000000..a1c448a3dd
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure an Eloqua SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Eloqua](#configure-integration-with-eloqua)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/eloqua/3.md b/snippets/sso-integrations/eloqua/3.md
new file mode 100644
index 0000000000..28aa236538
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Eloqua**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/eloqua/4.md b/snippets/sso-integrations/eloqua/4.md
new file mode 100644
index 0000000000..008d895d52
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        AudienceService Provider Entity URL from within Eloqua.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Eloqua.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/eloqua/5.md b/snippets/sso-integrations/eloqua/5.md
new file mode 100644
index 0000000000..d340926e75
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Eloqua
+
+To configure the integration with Eloqua, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/eloqua/6.md b/snippets/sso-integrations/eloqua/6.md
new file mode 100644
index 0000000000..d6c1f05b91
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/6.md
@@ -0,0 +1,34 @@
+#### Eloqua SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/eloqua/7.md b/snippets/sso-integrations/eloqua/7.md
new file mode 100644
index 0000000000..7d76266b5a
--- /dev/null
+++ b/snippets/sso-integrations/eloqua/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Eloqua. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/freshdesk/0.md b/snippets/sso-integrations/freshdesk/0.md
new file mode 100644
index 0000000000..6a3b3d5885
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Freshdesk
+
+The Freshdesk [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Freshdesk. Your users log in to Freshdesk with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/freshdesk/1.md b/snippets/sso-integrations/freshdesk/1.md
new file mode 100644
index 0000000000..de2205b569
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Freshdesk account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/freshdesk/2.md b/snippets/sso-integrations/freshdesk/2.md
new file mode 100644
index 0000000000..8b9471718d
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Freshdesk SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Freshdesk](#configure-integration-with-freshdesk)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/freshdesk/3.md b/snippets/sso-integrations/freshdesk/3.md
new file mode 100644
index 0000000000..e31133ee37
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Freshdesk**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/freshdesk/4.md b/snippets/sso-integrations/freshdesk/4.md
new file mode 100644
index 0000000000..8c42abfee8
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://{domain}.freshdesk.com/login/saml).
        AudienceService Provider Entity ID from within Freshdesk (https://{domain}.freshworks.com/sp/SAML/{xxxxxxxxxxxxxxxxxxx}/metadata).
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/freshdesk/5.md b/snippets/sso-integrations/freshdesk/5.md
new file mode 100644
index 0000000000..9258fb81cd
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Freshdesk
+
+To configure the integration with Freshdesk, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/freshdesk/6.md b/snippets/sso-integrations/freshdesk/6.md
new file mode 100644
index 0000000000..1327602b99
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/6.md
@@ -0,0 +1,34 @@
+#### Freshdesk SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/freshdesk/7.md b/snippets/sso-integrations/freshdesk/7.md
new file mode 100644
index 0000000000..e01dbfa513
--- /dev/null
+++ b/snippets/sso-integrations/freshdesk/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Freshdesk. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/github-enterprise-cloud/0.md b/snippets/sso-integrations/github-enterprise-cloud/0.md
new file mode 100644
index 0000000000..8f2ff76eb1
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for GitHub Enterprise Cloud
+
+The GitHub Enterprise Cloud [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for GitHub Enterprise Cloud. Your users log in to GitHub Enterprise Cloud with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/github-enterprise-cloud/1.md b/snippets/sso-integrations/github-enterprise-cloud/1.md
new file mode 100644
index 0000000000..d43826a623
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a GitHub Enterprise Cloud account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/github-enterprise-cloud/2.md b/snippets/sso-integrations/github-enterprise-cloud/2.md
new file mode 100644
index 0000000000..f0a2820270
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a GitHub Enterprise Cloud SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with GitHub Enterprise Cloud](#configure-integration-with-github-enterprise-cloud)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/github-enterprise-cloud/3.md b/snippets/sso-integrations/github-enterprise-cloud/3.md
new file mode 100644
index 0000000000..e2900dd948
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **GitHub Enterprise Cloud**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/github-enterprise-cloud/4.md b/snippets/sso-integrations/github-enterprise-cloud/4.md
new file mode 100644
index 0000000000..d7d81520e5
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}/saml/consume).
        AudienceYour GitHub Enterprise Cloud URL (https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of GitHub Enterprise Cloud.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/github-enterprise-cloud/5.md b/snippets/sso-integrations/github-enterprise-cloud/5.md
new file mode 100644
index 0000000000..399bb4f59a
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/5.md
@@ -0,0 +1,3 @@
+### Configure integration with GitHub Enterprise Cloud
+
+To configure the integration with GitHub Enterprise Cloud, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/github-enterprise-cloud/6.md b/snippets/sso-integrations/github-enterprise-cloud/6.md
new file mode 100644
index 0000000000..a52caa0ce6
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/6.md
@@ -0,0 +1,34 @@
+#### GitHub Enterprise Cloud SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/github-enterprise-cloud/7.md b/snippets/sso-integrations/github-enterprise-cloud/7.md
new file mode 100644
index 0000000000..76fefcbc7c
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-cloud/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to GitHub Enterprise Cloud. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/github-enterprise-server/0.md b/snippets/sso-integrations/github-enterprise-server/0.md
new file mode 100644
index 0000000000..8372a1d460
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for GitHub Enterprise Server
+
+The GitHub Enterprise Server [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for GitHub Enterprise Server. Your users log in to GitHub Enterprise Server with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/github-enterprise-server/1.md b/snippets/sso-integrations/github-enterprise-server/1.md
new file mode 100644
index 0000000000..d6969841da
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a GitHub Enterprise Server account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/github-enterprise-server/2.md b/snippets/sso-integrations/github-enterprise-server/2.md
new file mode 100644
index 0000000000..e56eee9011
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a GitHub Enterprise Server SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with GitHub Enterprise Server](#configure-integration-with-github-enterprise-server)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/github-enterprise-server/3.md b/snippets/sso-integrations/github-enterprise-server/3.md
new file mode 100644
index 0000000000..b9f952fe03
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **GitHub Enterprise Server**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/github-enterprise-server/4.md b/snippets/sso-integrations/github-enterprise-server/4.md
new file mode 100644
index 0000000000..9337adca49
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login ({YOUR_GITHUB_SERVER_URL}/saml/consume).
        AudienceYour GitHub Enterprise Server URL ({YOUR_GITHUB_SERVER_URL}).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of GitHub Enterprise Server.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/github-enterprise-server/5.md b/snippets/sso-integrations/github-enterprise-server/5.md
new file mode 100644
index 0000000000..4f37806a66
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/5.md
@@ -0,0 +1,3 @@
+### Configure integration with GitHub Enterprise Server
+
+To configure the integration with GitHub Enterprise Server, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/github-enterprise-server/6.md b/snippets/sso-integrations/github-enterprise-server/6.md
new file mode 100644
index 0000000000..95b3f392a4
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/6.md
@@ -0,0 +1,34 @@
+#### GitHub Enterprise Server SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/github-enterprise-server/7.md b/snippets/sso-integrations/github-enterprise-server/7.md
new file mode 100644
index 0000000000..d0bd6e8b03
--- /dev/null
+++ b/snippets/sso-integrations/github-enterprise-server/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to GitHub Enterprise Server. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/google-workspace/0.md b/snippets/sso-integrations/google-workspace/0.md
new file mode 100644
index 0000000000..7c513d5be8
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Google Workspace
+
+The Google Workspace [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for G Suite. Your users log in to Google Workspace with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/google-workspace/1.md b/snippets/sso-integrations/google-workspace/1.md
new file mode 100644
index 0000000000..1785de668f
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Google Workspace account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/google-workspace/2.md b/snippets/sso-integrations/google-workspace/2.md
new file mode 100644
index 0000000000..3043e5f6d6
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a G Suite SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Google Workspace](#configure-integration-with-google-workspace)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/google-workspace/3.md b/snippets/sso-integrations/google-workspace/3.md
new file mode 100644
index 0000000000..ea9a97e3d0
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Google Workspace**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/google-workspace/4.md b/snippets/sso-integrations/google-workspace/4.md
new file mode 100644
index 0000000000..5bc166c6ec
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://www.google.com/a/{domain}/acs).
        AudienceYour Google Workspace URL (https://www.google.com/a/{domain}/acs).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Google Workspace.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/google-workspace/5.md b/snippets/sso-integrations/google-workspace/5.md
new file mode 100644
index 0000000000..53f7473713
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Google Workspace
+
+To configure the integration with Google Workspace, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/google-workspace/6.md b/snippets/sso-integrations/google-workspace/6.md
new file mode 100644
index 0000000000..1284ddaf6b
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/6.md
@@ -0,0 +1,34 @@
+#### Google Workspace SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/google-workspace/7.md b/snippets/sso-integrations/google-workspace/7.md
new file mode 100644
index 0000000000..e901d4a5e6
--- /dev/null
+++ b/snippets/sso-integrations/google-workspace/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Google Workspace. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/heroku/0.md b/snippets/sso-integrations/heroku/0.md
new file mode 100644
index 0000000000..ea68553f61
--- /dev/null
+++ b/snippets/sso-integrations/heroku/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Heroku
+
+The Heroku [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Heroku. Your users log in to Heroku with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/heroku/1.md b/snippets/sso-integrations/heroku/1.md
new file mode 100644
index 0000000000..ca53261626
--- /dev/null
+++ b/snippets/sso-integrations/heroku/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Heroku account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/heroku/2.md b/snippets/sso-integrations/heroku/2.md
new file mode 100644
index 0000000000..972eae56b8
--- /dev/null
+++ b/snippets/sso-integrations/heroku/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Heroku SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Heroku](#configure-integration-with-heroku)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/heroku/3.md b/snippets/sso-integrations/heroku/3.md
new file mode 100644
index 0000000000..d4fc6e7592
--- /dev/null
+++ b/snippets/sso-integrations/heroku/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Heroku**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/heroku/4.md b/snippets/sso-integrations/heroku/4.md
new file mode 100644
index 0000000000..6dd9897330
--- /dev/null
+++ b/snippets/sso-integrations/heroku/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://sso.heroku.com/saml/YOUR-HEROKU-ORG).
        AudienceYour Heroku URL (https://sso.heroku.com/saml/YOUR-HEROKU-ORG).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Heroku.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/heroku/5.md b/snippets/sso-integrations/heroku/5.md
new file mode 100644
index 0000000000..39c65ec87a
--- /dev/null
+++ b/snippets/sso-integrations/heroku/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Heroku
+
+To configure the integration with Heroku, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/heroku/6.md b/snippets/sso-integrations/heroku/6.md
new file mode 100644
index 0000000000..899706e6a1
--- /dev/null
+++ b/snippets/sso-integrations/heroku/6.md
@@ -0,0 +1,34 @@
+#### Heroku SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/heroku/7.md b/snippets/sso-integrations/heroku/7.md
new file mode 100644
index 0000000000..b5aecf4910
--- /dev/null
+++ b/snippets/sso-integrations/heroku/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Heroku. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/hosted-graphite/0.md b/snippets/sso-integrations/hosted-graphite/0.md
new file mode 100644
index 0000000000..a2181639b2
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Hosted Graphite
+
+The Hosted Graphite [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Hosted Graphite. Your users log in to Hosted Graphite with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/hosted-graphite/1.md b/snippets/sso-integrations/hosted-graphite/1.md
new file mode 100644
index 0000000000..b128bb2032
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Hosted Graphite account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/hosted-graphite/2.md b/snippets/sso-integrations/hosted-graphite/2.md
new file mode 100644
index 0000000000..6cbc3fef16
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Hosted Graphite SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Hosted Graphite](#configure-integration-with-hosted-graphite)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/hosted-graphite/3.md b/snippets/sso-integrations/hosted-graphite/3.md
new file mode 100644
index 0000000000..6650e30d28
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Hosted Graphite**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/hosted-graphite/4.md b/snippets/sso-integrations/hosted-graphite/4.md
new file mode 100644
index 0000000000..823be02608
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/).
        AudienceService Provider Entity URL from within Hosted Graphite (https://www.hostedgraphite.com/metadata/{YOUR-USER-ID}/).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Hosted Graphite.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/hosted-graphite/5.md b/snippets/sso-integrations/hosted-graphite/5.md
new file mode 100644
index 0000000000..ac24df7752
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Hosted Graphite
+
+To configure the integration with Hosted Graphite, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/hosted-graphite/6.md b/snippets/sso-integrations/hosted-graphite/6.md
new file mode 100644
index 0000000000..e197705d8d
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/6.md
@@ -0,0 +1,34 @@
+#### Hosted Graphite SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/hosted-graphite/7.md b/snippets/sso-integrations/hosted-graphite/7.md
new file mode 100644
index 0000000000..0e9156c757
--- /dev/null
+++ b/snippets/sso-integrations/hosted-graphite/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Hosted Graphite. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/litmos/0.md b/snippets/sso-integrations/litmos/0.md
new file mode 100644
index 0000000000..3fb4be822f
--- /dev/null
+++ b/snippets/sso-integrations/litmos/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Litmos
+
+The Litmos [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Litmos. Your users log in to Litmos with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/litmos/1.md b/snippets/sso-integrations/litmos/1.md
new file mode 100644
index 0000000000..50e31fe67d
--- /dev/null
+++ b/snippets/sso-integrations/litmos/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Litmos account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/litmos/2.md b/snippets/sso-integrations/litmos/2.md
new file mode 100644
index 0000000000..f93a18f15e
--- /dev/null
+++ b/snippets/sso-integrations/litmos/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Litmos SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Litmos](#configure-integration-with-litmos)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/litmos/3.md b/snippets/sso-integrations/litmos/3.md
new file mode 100644
index 0000000000..77b39e6730
--- /dev/null
+++ b/snippets/sso-integrations/litmos/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Litmos**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/litmos/4.md b/snippets/sso-integrations/litmos/4.md
new file mode 100644
index 0000000000..ac5114c9da
--- /dev/null
+++ b/snippets/sso-integrations/litmos/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://{YOUR DOMAIN}.litmos.com/integration/samllogin).
        DestinationYour Litmos URL (https://{YOUR DOMAIN}.litmos.com/integration/samllogin).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Litmos.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/litmos/5.md b/snippets/sso-integrations/litmos/5.md
new file mode 100644
index 0000000000..971a5ab00f
--- /dev/null
+++ b/snippets/sso-integrations/litmos/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Litmos
+
+To configure the integration with Litmos, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/litmos/6.md b/snippets/sso-integrations/litmos/6.md
new file mode 100644
index 0000000000..78e186a939
--- /dev/null
+++ b/snippets/sso-integrations/litmos/6.md
@@ -0,0 +1,34 @@
+#### Litmos SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
\ No newline at end of file
diff --git a/snippets/sso-integrations/litmos/7.md b/snippets/sso-integrations/litmos/7.md
new file mode 100644
index 0000000000..0fa2b7b7e5
--- /dev/null
+++ b/snippets/sso-integrations/litmos/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Litmos. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/new-relic/0.md b/snippets/sso-integrations/new-relic/0.md
new file mode 100644
index 0000000000..921c6d8120
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for New Relic
+
+The New Relic [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for New Relic. Your users log in to New Relic with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/new-relic/1.md b/snippets/sso-integrations/new-relic/1.md
new file mode 100644
index 0000000000..e5aec59be2
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a New Relic account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/new-relic/2.md b/snippets/sso-integrations/new-relic/2.md
new file mode 100644
index 0000000000..bf6f170e4d
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a New Relic SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with New Relic](#configure-integration-with-new-relic)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/new-relic/3.md b/snippets/sso-integrations/new-relic/3.md
new file mode 100644
index 0000000000..76959c1cdb
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **New Relic**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/new-relic/4.md b/snippets/sso-integrations/new-relic/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/new-relic/5.md b/snippets/sso-integrations/new-relic/5.md
new file mode 100644
index 0000000000..e48144ac86
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/5.md
@@ -0,0 +1,3 @@
+### Configure integration with New Relic
+
+To configure the integration with New Relic, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/new-relic/6.md b/snippets/sso-integrations/new-relic/6.md
new file mode 100644
index 0000000000..629c2c7582
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/6.md
@@ -0,0 +1,34 @@
+#### New Relic SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/new-relic/7.md b/snippets/sso-integrations/new-relic/7.md
new file mode 100644
index 0000000000..64e7755e7e
--- /dev/null
+++ b/snippets/sso-integrations/new-relic/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to New Relic. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/office-365/0.md b/snippets/sso-integrations/office-365/0.md
new file mode 100644
index 0000000000..fecba04332
--- /dev/null
+++ b/snippets/sso-integrations/office-365/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Office 365
+
+The Office 365 [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Office 365. Your users log in to Office 365 with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/office-365/1.md b/snippets/sso-integrations/office-365/1.md
new file mode 100644
index 0000000000..34c79f9f78
--- /dev/null
+++ b/snippets/sso-integrations/office-365/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for an Office 365 account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/office-365/2.md b/snippets/sso-integrations/office-365/2.md
new file mode 100644
index 0000000000..0927900b88
--- /dev/null
+++ b/snippets/sso-integrations/office-365/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure an Office 365 SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Office 365](#configure-integration-with-office-365)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/office-365/3.md b/snippets/sso-integrations/office-365/3.md
new file mode 100644
index 0000000000..0aab7f0ce9
--- /dev/null
+++ b/snippets/sso-integrations/office-365/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Office 365**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/office-365/4.md b/snippets/sso-integrations/office-365/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/office-365/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/office-365/5.md b/snippets/sso-integrations/office-365/5.md
new file mode 100644
index 0000000000..53bf3fcfde
--- /dev/null
+++ b/snippets/sso-integrations/office-365/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Office 365
+
+To configure the integration with Office 365, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/office-365/6.md b/snippets/sso-integrations/office-365/6.md
new file mode 100644
index 0000000000..a544f8f5f6
--- /dev/null
+++ b/snippets/sso-integrations/office-365/6.md
@@ -0,0 +1,27 @@
+#### Office 365 Azure Active Directory Integration
+
+Before you configure Auth0 with Azure AD:
+
+* Make sure you are using an Office 365 edition that supports this integration. Currently, **Midsize** Business and any **Enterprise** [editions of Office 365](https://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx) support SSO with Auth0. 
+* Verify your Office 365 domain through DNS. Follow [Mircrosoft's instructions](https://support.office.com/en-us/article/gather-the-information-you-need-to-create-office-365-dns-records-77f90d4a-dc7f-4f09-8972-c1b03ea85a67).
+* Have one administrator account that you can use to sign in directly into Office 365.
+* Run Microsoft Azure AD Connect between your Active Directory and Office 365 to create your user accounts. You can [download Azure AD Connect from the Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=47594).
+
+:::note
+DirSync was deprecated by Microsoft on April 1, 2021. To learn how to upgrade from DirSync to Azure AD Connect, read [Azure AD Connect: Upgrade from DirSync](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-dirsync-upgrade-get-started).
+:::
+
+**Setup**
+1. Open the Microsoft Azure Active Directory Module for Windows PowerShell.
+2. Provide your Office 365 Service Administrator account credentials.
+    ```
+    $cred = Get-Credential
+    ```
+3. Create a context that connects you to Microsoft Azure AD.
+    ```
+    Connect-MsolService –Credential $cred
+    ```
+4. Change the domain authentication from standard identity to single sign-on.
+    ```
+    Set-MsolDomainAuthentication -DomainName "your-office365domain.com" -FederationBrandName "your-office365domain.com" -Authentication Federated -PassiveLogOnUri "REDACTED" -ActiveLogonUri "REDACTED" -MetadataExchangeUri "REDACTED" -SigningCertificate "REDACTED" -IssuerUri "REDACTED" -LogOffUri "REDACTED" -PreferredAuthenticationProtocol WsFed
+    ```
diff --git a/snippets/sso-integrations/office-365/7.md b/snippets/sso-integrations/office-365/7.md
new file mode 100644
index 0000000000..229ce1e98c
--- /dev/null
+++ b/snippets/sso-integrations/office-365/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Office 365. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/pluralsight/0.md b/snippets/sso-integrations/pluralsight/0.md
new file mode 100644
index 0000000000..08f2fff883
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Pluralsight
+
+The Pluralsight [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Pluralsight. Your users log in to Pluralsight with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/pluralsight/1.md b/snippets/sso-integrations/pluralsight/1.md
new file mode 100644
index 0000000000..6d2a503922
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Pluralsight account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/pluralsight/2.md b/snippets/sso-integrations/pluralsight/2.md
new file mode 100644
index 0000000000..c0b86caa2c
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Pluralsight SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Pluralsight](#configure-integration-with-pluralsight)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/pluralsight/3.md b/snippets/sso-integrations/pluralsight/3.md
new file mode 100644
index 0000000000..2ef71999f8
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Pluralsight**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/pluralsight/4.md b/snippets/sso-integrations/pluralsight/4.md
new file mode 100644
index 0000000000..3bf0659c44
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/4.md
@@ -0,0 +1,4 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, and click **Save**.
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/pluralsight/5.md b/snippets/sso-integrations/pluralsight/5.md
new file mode 100644
index 0000000000..5ed7d9c488
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Pluralsight
+
+To configure the integration with Pluralsight, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/pluralsight/6.md b/snippets/sso-integrations/pluralsight/6.md
new file mode 100644
index 0000000000..7101ae27f1
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/6.md
@@ -0,0 +1,34 @@
+#### Pluralsight SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/pluralsight/7.md b/snippets/sso-integrations/pluralsight/7.md
new file mode 100644
index 0000000000..54754926de
--- /dev/null
+++ b/snippets/sso-integrations/pluralsight/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Pluralsight. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/salesforce/0.md b/snippets/sso-integrations/salesforce/0.md
new file mode 100644
index 0000000000..848930ce66
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Salesforce
+
+The Salesforce [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Salesforce. Your users log in to Salesforce with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/salesforce/1.md b/snippets/sso-integrations/salesforce/1.md
new file mode 100644
index 0000000000..93924c51d1
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Salesforce account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/salesforce/2.md b/snippets/sso-integrations/salesforce/2.md
new file mode 100644
index 0000000000..6f52b5932d
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Salesforce SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Salesforce](#configure-integration-with-salesforce)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/salesforce/3.md b/snippets/sso-integrations/salesforce/3.md
new file mode 100644
index 0000000000..f7edee459c
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Salesforce**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/salesforce/4.md b/snippets/sso-integrations/salesforce/4.md
new file mode 100644
index 0000000000..7220c3f2b5
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Salesforce DomainYour Salesforce Domain.
        Entity IDArbitrary URL that identifies the Salesforce resource.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Salesforce.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/salesforce/5.md b/snippets/sso-integrations/salesforce/5.md
new file mode 100644
index 0000000000..f4d038ae13
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Salesforce
+
+To configure the integration with Salesforce, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/salesforce/6.md b/snippets/sso-integrations/salesforce/6.md
new file mode 100644
index 0000000000..215682cd30
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/6.md
@@ -0,0 +1,59 @@
+#### Salesforce SSO integration
+
+:::note
+Important: This only works on certain [Salesforce editions](http://na15.salesforce.com/help/doc/en/sso_saml.htm). It will not work on trial accounts.
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to Salesforce.
+
+2. Navigate to **Setup** > **Settings** > **Identity** > **Single-Sign-On Settings**.
+
+3. Enable SAML by clicking **Edit**, selecting the **SAML Enabled** checkbox, and clicking **Save**.
+
+4. Click **New** to create a new SAML Single Sign-On Setting, and enter the following settings:
+
+    * **Name**: anything (e.g., `auth0`)
+
+    * **Issuer**:
+    `urn:${account.namespace}`
+    
+    * **Identity Provider Certificate**: 
+    [Download your Auth0 signing certificate](https://${account.namespace}/pem)
+    
+    * **Identity Provider Login URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+    `https://${account.namespace}/samlp/SSO_CLIENT_ID`
+    
+    Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+    ```text
+    https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+    https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+    https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+    ```
+    
+    In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+    * **Entity ID**:
+    `https://test/salesforce.com`
+
+**Other settings**
+
+* **Request Signing Certificate**: Generate self-signed certificate
+* **Request Signature Method**: **RSA-SHA256**
+* **Assertion Decryption Certificate**: Leave default
+* **SAML Identity Type**:
+    * **Assertion** contains the User's Salesforce username: Auth0 will send by default the unique id (`user_id`) of the user as **NameIdentifier** (the default), and Salesforce will match that with the **Username** field. If you want to use the email instead, you can create a rule that maps the email to **NameIdentifier** ([here is an example](https://gist.github.com/woloski/8162612)).
+    * **Assertion** contains the **Federation ID** from the **User** Object: Auth0 will send the unique id (`user_id`) of the user as **NameIdentfier** (the default), and Salesforce will match that with the **Federation ID** field.
+    * **Assertion** contains the **User ID** from the **User** Object: Auth0 will send the unique identifier of the user (as **NameIdentfier**), and Salesforce will match that with the **User ID** field.
+* **SAML Identity Location**: Identity is in the **NameIdentifier** element of the **Subject** statement
+* **Server Provided Initiated Request Binding**: **HTTP POST**
+* **Custom Logout URL**: `https://${account.namespace}/logout`
+* **Custom Error URL**: Leave default
+* **Single Logout Enabled**: Enable this to set the Identity Provider Single Logout URL.
+* **API Name**: Leave default
+* **User Provisioning Enabled**: If checked, users will be just-in-time provisioned the first time they log in.
+
+If you have issues while logging in, you can use the SAML Assertion Validator tool. You will find it on Salesforce Single Sign-On settings page.
diff --git a/snippets/sso-integrations/salesforce/7.md b/snippets/sso-integrations/salesforce/7.md
new file mode 100644
index 0000000000..ff67ac0e1d
--- /dev/null
+++ b/snippets/sso-integrations/salesforce/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Salesforce. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/sentry/0.md b/snippets/sso-integrations/sentry/0.md
new file mode 100644
index 0000000000..bd7d017a34
--- /dev/null
+++ b/snippets/sso-integrations/sentry/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Sentry
+
+The Sentry [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Sentry. Your users log in to Sentry with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/sentry/1.md b/snippets/sso-integrations/sentry/1.md
new file mode 100644
index 0000000000..6ebc7aa93f
--- /dev/null
+++ b/snippets/sso-integrations/sentry/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Sentry account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/sentry/2.md b/snippets/sso-integrations/sentry/2.md
new file mode 100644
index 0000000000..d29f9f5fd4
--- /dev/null
+++ b/snippets/sso-integrations/sentry/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Sentry SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Sentry](#configure-integration-with-sentry)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/sentry/3.md b/snippets/sso-integrations/sentry/3.md
new file mode 100644
index 0000000000..56b66ace14
--- /dev/null
+++ b/snippets/sso-integrations/sentry/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Sentry**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/sentry/4.md b/snippets/sso-integrations/sentry/4.md
new file mode 100644
index 0000000000..9a0ed12800
--- /dev/null
+++ b/snippets/sso-integrations/sentry/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Organization SlugGenerated slug for your Sentry organization found in your URL (for example, the slug for `https://sentry.travel0.com/travel0-org/` would be `travel0-org`).
        Sentry URL PrefixIf you're using Sentry Community Edition, your URL prefix. Otherwise, leave blank.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Sentry.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/sentry/5.md b/snippets/sso-integrations/sentry/5.md
new file mode 100644
index 0000000000..8f9064d153
--- /dev/null
+++ b/snippets/sso-integrations/sentry/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Sentry
+
+To configure the integration with Sentry, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/sentry/6.md b/snippets/sso-integrations/sentry/6.md
new file mode 100644
index 0000000000..91f653cac8
--- /dev/null
+++ b/snippets/sso-integrations/sentry/6.md
@@ -0,0 +1,12 @@
+#### Sentry SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Login to your Sentry organization's **Auth settings** page as an admin.
+
+2. Select **Configure** for the **Auth0** provider.
+
+3. Enter the **Metadata URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
diff --git a/snippets/sso-integrations/sentry/7.md b/snippets/sso-integrations/sentry/7.md
new file mode 100644
index 0000000000..d527851d49
--- /dev/null
+++ b/snippets/sso-integrations/sentry/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Sentry. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/sharepoint/0.md b/snippets/sso-integrations/sharepoint/0.md
new file mode 100644
index 0000000000..f76418a80c
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for SharePoint
+
+The SharePoint [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for SharePoint. Your users log in to SharePoint with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/sharepoint/1.md b/snippets/sso-integrations/sharepoint/1.md
new file mode 100644
index 0000000000..908b040b2a
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a SharePoint account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/sharepoint/2.md b/snippets/sso-integrations/sharepoint/2.md
new file mode 100644
index 0000000000..44e025699f
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a SharePoint SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with SharePoint](#configure-integration-with-sharepoint)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/sharepoint/3.md b/snippets/sso-integrations/sharepoint/3.md
new file mode 100644
index 0000000000..ca03fd891f
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **SharePoint**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/sharepoint/4.md b/snippets/sso-integrations/sharepoint/4.md
new file mode 100644
index 0000000000..44dbaa785b
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        SharePoint URLInternal URL for the SharePoint application.
        External URLs (optional)Comma-separated list of URLs. Only required if the SharePoint application is exposed to the internet.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of SharePoint.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/sharepoint/5.md b/snippets/sso-integrations/sharepoint/5.md
new file mode 100644
index 0000000000..4c8cc62eb6
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/5.md
@@ -0,0 +1,3 @@
+### Configure integration with SharePoint
+
+To configure the integration with SharePoint, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/sharepoint/6.md b/snippets/sso-integrations/sharepoint/6.md
new file mode 100644
index 0000000000..26d15d03c6
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/6.md
@@ -0,0 +1,47 @@
+#### SharePoint SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Open a SharePoint Powershell session, and install the Auth0 PowerShell Module:
+`iex ((new-object net.webclient).DownloadString("https://cdn.auth0.com/sharepoint/install.ps1"))`
+
+2. Enable Auth0 for the SharePoint application by running the following PowerShell command (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration and the SHAREPOINT_URL placeholder with the SharePoint URL you configured earlier in this process):
+```text
+Enable-Auth0 -auth0Domain:"${account.namespace}" -clientId:"SSO_CLIENT_ID" -webAppUrl:"SHAREPOINT_URL" -identifierClaimType:"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -claims:@("Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "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'
+```
+
+:::note
+You can change the claim used to identify the user by modifying the `identifierClaimType` parameter. Also, you can map other claims by changing the `claims` parameter.
+:::
+
+3. Enable the custom claims provider:
+`Enable-ClaimsProvider`
+
+4. Go to **SharePoint Central Admin** > **Security**.
+
+5. Under the **General Security** section, click **Configure Auth0 Claims Provider**, and set the required configuration parameters:
+
+    * **Domain**:
+    `${account.namespace}`
+    
+    * **Client ID**:
+    SSO_CLIENT_ID
+
+    * **Client Secret**:
+    SSO_CLIENT_SECRET
+    
+    * **Identifier User Field**: Specify the property name that will be used to identify the user in the People Picker. By default, we use `Email`. You can see the list of the possible properties at the [User](https://github.com/auth0/auth0.net/blob/master/src/Auth0.ManagementApi/Models/User.cs#L13) and [UserBase](https://github.com/auth0/auth0.net/blob/master/src/Auth0.ManagementApi/Models/UserBase.cs) models.
+
+::: note
+These fields are multi-line fields, allowing you to specify multiple combinations of Domain/Client ID/Client Secret when you want to configure different SharePoint Web Applications with Auth0.
+:::
+
+6. Browse the app.
+
+The module uses the SharePoint PowerShell Cmdlets to configure SharePoint. Here is the [source code](https://github.com/auth0/auth0-sharepoint/tree/master/auth0-authentication-provider).
+
+* **Update**: To update an existing installation to the latest version of the claims provider, you can run `Update-ClaimsProvider`.
+* **Remove**: If you want to remove Auth0 from the web application, run `Disable-Auth0 SHAREPOINT_URL`. Be sure to replace the SHAREPOINT_URL placeholder with ythe SharePoint URL you configured earlier in this process. After that, you can also remove the claims provider by running `Disable-ClaimsProvider`.
+* **Troubleshoot**: To troubleshoot any issues with authentication or the Claims Provider, you can run `Troubleshoot-Auth0` and open a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}) to get help. (Available to customers with an active support plan. See [Auth0’s Support Policy](https://auth0.com/docs/support) for other options.)
\ No newline at end of file
diff --git a/snippets/sso-integrations/sharepoint/7.md b/snippets/sso-integrations/sharepoint/7.md
new file mode 100644
index 0000000000..421ee8cd3b
--- /dev/null
+++ b/snippets/sso-integrations/sharepoint/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to SharePoint. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the switches next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/slack/0.md b/snippets/sso-integrations/slack/0.md
new file mode 100644
index 0000000000..daccd8ec87
--- /dev/null
+++ b/snippets/sso-integrations/slack/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Slack
+
+The Slack [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Slack. Your users log in to Slack with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/slack/1.md b/snippets/sso-integrations/slack/1.md
new file mode 100644
index 0000000000..9d05666519
--- /dev/null
+++ b/snippets/sso-integrations/slack/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Slack account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/slack/2.md b/snippets/sso-integrations/slack/2.md
new file mode 100644
index 0000000000..8066c01b73
--- /dev/null
+++ b/snippets/sso-integrations/slack/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Slack SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Slack](#configure-integration-with-slack)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/slack/3.md b/snippets/sso-integrations/slack/3.md
new file mode 100644
index 0000000000..b148b5584d
--- /dev/null
+++ b/snippets/sso-integrations/slack/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Slack**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/slack/4.md b/snippets/sso-integrations/slack/4.md
new file mode 100644
index 0000000000..206ac8cd02
--- /dev/null
+++ b/snippets/sso-integrations/slack/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Team NameName of your Slack team.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Slack.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/slack/5.md b/snippets/sso-integrations/slack/5.md
new file mode 100644
index 0000000000..095d093c4d
--- /dev/null
+++ b/snippets/sso-integrations/slack/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Slack
+
+To configure the integration with Slack, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/slack/6.md b/snippets/sso-integrations/slack/6.md
new file mode 100644
index 0000000000..f922a79789
--- /dev/null
+++ b/snippets/sso-integrations/slack/6.md
@@ -0,0 +1,31 @@
+#### Slack SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to [Slack Authentication Settings](https://slack.com/admin/auth) as an administrator.
+
+2. Go to **SAML authentication** > **Configure**.
+
+3. For **SAML provider**, choose **Custom SAML 2.0**.
+
+4. Enter the **SAML 2.0 Endpoint (HTTP)** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+5. (Optional) Enter the **Identity Provider Issuer**:
+`urn:${account.namespace}`
+
+6. [Download your Auth0 signing certificate](https://${account.namespace}/pem); copy and paste its contents as the **Public certificate**.
+
+7. Save your configuration.
diff --git a/snippets/sso-integrations/slack/7.md b/snippets/sso-integrations/slack/7.md
new file mode 100644
index 0000000000..99e500efd5
--- /dev/null
+++ b/snippets/sso-integrations/slack/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Slack. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/springcm/0.md b/snippets/sso-integrations/springcm/0.md
new file mode 100644
index 0000000000..c06a03acce
--- /dev/null
+++ b/snippets/sso-integrations/springcm/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for SpringCM
+
+The SpringCM [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for SpringCM. Your users log in to SpringCM with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/springcm/1.md b/snippets/sso-integrations/springcm/1.md
new file mode 100644
index 0000000000..6066a73b29
--- /dev/null
+++ b/snippets/sso-integrations/springcm/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a SpringCM account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/springcm/2.md b/snippets/sso-integrations/springcm/2.md
new file mode 100644
index 0000000000..daa6c4b7c2
--- /dev/null
+++ b/snippets/sso-integrations/springcm/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a SpringCM SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with SpringCM](#configure-integration-with-springcm)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/springcm/3.md b/snippets/sso-integrations/springcm/3.md
new file mode 100644
index 0000000000..a545876d96
--- /dev/null
+++ b/snippets/sso-integrations/springcm/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **SpringCM**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/springcm/4.md b/snippets/sso-integrations/springcm/4.md
new file mode 100644
index 0000000000..42129114eb
--- /dev/null
+++ b/snippets/sso-integrations/springcm/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        SpringCM ACS URLACS URL for your SpringCM.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of SpringCM.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/springcm/5.md b/snippets/sso-integrations/springcm/5.md
new file mode 100644
index 0000000000..c9ca80c854
--- /dev/null
+++ b/snippets/sso-integrations/springcm/5.md
@@ -0,0 +1,3 @@
+### Configure integration with SpringCM
+
+To configure the integration with SpringCM, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/springcm/6.md b/snippets/sso-integrations/springcm/6.md
new file mode 100644
index 0000000000..f43fe0c5eb
--- /dev/null
+++ b/snippets/sso-integrations/springcm/6.md
@@ -0,0 +1,26 @@
+#### SpringCM SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to SpringCM as an admin.
+
+2. Select the **SAML SSO** menu under **Account Preferences**.
+
+3. Enter the **Issuer**:
+`urn:${account.namespace}`
+
+4. Enter the **Service Provider (SP) Initiated Endpoint** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+5. [Download your Auth0 signing certificate](https://${account.namespace}/pem), and upload it to SpringCM. Then select the uploaded file as the **Issuing Certificate**.
\ No newline at end of file
diff --git a/snippets/sso-integrations/springcm/7.md b/snippets/sso-integrations/springcm/7.md
new file mode 100644
index 0000000000..1123fed119
--- /dev/null
+++ b/snippets/sso-integrations/springcm/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to SpringCM. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/sprout-video/0.md b/snippets/sso-integrations/sprout-video/0.md
new file mode 100644
index 0000000000..52cc982e55
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Sprout Video
+
+The Sprout Video [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Sprout Video. Your users log in to Sprout Video with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/sprout-video/1.md b/snippets/sso-integrations/sprout-video/1.md
new file mode 100644
index 0000000000..6487b5b16c
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Sprout Video account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/sprout-video/2.md b/snippets/sso-integrations/sprout-video/2.md
new file mode 100644
index 0000000000..d672277a3e
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Sprout Video SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Sprout Video](#configure-integration-with-sprout-video)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/sprout-video/3.md b/snippets/sso-integrations/sprout-video/3.md
new file mode 100644
index 0000000000..9c61bf5ed1
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Sprout Video**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/sprout-video/4.md b/snippets/sso-integrations/sprout-video/4.md
new file mode 100644
index 0000000000..c6ea0db6af
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        AudienceYour Sprout Video URL (https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Sprout Video.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/sprout-video/5.md b/snippets/sso-integrations/sprout-video/5.md
new file mode 100644
index 0000000000..d4eb24c6e5
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Sprout Video
+
+To configure the integration with Sprout Video, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/sprout-video/6.md b/snippets/sso-integrations/sprout-video/6.md
new file mode 100644
index 0000000000..f24ba06a88
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/6.md
@@ -0,0 +1,34 @@
+#### Sprout Video SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/sprout-video/7.md b/snippets/sso-integrations/sprout-video/7.md
new file mode 100644
index 0000000000..bbf85e031a
--- /dev/null
+++ b/snippets/sso-integrations/sprout-video/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Sprout Video. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/tableau-online/0.md b/snippets/sso-integrations/tableau-online/0.md
new file mode 100644
index 0000000000..1b45079129
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Tableau Online
+
+The Tableau Online [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Tableau Online. Your users log in to Tableau Online with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/tableau-online/1.md b/snippets/sso-integrations/tableau-online/1.md
new file mode 100644
index 0000000000..4e5d6b59a9
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Tableau Online account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/tableau-online/2.md b/snippets/sso-integrations/tableau-online/2.md
new file mode 100644
index 0000000000..db9dc85b99
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Tableau Online SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Tableau Online](#configure-integration-with-tableau-online)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/tableau-online/3.md b/snippets/sso-integrations/tableau-online/3.md
new file mode 100644
index 0000000000..f3ed1af5e1
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Tableau Online**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/tableau-online/4.md b/snippets/sso-integrations/tableau-online/4.md
new file mode 100644
index 0000000000..0f732468c2
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/4.md
@@ -0,0 +1,36 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://sso.online.tableau.com/public/sp/SSO?alias={YOUR TABLEAU ALIAS}).
        AudienceService Provider Entity URL from within Tableau Online (https://sso.online.tableau.com/public/sp/metadata?alias={YOUR TABLEAU ALIAS}).
        RecipientYour Tableau Online URL (https://sso.online.tableau.com/public/sp/SSO?alias={YOUR TABLEAU ALIAS}).
        DestinationYour Tableau Online URL (https://sso.online.tableau.com/public/sp/SSO?alias={YOUR TABLEAU ALIAS}).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Tableau Online.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/tableau-online.png)
diff --git a/snippets/sso-integrations/tableau-online/5.md b/snippets/sso-integrations/tableau-online/5.md
new file mode 100644
index 0000000000..a62e47af1f
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Tableau Online
+
+To configure the integration with Tableau Online, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/tableau-online/6.md b/snippets/sso-integrations/tableau-online/6.md
new file mode 100644
index 0000000000..dee8f6d701
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/6.md
@@ -0,0 +1,34 @@
+#### Tableau Online SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/tableau-online/7.md b/snippets/sso-integrations/tableau-online/7.md
new file mode 100644
index 0000000000..cbe6d1ef03
--- /dev/null
+++ b/snippets/sso-integrations/tableau-online/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Tableau Online. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/tableau-server/0.md b/snippets/sso-integrations/tableau-server/0.md
new file mode 100644
index 0000000000..e40a23a5bb
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Tableau Server
+
+The Tableau Server [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Tableau Server. Your users log in to Tableau Server with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/tableau-server/1.md b/snippets/sso-integrations/tableau-server/1.md
new file mode 100644
index 0000000000..9042d0b577
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Tableau Server account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/tableau-server/2.md b/snippets/sso-integrations/tableau-server/2.md
new file mode 100644
index 0000000000..e5db8030e2
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Tableau Server SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Tableau Server](#configure-integration-with-tableau-server)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/tableau-server/3.md b/snippets/sso-integrations/tableau-server/3.md
new file mode 100644
index 0000000000..9a8e8bef21
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/articles/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Tableau Server**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/tableau-server/4.md b/snippets/sso-integrations/tableau-server/4.md
new file mode 100644
index 0000000000..5afdbcb70d
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/4.md
@@ -0,0 +1,36 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html).
        AudienceYour Tableau Server audience ({YOUR TABLEAU AUDIENCE}).
        RecipientYour Tableau Server URL (http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html).
        DestinationYour Tableau Server URL (http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Tableau Server.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/tableau-server/5.md b/snippets/sso-integrations/tableau-server/5.md
new file mode 100644
index 0000000000..484f9cc3be
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Tableau Server
+
+To configure the integration with Tableau Server, follow the instructions listed in the **Tutorial** view.
\ No newline at end of file
diff --git a/snippets/sso-integrations/tableau-server/6.md b/snippets/sso-integrations/tableau-server/6.md
new file mode 100644
index 0000000000..28d18adfe8
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/6.md
@@ -0,0 +1,34 @@
+#### Tableau Server SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/tableau-server/7.md b/snippets/sso-integrations/tableau-server/7.md
new file mode 100644
index 0000000000..5c951e9f40
--- /dev/null
+++ b/snippets/sso-integrations/tableau-server/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Tableau Server. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/workday/0.md b/snippets/sso-integrations/workday/0.md
new file mode 100644
index 0000000000..7746a31e9e
--- /dev/null
+++ b/snippets/sso-integrations/workday/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Workday
+
+The Workday [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Workday. Your users log in to Workday with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/workday/1.md b/snippets/sso-integrations/workday/1.md
new file mode 100644
index 0000000000..ff6255b0df
--- /dev/null
+++ b/snippets/sso-integrations/workday/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Workday account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/workday/2.md b/snippets/sso-integrations/workday/2.md
new file mode 100644
index 0000000000..023824159e
--- /dev/null
+++ b/snippets/sso-integrations/workday/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Workday SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Workday](#configure-integration-with-workday)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/workday/3.md b/snippets/sso-integrations/workday/3.md
new file mode 100644
index 0000000000..115df77e68
--- /dev/null
+++ b/snippets/sso-integrations/workday/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Workday**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/workday/4.md b/snippets/sso-integrations/workday/4.md
new file mode 100644
index 0000000000..e5b09a0215
--- /dev/null
+++ b/snippets/sso-integrations/workday/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://impl.workday.com//login-saml.html). You may want to change the subdomain `impl` depending on the Workday data center you are using.
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Workday.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/workday/5.md b/snippets/sso-integrations/workday/5.md
new file mode 100644
index 0000000000..21d34895eb
--- /dev/null
+++ b/snippets/sso-integrations/workday/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Workday
+
+To configure the integration with Workday, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/workday/6.md b/snippets/sso-integrations/workday/6.md
new file mode 100644
index 0000000000..908bfdbd46
--- /dev/null
+++ b/snippets/sso-integrations/workday/6.md
@@ -0,0 +1,34 @@
+#### Workday SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/workday/7.md b/snippets/sso-integrations/workday/7.md
new file mode 100644
index 0000000000..6054909a64
--- /dev/null
+++ b/snippets/sso-integrations/workday/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Workday. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/workpath/0.md b/snippets/sso-integrations/workpath/0.md
new file mode 100644
index 0000000000..fb8b10dee8
--- /dev/null
+++ b/snippets/sso-integrations/workpath/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Workpath
+
+The Workpath [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Workpath. Your users log in to Workpath with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/workpath/1.md b/snippets/sso-integrations/workpath/1.md
new file mode 100644
index 0000000000..d019ec2d81
--- /dev/null
+++ b/snippets/sso-integrations/workpath/1.md
@@ -0,0 +1,6 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Workpath account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/workpath/2.md b/snippets/sso-integrations/workpath/2.md
new file mode 100644
index 0000000000..7d7905ac0b
--- /dev/null
+++ b/snippets/sso-integrations/workpath/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Workpath SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Workpath](#configure-integration-with-workpath)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/workpath/3.md b/snippets/sso-integrations/workpath/3.md
new file mode 100644
index 0000000000..c266ca7c20
--- /dev/null
+++ b/snippets/sso-integrations/workpath/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Workpath**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/workpath/4.md b/snippets/sso-integrations/workpath/4.md
new file mode 100644
index 0000000000..d00e43b175
--- /dev/null
+++ b/snippets/sso-integrations/workpath/4.md
@@ -0,0 +1,28 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Callback URLURL to which the user is redirected after login (https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}).
        AudienceService Provider Entity URL from within Workpath (https://api.workpath.com/v1/saml/metadata/{YOUR-WORKPATH-SUBDOMAIN).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Workpath.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/workpath/5.md b/snippets/sso-integrations/workpath/5.md
new file mode 100644
index 0000000000..7b36826214
--- /dev/null
+++ b/snippets/sso-integrations/workpath/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Workpath
+
+To configure the integration with Workpath, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/workpath/6.md b/snippets/sso-integrations/workpath/6.md
new file mode 100644
index 0000000000..2fc92e8713
--- /dev/null
+++ b/snippets/sso-integrations/workpath/6.md
@@ -0,0 +1,34 @@
+#### Workpath SSO integration
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+Provide the following SAML protocol configuration parameters:
+
+* SAML Version:
+`2.0`
+
+* Issuer:
+`urn:${account.namespace}`
+
+* Identity Provider Certificate:
+`https://${account.namespace}/pem`
+
+* Identity Provider SHA1 fingerprint:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+* Identity Provider Login URL (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+* Identity Provider Metadata (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/metadata/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
diff --git a/snippets/sso-integrations/workpath/7.md b/snippets/sso-integrations/workpath/7.md
new file mode 100644
index 0000000000..170ec3dc4d
--- /dev/null
+++ b/snippets/sso-integrations/workpath/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Workpath. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/zendesk/0.md b/snippets/sso-integrations/zendesk/0.md
new file mode 100644
index 0000000000..851f2c7aef
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Zendesk
+
+The Zendesk [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Zendesk. Your users log in to Zendesk with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/zendesk/1.md b/snippets/sso-integrations/zendesk/1.md
new file mode 100644
index 0000000000..f84d165baf
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/1.md
@@ -0,0 +1,10 @@
+## Prerequisites
+
+Before you begin:
+
+* Sign up for a Zendesk account.
+* [Set up a connection](https://auth0.com/docs/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
+
+::: 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.
+:::
diff --git a/snippets/sso-integrations/zendesk/2.md b/snippets/sso-integrations/zendesk/2.md
new file mode 100644
index 0000000000..fd3face6a6
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Zendesk SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Zendesk](#configure-integration-with-zendesk)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/zendesk/3.md b/snippets/sso-integrations/zendesk/3.md
new file mode 100644
index 0000000000..bf3f32b6e1
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Zendesk**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/zendesk/4.md b/snippets/sso-integrations/zendesk/4.md
new file mode 100644
index 0000000000..735fc66f1b
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Zendesk Account NameYour Zendesk 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 Zendesk.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/zendesk/5.md b/snippets/sso-integrations/zendesk/5.md
new file mode 100644
index 0000000000..ebd8573ae1
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Zendesk
+
+To configure the integration with Zendesk, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/zendesk/6.md b/snippets/sso-integrations/zendesk/6.md
new file mode 100644
index 0000000000..7f36c59ecd
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/6.md
@@ -0,0 +1,32 @@
+#### Zendesk SSO integration
+
+:::note
+This integration uses SAML, which works with only [certain versions of Zendesk](https://support.zendesk.com/hc/en-us/articles/203663826-SSO-single-sign-on-options-in-Zendesk).
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. Log in to Zendesk as an administrator.
+
+2. Go to **Security** > **Single sign-on**.
+
+3. For **SAML**, select **Configure**.
+
+4. Select the **Enabled** checkbox.
+
+5. Enter the **SAML SSO URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+6. Enter the **Certificate fingerprint**:
+`A6:14:84:AC:34:55:FA:14:87:19:15:81:67:77:D2:59:EB:13:4B:FC`
+
+7. Enter the **Remote logout URL** (be sure to replace the ACCOUNT_NAME placeholder with your Zendesk account name, which will usually be the first segment in your Zendesk URL (for example, https://{accountname}.zendesk.com)):
+`https://${account.namespace}/v2/logout/?returnTo=https://ACCOUNT_NAME.zendesk.com`
+
+:::note
+You can use any URL for the `returnTo` parameter, but you must set it as an **Allowed Logout URL** in [**Auth0 Dashboard** > **Tenant Settings** > **Advanced**](https://${manage_url}/#/tenant/advanced). The example above uses your Zendesk home.
+:::
+
+8. Click **Save**. SAML SSO is now configured, but it is not automatically enabled for Zendesk users. To allow users to sign in with SSO, [enable external authentication in Zendesk](https://support.zendesk.com/hc/en-us/articles/203663676#topic_b15_1gd_jhb).
\ No newline at end of file
diff --git a/snippets/sso-integrations/zendesk/7.md b/snippets/sso-integrations/zendesk/7.md
new file mode 100644
index 0000000000..e3f2e49e59
--- /dev/null
+++ b/snippets/sso-integrations/zendesk/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Zendesk. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/snippets/sso-integrations/zoom/0.md b/snippets/sso-integrations/zoom/0.md
new file mode 100644
index 0000000000..ce8e967e98
--- /dev/null
+++ b/snippets/sso-integrations/zoom/0.md
@@ -0,0 +1,3 @@
+# Configure SSO Integration for Zoom
+
+The Zoom [Single Sign-on (SSO)](https://auth0.com/docs/sso) Integration creates a client application that uses Auth0 for authentication and provides SSO capabilities for Zoom. Your users log in to Zoom with Auth0 [identity providers](https://auth0.com/docs/identityproviders), which means the identity provider performs the identity credentials verification.
diff --git a/snippets/sso-integrations/zoom/1.md b/snippets/sso-integrations/zoom/1.md
new file mode 100644
index 0000000000..843e5fc77e
--- /dev/null
+++ b/snippets/sso-integrations/zoom/1.md
@@ -0,0 +1,7 @@
+## Prerequisites
+
+Before you begin:
+
+* [Sign up for a Zoom account](https://zoom.us/signup).
+* [Apply for a Vanity URL with Zoom](https://zoom.us/account).
+* [Set up a connection](/identityproviders), which is a source of users. Connections can be databases, social identity providers, or enterprise identity providers, and can be shared among different applications. You may set up more than one connection for use with SSO integrations.
diff --git a/snippets/sso-integrations/zoom/2.md b/snippets/sso-integrations/zoom/2.md
new file mode 100644
index 0000000000..2e90a888b4
--- /dev/null
+++ b/snippets/sso-integrations/zoom/2.md
@@ -0,0 +1,8 @@
+## Steps
+
+To configure a Zoom SSO integration, you will:
+
+1. [Consent to Auth0 SSO integration](#consent-to-auth0-sso-integration)
+2. [Configure Auth0 SSO integration](#create-auth0-sso-integration)
+3. [Configure integration with Zoom](#configure-integration-with-zoom)
+4. [Enable connections](#enable-connections)
diff --git a/snippets/sso-integrations/zoom/3.md b/snippets/sso-integrations/zoom/3.md
new file mode 100644
index 0000000000..84fd451af3
--- /dev/null
+++ b/snippets/sso-integrations/zoom/3.md
@@ -0,0 +1,10 @@
+### Consent to Auth0 SSO integration
+
+1. Navigate to [Auth0 Dashboard > Applications > SSO Integrations](${manage_url}/#/externalapps), and click **+ Create SSO Integration**.
+![Create SSO Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_list.png)
+
+2. Select **Zoom**.
+![Select Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_select-service.png)
+
+3. Click **Continue** to grant the integration access to the listed permissions.
+![Authorize Service](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_consent.png)
diff --git a/snippets/sso-integrations/zoom/4.md b/snippets/sso-integrations/zoom/4.md
new file mode 100644
index 0000000000..bc95cd17fd
--- /dev/null
+++ b/snippets/sso-integrations/zoom/4.md
@@ -0,0 +1,24 @@
+### Configure Auth0 SSO Integration
+
+Enter a name for your SSO Integration, configure the following settings, and click **Save**.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
        SettingDescription
        Zoom Account NameYour Zoom account name. This is the first segment of your Vanity URL (for example, https://{account}.zoom.us).
        Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of Zoom.
        
+
+![Save Integration](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_settings.png)
diff --git a/snippets/sso-integrations/zoom/5.md b/snippets/sso-integrations/zoom/5.md
new file mode 100644
index 0000000000..ed09419530
--- /dev/null
+++ b/snippets/sso-integrations/zoom/5.md
@@ -0,0 +1,3 @@
+### Configure integration with Zoom
+
+To configure the integration with Zoom, follow the instructions listed in the **Tutorial** view.
diff --git a/snippets/sso-integrations/zoom/6.md b/snippets/sso-integrations/zoom/6.md
new file mode 100644
index 0000000000..aedb7de8b2
--- /dev/null
+++ b/snippets/sso-integrations/zoom/6.md
@@ -0,0 +1,34 @@
+#### Zoom SSO integration
+
+:::note
+SAML SSO is available on only [the business edition of Zoom](http://zoom.us/pricing).
+:::
+
+Before you continue, make sure you have your SSO integration Client ID. You will use the Client ID to replace the `SSO_CLIENT_ID` placeholders.
+
+![Locate Client ID](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-tutorial.png)
+
+1. [Log in to Zoom](https://zoom.us/) as an administrator.
+
+2. [Open the SSO configuration panel](https://zoom.us/account/sso).
+
+3. Enter the **Sign-in page URL** (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+`https://${account.namespace}/samlp/SSO_CLIENT_ID`
+
+Alternatively, to log in with a specific identity provider, you can add a `connection` parameter (be sure to replace the SSO_CLIENT_ID placeholder with the Client ID of your SSO Integration):
+
+```text
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=email
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=google-oauth2
+https://${account.namespace}/samlp/SSO_CLIENT_ID?connection=Username-Password-Authentication
+```
+
+In this case, Auth0 will redirect users to the specified connection and will not display the Login widget. Make sure you send the SAMLRequest using `HTTP POST`.
+
+4. Optionally, enter the **Sign-out page URL**:
+`https://${account.namespace}/logout`
+
+5. [Download your Auth0 signing certificate](https://${account.namespace}/pem); copy and paste its contents as the **Identity provider certificate**.
+
+6. Enter the **Issuer**:
+`urn:${account.namespace}`
diff --git a/snippets/sso-integrations/zoom/7.md b/snippets/sso-integrations/zoom/7.md
new file mode 100644
index 0000000000..f2087d01ff
--- /dev/null
+++ b/snippets/sso-integrations/zoom/7.md
@@ -0,0 +1,8 @@
+### Enable connections
+
+Choose the connections to use with your SSO integration. Users in enabled connections will be allowed to log in to Zoom. By default, all configured connections are enabled.
+
+1. Select the **Connections** view.
+
+2. Toggle the sliders next to connection names to enable or disable them.
+![Enable/Disable Connections](https://auth0.com/docs/media/articles/dashboard/sso-integrations/dashboard-integrations-sso-create_view-connections.png)
\ No newline at end of file
diff --git a/updates/2016-06-10.yml b/updates/2016-06-10.yml
index 39e49cdf0f..f3d93fad38 100644
--- a/updates/2016-06-10.yml
+++ b/updates/2016-06-10.yml
@@ -4,7 +4,7 @@ added:
     tags:
       - impersonation
     description: |
-      A [new document](/user-profile/user-impersonation) was added on how to impersonate users.
+      A new document was added on how to impersonate users (deprecated).
 changed:
   -
     title: "Updated User Profile doc"
@@ -15,7 +15,7 @@ changed:
       - unblock user
       - delete user
     description: |
-      Updated [doc](/user-profile) with sections on how to [impersonate a user](/user-profile#impersonating-a-user), [block/unblock a user](/user-profile#blocking-and-unblocking-a-user), and [delete a user](/user-profile#deleting-a-user).
+      Updated [doc](/users/concepts/overview-user-profile) with sections on how to impersonate a user (deprecated), [block/unblock a user](/user-profile#blocking-and-unblocking-a-user), and [delete a user](/user-profile#deleting-a-user).
   -
     title: "Updated Custom Extensions doc"
     tags:
diff --git a/updates/2016-06-21.yml b/updates/2016-06-21.yml
index c11a174ccf..3eeb8343ea 100644
--- a/updates/2016-06-21.yml
+++ b/updates/2016-06-21.yml
@@ -6,7 +6,7 @@ changed:
       - impersonation
       - openid
     description: |
-      Added note at [User Profile](/user-profile) document on how to get a JWT when impersonating a user, using the [impersonation endpoint](/api/authentication#!#post--users--user_id--impersonate). 
+      Added note at [User Profile](users/concepts/overview-user-profile) document on how to get a JWT when impersonating a user, using the [impersonation endpoint](/api/authentication#!#post--users--user_id--impersonate). 
   -
     title: "Updated Java URL"
     tags:
diff --git a/updates/2016-06-22.yml b/updates/2016-06-22.yml
index 1f16b7b24b..f5042d447f 100644
--- a/updates/2016-06-22.yml
+++ b/updates/2016-06-22.yml
@@ -12,4 +12,4 @@ changed:
     description: |
       Updated [Java overview page](/java-overview) with info on new samples:
       - [Auth0 Spring Boot Application with Social and Database Connection, and Account Linking](https://github.com/auth0-samples/auth0-spring-boot-social-dbconnection-link)
-      - [Auth0 (AngularJS) Single Page Application + API Server Sample](https://github.com/auth0-samples/auth0-spring-security-api-client-samples/tree/master/auth0-spring-security-api-angular-client)
+      - [Auth0 (AngularJS) Single-Page Application + API Server Sample](https://github.com/auth0-samples/auth0-spring-security-api-client-samples/tree/master/auth0-spring-security-api-angular-client)
diff --git a/updates/2016-11-02.yml b/updates/2016-11-02.yml
index 7bc9e97236..b7c18f7d1c 100644
--- a/updates/2016-11-02.yml
+++ b/updates/2016-11-02.yml
@@ -5,4 +5,4 @@ added:
       - redirect
       - callback url
     description: |
-       A [new document](/tutorials/redirecting-users) was created on how to handle returning users after authentication.
+       A [new document](/users/guides/redirect-users-after-login) was created on how to handle returning users after authentication.
diff --git a/updates/2017-02-17.yml b/updates/2017-02-17.yml
index c38f8098b6..12db8e28c2 100644
--- a/updates/2017-02-17.yml
+++ b/updates/2017-02-17.yml
@@ -15,7 +15,7 @@ added:
     description: |
       Released new version of [Refresh Tokens (API Authorization)](https://auth0.com/docs/tokens/preview/refresh-token). The legacy version is still in place and you can find it at [Refresh Tokens](https://auth0.com/docs/tokens/refresh-token). The legacy doc will be served as default, with a panel at the top referring to the updated one.
   -
-    title: "New doc on how to verify an access token"
+    title: "New doc on how to verify an Access Token"
     tags:
       - api
       - access_token
diff --git a/updates/2017-04-10.yml b/updates/2017-04-10.yml
index 5a1164416f..c540654f7f 100644
--- a/updates/2017-04-10.yml
+++ b/updates/2017-04-10.yml
@@ -1,6 +1,6 @@
 added:
   -
-    title: "New doc: Why you should always use access tokens to secure an API"
+    title: "New doc: Why you should always use Access Tokens to secure an API"
     tags:
       - API Authorization
       - OAuth 2.0
diff --git a/updates/2017-05-02.yml b/updates/2017-05-02.yml
index 5d9727aec7..afcb234ea5 100644
--- a/updates/2017-05-02.yml
+++ b/updates/2017-05-02.yml
@@ -5,4 +5,4 @@ added:
       - user-profile
       - picture
     description: |
-      A [new doc](https://auth0.com/docs/user-profile/user-picture) was added that explains more about the user picture field and how to use the user_metadata to change it.
+      A [new doc](/users/guides/change-user-pictures) was added that explains more about the user picture field and how to use the user_metadata to change it.
diff --git a/updates/2017-06-15.yml b/updates/2017-06-15.yml
index d8302d9497..5cb1612869 100644
--- a/updates/2017-06-15.yml
+++ b/updates/2017-06-15.yml
@@ -7,4 +7,4 @@ added:
       - p&p
       - implicit grant
     description: |
-      A new doc was added for the [SPA+API architecture scenario](https://auth0.com/docs/architecture-scenarios/application/spa-api). The scenario features a Single Page Application (with an accompanying sample in Angular 2) which talks with an API (sample in Node.js). The application uses OpenID Connect and the OAuth 2.0 Implicit Grant to authorize users with Auth0.
+      A new doc was added for the [SPA+API architecture scenario](https://auth0.com/docs/architecture-scenarios/application/spa-api). The scenario features a Single-Page Application (with an accompanying sample in Angular 2) which talks with an API (sample in Node.js). The application uses OpenID Connect and the OAuth 2.0 Implicit Grant to authorize users with Auth0.
diff --git a/updates/2017-06-23.yml b/updates/2017-06-23.yml
deleted file mode 100644
index 0114127a33..0000000000
--- a/updates/2017-06-23.yml
+++ /dev/null
@@ -1,9 +0,0 @@
-added:
-  -
-    title: "Analytics Integrations"
-    tags:
-      - analytics
-      - facebook
-      - google
-    description: |
-      New docs have was added on how to setup and configure [Google](https://auth0.com/docs/analytics/integrations/google-analytics) and [Facebook](https://auth0.com/docs/analytics/integrations/facebook-analytics) analytics integrations with Auth0.
diff --git a/updates/2017-08-07.yml b/updates/2017-08-07.yml
index 4f63c6a954..d4b981641c 100644
--- a/updates/2017-08-07.yml
+++ b/updates/2017-08-07.yml
@@ -7,4 +7,4 @@ added:
       - api-gatway
       - tutorials
     description: |
-      A [new tutorial](https://auth0.com/docs/integrations/aws-api-gateway) was added on how to secure your API Gateway APIs using custom authorizers that handle Auth0 access tokens.
\ No newline at end of file
+      A [new tutorial](https://auth0.com/docs/integrations/aws-api-gateway) was added on how to secure your API Gateway APIs using custom authorizers that handle Auth0 Access Tokens.
diff --git a/updates/2017-08-16.yml b/updates/2017-08-16.yml
index 9e0cf606d7..53bf86a7c1 100644
--- a/updates/2017-08-16.yml
+++ b/updates/2017-08-16.yml
@@ -5,4 +5,4 @@ changed:
       - refresh_token
       - revoke
     description: |
-      Added the [/oauth/revoke endpoint](https://auth0.com/docs/api/authentication#revoke-refresh-token) at the Authentication API Explorer. It can be used to revoke a refresh token.
\ No newline at end of file
+      Added the [/oauth/revoke endpoint](https://auth0.com/docs/api/authentication#revoke-refresh-token) at the Authentication API Explorer. It can be used to revoke a Refresh Token.
diff --git a/updates/2017-09-08.yml b/updates/2017-09-08.yml
index eac861a6c2..bef04432a7 100644
--- a/updates/2017-09-08.yml
+++ b/updates/2017-09-08.yml
@@ -7,4 +7,4 @@ added:
       - p&p
       - pkce
     description: |
-      A new doc was added for the [Mobile+API architecture scenario](https://auth0.com/docs/architecture-scenarios/application/mobile-api). The scenario features a mobile app (with an accompanying Android sample) which uses an API (sample in Node.js). The application uses OpenID Connect and the [OAuth 2.0 Authorization Code Grant with PKCE](https://auth0.com/docs/api-auth/grant/authorization-code-pkce) to authorize users with Auth0.
+      A new doc was added for the [Mobile+API architecture scenario](/architecture-scenarios/application/mobile-api). The scenario features a mobile app (with an accompanying Android sample) which uses an API (sample in Node.js). The application uses OpenID Connect and the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) to authorize users with Auth0.
diff --git a/updates/2017-11-13.yml b/updates/2017-11-13.yml
index 19f2e631de..b8878ab427 100644
--- a/updates/2017-11-13.yml
+++ b/updates/2017-11-13.yml
@@ -5,11 +5,11 @@ added:
       - migration
       - gigya
     description: |
-      A new document on how to [Migrate Users from Gigya to Auth0](https://auth0.com/docs/users/migrations/gigya) was added.
+      A new document on how to [Migrate Users from Gigya to Auth0](https://auth0.com/docs/users/references/user-migration-scenarios) was added.
   -
     title: "Migrate Users from Stormpath to Auth0"
     tags:
       - migration
       - stormpath
     description: |
-      A new document on how to [Migrate Users from Stormpath to Auth0](https://auth0.com/docs/users/migrations/stormpath) was added.
+      A new document on how to [Migrate Users from Stormpath to Auth0](https://auth0.com/docs/users/references/user-migration-scenarios) was added.
diff --git a/updates/2018-02-15.yml b/updates/2018-02-15.yml
index b914e9fab4..c891de0c2e 100644
--- a/updates/2018-02-15.yml
+++ b/updates/2018-02-15.yml
@@ -4,6 +4,6 @@ added:
     tags:
       - native
       - passwordless
-      - universal login
+      - Universal Login
     description: |
-      A new document, [Native Passwordless with Universal Login](https://auth0.com/docs/connections/passwordless/native-passwordless-universal), was added with instructions on setting up universal login for native applications that require passwordless authentication.
+      A new document, [Native Passwordless with Universal Login](https://auth0.com/docs/connections/passwordless/native-passwordless-universal), was added with instructions on setting up Universal Login for native applications that require passwordless authentication.
diff --git a/updates/2018-02-22.yml b/updates/2018-02-22.yml
index 02979d69a7..6cdd318c7b 100644
--- a/updates/2018-02-22.yml
+++ b/updates/2018-02-22.yml
@@ -6,4 +6,4 @@ added:
       - access control
       - migration
     description: |
-      A new tutorial, [Migrate from Azure Access Control Service to Auth0](https://auth0.com/docs/users/migrations/azure-access-control), was added with instructions on migrating from Azure Access Control to Auth0 and connecting to a WS-Federation identity provider.
+      A new tutorial, [Migrate from Azure Access Control Service to Auth0](https://auth0.com/docs/users/guides/azure-access-control), was added with instructions on migrating from Azure Access Control to Auth0 and connecting to a WS-Federation identity provider.
diff --git a/updates/2018-06-05.yml b/updates/2018-06-05.yml
new file mode 100644
index 0000000000..7540828514
--- /dev/null
+++ b/updates/2018-06-05.yml
@@ -0,0 +1,10 @@
+changed:
+  -
+    title: "Access from a different device or location"
+    tags:
+      - custom mfa
+      - custom multifactor
+      - rules
+      - mfa
+    description: |
+      The rule illustrated in this example is easily circumvented and should not be utilized as a robust control for requiring MFA. Therefore, it has been removed from documentation.
diff --git a/updates/2018-09-07.yml b/updates/2018-09-07.yml
new file mode 100644
index 0000000000..3863b807ce
--- /dev/null
+++ b/updates/2018-09-07.yml
@@ -0,0 +1,39 @@
+added:
+  -
+    title: "Recommended Tenant Settings"
+    tags:
+      - best-practices
+      - tenant
+      - configuration
+    description: |
+      A new document, [Recommended Tenant Settings](https://auth0.com/docs/best-practices/tenant-settings), was added with best practices and tips on tenant configuration.
+  -
+    title: "Recommended Application Settings"
+    tags:
+      - best-practices
+      - application
+      - configuration
+    description: |
+      A new document, [Recommended Application Settings](https://auth0.com/docs/best-practices/application-settings), was added with best practices and tips on application configuration.
+  -
+    title: "Recommended Connection Settings"
+    tags:
+      - best-practices
+      - connection
+      - configuration
+    description: |
+      A new document, [Recommended Connection Settings](https://auth0.com/docs/best-practices/connection-settings), was added with best practices and tips on connection configuration.
+  -
+    title: "Best Practices: General Operations"
+    tags:
+      - best-practices
+      - operations
+    description: |
+      A new document, [Best Practices: General Operations](https://auth0.com/docs/best-practices/operations), was added with best practices on general Auth0 usage and operation.
+  -
+    title: "Best Practices: Rules"
+    tags:
+      - best-practices
+      - rules
+    description: |
+      A new document, [Best Practices: Rules](https://auth0.com/docs/best-practices/rules), was added with best practices for writing and managing rules.
\ No newline at end of file
diff --git a/updates/2018-09-17.yml b/updates/2018-09-17.yml
new file mode 100644
index 0000000000..898e9eb3c5
--- /dev/null
+++ b/updates/2018-09-17.yml
@@ -0,0 +1,8 @@
+added:
+  -
+    title: "Why You Should Update the PSaaS Appliance Regularly"
+    tags:
+      - appliance
+      - admin
+      - updates
+    description: A [guide on why it is important to update the PSaaS Appliance regularly](http://auth0.com/docs/appliance/admin/importance-of-updates) was added.
diff --git a/updates/2018-12-13.yml b/updates/2018-12-13.yml
new file mode 100644
index 0000000000..1627b74086
--- /dev/null
+++ b/updates/2018-12-13.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "Updated tutorial on using Resource Owner Password from Server side"
+    tags:
+      - api-auth
+      - brute-force-protection
+      - whitelist
+    description: Updated [tutorial](https://auth0.com/docs/api-auth/tutorials/using-resource-owner-password-from-server-side#sending-the-end-user-ip-from-your-server) to describe how both the IP address passed as part of the `auth0-forwarded-for` header, and the IP address of the request itself, will be matched against the configured whitelist for brute-force protection wnen sending the end-user IP from your server.
\ No newline at end of file
diff --git a/updates/2019-01-07.yml b/updates/2019-01-07.yml
new file mode 100644
index 0000000000..f7764c7d84
--- /dev/null
+++ b/updates/2019-01-07.yml
@@ -0,0 +1,7 @@
+added:
+  -
+    title: "Added documentation for the Auth0 Deploy CLI Tool"
+    tags:
+      - extensions
+      - deploy-cli
+    description: New documentation has been added describing the Auth0 Deploy CLI tool which allows you to import/export tenant configuration objects.
\ No newline at end of file
diff --git a/updates/2019-03-05.yml b/updates/2019-03-05.yml
new file mode 100644
index 0000000000..174cb84764
--- /dev/null
+++ b/updates/2019-03-05.yml
@@ -0,0 +1,7 @@
+changed:
+  -
+    title: "Updated tutorial on using Resource Owner Password from Server side"
+    tags:
+      - oidc
+      - client-secret
+    description: Updated [tutorial](https://auth0.com/docs/applications/guides/rotate-client-secret-dashboard) to reflect updates to the UI.
diff --git a/updates/2019-03-27.yml b/updates/2019-03-27.yml
new file mode 100644
index 0000000000..5fe402b32a
--- /dev/null
+++ b/updates/2019-03-27.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "API Rate Limits"
+    tags:
+      - api
+      - ratelimits
+    description: |
+      Updated the [Rate Limit Policy](/rate-limits) to reflect the new limits on the `/authorize` path.
diff --git a/updates/2019-04-12.yml b/updates/2019-04-12.yml
new file mode 100644
index 0000000000..2773bb01db
--- /dev/null
+++ b/updates/2019-04-12.yml
@@ -0,0 +1,10 @@
+changed:
+  -
+    title: "Logs - Query Syntax"
+    tags:
+      - logs
+      - log-management
+      - search
+      - query-syntax
+    description: |
+      Updated the [Logs Query Syntax](/logs/query-syntax) to remove temporary limits on the date functionality.
diff --git a/updates/2019-07-01.yml b/updates/2019-07-01.yml
new file mode 100644
index 0000000000..e58312fe41
--- /dev/null
+++ b/updates/2019-07-01.yml
@@ -0,0 +1,26 @@
+changed:
+  -
+    title: "Gradle include file for reusage"
+    tags:
+      - quickstart
+      - android
+    description: |
+      The _auth0.md and the _api_authz.md files were both using redundant and inconsistent gradle instructions. A _gradle file was created on the includes for reusage and consistency.
+fixed:
+  -
+    title: "Android SDK doc used deprecated compile"
+    tags:
+      - android
+      - library
+      - save-and-refresh-tokens
+    description: |
+      The save-and-refresh-tokens.md file used deprecated `compile` instead of `implementation`. To keep consistency the file points to the docs.
+added:
+  -
+    title: "Penetration Testing Policy"
+    tags:
+      - security
+      - policy
+      - penetration testing
+    description: |
+      Update Restrictions for Auth0 Penetration Testing Policy to include Management Dashboard
diff --git a/updates/2019-07-18.yml b/updates/2019-07-18.yml
new file mode 100644
index 0000000000..5f6be11e6d
--- /dev/null
+++ b/updates/2019-07-18.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "API v1 to v2 changes"
+    tags:
+      - guide
+      - api
+    description: |
+      The changes document has been updated to accurately reflect v2 routes that can be used as alternatives to deprecated v1 routes.
diff --git a/updates/2019-10-01.yml b/updates/2019-10-01.yml
new file mode 100644
index 0000000000..7eb7b66106
--- /dev/null
+++ b/updates/2019-10-01.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "Import Users Worker - Filter Duplicate Users"
+    tags:
+      - import
+      - users
+    description: |
+      User import behavior is being updated to allow for upserting users by user_id and username in addition to email.
diff --git a/updates/2019-10-24.yml b/updates/2019-10-24.yml
new file mode 100644
index 0000000000..28fbcad996
--- /dev/null
+++ b/updates/2019-10-24.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "Passwordless connections with hooks"
+    tags:
+      - hooks
+      - passwordless
+    description: |
+      Updated documentation to reflect that passwordless connections now work with the pre-user-registration and post-user-registration hooks.
diff --git a/updates/2019-10-30.yml b/updates/2019-10-30.yml
new file mode 100644
index 0000000000..20d64cf56b
--- /dev/null
+++ b/updates/2019-10-30.yml
@@ -0,0 +1,10 @@
+changed:
+  -
+    title: "Custom password hash"
+    tags:
+      - custom
+      - password
+      - hash
+      - password_hash
+    description: |
+      Updated documentation to reflect that users can now upload users with a broader set of hashed passwords.
diff --git a/updates/2020-01-20.yml b/updates/2020-01-20.yml
new file mode 100644
index 0000000000..90126a7fcc
--- /dev/null
+++ b/updates/2020-01-20.yml
@@ -0,0 +1,8 @@
+changed:
+  -
+    title: "API Rate Limits"
+    tags:
+      - api
+      - ratelimits
+    description: |
+      Updated the [Rate Limit Policy](/rate-limits) to remove limits on the `/authorize` path.
diff --git a/yarn-error.log b/yarn-error.log
new file mode 100644
index 0000000000..32d90dc8cb
--- /dev/null
+++ b/yarn-error.log
@@ -0,0 +1,2723 @@
+Arguments: 
+  /Users/rachelkhoriander/.nvm/versions/node/v12.9.1/bin/node /usr/local/Cellar/yarn/1.5.1_1/libexec/bin/yarn.js dev
+
+PATH: 
+  /Users/rachelkhoriander/.nvm/versions/node/v12.9.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
+
+Yarn version: 
+  1.5.1
+
+Node version: 
+  12.9.1
+
+Platform: 
+  darwin x64
+
+npm manifest: 
+  {
+    "name": "docs",
+    "version": "1.0.0",
+    "description": "This is the repository for the Auth0 documentation.",
+    "author": "Auth0 Inc.",
+    "scripts": {
+      "heroku-prebuild": "bash prebuild.sh",
+      "heroku-postbuild": "bash postbuild.sh",
+      "precommit": "lint-staged"
+    },
+    "lint-staged": {
+      "*.md": "markdownlint"
+    },
+    "engines": {
+      "node": "12.9.1",
+      "yarn": "^1.4.0"
+    },
+    "devDependencies": {
+      "commander": "^2.8.1",
+      "husky": "^0.13.3",
+      "imagemin": "^4.0.0",
+      "imagemin-optipng": "^4.3.0",
+      "lint-staged": "^3.4.2",
+      "markdownlint": "^0.13.0",
+      "markdownlint-cli": "^0.15.0"
+    }
+  }
+
+yarn manifest: 
+  No manifest
+
+Lockfile: 
+  # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
+  # yarn lockfile v1
+  
+  
+  ansi-escapes@^1.0.0:
+    version "1.4.0"
+    resolved "https://registry.yarnpkg.com/ansi-escapes/-/ansi-escapes-1.4.0.tgz#d3a8a83b319aa67793662b13e761c7911422306e"
+    integrity sha1-06ioOzGapneTZisT52HHkRQiMG4=
+  
+  ansi-gray@^0.1.1:
+    version "0.1.1"
+    resolved "https://registry.yarnpkg.com/ansi-gray/-/ansi-gray-0.1.1.tgz#2962cf54ec9792c48510a3deb524436861ef7251"
+    integrity sha1-KWLPVOyXksSFEKPetSRDaGHvclE=
+    dependencies:
+      ansi-wrap "0.1.0"
+  
+  ansi-regex@^2.0.0:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df"
+    integrity sha1-w7M6te42DYbg5ijwRorn7yfWVN8=
+  
+  ansi-styles@^2.2.1:
+    version "2.2.1"
+    resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe"
+    integrity sha1-tDLdM1i2NM914eRmQ2gkBTPB3b4=
+  
+  ansi-wrap@0.1.0:
+    version "0.1.0"
+    resolved "https://registry.yarnpkg.com/ansi-wrap/-/ansi-wrap-0.1.0.tgz#a82250ddb0015e9a27ca82e82ea603bbfa45efaf"
+    integrity sha1-qCJQ3bABXponyoLoLqYDu/pF768=
+  
+  app-root-path@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/app-root-path/-/app-root-path-2.1.0.tgz#98bf6599327ecea199309866e8140368fd2e646a"
+    integrity sha1-mL9lmTJ+zqGZMJhm6BQDaP0uZGo=
+  
+  archive-type@^3.0.0, archive-type@^3.0.1:
+    version "3.2.0"
+    resolved "https://registry.yarnpkg.com/archive-type/-/archive-type-3.2.0.tgz#9cd9c006957ebe95fadad5bd6098942a813737f6"
+    integrity sha1-nNnABpV+vpX62tW9YJiUKoE3N/Y=
+    dependencies:
+      file-type "^3.1.0"
+  
+  argparse@^1.0.7:
+    version "1.0.10"
+    resolved "https://registry.yarnpkg.com/argparse/-/argparse-1.0.10.tgz#bcd6791ea5ae09725e17e5ad988134cd40b3d911"
+    integrity sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==
+    dependencies:
+      sprintf-js "~1.0.2"
+  
+  arr-diff@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/arr-diff/-/arr-diff-2.0.0.tgz#8f3b827f955a8bd669697e4a4256ac3ceae356cf"
+    integrity sha1-jzuCf5Vai9ZpaX5KQlasPOrjVs8=
+    dependencies:
+      arr-flatten "^1.0.1"
+  
+  arr-flatten@^1.0.1:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/arr-flatten/-/arr-flatten-1.1.0.tgz#36048bbff4e7b47e136644316c99669ea5ae91f1"
+    integrity sha512-L3hKV5R/p5o81R7O02IGnwpDmkp6E982XhtbuwSe3O4qOtMMMtodicASA1Cny2U+aCXcNpml+m4dPsvsJ3jatg==
+  
+  array-differ@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/array-differ/-/array-differ-1.0.0.tgz#eff52e3758249d33be402b8bb8e564bb2b5d4031"
+    integrity sha1-7/UuN1gknTO+QCuLuOVkuytdQDE=
+  
+  array-find-index@^1.0.1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/array-find-index/-/array-find-index-1.0.2.tgz#df010aa1287e164bbda6f9723b0a96a1ec4187a1"
+    integrity sha1-3wEKoSh+Fku9pvlyOwqWoexBh6E=
+  
+  array-uniq@^1.0.0, array-uniq@^1.0.2:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/array-uniq/-/array-uniq-1.0.3.tgz#af6ac877a25cc7f74e058894753858dfdb24fdb6"
+    integrity sha1-r2rId6Jcx/dOBYiUdThY39sk/bY=
+  
+  array-unique@^0.2.1:
+    version "0.2.1"
+    resolved "https://registry.yarnpkg.com/array-unique/-/array-unique-0.2.1.tgz#a1d97ccafcbc2625cc70fadceb36a50c58b01a53"
+    integrity sha1-odl8yvy8JiXMcPrc6zalDFiwGlM=
+  
+  async-each-series@^1.1.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/async-each-series/-/async-each-series-1.1.0.tgz#f42fd8155d38f21a5b8ea07c28e063ed1700b138"
+    integrity sha1-9C/YFV048hpbjqB8KOBj7RcAsTg=
+  
+  balanced-match@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.0.tgz#89b4d199ab2bee49de164ea02b89ce462d71b767"
+    integrity sha1-ibTRmasr7kneFk6gK4nORi1xt2c=
+  
+  beeper@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/beeper/-/beeper-1.1.1.tgz#e6d5ea8c5dad001304a70b22638447f69cb2f809"
+    integrity sha1-5tXqjF2tABMEpwsiY4RH9pyy+Ak=
+  
+  bin-build@^2.0.0:
+    version "2.2.0"
+    resolved "https://registry.yarnpkg.com/bin-build/-/bin-build-2.2.0.tgz#11f8dd61f70ffcfa2bdcaa5b46f5e8fedd4221cc"
+    integrity sha1-EfjdYfcP/Por3KpbRvXo/t1CIcw=
+    dependencies:
+      archive-type "^3.0.1"
+      decompress "^3.0.0"
+      download "^4.1.2"
+      exec-series "^1.0.0"
+      rimraf "^2.2.6"
+      tempfile "^1.0.0"
+      url-regex "^3.0.0"
+  
+  bin-check@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/bin-check/-/bin-check-2.0.0.tgz#86f8e6f4253893df60dc316957f5af02acb05930"
+    integrity sha1-hvjm9CU4k99g3DFpV/WvAqywWTA=
+    dependencies:
+      executable "^1.0.0"
+  
+  bin-version-check@^2.1.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/bin-version-check/-/bin-version-check-2.1.0.tgz#e4e5df290b9069f7d111324031efc13fdd11a5b0"
+    integrity sha1-5OXfKQuQaffRETJAMe/BP90RpbA=
+    dependencies:
+      bin-version "^1.0.0"
+      minimist "^1.1.0"
+      semver "^4.0.3"
+      semver-truncate "^1.0.0"
+  
+  bin-version@^1.0.0:
+    version "1.0.4"
+    resolved "https://registry.yarnpkg.com/bin-version/-/bin-version-1.0.4.tgz#9eb498ee6fd76f7ab9a7c160436f89579435d78e"
+    integrity sha1-nrSY7m/Xb3q5p8FgQ2+JV5Q1144=
+    dependencies:
+      find-versions "^1.0.0"
+  
+  bin-wrapper@^3.0.0:
+    version "3.0.2"
+    resolved "https://registry.yarnpkg.com/bin-wrapper/-/bin-wrapper-3.0.2.tgz#67d3306262e4b1a5f2f88ee23464f6a655677aeb"
+    integrity sha1-Z9MwYmLksaXy+I7iNGT2plVneus=
+    dependencies:
+      bin-check "^2.0.0"
+      bin-version-check "^2.1.0"
+      download "^4.0.0"
+      each-async "^1.1.1"
+      lazy-req "^1.0.0"
+      os-filter-obj "^1.0.0"
+  
+  bl@^1.0.0:
+    version "1.2.2"
+    resolved "https://registry.yarnpkg.com/bl/-/bl-1.2.2.tgz#a160911717103c07410cef63ef51b397c025af9c"
+    integrity sha512-e8tQYnZodmebYDWGH7KMRvtzKXaJHx3BbilrgZCfvyLUYdKpK1t5PSPmpkny/SgiTSCnjfLW7v5rlONXVFkQEA==
+    dependencies:
+      readable-stream "^2.3.5"
+      safe-buffer "^5.1.1"
+  
+  brace-expansion@^1.1.7:
+    version "1.1.11"
+    resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
+    integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
+    dependencies:
+      balanced-match "^1.0.0"
+      concat-map "0.0.1"
+  
+  braces@^1.8.2:
+    version "1.8.5"
+    resolved "https://registry.yarnpkg.com/braces/-/braces-1.8.5.tgz#ba77962e12dff969d6b76711e914b737857bf6a7"
+    integrity sha1-uneWLhLf+WnWt2cR6RS3N4V79qc=
+    dependencies:
+      expand-range "^1.8.1"
+      preserve "^0.2.0"
+      repeat-element "^1.1.2"
+  
+  buffer-alloc-unsafe@^1.1.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/buffer-alloc-unsafe/-/buffer-alloc-unsafe-1.1.0.tgz#bd7dc26ae2972d0eda253be061dba992349c19f0"
+    integrity sha512-TEM2iMIEQdJ2yjPJoSIsldnleVaAk1oW3DBVUykyOLsEsFmEc9kn+SFFPz+gl54KQNxlDnAwCXosOS9Okx2xAg==
+  
+  buffer-alloc@^1.2.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/buffer-alloc/-/buffer-alloc-1.2.0.tgz#890dd90d923a873e08e10e5fd51a57e5b7cce0ec"
+    integrity sha512-CFsHQgjtW1UChdXgbyJGtnm+O/uLQeZdtbDo8mfUgYXCHSM1wgrVxXm6bSyrUuErEb+4sYVGCzASBRot7zyrow==
+    dependencies:
+      buffer-alloc-unsafe "^1.1.0"
+      buffer-fill "^1.0.0"
+  
+  buffer-crc32@~0.2.3:
+    version "0.2.13"
+    resolved "https://registry.yarnpkg.com/buffer-crc32/-/buffer-crc32-0.2.13.tgz#0d333e3f00eac50aa1454abd30ef8c2a5d9a7242"
+    integrity sha1-DTM+PwDqxQqhRUq9MO+MKl2ackI=
+  
+  buffer-fill@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/buffer-fill/-/buffer-fill-1.0.0.tgz#f8f78b76789888ef39f205cd637f68e702122b2c"
+    integrity sha1-+PeLdniYiO858gXNY39o5wISKyw=
+  
+  buffer-from@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/buffer-from/-/buffer-from-1.1.1.tgz#32713bc028f75c02fdb710d7c7bcec1f2c6070ef"
+    integrity sha512-MQcXEUbCKtEo7bhqEs6560Hyd4XaovZlO/k9V3hjVUF/zwW7KBVdSK4gIt/bzwS9MbR5qob+F5jusZsb0YQK2A==
+  
+  buffer-to-vinyl@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/buffer-to-vinyl/-/buffer-to-vinyl-1.1.0.tgz#00f15faee3ab7a1dda2cde6d9121bffdd07b2262"
+    integrity sha1-APFfruOreh3aLN5tkSG//dB7ImI=
+    dependencies:
+      file-type "^3.1.0"
+      readable-stream "^2.0.2"
+      uuid "^2.0.1"
+      vinyl "^1.0.0"
+  
+  camelcase-keys@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/camelcase-keys/-/camelcase-keys-2.1.0.tgz#308beeaffdf28119051efa1d932213c91b8f92e7"
+    integrity sha1-MIvur/3ygRkFHvodkyITyRuPkuc=
+    dependencies:
+      camelcase "^2.0.0"
+      map-obj "^1.0.0"
+  
+  camelcase@^2.0.0:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/camelcase/-/camelcase-2.1.1.tgz#7c1d16d679a1bbe59ca02cacecfb011e201f5a1f"
+    integrity sha1-fB0W1nmhu+WcoCys7PsBHiAfWh8=
+  
+  capture-stack-trace@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/capture-stack-trace/-/capture-stack-trace-1.0.1.tgz#a6c0bbe1f38f3aa0b92238ecb6ff42c344d4135d"
+    integrity sha512-mYQLZnx5Qt1JgB1WEiMCf2647plpGeQ2NMR/5L0HNZzGQo4fuSPnK+wjfPnKZV0aiJDgzmWqqkV/g7JD+DW0qw==
+  
+  caw@^1.0.1:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/caw/-/caw-1.2.0.tgz#ffb226fe7efc547288dc62ee3e97073c212d1034"
+    integrity sha1-/7Im/n78VHKI3GLuPpcHPCEtEDQ=
+    dependencies:
+      get-proxy "^1.0.1"
+      is-obj "^1.0.0"
+      object-assign "^3.0.0"
+      tunnel-agent "^0.4.0"
+  
+  chalk@^1.0.0, chalk@^1.1.1, chalk@^1.1.3:
+    version "1.1.3"
+    resolved "https://registry.yarnpkg.com/chalk/-/chalk-1.1.3.tgz#a8115c55e4a702fe4d150abd3872822a7e09fc98"
+    integrity sha1-qBFcVeSnAv5NFQq9OHKCKn4J/Jg=
+    dependencies:
+      ansi-styles "^2.2.1"
+      escape-string-regexp "^1.0.2"
+      has-ansi "^2.0.0"
+      strip-ansi "^3.0.0"
+      supports-color "^2.0.0"
+  
+  ci-info@^1.5.0:
+    version "1.6.0"
+    resolved "https://registry.yarnpkg.com/ci-info/-/ci-info-1.6.0.tgz#2ca20dbb9ceb32d4524a683303313f0304b1e497"
+    integrity sha512-vsGdkwSCDpWmP80ncATX7iea5DWQemg1UgCW5J8tqjU3lYw4FBYuj89J0CTVomA7BEfvSZd84GmHko+MxFQU2A==
+  
+  clap@^1.0.9:
+    version "1.2.3"
+    resolved "https://registry.yarnpkg.com/clap/-/clap-1.2.3.tgz#4f36745b32008492557f46412d66d50cb99bce51"
+    integrity sha512-4CoL/A3hf90V3VIEjeuhSvlGFEHKzOz+Wfc2IVZc+FaUgU0ZQafJTP49fvnULipOPcAfqhyI2duwQyns6xqjYA==
+    dependencies:
+      chalk "^1.1.3"
+  
+  cli-cursor@^1.0.2:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/cli-cursor/-/cli-cursor-1.0.2.tgz#64da3f7d56a54412e59794bd62dc35295e8f2987"
+    integrity sha1-ZNo/fValRBLll5S9Ytw1KV6PKYc=
+    dependencies:
+      restore-cursor "^1.0.1"
+  
+  cli-spinners@^0.1.2:
+    version "0.1.2"
+    resolved "https://registry.yarnpkg.com/cli-spinners/-/cli-spinners-0.1.2.tgz#bb764d88e185fb9e1e6a2a1f19772318f605e31c"
+    integrity sha1-u3ZNiOGF+54eaiofGXcjGPYF4xw=
+  
+  cli-truncate@^0.2.1:
+    version "0.2.1"
+    resolved "https://registry.yarnpkg.com/cli-truncate/-/cli-truncate-0.2.1.tgz#9f15cfbb0705005369216c626ac7d05ab90dd574"
+    integrity sha1-nxXPuwcFAFNpIWxiasfQWrkN1XQ=
+    dependencies:
+      slice-ansi "0.0.4"
+      string-width "^1.0.1"
+  
+  clone-stats@^0.0.1:
+    version "0.0.1"
+    resolved "https://registry.yarnpkg.com/clone-stats/-/clone-stats-0.0.1.tgz#b88f94a82cf38b8791d58046ea4029ad88ca99d1"
+    integrity sha1-uI+UqCzzi4eR1YBG6kAprYjKmdE=
+  
+  clone@^0.2.0:
+    version "0.2.0"
+    resolved "https://registry.yarnpkg.com/clone/-/clone-0.2.0.tgz#c6126a90ad4f72dbf5acdb243cc37724fe93fc1f"
+    integrity sha1-xhJqkK1Pctv1rNskPMN3JP6T/B8=
+  
+  clone@^1.0.0:
+    version "1.0.4"
+    resolved "https://registry.yarnpkg.com/clone/-/clone-1.0.4.tgz#da309cc263df15994c688ca902179ca3c7cd7c7e"
+    integrity sha1-2jCcwmPfFZlMaIypAheco8fNfH4=
+  
+  co@3.1.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/co/-/co-3.1.0.tgz#4ea54ea5a08938153185e15210c68d9092bc1b78"
+    integrity sha1-TqVOpaCJOBUxheFSEMaNkJK8G3g=
+  
+  coa@~1.0.1:
+    version "1.0.4"
+    resolved "https://registry.yarnpkg.com/coa/-/coa-1.0.4.tgz#a9ef153660d6a86a8bdec0289a5c684d217432fd"
+    integrity sha1-qe8VNmDWqGqL3sAomlxoTSF0Mv0=
+    dependencies:
+      q "^1.1.2"
+  
+  code-point-at@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/code-point-at/-/code-point-at-1.1.0.tgz#0d070b4d043a5bea33a2f1a40e2edb3d9a4ccf77"
+    integrity sha1-DQcLTQQ6W+ozovGkDi7bPZpMz3c=
+  
+  color-support@^1.1.3:
+    version "1.1.3"
+    resolved "https://registry.yarnpkg.com/color-support/-/color-support-1.1.3.tgz#93834379a1cc9a0c61f82f52f0d04322251bd5a2"
+    integrity sha512-qiBjkpbMLO/HL68y+lh4q0/O1MZFj2RX6X/KmMa3+gJD3z+WwI1ZzDHysvqHGS3mP6mznPckpXmw1nI9cJjyRg==
+  
+  colors@~1.1.2:
+    version "1.1.2"
+    resolved "https://registry.yarnpkg.com/colors/-/colors-1.1.2.tgz#168a4701756b6a7f51a12ce0c97bfa28c084ed63"
+    integrity sha1-FopHAXVran9RoSzgyXv6KMCE7WM=
+  
+  commander@^2.8.1, commander@^2.9.0:
+    version "2.19.0"
+    resolved "https://registry.yarnpkg.com/commander/-/commander-2.19.0.tgz#f6198aa84e5b83c46054b94ddedbfed5ee9ff12a"
+    integrity sha512-6tvAOO+D6OENvRAh524Dh9jcfKTYDQAqvqezbCW82xj5X0pSrcpxtvRKHLG0yBY6SD7PSDrJaj+0AiOcKVd1Xg==
+  
+  commander@~2.8.1:
+    version "2.8.1"
+    resolved "https://registry.yarnpkg.com/commander/-/commander-2.8.1.tgz#06be367febfda0c330aa1e2a072d3dc9762425d4"
+    integrity sha1-Br42f+v9oMMwqh4qBy09yXYkJdQ=
+    dependencies:
+      graceful-readlink ">= 1.0.0"
+  
+  commander@~2.9.0:
+    version "2.9.0"
+    resolved "https://registry.yarnpkg.com/commander/-/commander-2.9.0.tgz#9c99094176e12240cb22d6c5146098400fe0f7d4"
+    integrity sha1-nJkJQXbhIkDLItbFFGCYQA/g99Q=
+    dependencies:
+      graceful-readlink ">= 1.0.0"
+  
+  concat-map@0.0.1:
+    version "0.0.1"
+    resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
+    integrity sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=
+  
+  concat-stream@^1.4.6, concat-stream@^1.4.7:
+    version "1.6.2"
+    resolved "https://registry.yarnpkg.com/concat-stream/-/concat-stream-1.6.2.tgz#904bdf194cd3122fc675c77fc4ac3d4ff0fd1a34"
+    integrity sha512-27HBghJxjiZtIk3Ycvn/4kbJk/1uZuJFfuPEns6LaEvpvG1f0hTea8lilrouyo9mVc2GWdcEZ8OLoGmSADlrCw==
+    dependencies:
+      buffer-from "^1.0.0"
+      inherits "^2.0.3"
+      readable-stream "^2.2.2"
+      typedarray "^0.0.6"
+  
+  console-stream@^0.1.1:
+    version "0.1.1"
+    resolved "https://registry.yarnpkg.com/console-stream/-/console-stream-0.1.1.tgz#a095fe07b20465955f2fafd28b5d72bccd949d44"
+    integrity sha1-oJX+B7IEZZVfL6/Si11yvM2UnUQ=
+  
+  convert-source-map@^1.1.1:
+    version "1.6.0"
+    resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.6.0.tgz#51b537a8c43e0f04dec1993bffcdd504e758ac20"
+    integrity sha512-eFu7XigvxdZ1ETfbgPBohgyQ/Z++C0eEhTor0qRwBw9unw+L0/6V8wkSuGgzdThkiS5lSpdptOQPD8Ak40a+7A==
+    dependencies:
+      safe-buffer "~5.1.1"
+  
+  core-util-is@~1.0.0:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/core-util-is/-/core-util-is-1.0.2.tgz#b5fd54220aa2bc5ab57aab7140c940754503c1a7"
+    integrity sha1-tf1UIgqivFq1eqtxQMlAdUUDwac=
+  
+  cosmiconfig@^1.1.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/cosmiconfig/-/cosmiconfig-1.1.0.tgz#0dea0f9804efdfb929fbb1b188e25553ea053d37"
+    integrity sha1-DeoPmATv37kp+7GxiOJVU+oFPTc=
+    dependencies:
+      graceful-fs "^4.1.2"
+      js-yaml "^3.4.3"
+      minimist "^1.2.0"
+      object-assign "^4.0.1"
+      os-homedir "^1.0.1"
+      parse-json "^2.2.0"
+      pinkie-promise "^2.0.0"
+      require-from-string "^1.1.0"
+  
+  create-error-class@^3.0.1:
+    version "3.0.2"
+    resolved "https://registry.yarnpkg.com/create-error-class/-/create-error-class-3.0.2.tgz#06be7abef947a3f14a30fd610671d401bca8b7b6"
+    integrity sha1-Br56vvlHo/FKMP1hBnHUAbyot7Y=
+    dependencies:
+      capture-stack-trace "^1.0.0"
+  
+  cross-spawn@^5.0.1:
+    version "5.1.0"
+    resolved "https://registry.yarnpkg.com/cross-spawn/-/cross-spawn-5.1.0.tgz#e8bd0efee58fcff6f8f94510a0a554bbfa235449"
+    integrity sha1-6L0O/uWPz/b4+UUQoKVUu/ojVEk=
+    dependencies:
+      lru-cache "^4.0.1"
+      shebang-command "^1.2.0"
+      which "^1.2.9"
+  
+  csso@~2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/csso/-/csso-2.0.0.tgz#178b43a44621221c27756086f531e02f42900ee8"
+    integrity sha1-F4tDpEYhIhwndWCG9THgL0KQDug=
+    dependencies:
+      clap "^1.0.9"
+      source-map "^0.5.3"
+  
+  currently-unhandled@^0.4.1:
+    version "0.4.1"
+    resolved "https://registry.yarnpkg.com/currently-unhandled/-/currently-unhandled-0.4.1.tgz#988df33feab191ef799a61369dd76c17adf957ea"
+    integrity sha1-mI3zP+qxke95mmE2nddsF635V+o=
+    dependencies:
+      array-find-index "^1.0.1"
+  
+  date-fns@^1.27.2:
+    version "1.30.1"
+    resolved "https://registry.yarnpkg.com/date-fns/-/date-fns-1.30.1.tgz#2e71bf0b119153dbb4cc4e88d9ea5acfb50dc05c"
+    integrity sha512-hBSVCvSmWC+QypYObzwGOd9wqdDpOt+0wl0KbU+R+uuZBS1jN8VsD1ss3irQDknRj5NvxiTF6oj/nDRnN/UQNw==
+  
+  dateformat@^2.0.0:
+    version "2.2.0"
+    resolved "https://registry.yarnpkg.com/dateformat/-/dateformat-2.2.0.tgz#4065e2013cf9fb916ddfd82efb506ad4c6769062"
+    integrity sha1-QGXiATz5+5Ft39gu+1Bq1MZ2kGI=
+  
+  decamelize@^1.1.2:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/decamelize/-/decamelize-1.2.0.tgz#f6534d15148269b20352e7bee26f501f9a191290"
+    integrity sha1-9lNNFRSCabIDUue+4m9QH5oZEpA=
+  
+  decompress-tar@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/decompress-tar/-/decompress-tar-3.1.0.tgz#217c789f9b94450efaadc5c5e537978fc333c466"
+    integrity sha1-IXx4n5uURQ76rcXF5TeXj8MzxGY=
+    dependencies:
+      is-tar "^1.0.0"
+      object-assign "^2.0.0"
+      strip-dirs "^1.0.0"
+      tar-stream "^1.1.1"
+      through2 "^0.6.1"
+      vinyl "^0.4.3"
+  
+  decompress-tarbz2@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/decompress-tarbz2/-/decompress-tarbz2-3.1.0.tgz#8b23935681355f9f189d87256a0f8bdd96d9666d"
+    integrity sha1-iyOTVoE1X58YnYclag+L3ZbZZm0=
+    dependencies:
+      is-bzip2 "^1.0.0"
+      object-assign "^2.0.0"
+      seek-bzip "^1.0.3"
+      strip-dirs "^1.0.0"
+      tar-stream "^1.1.1"
+      through2 "^0.6.1"
+      vinyl "^0.4.3"
+  
+  decompress-targz@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/decompress-targz/-/decompress-targz-3.1.0.tgz#b2c13df98166268991b715d6447f642e9696f5a0"
+    integrity sha1-ssE9+YFmJomRtxXWRH9kLpaW9aA=
+    dependencies:
+      is-gzip "^1.0.0"
+      object-assign "^2.0.0"
+      strip-dirs "^1.0.0"
+      tar-stream "^1.1.1"
+      through2 "^0.6.1"
+      vinyl "^0.4.3"
+  
+  decompress-unzip@^3.0.0:
+    version "3.4.0"
+    resolved "https://registry.yarnpkg.com/decompress-unzip/-/decompress-unzip-3.4.0.tgz#61475b4152066bbe3fee12f9d629d15fe6478eeb"
+    integrity sha1-YUdbQVIGa74/7hL51inRX+ZHjus=
+    dependencies:
+      is-zip "^1.0.0"
+      read-all-stream "^3.0.0"
+      stat-mode "^0.2.0"
+      strip-dirs "^1.0.0"
+      through2 "^2.0.0"
+      vinyl "^1.0.0"
+      yauzl "^2.2.1"
+  
+  decompress@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/decompress/-/decompress-3.0.0.tgz#af1dd50d06e3bfc432461d37de11b38c0d991bed"
+    integrity sha1-rx3VDQbjv8QyRh033hGzjA2ZG+0=
+    dependencies:
+      buffer-to-vinyl "^1.0.0"
+      concat-stream "^1.4.6"
+      decompress-tar "^3.0.0"
+      decompress-tarbz2 "^3.0.0"
+      decompress-targz "^3.0.0"
+      decompress-unzip "^3.0.0"
+      stream-combiner2 "^1.1.1"
+      vinyl-assign "^1.0.1"
+      vinyl-fs "^2.2.0"
+  
+  deep-extend@^0.6.0:
+    version "0.6.0"
+    resolved "https://registry.yarnpkg.com/deep-extend/-/deep-extend-0.6.0.tgz#c4fa7c95404a17a9c3e8ca7e1537312b736330ac"
+    integrity sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==
+  
+  deep-extend@~0.5.1:
+    version "0.5.1"
+    resolved "https://registry.yarnpkg.com/deep-extend/-/deep-extend-0.5.1.tgz#b894a9dd90d3023fbf1c55a394fb858eb2066f1f"
+    integrity sha512-N8vBdOa+DF7zkRrDCsaOXoCs/E2fJfx9B9MrKnnSiHNh4ws7eSys6YQE4KvT1cecKmOASYQBhbKjeuDD9lT81w==
+  
+  download@^4.0.0, download@^4.1.2:
+    version "4.4.3"
+    resolved "https://registry.yarnpkg.com/download/-/download-4.4.3.tgz#aa55fdad392d95d4b68e8c2be03e0c2aa21ba9ac"
+    integrity sha1-qlX9rTktldS2jowr4D4MKqIbqaw=
+    dependencies:
+      caw "^1.0.1"
+      concat-stream "^1.4.7"
+      each-async "^1.0.0"
+      filenamify "^1.0.1"
+      got "^5.0.0"
+      gulp-decompress "^1.2.0"
+      gulp-rename "^1.2.0"
+      is-url "^1.2.0"
+      object-assign "^4.0.1"
+      read-all-stream "^3.0.0"
+      readable-stream "^2.0.2"
+      stream-combiner2 "^1.1.1"
+      vinyl "^1.0.0"
+      vinyl-fs "^2.2.0"
+      ware "^1.2.0"
+  
+  duplexer2@0.0.2:
+    version "0.0.2"
+    resolved "https://registry.yarnpkg.com/duplexer2/-/duplexer2-0.0.2.tgz#c614dcf67e2fb14995a91711e5a617e8a60a31db"
+    integrity sha1-xhTc9n4vsUmVqRcR5aYX6KYKMds=
+    dependencies:
+      readable-stream "~1.1.9"
+  
+  duplexer2@^0.1.4, duplexer2@~0.1.0:
+    version "0.1.4"
+    resolved "https://registry.yarnpkg.com/duplexer2/-/duplexer2-0.1.4.tgz#8b12dab878c0d69e3e7891051662a32fc6bddcc1"
+    integrity sha1-ixLauHjA1p4+eJEFFmKjL8a93ME=
+    dependencies:
+      readable-stream "^2.0.2"
+  
+  duplexify@^3.2.0:
+    version "3.7.1"
+    resolved "https://registry.yarnpkg.com/duplexify/-/duplexify-3.7.1.tgz#2a4df5317f6ccfd91f86d6fd25d8d8a103b88309"
+    integrity sha512-07z8uv2wMyS51kKhD1KsdXJg5WQ6t93RneqRxUHnskXVtlYYkLqM0gqStQZ3pj073g687jPCHrqNfCzawLYh5g==
+    dependencies:
+      end-of-stream "^1.0.0"
+      inherits "^2.0.1"
+      readable-stream "^2.0.0"
+      stream-shift "^1.0.0"
+  
+  each-async@^1.0.0, each-async@^1.1.1:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/each-async/-/each-async-1.1.1.tgz#dee5229bdf0ab6ba2012a395e1b869abf8813473"
+    integrity sha1-3uUim98KtrogEqOV4bhpq/iBNHM=
+    dependencies:
+      onetime "^1.0.0"
+      set-immediate-shim "^1.0.0"
+  
+  elegant-spinner@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/elegant-spinner/-/elegant-spinner-1.0.1.tgz#db043521c95d7e303fd8f345bedc3349cfb0729e"
+    integrity sha1-2wQ1IcldfjA/2PNFvtwzSc+wcp4=
+  
+  end-of-stream@^1.0.0:
+    version "1.4.1"
+    resolved "https://registry.yarnpkg.com/end-of-stream/-/end-of-stream-1.4.1.tgz#ed29634d19baba463b6ce6b80a37213eab71ec43"
+    integrity sha512-1MkrZNvWTKCaigbn+W15elq2BB/L22nqrSY5DKlo3X6+vclJm8Bb5djXJBmEX6fS3+zCh/F4VBK5Z2KxJt4s2Q==
+    dependencies:
+      once "^1.4.0"
+  
+  entities@~1.1.1:
+    version "1.1.2"
+    resolved "https://registry.yarnpkg.com/entities/-/entities-1.1.2.tgz#bdfa735299664dfafd34529ed4f8522a275fea56"
+    integrity sha512-f2LZMYl1Fzu7YSBKg+RoROelpOaNrcGmE9AZubeDfrCEia483oW4MI4VyFd5VNHIgQ/7qm1I0wUHK1eJnn2y2w==
+  
+  error-ex@^1.2.0:
+    version "1.3.2"
+    resolved "https://registry.yarnpkg.com/error-ex/-/error-ex-1.3.2.tgz#b4ac40648107fdcdcfae242f428bea8a14d4f1bf"
+    integrity sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==
+    dependencies:
+      is-arrayish "^0.2.1"
+  
+  escape-string-regexp@^1.0.2, escape-string-regexp@^1.0.5:
+    version "1.0.5"
+    resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz#1b61c0562190a8dff6ae3bb2cf0200ca130b86d4"
+    integrity sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=
+  
+  esprima@^2.6.0:
+    version "2.7.3"
+    resolved "https://registry.yarnpkg.com/esprima/-/esprima-2.7.3.tgz#96e3b70d5779f6ad49cd032673d1c312767ba581"
+    integrity sha1-luO3DVd59q1JzQMmc9HDEnZ7pYE=
+  
+  esprima@^4.0.0:
+    version "4.0.1"
+    resolved "https://registry.yarnpkg.com/esprima/-/esprima-4.0.1.tgz#13b04cdb3e6c5d19df91ab6987a8695619b0aa71"
+    integrity sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==
+  
+  exec-buffer@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/exec-buffer/-/exec-buffer-2.0.1.tgz#0028a31be0b1460b61d075f96af4583b9e335ea0"
+    integrity sha1-ACijG+CxRgth0HX5avRYO54zXqA=
+    dependencies:
+      rimraf "^2.2.6"
+      tempfile "^1.0.0"
+  
+  exec-series@^1.0.0:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/exec-series/-/exec-series-1.0.3.tgz#6d257a9beac482a872c7783bc8615839fc77143a"
+    integrity sha1-bSV6m+rEgqhyx3g7yGFYOfx3FDo=
+    dependencies:
+      async-each-series "^1.1.0"
+      object-assign "^4.1.0"
+  
+  execa@^0.7.0:
+    version "0.7.0"
+    resolved "https://registry.yarnpkg.com/execa/-/execa-0.7.0.tgz#944becd34cc41ee32a63a9faf27ad5a65fc59777"
+    integrity sha1-lEvs00zEHuMqY6n68nrVpl/Fl3c=
+    dependencies:
+      cross-spawn "^5.0.1"
+      get-stream "^3.0.0"
+      is-stream "^1.1.0"
+      npm-run-path "^2.0.0"
+      p-finally "^1.0.0"
+      signal-exit "^3.0.0"
+      strip-eof "^1.0.0"
+  
+  executable@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/executable/-/executable-1.1.0.tgz#877980e9112f3391066da37265de7ad8434ab4d9"
+    integrity sha1-h3mA6REvM5EGbaNyZd562ENKtNk=
+    dependencies:
+      meow "^3.1.0"
+  
+  exit-hook@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/exit-hook/-/exit-hook-1.1.1.tgz#f05ca233b48c05d54fff07765df8507e95c02ff8"
+    integrity sha1-8FyiM7SMBdVP/wd2XfhQfpXAL/g=
+  
+  expand-brackets@^0.1.4:
+    version "0.1.5"
+    resolved "https://registry.yarnpkg.com/expand-brackets/-/expand-brackets-0.1.5.tgz#df07284e342a807cd733ac5af72411e581d1177b"
+    integrity sha1-3wcoTjQqgHzXM6xa9yQR5YHRF3s=
+    dependencies:
+      is-posix-bracket "^0.1.0"
+  
+  expand-range@^1.8.1:
+    version "1.8.2"
+    resolved "https://registry.yarnpkg.com/expand-range/-/expand-range-1.8.2.tgz#a299effd335fe2721ebae8e257ec79644fc85337"
+    integrity sha1-opnv/TNf4nIeuujiV+x5ZE/IUzc=
+    dependencies:
+      fill-range "^2.1.0"
+  
+  extend-shallow@^2.0.1:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/extend-shallow/-/extend-shallow-2.0.1.tgz#51af7d614ad9a9f610ea1bafbb989d6b1c56890f"
+    integrity sha1-Ua99YUrZqfYQ6huvu5idaxxWiQ8=
+    dependencies:
+      is-extendable "^0.1.0"
+  
+  extend@^3.0.0:
+    version "3.0.2"
+    resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.2.tgz#f8b1136b4071fbd8eb140aff858b1019ec2915fa"
+    integrity sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==
+  
+  extglob@^0.3.1:
+    version "0.3.2"
+    resolved "https://registry.yarnpkg.com/extglob/-/extglob-0.3.2.tgz#2e18ff3d2f49ab2765cec9023f011daa8d8349a1"
+    integrity sha1-Lhj/PS9JqydlzskCPwEdqo2DSaE=
+    dependencies:
+      is-extglob "^1.0.0"
+  
+  fancy-log@^1.1.0:
+    version "1.3.3"
+    resolved "https://registry.yarnpkg.com/fancy-log/-/fancy-log-1.3.3.tgz#dbc19154f558690150a23953a0adbd035be45fc7"
+    integrity sha512-k9oEhlyc0FrVh25qYuSELjr8oxsCoc4/LEZfg2iJJrfEk/tZL9bCoJE47gqAvI2m/AUjluCS4+3I0eTx8n3AEw==
+    dependencies:
+      ansi-gray "^0.1.1"
+      color-support "^1.1.3"
+      parse-node-version "^1.0.0"
+      time-stamp "^1.0.0"
+  
+  fd-slicer@~1.1.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/fd-slicer/-/fd-slicer-1.1.0.tgz#25c7c89cb1f9077f8891bbe61d8f390eae256f1e"
+    integrity sha1-JcfInLH5B3+IkbvmHY85Dq4lbx4=
+    dependencies:
+      pend "~1.2.0"
+  
+  figures@^1.3.5, figures@^1.7.0:
+    version "1.7.0"
+    resolved "https://registry.yarnpkg.com/figures/-/figures-1.7.0.tgz#cbe1e3affcf1cd44b80cadfed28dc793a9701d2e"
+    integrity sha1-y+Hjr/zxzUS4DK3+0o3Hk6lwHS4=
+    dependencies:
+      escape-string-regexp "^1.0.5"
+      object-assign "^4.1.0"
+  
+  file-type@^3.1.0:
+    version "3.9.0"
+    resolved "https://registry.yarnpkg.com/file-type/-/file-type-3.9.0.tgz#257a078384d1db8087bc449d107d52a52672b9e9"
+    integrity sha1-JXoHg4TR24CHvESdEH1SpSZyuek=
+  
+  filename-regex@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/filename-regex/-/filename-regex-2.0.1.tgz#c1c4b9bee3e09725ddb106b75c1e301fe2f18b26"
+    integrity sha1-wcS5vuPglyXdsQa3XB4wH+LxiyY=
+  
+  filename-reserved-regex@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/filename-reserved-regex/-/filename-reserved-regex-1.0.0.tgz#e61cf805f0de1c984567d0386dc5df50ee5af7e4"
+    integrity sha1-5hz4BfDeHJhFZ9A4bcXfUO5a9+Q=
+  
+  filenamify@^1.0.1:
+    version "1.2.1"
+    resolved "https://registry.yarnpkg.com/filenamify/-/filenamify-1.2.1.tgz#a9f2ffd11c503bed300015029272378f1f1365a5"
+    integrity sha1-qfL/0RxQO+0wABUCknI3jx8TZaU=
+    dependencies:
+      filename-reserved-regex "^1.0.0"
+      strip-outer "^1.0.0"
+      trim-repeated "^1.0.0"
+  
+  fill-range@^2.1.0:
+    version "2.2.4"
+    resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-2.2.4.tgz#eb1e773abb056dcd8df2bfdf6af59b8b3a936565"
+    integrity sha512-cnrcCbj01+j2gTG921VZPnHbjmdAf8oQV/iGeV2kZxGSyfYjjTyY79ErsK1WJWMpw6DaApEX72binqJE+/d+5Q==
+    dependencies:
+      is-number "^2.1.0"
+      isobject "^2.0.0"
+      randomatic "^3.0.0"
+      repeat-element "^1.1.2"
+      repeat-string "^1.5.2"
+  
+  find-parent-dir@^0.3.0:
+    version "0.3.0"
+    resolved "https://registry.yarnpkg.com/find-parent-dir/-/find-parent-dir-0.3.0.tgz#33c44b429ab2b2f0646299c5f9f718f376ff8d54"
+    integrity sha1-M8RLQpqysvBkYpnF+fcY83b/jVQ=
+  
+  find-up@^1.0.0:
+    version "1.1.2"
+    resolved "https://registry.yarnpkg.com/find-up/-/find-up-1.1.2.tgz#6b2e9822b1a2ce0a60ab64d610eccad53cb24d0f"
+    integrity sha1-ay6YIrGizgpgq2TWEOzK1TyyTQ8=
+    dependencies:
+      path-exists "^2.0.0"
+      pinkie-promise "^2.0.0"
+  
+  find-versions@^1.0.0:
+    version "1.2.1"
+    resolved "https://registry.yarnpkg.com/find-versions/-/find-versions-1.2.1.tgz#cbde9f12e38575a0af1be1b9a2c5d5fd8f186b62"
+    integrity sha1-y96fEuOFdaCvG+G5osXV/Y8Ya2I=
+    dependencies:
+      array-uniq "^1.0.0"
+      get-stdin "^4.0.1"
+      meow "^3.5.0"
+      semver-regex "^1.0.0"
+  
+  first-chunk-stream@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/first-chunk-stream/-/first-chunk-stream-1.0.0.tgz#59bfb50cd905f60d7c394cd3d9acaab4e6ad934e"
+    integrity sha1-Wb+1DNkF9g18OUzT2ayqtOatk04=
+  
+  for-in@^1.0.1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80"
+    integrity sha1-gQaNKVqBQuwKxybG4iAMMPttXoA=
+  
+  for-own@^0.1.4:
+    version "0.1.5"
+    resolved "https://registry.yarnpkg.com/for-own/-/for-own-0.1.5.tgz#5265c681a4f294dabbf17c9509b6763aa84510ce"
+    integrity sha1-UmXGgaTylNq78XyVCbZ2OqhFEM4=
+    dependencies:
+      for-in "^1.0.1"
+  
+  fs-constants@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/fs-constants/-/fs-constants-1.0.0.tgz#6be0de9be998ce16af8afc24497b9ee9b7ccd9ad"
+    integrity sha512-y6OAwoSIf7FyjMIv94u+b5rdheZEjzR63GTyZJm5qh4Bi+2YgwLCcI/fPFZkL5PSixOt6ZNKm+w+Hfp/Bciwow==
+  
+  fs.realpath@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
+    integrity sha1-FQStJSMVjKpA20onh8sBQRmU6k8=
+  
+  get-proxy@^1.0.1:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/get-proxy/-/get-proxy-1.1.0.tgz#894854491bc591b0f147d7ae570f5c678b7256eb"
+    integrity sha1-iUhUSRvFkbDxR9euVw9cZ4tyVus=
+    dependencies:
+      rc "^1.1.2"
+  
+  get-stdin@^4.0.1:
+    version "4.0.1"
+    resolved "https://registry.yarnpkg.com/get-stdin/-/get-stdin-4.0.1.tgz#b968c6b0a04384324902e8bf1a5df32579a450fe"
+    integrity sha1-uWjGsKBDhDJJAui/Gl3zJXmkUP4=
+  
+  get-stdin@~5.0.1:
+    version "5.0.1"
+    resolved "https://registry.yarnpkg.com/get-stdin/-/get-stdin-5.0.1.tgz#122e161591e21ff4c52530305693f20e6393a398"
+    integrity sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g=
+  
+  get-stream@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/get-stream/-/get-stream-3.0.0.tgz#8e943d1358dc37555054ecbe2edb05aa174ede14"
+    integrity sha1-jpQ9E1jcN1VQVOy+LtsFqhdO3hQ=
+  
+  gifsicle@^3.0.0:
+    version "3.0.4"
+    resolved "https://registry.yarnpkg.com/gifsicle/-/gifsicle-3.0.4.tgz#f45cb5ed10165b665dc929e0e9328b6c821dfa3b"
+    integrity sha1-9Fy17RAWW2ZdySng6TKLbIId+js=
+    dependencies:
+      bin-build "^2.0.0"
+      bin-wrapper "^3.0.0"
+      logalot "^2.0.0"
+  
+  glob-base@^0.3.0:
+    version "0.3.0"
+    resolved "https://registry.yarnpkg.com/glob-base/-/glob-base-0.3.0.tgz#dbb164f6221b1c0b1ccf82aea328b497df0ea3c4"
+    integrity sha1-27Fk9iIbHAscz4Kuoyi0l98Oo8Q=
+    dependencies:
+      glob-parent "^2.0.0"
+      is-glob "^2.0.0"
+  
+  glob-parent@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-2.0.0.tgz#81383d72db054fcccf5336daa902f182f6edbb28"
+    integrity sha1-gTg9ctsFT8zPUzbaqQLxgvbtuyg=
+    dependencies:
+      is-glob "^2.0.0"
+  
+  glob-parent@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-3.1.0.tgz#9e6af6299d8d3bd2bd40430832bd113df906c5ae"
+    integrity sha1-nmr2KZ2NO9K9QEMIMr0RPfkGxa4=
+    dependencies:
+      is-glob "^3.1.0"
+      path-dirname "^1.0.0"
+  
+  glob-stream@^5.3.2:
+    version "5.3.5"
+    resolved "https://registry.yarnpkg.com/glob-stream/-/glob-stream-5.3.5.tgz#a55665a9a8ccdc41915a87c701e32d4e016fad22"
+    integrity sha1-pVZlqajM3EGRWofHAeMtTgFvrSI=
+    dependencies:
+      extend "^3.0.0"
+      glob "^5.0.3"
+      glob-parent "^3.0.0"
+      micromatch "^2.3.7"
+      ordered-read-streams "^0.3.0"
+      through2 "^0.6.0"
+      to-absolute-glob "^0.1.1"
+      unique-stream "^2.0.2"
+  
+  glob@^5.0.3:
+    version "5.0.15"
+    resolved "https://registry.yarnpkg.com/glob/-/glob-5.0.15.tgz#1bc936b9e02f4a603fcc222ecf7633d30b8b93b1"
+    integrity sha1-G8k2ueAvSmA/zCIuz3Yz0wuLk7E=
+    dependencies:
+      inflight "^1.0.4"
+      inherits "2"
+      minimatch "2 || 3"
+      once "^1.3.0"
+      path-is-absolute "^1.0.0"
+  
+  glob@^7.1.3, glob@~7.1.2:
+    version "7.1.3"
+    resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.3.tgz#3960832d3f1574108342dafd3a67b332c0969df1"
+    integrity sha512-vcfuiIxogLV4DlGBHIUOwI0IbrJ8HWPc4MU7HzviGeNho/UJDfi6B5p3sHeWIQ0KGIU0Jpxi5ZHxemQfLkkAwQ==
+    dependencies:
+      fs.realpath "^1.0.0"
+      inflight "^1.0.4"
+      inherits "2"
+      minimatch "^3.0.4"
+      once "^1.3.0"
+      path-is-absolute "^1.0.0"
+  
+  glogg@^1.0.0:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/glogg/-/glogg-1.0.2.tgz#2d7dd702beda22eb3bffadf880696da6d846313f"
+    integrity sha512-5mwUoSuBk44Y4EshyiqcH95ZntbDdTQqA3QYSrxmzj28Ai0vXBGMH1ApSANH14j2sIRtqCEyg6PfsuP7ElOEDA==
+    dependencies:
+      sparkles "^1.0.0"
+  
+  got@^5.0.0:
+    version "5.7.1"
+    resolved "https://registry.yarnpkg.com/got/-/got-5.7.1.tgz#5f81635a61e4a6589f180569ea4e381680a51f35"
+    integrity sha1-X4FjWmHkplifGAVp6k44FoClHzU=
+    dependencies:
+      create-error-class "^3.0.1"
+      duplexer2 "^0.1.4"
+      is-redirect "^1.0.0"
+      is-retry-allowed "^1.0.0"
+      is-stream "^1.0.0"
+      lowercase-keys "^1.0.0"
+      node-status-codes "^1.0.0"
+      object-assign "^4.0.1"
+      parse-json "^2.1.0"
+      pinkie-promise "^2.0.0"
+      read-all-stream "^3.0.0"
+      readable-stream "^2.0.5"
+      timed-out "^3.0.0"
+      unzip-response "^1.0.2"
+      url-parse-lax "^1.0.0"
+  
+  graceful-fs@^4.0.0, graceful-fs@^4.1.2:
+    version "4.1.15"
+    resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-4.1.15.tgz#ffb703e1066e8a0eeaa4c8b80ba9253eeefbfb00"
+    integrity sha512-6uHUhOPEBgQ24HM+r6b/QwWfZq+yiFcipKFrOFiBEnWdy5sdzYoi+pJeQaPI5qOLRFqWmAXUPQNsielzdLoecA==
+  
+  "graceful-readlink@>= 1.0.0":
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/graceful-readlink/-/graceful-readlink-1.0.1.tgz#4cafad76bc62f02fa039b2f94e9a3dd3a391a725"
+    integrity sha1-TK+tdrxi8C+gObL5Tpo906ORpyU=
+  
+  gulp-decompress@^1.2.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/gulp-decompress/-/gulp-decompress-1.2.0.tgz#8eeb65a5e015f8ed8532cafe28454960626f0dc7"
+    integrity sha1-jutlpeAV+O2FMsr+KEVJYGJvDcc=
+    dependencies:
+      archive-type "^3.0.0"
+      decompress "^3.0.0"
+      gulp-util "^3.0.1"
+      readable-stream "^2.0.2"
+  
+  gulp-rename@^1.2.0:
+    version "1.4.0"
+    resolved "https://registry.yarnpkg.com/gulp-rename/-/gulp-rename-1.4.0.tgz#de1c718e7c4095ae861f7296ef4f3248648240bd"
+    integrity sha512-swzbIGb/arEoFK89tPY58vg3Ok1bw+d35PfUNwWqdo7KM4jkmuGA78JiDNqR+JeZFaeeHnRg9N7aihX3YPmsyg==
+  
+  gulp-sourcemaps@1.6.0:
+    version "1.6.0"
+    resolved "https://registry.yarnpkg.com/gulp-sourcemaps/-/gulp-sourcemaps-1.6.0.tgz#b86ff349d801ceb56e1d9e7dc7bbcb4b7dee600c"
+    integrity sha1-uG/zSdgBzrVuHZ59x7vLS33uYAw=
+    dependencies:
+      convert-source-map "^1.1.1"
+      graceful-fs "^4.1.2"
+      strip-bom "^2.0.0"
+      through2 "^2.0.0"
+      vinyl "^1.0.0"
+  
+  gulp-util@^3.0.1:
+    version "3.0.8"
+    resolved "https://registry.yarnpkg.com/gulp-util/-/gulp-util-3.0.8.tgz#0054e1e744502e27c04c187c3ecc505dd54bbb4f"
+    integrity sha1-AFTh50RQLifATBh8PsxQXdVLu08=
+    dependencies:
+      array-differ "^1.0.0"
+      array-uniq "^1.0.2"
+      beeper "^1.0.0"
+      chalk "^1.0.0"
+      dateformat "^2.0.0"
+      fancy-log "^1.1.0"
+      gulplog "^1.0.0"
+      has-gulplog "^0.1.0"
+      lodash._reescape "^3.0.0"
+      lodash._reevaluate "^3.0.0"
+      lodash._reinterpolate "^3.0.0"
+      lodash.template "^3.0.0"
+      minimist "^1.1.0"
+      multipipe "^0.1.2"
+      object-assign "^3.0.0"
+      replace-ext "0.0.1"
+      through2 "^2.0.0"
+      vinyl "^0.5.0"
+  
+  gulplog@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/gulplog/-/gulplog-1.0.0.tgz#e28c4d45d05ecbbed818363ce8f9c5926229ffe5"
+    integrity sha1-4oxNRdBey77YGDY86PnFkmIp/+U=
+    dependencies:
+      glogg "^1.0.0"
+  
+  has-ansi@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91"
+    integrity sha1-NPUEnOHs3ysGSa8+8k5F7TVBbZE=
+    dependencies:
+      ansi-regex "^2.0.0"
+  
+  has-gulplog@^0.1.0:
+    version "0.1.0"
+    resolved "https://registry.yarnpkg.com/has-gulplog/-/has-gulplog-0.1.0.tgz#6414c82913697da51590397dafb12f22967811ce"
+    integrity sha1-ZBTIKRNpfaUVkDl9r7EvIpZ4Ec4=
+    dependencies:
+      sparkles "^1.0.0"
+  
+  hosted-git-info@^2.1.4:
+    version "2.7.1"
+    resolved "https://registry.yarnpkg.com/hosted-git-info/-/hosted-git-info-2.7.1.tgz#97f236977bd6e125408930ff6de3eec6281ec047"
+    integrity sha512-7T/BxH19zbcCTa8XkMlbK5lTo1WtgkFi3GvdWEyNuc4Vex7/9Dqbnpsf4JMydcfj9HCg4zUWFTL3Za6lapg5/w==
+  
+  husky@^0.13.3:
+    version "0.13.4"
+    resolved "https://registry.yarnpkg.com/husky/-/husky-0.13.4.tgz#48785c5028de3452a51c48c12c4f94b2124a1407"
+    integrity sha1-SHhcUCjeNFKlHEjBLE+UshJKFAc=
+    dependencies:
+      chalk "^1.1.3"
+      find-parent-dir "^0.3.0"
+      is-ci "^1.0.9"
+      normalize-path "^1.0.0"
+  
+  imagemin-gifsicle@^4.0.0:
+    version "4.2.0"
+    resolved "https://registry.yarnpkg.com/imagemin-gifsicle/-/imagemin-gifsicle-4.2.0.tgz#0fef9bbad3476e6b76885736cc5b0b87a08757ca"
+    integrity sha1-D++butNHbmt2iFc2zFsLh6CHV8o=
+    dependencies:
+      gifsicle "^3.0.0"
+      is-gif "^1.0.0"
+      through2 "^0.6.1"
+  
+  imagemin-jpegtran@^4.0.0:
+    version "4.3.2"
+    resolved "https://registry.yarnpkg.com/imagemin-jpegtran/-/imagemin-jpegtran-4.3.2.tgz#1bc6d1e2bd13fdb64d245526d635a7e5dfeb12fc"
+    integrity sha1-G8bR4r0T/bZNJFUm1jWn5d/rEvw=
+    dependencies:
+      is-jpg "^1.0.0"
+      jpegtran-bin "^3.0.0"
+      through2 "^2.0.0"
+  
+  imagemin-optipng@^4.0.0, imagemin-optipng@^4.3.0:
+    version "4.3.0"
+    resolved "https://registry.yarnpkg.com/imagemin-optipng/-/imagemin-optipng-4.3.0.tgz#7604663ab2ee315733274726fd1c374d2b44adb6"
+    integrity sha1-dgRmOrLuMVczJ0cm/Rw3TStErbY=
+    dependencies:
+      exec-buffer "^2.0.0"
+      is-png "^1.0.0"
+      optipng-bin "^3.0.0"
+      through2 "^0.6.1"
+  
+  imagemin-svgo@^4.0.0:
+    version "4.2.1"
+    resolved "https://registry.yarnpkg.com/imagemin-svgo/-/imagemin-svgo-4.2.1.tgz#54f07dc56f47260462df6a61c54befb44b57be55"
+    integrity sha1-VPB9xW9HJgRi32phxUvvtEtXvlU=
+    dependencies:
+      is-svg "^1.0.0"
+      svgo "^0.6.0"
+      through2 "^2.0.0"
+  
+  imagemin@^4.0.0:
+    version "4.0.0"
+    resolved "https://registry.yarnpkg.com/imagemin/-/imagemin-4.0.0.tgz#e90e7f0936836595f18fa15fe906f4fa259ea847"
+    integrity sha1-6Q5/CTaDZZXxj6Ff6Qb0+iWeqEc=
+    dependencies:
+      buffer-to-vinyl "^1.0.0"
+      concat-stream "^1.4.6"
+      optional "^0.1.0"
+      readable-stream "^2.0.0"
+      stream-combiner2 "^1.1.1"
+      vinyl-fs "^2.1.1"
+    optionalDependencies:
+      imagemin-gifsicle "^4.0.0"
+      imagemin-jpegtran "^4.0.0"
+      imagemin-optipng "^4.0.0"
+      imagemin-svgo "^4.0.0"
+  
+  indent-string@^2.1.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/indent-string/-/indent-string-2.1.0.tgz#8e2d48348742121b4a8218b7a137e9a52049dc80"
+    integrity sha1-ji1INIdCEhtKghi3oTfppSBJ3IA=
+    dependencies:
+      repeating "^2.0.0"
+  
+  indent-string@^3.0.0:
+    version "3.2.0"
+    resolved "https://registry.yarnpkg.com/indent-string/-/indent-string-3.2.0.tgz#4a5fd6d27cc332f37e5419a504dbb837105c9289"
+    integrity sha1-Sl/W0nzDMvN+VBmlBNu4NxBckok=
+  
+  inflight@^1.0.4:
+    version "1.0.6"
+    resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
+    integrity sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=
+    dependencies:
+      once "^1.3.0"
+      wrappy "1"
+  
+  inherits@2, inherits@^2.0.1, inherits@^2.0.3, inherits@~2.0.1, inherits@~2.0.3:
+    version "2.0.3"
+    resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.3.tgz#633c2c83e3da42a502f52466022480f4208261de"
+    integrity sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=
+  
+  ini@~1.3.0:
+    version "1.3.5"
+    resolved "https://registry.yarnpkg.com/ini/-/ini-1.3.5.tgz#eee25f56db1c9ec6085e0c22778083f596abf927"
+    integrity sha512-RZY5huIKCMRWDUqZlEi72f/lmXKMvuszcMBduliQ3nnWbx9X/ZBQO7DijMEYS9EhHBb2qacRUMtC7svLwe0lcw==
+  
+  ip-regex@^1.0.1:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/ip-regex/-/ip-regex-1.0.3.tgz#dc589076f659f419c222039a33316f1c7387effd"
+    integrity sha1-3FiQdvZZ9BnCIgOaMzFvHHOH7/0=
+  
+  is-absolute@^0.1.5:
+    version "0.1.7"
+    resolved "https://registry.yarnpkg.com/is-absolute/-/is-absolute-0.1.7.tgz#847491119fccb5fb436217cc737f7faad50f603f"
+    integrity sha1-hHSREZ/MtftDYhfMc39/qtUPYD8=
+    dependencies:
+      is-relative "^0.1.0"
+  
+  is-arrayish@^0.2.1:
+    version "0.2.1"
+    resolved "https://registry.yarnpkg.com/is-arrayish/-/is-arrayish-0.2.1.tgz#77c99840527aa8ecb1a8ba697b80645a7a926a9d"
+    integrity sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=
+  
+  is-buffer@^1.1.5:
+    version "1.1.6"
+    resolved "https://registry.yarnpkg.com/is-buffer/-/is-buffer-1.1.6.tgz#efaa2ea9daa0d7ab2ea13a97b2b8ad51fefbe8be"
+    integrity sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==
+  
+  is-bzip2@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-bzip2/-/is-bzip2-1.0.0.tgz#5ee58eaa5a2e9c80e21407bedf23ae5ac091b3fc"
+    integrity sha1-XuWOqlounIDiFAe+3yOuWsCRs/w=
+  
+  is-ci@^1.0.9:
+    version "1.2.1"
+    resolved "https://registry.yarnpkg.com/is-ci/-/is-ci-1.2.1.tgz#e3779c8ee17fccf428488f6e281187f2e632841c"
+    integrity sha512-s6tfsaQaQi3JNciBH6shVqEDvhGut0SUXr31ag8Pd8BBbVVlcGfWhpPmEOoM6RJ5TFhbypvf5yyRw/VXW1IiWg==
+    dependencies:
+      ci-info "^1.5.0"
+  
+  is-dotfile@^1.0.0:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/is-dotfile/-/is-dotfile-1.0.3.tgz#a6a2f32ffd2dfb04f5ca25ecd0f6b83cf798a1e1"
+    integrity sha1-pqLzL/0t+wT1yiXs0Pa4PPeYoeE=
+  
+  is-equal-shallow@^0.1.3:
+    version "0.1.3"
+    resolved "https://registry.yarnpkg.com/is-equal-shallow/-/is-equal-shallow-0.1.3.tgz#2238098fc221de0bcfa5d9eac4c45d638aa1c534"
+    integrity sha1-IjgJj8Ih3gvPpdnqxMRdY4qhxTQ=
+    dependencies:
+      is-primitive "^2.0.0"
+  
+  is-extendable@^0.1.0, is-extendable@^0.1.1:
+    version "0.1.1"
+    resolved "https://registry.yarnpkg.com/is-extendable/-/is-extendable-0.1.1.tgz#62b110e289a471418e3ec36a617d472e301dfc89"
+    integrity sha1-YrEQ4omkcUGOPsNqYX1HLjAd/Ik=
+  
+  is-extglob@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-extglob/-/is-extglob-1.0.0.tgz#ac468177c4943405a092fc8f29760c6ffc6206c0"
+    integrity sha1-rEaBd8SUNAWgkvyPKXYMb/xiBsA=
+  
+  is-extglob@^2.1.0:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/is-extglob/-/is-extglob-2.1.1.tgz#a88c02535791f02ed37c76a1b9ea9773c833f8c2"
+    integrity sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=
+  
+  is-finite@^1.0.0:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/is-finite/-/is-finite-1.0.2.tgz#cc6677695602be550ef11e8b4aa6305342b6d0aa"
+    integrity sha1-zGZ3aVYCvlUO8R6LSqYwU0K20Ko=
+    dependencies:
+      number-is-nan "^1.0.0"
+  
+  is-fullwidth-code-point@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-fullwidth-code-point/-/is-fullwidth-code-point-1.0.0.tgz#ef9e31386f031a7f0d643af82fde50c457ef00cb"
+    integrity sha1-754xOG8DGn8NZDr4L95QxFfvAMs=
+    dependencies:
+      number-is-nan "^1.0.0"
+  
+  is-gif@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-gif/-/is-gif-1.0.0.tgz#a6d2ae98893007bffa97a1d8c01d63205832097e"
+    integrity sha1-ptKumIkwB7/6l6HYwB1jIFgyCX4=
+  
+  is-glob@^2.0.0, is-glob@^2.0.1:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-2.0.1.tgz#d096f926a3ded5600f3fdfd91198cb0888c2d863"
+    integrity sha1-0Jb5JqPe1WAPP9/ZEZjLCIjC2GM=
+    dependencies:
+      is-extglob "^1.0.0"
+  
+  is-glob@^3.1.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-3.1.0.tgz#7ba5ae24217804ac70707b96922567486cc3e84a"
+    integrity sha1-e6WuJCF4BKxwcHuWkiVnSGzD6Eo=
+    dependencies:
+      is-extglob "^2.1.0"
+  
+  is-gzip@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-gzip/-/is-gzip-1.0.0.tgz#6ca8b07b99c77998025900e555ced8ed80879a83"
+    integrity sha1-bKiwe5nHeZgCWQDlVc7Y7YCHmoM=
+  
+  is-jpg@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/is-jpg/-/is-jpg-1.0.1.tgz#296d57fdd99ce010434a7283e346ab9a1035e975"
+    integrity sha1-KW1X/dmc4BBDSnKD40armhA16XU=
+  
+  is-natural-number@^2.0.0:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/is-natural-number/-/is-natural-number-2.1.1.tgz#7d4c5728377ef386c3e194a9911bf57c6dc335e7"
+    integrity sha1-fUxXKDd+84bD4ZSpkRv1fG3DNec=
+  
+  is-number@^2.1.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/is-number/-/is-number-2.1.0.tgz#01fcbbb393463a548f2f466cce16dece49db908f"
+    integrity sha1-Afy7s5NGOlSPL0ZszhbezknbkI8=
+    dependencies:
+      kind-of "^3.0.2"
+  
+  is-number@^4.0.0:
+    version "4.0.0"
+    resolved "https://registry.yarnpkg.com/is-number/-/is-number-4.0.0.tgz#0026e37f5454d73e356dfe6564699867c6a7f0ff"
+    integrity sha512-rSklcAIlf1OmFdyAqbnWTLVelsQ58uvZ66S/ZyawjWqIviTWCjg2PzVGw8WUA+nNuPTqb4wgA+NszrJ+08LlgQ==
+  
+  is-obj@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/is-obj/-/is-obj-1.0.1.tgz#3e4729ac1f5fde025cd7d83a896dab9f4f67db0f"
+    integrity sha1-PkcprB9f3gJc19g6iW2rn09n2w8=
+  
+  is-png@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/is-png/-/is-png-1.1.0.tgz#d574b12bf275c0350455570b0e5b57ab062077ce"
+    integrity sha1-1XSxK/J1wDUEVVcLDltXqwYgd84=
+  
+  is-posix-bracket@^0.1.0:
+    version "0.1.1"
+    resolved "https://registry.yarnpkg.com/is-posix-bracket/-/is-posix-bracket-0.1.1.tgz#3334dc79774368e92f016e6fbc0a88f5cd6e6bc4"
+    integrity sha1-MzTceXdDaOkvAW5vvAqI9c1ua8Q=
+  
+  is-primitive@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/is-primitive/-/is-primitive-2.0.0.tgz#207bab91638499c07b2adf240a41a87210034575"
+    integrity sha1-IHurkWOEmcB7Kt8kCkGochADRXU=
+  
+  is-promise@^2.1.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/is-promise/-/is-promise-2.1.0.tgz#79a2a9ece7f096e80f36d2b2f3bc16c1ff4bf3fa"
+    integrity sha1-eaKp7OfwlugPNtKy87wWwf9L8/o=
+  
+  is-redirect@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-redirect/-/is-redirect-1.0.0.tgz#1d03dded53bd8db0f30c26e4f95d36fc7c87dc24"
+    integrity sha1-HQPd7VO9jbDzDCbk+V02/HyH3CQ=
+  
+  is-relative@^0.1.0:
+    version "0.1.3"
+    resolved "https://registry.yarnpkg.com/is-relative/-/is-relative-0.1.3.tgz#905fee8ae86f45b3ec614bc3c15c869df0876e82"
+    integrity sha1-kF/uiuhvRbPsYUvDwVyGnfCHboI=
+  
+  is-retry-allowed@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/is-retry-allowed/-/is-retry-allowed-1.1.0.tgz#11a060568b67339444033d0125a61a20d564fb34"
+    integrity sha1-EaBgVotnM5REAz0BJaYaINVk+zQ=
+  
+  is-stream@^1.0.0, is-stream@^1.0.1, is-stream@^1.1.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/is-stream/-/is-stream-1.1.0.tgz#12d4a3dd4e68e0b79ceb8dbc84173ae80d91ca44"
+    integrity sha1-EtSj3U5o4Lec6428hBc66A2RykQ=
+  
+  is-svg@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/is-svg/-/is-svg-1.1.1.tgz#ac0efaafb653ac58473708b1f873636ca110e31b"
+    integrity sha1-rA76r7ZTrFhHNwix+HNjbKEQ4xs=
+  
+  is-tar@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-tar/-/is-tar-1.0.0.tgz#2f6b2e1792c1f5bb36519acaa9d65c0d26fe853d"
+    integrity sha1-L2suF5LB9bs2UZrKqdZcDSb+hT0=
+  
+  is-url@^1.2.0:
+    version "1.2.4"
+    resolved "https://registry.yarnpkg.com/is-url/-/is-url-1.2.4.tgz#04a4df46d28c4cff3d73d01ff06abeb318a1aa52"
+    integrity sha512-ITvGim8FhRiYe4IQ5uHSkj7pVaPDrCTkNd3yq3cV7iZAcJdHTUMPMEHcqSOy9xZ9qFenQCvi+2wjH9a1nXqHww==
+  
+  is-utf8@^0.2.0:
+    version "0.2.1"
+    resolved "https://registry.yarnpkg.com/is-utf8/-/is-utf8-0.2.1.tgz#4b0da1442104d1b336340e80797e865cf39f7d72"
+    integrity sha1-Sw2hRCEE0bM2NA6AeX6GXPOffXI=
+  
+  is-valid-glob@^0.3.0:
+    version "0.3.0"
+    resolved "https://registry.yarnpkg.com/is-valid-glob/-/is-valid-glob-0.3.0.tgz#d4b55c69f51886f9b65c70d6c2622d37e29f48fe"
+    integrity sha1-1LVcafUYhvm2XHDWwmItN+KfSP4=
+  
+  is-zip@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/is-zip/-/is-zip-1.0.0.tgz#47b0a8ff4d38a76431ccfd99a8e15a4c86ba2325"
+    integrity sha1-R7Co/004p2QxzP2ZqOFaTIa6IyU=
+  
+  isarray@0.0.1:
+    version "0.0.1"
+    resolved "https://registry.yarnpkg.com/isarray/-/isarray-0.0.1.tgz#8a18acfca9a8f4177e09abfc6038939b05d1eedf"
+    integrity sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=
+  
+  isarray@1.0.0, isarray@~1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/isarray/-/isarray-1.0.0.tgz#bb935d48582cba168c06834957a54a3e07124f11"
+    integrity sha1-u5NdSFgsuhaMBoNJV6VKPgcSTxE=
+  
+  isexe@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/isexe/-/isexe-2.0.0.tgz#e8fbf374dc556ff8947a10dcb0572d633f2cfa10"
+    integrity sha1-6PvzdNxVb/iUehDcsFctYz8s+hA=
+  
+  isobject@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/isobject/-/isobject-2.1.0.tgz#f065561096a3f1da2ef46272f815c840d87e0c89"
+    integrity sha1-8GVWEJaj8dou9GJy+BXIQNh+DIk=
+    dependencies:
+      isarray "1.0.0"
+  
+  jpegtran-bin@^3.0.0:
+    version "3.2.0"
+    resolved "https://registry.yarnpkg.com/jpegtran-bin/-/jpegtran-bin-3.2.0.tgz#f60ecf4ae999c0bdad2e9fbcdf2b6f0981e7a29b"
+    integrity sha1-9g7PSumZwL2tLp+83ytvCYHnops=
+    dependencies:
+      bin-build "^2.0.0"
+      bin-wrapper "^3.0.0"
+      logalot "^2.0.0"
+  
+  js-yaml@^3.4.3:
+    version "3.12.2"
+    resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.12.2.tgz#ef1d067c5a9d9cb65bd72f285b5d8105c77f14fc"
+    integrity sha512-QHn/Lh/7HhZ/Twc7vJYQTkjuCa0kaCcDcjK5Zlk2rvnUpy7DxMJ23+Jc2dcyvltwQVg1nygAVlB2oRDFHoRS5Q==
+    dependencies:
+      argparse "^1.0.7"
+      esprima "^4.0.0"
+  
+  js-yaml@~3.13.0:
+    version "3.13.1"
+    resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.13.1.tgz#aff151b30bfdfa8e49e05da22e7415e9dfa37847"
+    integrity sha512-YfbcO7jXDdyj0DGxYVSlSeQNHbD7XPWvrVWeVUujrQEoZzWJIRrCPoyk6kL6IAjAG2IolMK4T0hNUe0HOUs5Jw==
+    dependencies:
+      argparse "^1.0.7"
+      esprima "^4.0.0"
+  
+  js-yaml@~3.6.0:
+    version "3.6.1"
+    resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.6.1.tgz#6e5fe67d8b205ce4d22fad05b7781e8dadcc4b30"
+    integrity sha1-bl/mfYsgXOTSL60Ft3geja3MSzA=
+    dependencies:
+      argparse "^1.0.7"
+      esprima "^2.6.0"
+  
+  json-stable-stringify-without-jsonify@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz#9db7b59496ad3f3cfef30a75142d2d930ad72651"
+    integrity sha1-nbe1lJatPzz+8wp1FC0tkwrXJlE=
+  
+  kind-of@^3.0.2:
+    version "3.2.2"
+    resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-3.2.2.tgz#31ea21a734bab9bbb0f32466d893aea51e4a3c64"
+    integrity sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=
+    dependencies:
+      is-buffer "^1.1.5"
+  
+  kind-of@^6.0.0:
+    version "6.0.2"
+    resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.2.tgz#01146b36a6218e64e58f3a8d66de5d7fc6f6d051"
+    integrity sha512-s5kLOcnH0XqDO+FvuaLX8DDjZ18CGFk7VygH40QoKPUQhW4e2rvM0rwUq0t8IQDOwYSeLK01U90OjzBTme2QqA==
+  
+  lazy-req@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/lazy-req/-/lazy-req-1.1.0.tgz#bdaebead30f8d824039ce0ce149d4daa07ba1fac"
+    integrity sha1-va6+rTD42CQDnODOFJ1Nqge6H6w=
+  
+  lazystream@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/lazystream/-/lazystream-1.0.0.tgz#f6995fe0f820392f61396be89462407bb77168e4"
+    integrity sha1-9plf4PggOS9hOWvolGJAe7dxaOQ=
+    dependencies:
+      readable-stream "^2.0.5"
+  
+  linkify-it@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/linkify-it/-/linkify-it-2.1.0.tgz#c4caf38a6cd7ac2212ef3c7d2bde30a91561f9db"
+    integrity sha512-4REs8/062kV2DSHxNfq5183zrqXMl7WP0WzABH9IeJI+NLm429FgE1PDecltYfnOoFDFlZGh2T8PfZn0r+GTRg==
+    dependencies:
+      uc.micro "^1.0.1"
+  
+  lint-staged@^3.4.2:
+    version "3.6.1"
+    resolved "https://registry.yarnpkg.com/lint-staged/-/lint-staged-3.6.1.tgz#24423c8b7bd99d96e15acd1ac8cb392a78e58582"
+    integrity sha1-JEI8i3vZnZbhWs0ayMs5KnjlhYI=
+    dependencies:
+      app-root-path "^2.0.0"
+      cosmiconfig "^1.1.0"
+      execa "^0.7.0"
+      listr "^0.12.0"
+      lodash.chunk "^4.2.0"
+      minimatch "^3.0.0"
+      npm-which "^3.0.1"
+      p-map "^1.1.1"
+      staged-git-files "0.0.4"
+  
+  listr-silent-renderer@^1.1.1:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/listr-silent-renderer/-/listr-silent-renderer-1.1.1.tgz#924b5a3757153770bf1a8e3fbf74b8bbf3f9242e"
+    integrity sha1-kktaN1cVN3C/Go4/v3S4u/P5JC4=
+  
+  listr-update-renderer@^0.2.0:
+    version "0.2.0"
+    resolved "https://registry.yarnpkg.com/listr-update-renderer/-/listr-update-renderer-0.2.0.tgz#ca80e1779b4e70266807e8eed1ad6abe398550f9"
+    integrity sha1-yoDhd5tOcCZoB+ju0a1qvjmFUPk=
+    dependencies:
+      chalk "^1.1.3"
+      cli-truncate "^0.2.1"
+      elegant-spinner "^1.0.1"
+      figures "^1.7.0"
+      indent-string "^3.0.0"
+      log-symbols "^1.0.2"
+      log-update "^1.0.2"
+      strip-ansi "^3.0.1"
+  
+  listr-verbose-renderer@^0.4.0:
+    version "0.4.1"
+    resolved "https://registry.yarnpkg.com/listr-verbose-renderer/-/listr-verbose-renderer-0.4.1.tgz#8206f4cf6d52ddc5827e5fd14989e0e965933a35"
+    integrity sha1-ggb0z21S3cWCfl/RSYng6WWTOjU=
+    dependencies:
+      chalk "^1.1.3"
+      cli-cursor "^1.0.2"
+      date-fns "^1.27.2"
+      figures "^1.7.0"
+  
+  listr@^0.12.0:
+    version "0.12.0"
+    resolved "https://registry.yarnpkg.com/listr/-/listr-0.12.0.tgz#6bce2c0f5603fa49580ea17cd6a00cc0e5fa451a"
+    integrity sha1-a84sD1YD+klYDqF81qAMwOX6RRo=
+    dependencies:
+      chalk "^1.1.3"
+      cli-truncate "^0.2.1"
+      figures "^1.7.0"
+      indent-string "^2.1.0"
+      is-promise "^2.1.0"
+      is-stream "^1.1.0"
+      listr-silent-renderer "^1.1.1"
+      listr-update-renderer "^0.2.0"
+      listr-verbose-renderer "^0.4.0"
+      log-symbols "^1.0.2"
+      log-update "^1.0.2"
+      ora "^0.2.3"
+      p-map "^1.1.1"
+      rxjs "^5.0.0-beta.11"
+      stream-to-observable "^0.1.0"
+      strip-ansi "^3.0.1"
+  
+  load-json-file@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/load-json-file/-/load-json-file-1.1.0.tgz#956905708d58b4bab4c2261b04f59f31c99374c0"
+    integrity sha1-lWkFcI1YtLq0wiYbBPWfMcmTdMA=
+    dependencies:
+      graceful-fs "^4.1.2"
+      parse-json "^2.2.0"
+      pify "^2.0.0"
+      pinkie-promise "^2.0.0"
+      strip-bom "^2.0.0"
+  
+  lodash._basecopy@^3.0.0:
+    version "3.0.1"
+    resolved "https://registry.yarnpkg.com/lodash._basecopy/-/lodash._basecopy-3.0.1.tgz#8da0e6a876cf344c0ad8a54882111dd3c5c7ca36"
+    integrity sha1-jaDmqHbPNEwK2KVIghEd08XHyjY=
+  
+  lodash._basetostring@^3.0.0:
+    version "3.0.1"
+    resolved "https://registry.yarnpkg.com/lodash._basetostring/-/lodash._basetostring-3.0.1.tgz#d1861d877f824a52f669832dcaf3ee15566a07d5"
+    integrity sha1-0YYdh3+CSlL2aYMtyvPuFVZqB9U=
+  
+  lodash._basevalues@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/lodash._basevalues/-/lodash._basevalues-3.0.0.tgz#5b775762802bde3d3297503e26300820fdf661b7"
+    integrity sha1-W3dXYoAr3j0yl1A+JjAIIP32Ybc=
+  
+  lodash._getnative@^3.0.0:
+    version "3.9.1"
+    resolved "https://registry.yarnpkg.com/lodash._getnative/-/lodash._getnative-3.9.1.tgz#570bc7dede46d61cdcde687d65d3eecbaa3aaff5"
+    integrity sha1-VwvH3t5G1hzc3mh9ZdPuy6o6r/U=
+  
+  lodash._isiterateecall@^3.0.0:
+    version "3.0.9"
+    resolved "https://registry.yarnpkg.com/lodash._isiterateecall/-/lodash._isiterateecall-3.0.9.tgz#5203ad7ba425fae842460e696db9cf3e6aac057c"
+    integrity sha1-UgOte6Ql+uhCRg5pbbnPPmqsBXw=
+  
+  lodash._reescape@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/lodash._reescape/-/lodash._reescape-3.0.0.tgz#2b1d6f5dfe07c8a355753e5f27fac7f1cde1616a"
+    integrity sha1-Kx1vXf4HyKNVdT5fJ/rH8c3hYWo=
+  
+  lodash._reevaluate@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/lodash._reevaluate/-/lodash._reevaluate-3.0.0.tgz#58bc74c40664953ae0b124d806996daca431e2ed"
+    integrity sha1-WLx0xAZklTrgsSTYBpltrKQx4u0=
+  
+  lodash._reinterpolate@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/lodash._reinterpolate/-/lodash._reinterpolate-3.0.0.tgz#0ccf2d89166af03b3663c796538b75ac6e114d9d"
+    integrity sha1-DM8tiRZq8Ds2Y8eWU4t1rG4RTZ0=
+  
+  lodash._root@^3.0.0:
+    version "3.0.1"
+    resolved "https://registry.yarnpkg.com/lodash._root/-/lodash._root-3.0.1.tgz#fba1c4524c19ee9a5f8136b4609f017cf4ded692"
+    integrity sha1-+6HEUkwZ7ppfgTa0YJ8BfPTe1pI=
+  
+  lodash.chunk@^4.2.0:
+    version "4.2.0"
+    resolved "https://registry.yarnpkg.com/lodash.chunk/-/lodash.chunk-4.2.0.tgz#66e5ce1f76ed27b4303d8c6512e8d1216e8106bc"
+    integrity sha1-ZuXOH3btJ7QwPYxlEujRIW6BBrw=
+  
+  lodash.differencewith@~4.5.0:
+    version "4.5.0"
+    resolved "https://registry.yarnpkg.com/lodash.differencewith/-/lodash.differencewith-4.5.0.tgz#bafafbc918b55154e179176a00bb0aefaac854b7"
+    integrity sha1-uvr7yRi1UVTheRdqALsK76rIVLc=
+  
+  lodash.escape@^3.0.0:
+    version "3.2.0"
+    resolved "https://registry.yarnpkg.com/lodash.escape/-/lodash.escape-3.2.0.tgz#995ee0dc18c1b48cc92effae71a10aab5b487698"
+    integrity sha1-mV7g3BjBtIzJLv+ucaEKq1tIdpg=
+    dependencies:
+      lodash._root "^3.0.0"
+  
+  lodash.flatten@~4.4.0:
+    version "4.4.0"
+    resolved "https://registry.yarnpkg.com/lodash.flatten/-/lodash.flatten-4.4.0.tgz#f31c22225a9632d2bbf8e4addbef240aa765a61f"
+    integrity sha1-8xwiIlqWMtK7+OSt2+8kCqdlph8=
+  
+  lodash.isarguments@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/lodash.isarguments/-/lodash.isarguments-3.1.0.tgz#2f573d85c6a24289ff00663b491c1d338ff3458a"
+    integrity sha1-L1c9hcaiQon/AGY7SRwdM4/zRYo=
+  
+  lodash.isarray@^3.0.0:
+    version "3.0.4"
+    resolved "https://registry.yarnpkg.com/lodash.isarray/-/lodash.isarray-3.0.4.tgz#79e4eb88c36a8122af86f844aa9bcd851b5fbb55"
+    integrity sha1-eeTriMNqgSKvhvhEqpvNhRtfu1U=
+  
+  lodash.isequal@^4.0.0:
+    version "4.5.0"
+    resolved "https://registry.yarnpkg.com/lodash.isequal/-/lodash.isequal-4.5.0.tgz#415c4478f2bcc30120c22ce10ed3226f7d3e18e0"
+    integrity sha1-QVxEePK8wwEgwizhDtMib30+GOA=
+  
+  lodash.keys@^3.0.0:
+    version "3.1.2"
+    resolved "https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a"
+    integrity sha1-TbwEcrFWvlCgsoaFXRvQsMZWCYo=
+    dependencies:
+      lodash._getnative "^3.0.0"
+      lodash.isarguments "^3.0.0"
+      lodash.isarray "^3.0.0"
+  
+  lodash.restparam@^3.0.0:
+    version "3.6.1"
+    resolved "https://registry.yarnpkg.com/lodash.restparam/-/lodash.restparam-3.6.1.tgz#936a4e309ef330a7645ed4145986c85ae5b20805"
+    integrity sha1-k2pOMJ7zMKdkXtQUWYbIWuWyCAU=
+  
+  lodash.template@^3.0.0:
+    version "3.6.2"
+    resolved "https://registry.yarnpkg.com/lodash.template/-/lodash.template-3.6.2.tgz#f8cdecc6169a255be9098ae8b0c53d378931d14f"
+    integrity sha1-+M3sxhaaJVvpCYrosMU9N4kx0U8=
+    dependencies:
+      lodash._basecopy "^3.0.0"
+      lodash._basetostring "^3.0.0"
+      lodash._basevalues "^3.0.0"
+      lodash._isiterateecall "^3.0.0"
+      lodash._reinterpolate "^3.0.0"
+      lodash.escape "^3.0.0"
+      lodash.keys "^3.0.0"
+      lodash.restparam "^3.0.0"
+      lodash.templatesettings "^3.0.0"
+  
+  lodash.templatesettings@^3.0.0:
+    version "3.1.1"
+    resolved "https://registry.yarnpkg.com/lodash.templatesettings/-/lodash.templatesettings-3.1.1.tgz#fb307844753b66b9f1afa54e262c745307dba8e5"
+    integrity sha1-+zB4RHU7Zrnxr6VOJix0UwfbqOU=
+    dependencies:
+      lodash._reinterpolate "^3.0.0"
+      lodash.escape "^3.0.0"
+  
+  log-symbols@^1.0.2:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/log-symbols/-/log-symbols-1.0.2.tgz#376ff7b58ea3086a0f09facc74617eca501e1a18"
+    integrity sha1-N2/3tY6jCGoPCfrMdGF+ylAeGhg=
+    dependencies:
+      chalk "^1.0.0"
+  
+  log-update@^1.0.2:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/log-update/-/log-update-1.0.2.tgz#19929f64c4093d2d2e7075a1dad8af59c296b8d1"
+    integrity sha1-GZKfZMQJPS0ucHWh2tivWcKWuNE=
+    dependencies:
+      ansi-escapes "^1.0.0"
+      cli-cursor "^1.0.2"
+  
+  logalot@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/logalot/-/logalot-2.1.0.tgz#5f8e8c90d304edf12530951a5554abb8c5e3f552"
+    integrity sha1-X46MkNME7fElMJUaVVSruMXj9VI=
+    dependencies:
+      figures "^1.3.5"
+      squeak "^1.0.0"
+  
+  longest@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/longest/-/longest-1.0.1.tgz#30a0b2da38f73770e8294a0d22e6625ed77d0097"
+    integrity sha1-MKCy2jj3N3DoKUoNIuZiXtd9AJc=
+  
+  loud-rejection@^1.0.0:
+    version "1.6.0"
+    resolved "https://registry.yarnpkg.com/loud-rejection/-/loud-rejection-1.6.0.tgz#5b46f80147edee578870f086d04821cf998e551f"
+    integrity sha1-W0b4AUft7leIcPCG0Eghz5mOVR8=
+    dependencies:
+      currently-unhandled "^0.4.1"
+      signal-exit "^3.0.0"
+  
+  lowercase-keys@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/lowercase-keys/-/lowercase-keys-1.0.1.tgz#6f9e30b47084d971a7c820ff15a6c5167b74c26f"
+    integrity sha512-G2Lj61tXDnVFFOi8VZds+SoQjtQC3dgokKdDG2mTm1tx4m50NUHBOZSBwQQHyy0V12A0JTG4icfZQH+xPyh8VA==
+  
+  lpad-align@^1.0.1:
+    version "1.1.2"
+    resolved "https://registry.yarnpkg.com/lpad-align/-/lpad-align-1.1.2.tgz#21f600ac1c3095c3c6e497ee67271ee08481fe9e"
+    integrity sha1-IfYArBwwlcPG5JfuZyce4ISB/p4=
+    dependencies:
+      get-stdin "^4.0.1"
+      indent-string "^2.1.0"
+      longest "^1.0.0"
+      meow "^3.3.0"
+  
+  lru-cache@^4.0.1:
+    version "4.1.5"
+    resolved "https://registry.yarnpkg.com/lru-cache/-/lru-cache-4.1.5.tgz#8bbe50ea85bed59bc9e33dcab8235ee9bcf443cd"
+    integrity sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==
+    dependencies:
+      pseudomap "^1.0.2"
+      yallist "^2.1.2"
+  
+  map-obj@^1.0.0, map-obj@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/map-obj/-/map-obj-1.0.1.tgz#d933ceb9205d82bdcf4886f6742bdc2b4dea146d"
+    integrity sha1-2TPOuSBdgr3PSIb2dCvcK03qFG0=
+  
+  markdown-it@8.4.2:
+    version "8.4.2"
+    resolved "https://registry.yarnpkg.com/markdown-it/-/markdown-it-8.4.2.tgz#386f98998dc15a37722aa7722084f4020bdd9b54"
+    integrity sha512-GcRz3AWTqSUphY3vsUqQSFMbgR38a4Lh3GWlHRh/7MRwz8mcu9n2IO7HOh+bXHrR9kOPDl5RNCaEsrneb+xhHQ==
+    dependencies:
+      argparse "^1.0.7"
+      entities "~1.1.1"
+      linkify-it "^2.0.0"
+      mdurl "^1.0.1"
+      uc.micro "^1.0.5"
+  
+  markdownlint-cli@^0.15.0:
+    version "0.15.0"
+    resolved "https://registry.yarnpkg.com/markdownlint-cli/-/markdownlint-cli-0.15.0.tgz#12a820d3745a955cff2877157d132248e9d3802b"
+    integrity sha512-UTstPEXMix4CO1RIgjX3Bd1M+xklc4KXMP2309Zfp5y3UJOASWLSXnTnzkztBn5aZRt7bzLZmxTaR8M4J8cbbQ==
+    dependencies:
+      commander "~2.9.0"
+      deep-extend "~0.5.1"
+      get-stdin "~5.0.1"
+      glob "~7.1.2"
+      js-yaml "~3.13.0"
+      lodash.differencewith "~4.5.0"
+      lodash.flatten "~4.4.0"
+      markdownlint "~0.13.0"
+      minimatch "~3.0.4"
+      rc "~1.2.7"
+  
+  markdownlint@^0.13.0, markdownlint@~0.13.0:
+    version "0.13.0"
+    resolved "https://registry.yarnpkg.com/markdownlint/-/markdownlint-0.13.0.tgz#39ffd5ffbf1198c761a5ef3e28c195e5eb8dd669"
+    integrity sha512-mGeDEbvmRk2T8f043lK7Lhcdi7mr68hQqGsJCS4p52uvEyOLym28s3r7GA6aaFQFtwT0MfFaJ/7Ex4n/HVPUnQ==
+    dependencies:
+      markdown-it "8.4.2"
+  
+  math-random@^1.0.1:
+    version "1.0.4"
+    resolved "https://registry.yarnpkg.com/math-random/-/math-random-1.0.4.tgz#5dd6943c938548267016d4e34f057583080c514c"
+    integrity sha512-rUxjysqif/BZQH2yhd5Aaq7vXMSx9NdEsQcyA07uEzIvxgI7zIr33gGsh+RU0/XjmQpCW7RsVof1vlkvQVCK5A==
+  
+  mdurl@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/mdurl/-/mdurl-1.0.1.tgz#fe85b2ec75a59037f2adfec100fd6c601761152e"
+    integrity sha1-/oWy7HWlkDfyrf7BAP1sYBdhFS4=
+  
+  meow@^3.1.0, meow@^3.3.0, meow@^3.5.0:
+    version "3.7.0"
+    resolved "https://registry.yarnpkg.com/meow/-/meow-3.7.0.tgz#72cb668b425228290abbfa856892587308a801fb"
+    integrity sha1-cstmi0JSKCkKu/qFaJJYcwioAfs=
+    dependencies:
+      camelcase-keys "^2.0.0"
+      decamelize "^1.1.2"
+      loud-rejection "^1.0.0"
+      map-obj "^1.0.1"
+      minimist "^1.1.3"
+      normalize-package-data "^2.3.4"
+      object-assign "^4.0.1"
+      read-pkg-up "^1.0.1"
+      redent "^1.0.0"
+      trim-newlines "^1.0.0"
+  
+  merge-stream@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/merge-stream/-/merge-stream-1.0.1.tgz#4041202d508a342ba00174008df0c251b8c135e1"
+    integrity sha1-QEEgLVCKNCugAXQAjfDCUbjBNeE=
+    dependencies:
+      readable-stream "^2.0.1"
+  
+  micromatch@^2.3.7:
+    version "2.3.11"
+    resolved "https://registry.yarnpkg.com/micromatch/-/micromatch-2.3.11.tgz#86677c97d1720b363431d04d0d15293bd38c1565"
+    integrity sha1-hmd8l9FyCzY0MdBNDRUpO9OMFWU=
+    dependencies:
+      arr-diff "^2.0.0"
+      array-unique "^0.2.1"
+      braces "^1.8.2"
+      expand-brackets "^0.1.4"
+      extglob "^0.3.1"
+      filename-regex "^2.0.0"
+      is-extglob "^1.0.0"
+      is-glob "^2.0.1"
+      kind-of "^3.0.2"
+      normalize-path "^2.0.1"
+      object.omit "^2.0.0"
+      parse-glob "^3.0.4"
+      regex-cache "^0.4.2"
+  
+  "minimatch@2 || 3", minimatch@^3.0.0, minimatch@^3.0.4, minimatch@~3.0.4:
+    version "3.0.4"
+    resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.4.tgz#5166e286457f03306064be5497e8dbb0c3d32083"
+    integrity sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==
+    dependencies:
+      brace-expansion "^1.1.7"
+  
+  minimist@0.0.8:
+    version "0.0.8"
+    resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d"
+    integrity sha1-hX/Kv8M5fSYluCKCYuhqp6ARsF0=
+  
+  minimist@^1.1.0, minimist@^1.1.3, minimist@^1.2.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.0.tgz#a35008b20f41383eec1fb914f4cd5df79a264284"
+    integrity sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=
+  
+  mkdirp@^0.5.0, mkdirp@~0.5.1:
+    version "0.5.1"
+    resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903"
+    integrity sha1-MAV0OOrGz3+MR2fzhkjWaX11yQM=
+    dependencies:
+      minimist "0.0.8"
+  
+  multipipe@^0.1.2:
+    version "0.1.2"
+    resolved "https://registry.yarnpkg.com/multipipe/-/multipipe-0.1.2.tgz#2a8f2ddf70eed564dff2d57f1e1a137d9f05078b"
+    integrity sha1-Ko8t33Du1WTf8tV/HhoTfZ8FB4s=
+    dependencies:
+      duplexer2 "0.0.2"
+  
+  node-status-codes@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/node-status-codes/-/node-status-codes-1.0.0.tgz#5ae5541d024645d32a58fcddc9ceecea7ae3ac2f"
+    integrity sha1-WuVUHQJGRdMqWPzdyc7s6nrjrC8=
+  
+  normalize-package-data@^2.3.2, normalize-package-data@^2.3.4:
+    version "2.5.0"
+    resolved "https://registry.yarnpkg.com/normalize-package-data/-/normalize-package-data-2.5.0.tgz#e66db1838b200c1dfc233225d12cb36520e234a8"
+    integrity sha512-/5CMN3T0R4XTj4DcGaexo+roZSdSFW/0AOOTROrjxzCG1wrWXEsGbRKevjlIL+ZDE4sZlJr5ED4YW0yqmkK+eA==
+    dependencies:
+      hosted-git-info "^2.1.4"
+      resolve "^1.10.0"
+      semver "2 || 3 || 4 || 5"
+      validate-npm-package-license "^3.0.1"
+  
+  normalize-path@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/normalize-path/-/normalize-path-1.0.0.tgz#32d0e472f91ff345701c15a8311018d3b0a90379"
+    integrity sha1-MtDkcvkf80VwHBWoMRAY07CpA3k=
+  
+  normalize-path@^2.0.1:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/normalize-path/-/normalize-path-2.1.1.tgz#1ab28b556e198363a8c1a6f7e6fa20137fe6aed9"
+    integrity sha1-GrKLVW4Zg2Oowab35vogE3/mrtk=
+    dependencies:
+      remove-trailing-separator "^1.0.1"
+  
+  npm-path@^2.0.2:
+    version "2.0.4"
+    resolved "https://registry.yarnpkg.com/npm-path/-/npm-path-2.0.4.tgz#c641347a5ff9d6a09e4d9bce5580c4f505278e64"
+    integrity sha512-IFsj0R9C7ZdR5cP+ET342q77uSRdtWOlWpih5eC+lu29tIDbNEgDbzgVJ5UFvYHWhxDZ5TFkJafFioO0pPQjCw==
+    dependencies:
+      which "^1.2.10"
+  
+  npm-run-path@^2.0.0:
+    version "2.0.2"
+    resolved "https://registry.yarnpkg.com/npm-run-path/-/npm-run-path-2.0.2.tgz#35a9232dfa35d7067b4cb2ddf2357b1871536c5f"
+    integrity sha1-NakjLfo11wZ7TLLd8jV7GHFTbF8=
+    dependencies:
+      path-key "^2.0.0"
+  
+  npm-which@^3.0.1:
+    version "3.0.1"
+    resolved "https://registry.yarnpkg.com/npm-which/-/npm-which-3.0.1.tgz#9225f26ec3a285c209cae67c3b11a6b4ab7140aa"
+    integrity sha1-kiXybsOihcIJyuZ8OxGmtKtxQKo=
+    dependencies:
+      commander "^2.9.0"
+      npm-path "^2.0.2"
+      which "^1.2.10"
+  
+  number-is-nan@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/number-is-nan/-/number-is-nan-1.0.1.tgz#097b602b53422a522c1afb8790318336941a011d"
+    integrity sha1-CXtgK1NCKlIsGvuHkDGDNpQaAR0=
+  
+  object-assign@^2.0.0:
+    version "2.1.1"
+    resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-2.1.1.tgz#43c36e5d569ff8e4816c4efa8be02d26967c18aa"
+    integrity sha1-Q8NuXVaf+OSBbE76i+AtJpZ8GKo=
+  
+  object-assign@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-3.0.0.tgz#9bedd5ca0897949bca47e7ff408062d549f587f2"
+    integrity sha1-m+3VygiXlJvKR+f/QIBi1Un1h/I=
+  
+  object-assign@^4.0.0, object-assign@^4.0.1, object-assign@^4.1.0:
+    version "4.1.1"
+    resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-4.1.1.tgz#2109adc7965887cfc05cbbd442cac8bfbb360863"
+    integrity sha1-IQmtx5ZYh8/AXLvUQsrIv7s2CGM=
+  
+  object.omit@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/object.omit/-/object.omit-2.0.1.tgz#1a9c744829f39dbb858c76ca3579ae2a54ebd1fa"
+    integrity sha1-Gpx0SCnznbuFjHbKNXmuKlTr0fo=
+    dependencies:
+      for-own "^0.1.4"
+      is-extendable "^0.1.1"
+  
+  once@^1.3.0, once@^1.4.0:
+    version "1.4.0"
+    resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
+    integrity sha1-WDsap3WWHUsROsF9nFC6753Xa9E=
+    dependencies:
+      wrappy "1"
+  
+  onetime@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/onetime/-/onetime-1.1.0.tgz#a1f7838f8314c516f05ecefcbc4ccfe04b4ed789"
+    integrity sha1-ofeDj4MUxRbwXs78vEzP4EtO14k=
+  
+  optional@^0.1.0:
+    version "0.1.4"
+    resolved "https://registry.yarnpkg.com/optional/-/optional-0.1.4.tgz#cdb1a9bedc737d2025f690ceeb50e049444fd5b3"
+    integrity sha512-gtvrrCfkE08wKcgXaVwQVgwEQ8vel2dc5DDBn9RLQZ3YtmtkBss6A2HY6BnJH4N/4Ku97Ri/SF8sNWE2225WJw==
+  
+  optipng-bin@^3.0.0:
+    version "3.1.4"
+    resolved "https://registry.yarnpkg.com/optipng-bin/-/optipng-bin-3.1.4.tgz#95d34f2c488704f6fd70606bfea0c659f1d95d84"
+    integrity sha1-ldNPLEiHBPb9cGBr/qDGWfHZXYQ=
+    dependencies:
+      bin-build "^2.0.0"
+      bin-wrapper "^3.0.0"
+      logalot "^2.0.0"
+  
+  ora@^0.2.3:
+    version "0.2.3"
+    resolved "https://registry.yarnpkg.com/ora/-/ora-0.2.3.tgz#37527d220adcd53c39b73571d754156d5db657a4"
+    integrity sha1-N1J9Igrc1Tw5tzVx11QVbV22V6Q=
+    dependencies:
+      chalk "^1.1.1"
+      cli-cursor "^1.0.2"
+      cli-spinners "^0.1.2"
+      object-assign "^4.0.1"
+  
+  ordered-read-streams@^0.3.0:
+    version "0.3.0"
+    resolved "https://registry.yarnpkg.com/ordered-read-streams/-/ordered-read-streams-0.3.0.tgz#7137e69b3298bb342247a1bbee3881c80e2fd78b"
+    integrity sha1-cTfmmzKYuzQiR6G77jiByA4v14s=
+    dependencies:
+      is-stream "^1.0.1"
+      readable-stream "^2.0.1"
+  
+  os-filter-obj@^1.0.0:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/os-filter-obj/-/os-filter-obj-1.0.3.tgz#5915330d90eced557d2d938a31c6dd214d9c63ad"
+    integrity sha1-WRUzDZDs7VV9LZOKMcbdIU2cY60=
+  
+  os-homedir@^1.0.1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/os-homedir/-/os-homedir-1.0.2.tgz#ffbc4988336e0e833de0c168c7ef152121aa7fb3"
+    integrity sha1-/7xJiDNuDoM94MFox+8VISGqf7M=
+  
+  os-tmpdir@^1.0.0:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/os-tmpdir/-/os-tmpdir-1.0.2.tgz#bbe67406c79aa85c5cfec766fe5734555dfa1274"
+    integrity sha1-u+Z0BseaqFxc/sdm/lc0VV36EnQ=
+  
+  p-finally@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/p-finally/-/p-finally-1.0.0.tgz#3fbcfb15b899a44123b34b6dcc18b724336a2cae"
+    integrity sha1-P7z7FbiZpEEjs0ttzBi3JDNqLK4=
+  
+  p-map@^1.1.1:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/p-map/-/p-map-1.2.0.tgz#e4e94f311eabbc8633a1e79908165fca26241b6b"
+    integrity sha512-r6zKACMNhjPJMTl8KcFH4li//gkrXWfbD6feV8l6doRHlzljFWGJ2AP6iKaCJXyZmAUMOPtvbW7EXkbWO/pLEA==
+  
+  parse-glob@^3.0.4:
+    version "3.0.4"
+    resolved "https://registry.yarnpkg.com/parse-glob/-/parse-glob-3.0.4.tgz#b2c376cfb11f35513badd173ef0bb6e3a388391c"
+    integrity sha1-ssN2z7EfNVE7rdFz7wu246OIORw=
+    dependencies:
+      glob-base "^0.3.0"
+      is-dotfile "^1.0.0"
+      is-extglob "^1.0.0"
+      is-glob "^2.0.0"
+  
+  parse-json@^2.1.0, parse-json@^2.2.0:
+    version "2.2.0"
+    resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-2.2.0.tgz#f480f40434ef80741f8469099f8dea18f55a4dc9"
+    integrity sha1-9ID0BDTvgHQfhGkJn43qGPVaTck=
+    dependencies:
+      error-ex "^1.2.0"
+  
+  parse-node-version@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/parse-node-version/-/parse-node-version-1.0.1.tgz#e2b5dbede00e7fa9bc363607f53327e8b073189b"
+    integrity sha512-3YHlOa/JgH6Mnpr05jP9eDG254US9ek25LyIxZlDItp2iJtwyaXQb57lBYLdT3MowkUFYEV2XXNAYIPlESvJlA==
+  
+  path-dirname@^1.0.0:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/path-dirname/-/path-dirname-1.0.2.tgz#cc33d24d525e099a5388c0336c6e32b9160609e0"
+    integrity sha1-zDPSTVJeCZpTiMAzbG4yuRYGCeA=
+  
+  path-exists@^2.0.0:
+    version "2.1.0"
+    resolved "https://registry.yarnpkg.com/path-exists/-/path-exists-2.1.0.tgz#0feb6c64f0fc518d9a754dd5efb62c7022761f4b"
+    integrity sha1-D+tsZPD8UY2adU3V77YscCJ2H0s=
+    dependencies:
+      pinkie-promise "^2.0.0"
+  
+  path-is-absolute@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
+    integrity sha1-F0uSaHNVNP+8es5r9TpanhtcX18=
+  
+  path-key@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/path-key/-/path-key-2.0.1.tgz#411cadb574c5a140d3a4b1910d40d80cc9f40b40"
+    integrity sha1-QRyttXTFoUDTpLGRDUDYDMn0C0A=
+  
+  path-parse@^1.0.6:
+    version "1.0.6"
+    resolved "https://registry.yarnpkg.com/path-parse/-/path-parse-1.0.6.tgz#d62dbb5679405d72c4737ec58600e9ddcf06d24c"
+    integrity sha512-GSmOT2EbHrINBf9SR7CDELwlJ8AENk3Qn7OikK4nFYAu3Ote2+JYNVvkpAEQm3/TLNEJFD/xZJjzyxg3KBWOzw==
+  
+  path-type@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/path-type/-/path-type-1.1.0.tgz#59c44f7ee491da704da415da5a4070ba4f8fe441"
+    integrity sha1-WcRPfuSR2nBNpBXaWkBwuk+P5EE=
+    dependencies:
+      graceful-fs "^4.1.2"
+      pify "^2.0.0"
+      pinkie-promise "^2.0.0"
+  
+  pend@~1.2.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/pend/-/pend-1.2.0.tgz#7a57eb550a6783f9115331fcf4663d5c8e007a50"
+    integrity sha1-elfrVQpng/kRUzH89GY9XI4AelA=
+  
+  pify@^2.0.0:
+    version "2.3.0"
+    resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c"
+    integrity sha1-7RQaasBDqEnqWISY59yosVMw6Qw=
+  
+  pinkie-promise@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/pinkie-promise/-/pinkie-promise-2.0.1.tgz#2135d6dfa7a358c069ac9b178776288228450ffa"
+    integrity sha1-ITXW36ejWMBprJsXh3YogihFD/o=
+    dependencies:
+      pinkie "^2.0.0"
+  
+  pinkie@^2.0.0:
+    version "2.0.4"
+    resolved "https://registry.yarnpkg.com/pinkie/-/pinkie-2.0.4.tgz#72556b80cfa0d48a974e80e77248e80ed4f7f870"
+    integrity sha1-clVrgM+g1IqXToDnckjoDtT3+HA=
+  
+  prepend-http@^1.0.1:
+    version "1.0.4"
+    resolved "https://registry.yarnpkg.com/prepend-http/-/prepend-http-1.0.4.tgz#d4f4562b0ce3696e41ac52d0e002e57a635dc6dc"
+    integrity sha1-1PRWKwzjaW5BrFLQ4ALlemNdxtw=
+  
+  preserve@^0.2.0:
+    version "0.2.0"
+    resolved "https://registry.yarnpkg.com/preserve/-/preserve-0.2.0.tgz#815ed1f6ebc65926f865b310c0713bcb3315ce4b"
+    integrity sha1-gV7R9uvGWSb4ZbMQwHE7yzMVzks=
+  
+  process-nextick-args@~2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/process-nextick-args/-/process-nextick-args-2.0.0.tgz#a37d732f4271b4ab1ad070d35508e8290788ffaa"
+    integrity sha512-MtEC1TqN0EU5nephaJ4rAtThHtC86dNN9qCuEhtshvpVBkAW5ZO7BASN9REnF9eoXGcRub+pFuKEpOHE+HbEMw==
+  
+  pseudomap@^1.0.2:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/pseudomap/-/pseudomap-1.0.2.tgz#f052a28da70e618917ef0a8ac34c1ae5a68286b3"
+    integrity sha1-8FKijacOYYkX7wqKw0wa5aaChrM=
+  
+  q@^1.1.2:
+    version "1.5.1"
+    resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7"
+    integrity sha1-fjL3W0E4EpHQRhHxvxQQmsAGUdc=
+  
+  randomatic@^3.0.0:
+    version "3.1.1"
+    resolved "https://registry.yarnpkg.com/randomatic/-/randomatic-3.1.1.tgz#b776efc59375984e36c537b2f51a1f0aff0da1ed"
+    integrity sha512-TuDE5KxZ0J461RVjrJZCJc+J+zCkTb1MbH9AQUq68sMhOMcy9jLcb3BrZKgp9q9Ncltdg4QVqWrH02W2EFFVYw==
+    dependencies:
+      is-number "^4.0.0"
+      kind-of "^6.0.0"
+      math-random "^1.0.1"
+  
+  rc@^1.1.2, rc@~1.2.7:
+    version "1.2.8"
+    resolved "https://registry.yarnpkg.com/rc/-/rc-1.2.8.tgz#cd924bf5200a075b83c188cd6b9e211b7fc0d3ed"
+    integrity sha512-y3bGgqKj3QBdxLbLkomlohkvsA8gdAiUQlSBJnBhfn+BPxg4bc62d8TcBW15wavDfgexCgccckhcZvywyQYPOw==
+    dependencies:
+      deep-extend "^0.6.0"
+      ini "~1.3.0"
+      minimist "^1.2.0"
+      strip-json-comments "~2.0.1"
+  
+  read-all-stream@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/read-all-stream/-/read-all-stream-3.1.0.tgz#35c3e177f2078ef789ee4bfafa4373074eaef4fa"
+    integrity sha1-NcPhd/IHjveJ7kv6+kNzB06u9Po=
+    dependencies:
+      pinkie-promise "^2.0.0"
+      readable-stream "^2.0.0"
+  
+  read-pkg-up@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/read-pkg-up/-/read-pkg-up-1.0.1.tgz#9d63c13276c065918d57f002a57f40a1b643fb02"
+    integrity sha1-nWPBMnbAZZGNV/ACpX9AobZD+wI=
+    dependencies:
+      find-up "^1.0.0"
+      read-pkg "^1.0.0"
+  
+  read-pkg@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/read-pkg/-/read-pkg-1.1.0.tgz#f5ffaa5ecd29cb31c0474bca7d756b6bb29e3f28"
+    integrity sha1-9f+qXs0pyzHAR0vKfXVra7KePyg=
+    dependencies:
+      load-json-file "^1.0.0"
+      normalize-package-data "^2.3.2"
+      path-type "^1.0.0"
+  
+  "readable-stream@>=1.0.33-1 <1.1.0-0":
+    version "1.0.34"
+    resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-1.0.34.tgz#125820e34bc842d2f2aaafafe4c2916ee32c157c"
+    integrity sha1-Elgg40vIQtLyqq+v5MKRbuMsFXw=
+    dependencies:
+      core-util-is "~1.0.0"
+      inherits "~2.0.1"
+      isarray "0.0.1"
+      string_decoder "~0.10.x"
+  
+  readable-stream@^2.0.0, readable-stream@^2.0.1, readable-stream@^2.0.2, readable-stream@^2.0.4, readable-stream@^2.0.5, readable-stream@^2.2.2, readable-stream@^2.3.0, readable-stream@^2.3.5, readable-stream@~2.3.6:
+    version "2.3.6"
+    resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.3.6.tgz#b11c27d88b8ff1fbe070643cf94b0c79ae1b0aaf"
+    integrity sha512-tQtKA9WIAhBF3+VLAseyMqZeBjW0AHJoxOtYqSUZNJxauErmLbVm2FW1y+J/YA9dUrAC39ITejlZWhVIwawkKw==
+    dependencies:
+      core-util-is "~1.0.0"
+      inherits "~2.0.3"
+      isarray "~1.0.0"
+      process-nextick-args "~2.0.0"
+      safe-buffer "~5.1.1"
+      string_decoder "~1.1.1"
+      util-deprecate "~1.0.1"
+  
+  readable-stream@~1.1.9:
+    version "1.1.14"
+    resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-1.1.14.tgz#7cf4c54ef648e3813084c636dd2079e166c081d9"
+    integrity sha1-fPTFTvZI44EwhMY23SB54WbAgdk=
+    dependencies:
+      core-util-is "~1.0.0"
+      inherits "~2.0.1"
+      isarray "0.0.1"
+      string_decoder "~0.10.x"
+  
+  redent@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/redent/-/redent-1.0.0.tgz#cf916ab1fd5f1f16dfb20822dd6ec7f730c2afde"
+    integrity sha1-z5Fqsf1fHxbfsggi3W7H9zDCr94=
+    dependencies:
+      indent-string "^2.1.0"
+      strip-indent "^1.0.1"
+  
+  regex-cache@^0.4.2:
+    version "0.4.4"
+    resolved "https://registry.yarnpkg.com/regex-cache/-/regex-cache-0.4.4.tgz#75bdc58a2a1496cec48a12835bc54c8d562336dd"
+    integrity sha512-nVIZwtCjkC9YgvWkpM55B5rBhBYRZhAaJbgcFYXXsHnbZ9UZI9nnVWYZpBlCqv9ho2eZryPnWrZGsOdPwVWXWQ==
+    dependencies:
+      is-equal-shallow "^0.1.3"
+  
+  remove-trailing-separator@^1.0.1:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/remove-trailing-separator/-/remove-trailing-separator-1.1.0.tgz#c24bce2a283adad5bc3f58e0d48249b92379d8ef"
+    integrity sha1-wkvOKig62tW8P1jg1IJJuSN52O8=
+  
+  repeat-element@^1.1.2:
+    version "1.1.3"
+    resolved "https://registry.yarnpkg.com/repeat-element/-/repeat-element-1.1.3.tgz#782e0d825c0c5a3bb39731f84efee6b742e6b1ce"
+    integrity sha512-ahGq0ZnV5m5XtZLMb+vP76kcAM5nkLqk0lpqAuojSKGgQtn4eRi4ZZGm2olo2zKFH+sMsWaqOCW1dqAnOru72g==
+  
+  repeat-string@^1.5.2:
+    version "1.6.1"
+    resolved "https://registry.yarnpkg.com/repeat-string/-/repeat-string-1.6.1.tgz#8dcae470e1c88abc2d600fff4a776286da75e637"
+    integrity sha1-jcrkcOHIirwtYA//Sndihtp15jc=
+  
+  repeating@^2.0.0:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/repeating/-/repeating-2.0.1.tgz#5214c53a926d3552707527fbab415dbc08d06dda"
+    integrity sha1-UhTFOpJtNVJwdSf7q0FdvAjQbdo=
+    dependencies:
+      is-finite "^1.0.0"
+  
+  replace-ext@0.0.1:
+    version "0.0.1"
+    resolved "https://registry.yarnpkg.com/replace-ext/-/replace-ext-0.0.1.tgz#29bbd92078a739f0bcce2b4ee41e837953522924"
+    integrity sha1-KbvZIHinOfC8zitO5B6DeVNSKSQ=
+  
+  require-from-string@^1.1.0:
+    version "1.2.1"
+    resolved "https://registry.yarnpkg.com/require-from-string/-/require-from-string-1.2.1.tgz#529c9ccef27380adfec9a2f965b649bbee636418"
+    integrity sha1-UpyczvJzgK3+yaL5ZbZJu+5jZBg=
+  
+  resolve@^1.10.0:
+    version "1.10.0"
+    resolved "https://registry.yarnpkg.com/resolve/-/resolve-1.10.0.tgz#3bdaaeaf45cc07f375656dfd2e54ed0810b101ba"
+    integrity sha512-3sUr9aq5OfSg2S9pNtPA9hL1FVEAjvfOC4leW0SNf/mpnaakz2a9femSd6LqAww2RaFctwyf1lCqnTHuF1rxDg==
+    dependencies:
+      path-parse "^1.0.6"
+  
+  restore-cursor@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/restore-cursor/-/restore-cursor-1.0.1.tgz#34661f46886327fed2991479152252df92daa541"
+    integrity sha1-NGYfRohjJ/7SmRR5FSJS35LapUE=
+    dependencies:
+      exit-hook "^1.0.0"
+      onetime "^1.0.0"
+  
+  rimraf@^2.2.6:
+    version "2.6.3"
+    resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.6.3.tgz#b2d104fe0d8fb27cf9e0a1cda8262dd3833c6cab"
+    integrity sha512-mwqeW5XsA2qAejG46gYdENaxXjx9onRNCfn7L0duuP4hCuTIi/QO7PDK07KJfp1d+izWPrzEJDcSqBa0OZQriA==
+    dependencies:
+      glob "^7.1.3"
+  
+  rxjs@^5.0.0-beta.11:
+    version "5.5.12"
+    resolved "https://registry.yarnpkg.com/rxjs/-/rxjs-5.5.12.tgz#6fa61b8a77c3d793dbaf270bee2f43f652d741cc"
+    integrity sha512-xx2itnL5sBbqeeiVgNPVuQQ1nC8Jp2WfNJhXWHmElW9YmrpS9UVnNzhP3EH3HFqexO5Tlp8GhYY+WEcqcVMvGw==
+    dependencies:
+      symbol-observable "1.0.1"
+  
+  safe-buffer@^5.1.1, safe-buffer@~5.1.0, safe-buffer@~5.1.1:
+    version "5.1.2"
+    resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.1.2.tgz#991ec69d296e0313747d59bdfd2b745c35f8828d"
+    integrity sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==
+  
+  sax@~1.2.1:
+    version "1.2.4"
+    resolved "https://registry.yarnpkg.com/sax/-/sax-1.2.4.tgz#2816234e2378bddc4e5354fab5caa895df7100d9"
+    integrity sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==
+  
+  seek-bzip@^1.0.3:
+    version "1.0.5"
+    resolved "https://registry.yarnpkg.com/seek-bzip/-/seek-bzip-1.0.5.tgz#cfe917cb3d274bcffac792758af53173eb1fabdc"
+    integrity sha1-z+kXyz0nS8/6x5J1ivUxc+sfq9w=
+    dependencies:
+      commander "~2.8.1"
+  
+  semver-regex@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/semver-regex/-/semver-regex-1.0.0.tgz#92a4969065f9c70c694753d55248fc68f8f652c9"
+    integrity sha1-kqSWkGX5xwxpR1PVUkj8aPj2Usk=
+  
+  semver-truncate@^1.0.0:
+    version "1.1.2"
+    resolved "https://registry.yarnpkg.com/semver-truncate/-/semver-truncate-1.1.2.tgz#57f41de69707a62709a7e0104ba2117109ea47e8"
+    integrity sha1-V/Qd5pcHpicJp+AQS6IRcQnqR+g=
+    dependencies:
+      semver "^5.3.0"
+  
+  "semver@2 || 3 || 4 || 5", semver@^5.3.0:
+    version "5.6.0"
+    resolved "https://registry.yarnpkg.com/semver/-/semver-5.6.0.tgz#7e74256fbaa49c75aa7c7a205cc22799cac80004"
+    integrity sha512-RS9R6R35NYgQn++fkDWaOmqGoj4Ek9gGs+DPxNUZKuwE183xjJroKvyo1IzVFeXvUrvmALy6FWD5xrdJT25gMg==
+  
+  semver@^4.0.3:
+    version "4.3.6"
+    resolved "https://registry.yarnpkg.com/semver/-/semver-4.3.6.tgz#300bc6e0e86374f7ba61068b5b1ecd57fc6532da"
+    integrity sha1-MAvG4OhjdPe6YQaLWx7NV/xlMto=
+  
+  set-immediate-shim@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/set-immediate-shim/-/set-immediate-shim-1.0.1.tgz#4b2b1b27eb808a9f8dcc481a58e5e56f599f3f61"
+    integrity sha1-SysbJ+uAip+NzEgaWOXlb1mfP2E=
+  
+  shebang-command@^1.2.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/shebang-command/-/shebang-command-1.2.0.tgz#44aac65b695b03398968c39f363fee5deafdf1ea"
+    integrity sha1-RKrGW2lbAzmJaMOfNj/uXer98eo=
+    dependencies:
+      shebang-regex "^1.0.0"
+  
+  shebang-regex@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/shebang-regex/-/shebang-regex-1.0.0.tgz#da42f49740c0b42db2ca9728571cb190c98efea3"
+    integrity sha1-2kL0l0DAtC2yypcoVxyxkMmO/qM=
+  
+  signal-exit@^3.0.0:
+    version "3.0.2"
+    resolved "https://registry.yarnpkg.com/signal-exit/-/signal-exit-3.0.2.tgz#b5fdc08f1287ea1178628e415e25132b73646c6d"
+    integrity sha1-tf3AjxKH6hF4Yo5BXiUTK3NkbG0=
+  
+  slice-ansi@0.0.4:
+    version "0.0.4"
+    resolved "https://registry.yarnpkg.com/slice-ansi/-/slice-ansi-0.0.4.tgz#edbf8903f66f7ce2f8eafd6ceed65e264c831b35"
+    integrity sha1-7b+JA/ZvfOL46v1s7tZeJkyDGzU=
+  
+  source-map@^0.5.3:
+    version "0.5.7"
+    resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.5.7.tgz#8a039d2d1021d22d1ea14c80d8ea468ba2ef3fcc"
+    integrity sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=
+  
+  sparkles@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/sparkles/-/sparkles-1.0.1.tgz#008db65edce6c50eec0c5e228e1945061dd0437c"
+    integrity sha512-dSO0DDYUahUt/0/pD/Is3VIm5TGJjludZ0HVymmhYF6eNA53PVLhnUk0znSYbH8IYBuJdCE+1luR22jNLMaQdw==
+  
+  spdx-correct@^3.0.0:
+    version "3.1.0"
+    resolved "https://registry.yarnpkg.com/spdx-correct/-/spdx-correct-3.1.0.tgz#fb83e504445268f154b074e218c87c003cd31df4"
+    integrity sha512-lr2EZCctC2BNR7j7WzJ2FpDznxky1sjfxvvYEyzxNyb6lZXHODmEoJeFu4JupYlkfha1KZpJyoqiJ7pgA1qq8Q==
+    dependencies:
+      spdx-expression-parse "^3.0.0"
+      spdx-license-ids "^3.0.0"
+  
+  spdx-exceptions@^2.1.0:
+    version "2.2.0"
+    resolved "https://registry.yarnpkg.com/spdx-exceptions/-/spdx-exceptions-2.2.0.tgz#2ea450aee74f2a89bfb94519c07fcd6f41322977"
+    integrity sha512-2XQACfElKi9SlVb1CYadKDXvoajPgBVPn/gOQLrTvHdElaVhr7ZEbqJaRnJLVNeaI4cMEAgVCeBMKF6MWRDCRA==
+  
+  spdx-expression-parse@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/spdx-expression-parse/-/spdx-expression-parse-3.0.0.tgz#99e119b7a5da00e05491c9fa338b7904823b41d0"
+    integrity sha512-Yg6D3XpRD4kkOmTpdgbUiEJFKghJH03fiC1OPll5h/0sO6neh2jqRDVHOQ4o/LMea0tgCkbMgea5ip/e+MkWyg==
+    dependencies:
+      spdx-exceptions "^2.1.0"
+      spdx-license-ids "^3.0.0"
+  
+  spdx-license-ids@^3.0.0:
+    version "3.0.3"
+    resolved "https://registry.yarnpkg.com/spdx-license-ids/-/spdx-license-ids-3.0.3.tgz#81c0ce8f21474756148bbb5f3bfc0f36bf15d76e"
+    integrity sha512-uBIcIl3Ih6Phe3XHK1NqboJLdGfwr1UN3k6wSD1dZpmPsIkb8AGNbZYJ1fOBk834+Gxy8rpfDxrS6XLEMZMY2g==
+  
+  sprintf-js@~1.0.2:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/sprintf-js/-/sprintf-js-1.0.3.tgz#04e6926f662895354f3dd015203633b857297e2c"
+    integrity sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=
+  
+  squeak@^1.0.0:
+    version "1.3.0"
+    resolved "https://registry.yarnpkg.com/squeak/-/squeak-1.3.0.tgz#33045037b64388b567674b84322a6521073916c3"
+    integrity sha1-MwRQN7ZDiLVnZ0uEMiplIQc5FsM=
+    dependencies:
+      chalk "^1.0.0"
+      console-stream "^0.1.1"
+      lpad-align "^1.0.1"
+  
+  staged-git-files@0.0.4:
+    version "0.0.4"
+    resolved "https://registry.yarnpkg.com/staged-git-files/-/staged-git-files-0.0.4.tgz#d797e1b551ca7a639dec0237dc6eb4bb9be17d35"
+    integrity sha1-15fhtVHKemOd7AI33G60u5vhfTU=
+  
+  stat-mode@^0.2.0:
+    version "0.2.2"
+    resolved "https://registry.yarnpkg.com/stat-mode/-/stat-mode-0.2.2.tgz#e6c80b623123d7d80cf132ce538f346289072502"
+    integrity sha1-5sgLYjEj19gM8TLOU480YokHJQI=
+  
+  stream-combiner2@^1.1.1:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/stream-combiner2/-/stream-combiner2-1.1.1.tgz#fb4d8a1420ea362764e21ad4780397bebcb41cbe"
+    integrity sha1-+02KFCDqNidk4hrUeAOXvry0HL4=
+    dependencies:
+      duplexer2 "~0.1.0"
+      readable-stream "^2.0.2"
+  
+  stream-shift@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/stream-shift/-/stream-shift-1.0.0.tgz#d5c752825e5367e786f78e18e445ea223a155952"
+    integrity sha1-1cdSgl5TZ+eG944Y5EXqIjoVWVI=
+  
+  stream-to-observable@^0.1.0:
+    version "0.1.0"
+    resolved "https://registry.yarnpkg.com/stream-to-observable/-/stream-to-observable-0.1.0.tgz#45bf1d9f2d7dc09bed81f1c307c430e68b84cffe"
+    integrity sha1-Rb8dny19wJvtgfHDB8Qw5ouEz/4=
+  
+  string-width@^1.0.1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/string-width/-/string-width-1.0.2.tgz#118bdf5b8cdc51a2a7e70d211e07e2b0b9b107d3"
+    integrity sha1-EYvfW4zcUaKn5w0hHgfisLmxB9M=
+    dependencies:
+      code-point-at "^1.0.0"
+      is-fullwidth-code-point "^1.0.0"
+      strip-ansi "^3.0.0"
+  
+  string_decoder@~0.10.x:
+    version "0.10.31"
+    resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-0.10.31.tgz#62e203bc41766c6c28c9fc84301dab1c5310fa94"
+    integrity sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=
+  
+  string_decoder@~1.1.1:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-1.1.1.tgz#9cf1611ba62685d7030ae9e4ba34149c3af03fc8"
+    integrity sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==
+    dependencies:
+      safe-buffer "~5.1.0"
+  
+  strip-ansi@^3.0.0, strip-ansi@^3.0.1:
+    version "3.0.1"
+    resolved "https://registry.yarnpkg.com/strip-ansi/-/strip-ansi-3.0.1.tgz#6a385fb8853d952d5ff05d0e8aaf94278dc63dcf"
+    integrity sha1-ajhfuIU9lS1f8F0Oiq+UJ43GPc8=
+    dependencies:
+      ansi-regex "^2.0.0"
+  
+  strip-bom-stream@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/strip-bom-stream/-/strip-bom-stream-1.0.0.tgz#e7144398577d51a6bed0fa1994fa05f43fd988ee"
+    integrity sha1-5xRDmFd9Uaa+0PoZlPoF9D/ZiO4=
+    dependencies:
+      first-chunk-stream "^1.0.0"
+      strip-bom "^2.0.0"
+  
+  strip-bom@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/strip-bom/-/strip-bom-2.0.0.tgz#6219a85616520491f35788bdbf1447a99c7e6b0e"
+    integrity sha1-YhmoVhZSBJHzV4i9vxRHqZx+aw4=
+    dependencies:
+      is-utf8 "^0.2.0"
+  
+  strip-dirs@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/strip-dirs/-/strip-dirs-1.1.1.tgz#960bbd1287844f3975a4558aa103a8255e2456a0"
+    integrity sha1-lgu9EoeETzl1pFWKoQOoJV4kVqA=
+    dependencies:
+      chalk "^1.0.0"
+      get-stdin "^4.0.1"
+      is-absolute "^0.1.5"
+      is-natural-number "^2.0.0"
+      minimist "^1.1.0"
+      sum-up "^1.0.1"
+  
+  strip-eof@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/strip-eof/-/strip-eof-1.0.0.tgz#bb43ff5598a6eb05d89b59fcd129c983313606bf"
+    integrity sha1-u0P/VZim6wXYm1n80SnJgzE2Br8=
+  
+  strip-indent@^1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/strip-indent/-/strip-indent-1.0.1.tgz#0c7962a6adefa7bbd4ac366460a638552ae1a0a2"
+    integrity sha1-DHlipq3vp7vUrDZkYKY4VSrhoKI=
+    dependencies:
+      get-stdin "^4.0.1"
+  
+  strip-json-comments@~2.0.1:
+    version "2.0.1"
+    resolved "https://registry.yarnpkg.com/strip-json-comments/-/strip-json-comments-2.0.1.tgz#3c531942e908c2697c0ec344858c286c7ca0a60a"
+    integrity sha1-PFMZQukIwml8DsNEhYwobHygpgo=
+  
+  strip-outer@^1.0.0:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/strip-outer/-/strip-outer-1.0.1.tgz#b2fd2abf6604b9d1e6013057195df836b8a9d631"
+    integrity sha512-k55yxKHwaXnpYGsOzg4Vl8+tDrWylxDEpknGjhTiZB8dFRU5rTo9CAzeycivxV3s+zlTKwrs6WxMxR95n26kwg==
+    dependencies:
+      escape-string-regexp "^1.0.2"
+  
+  sum-up@^1.0.1:
+    version "1.0.3"
+    resolved "https://registry.yarnpkg.com/sum-up/-/sum-up-1.0.3.tgz#1c661f667057f63bcb7875aa1438bc162525156e"
+    integrity sha1-HGYfZnBX9jvLeHWqFDi8FiUlFW4=
+    dependencies:
+      chalk "^1.0.0"
+  
+  supports-color@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-2.0.0.tgz#535d045ce6b6363fa40117084629995e9df324c7"
+    integrity sha1-U10EXOa2Nj+kARcIRimZXp3zJMc=
+  
+  svgo@^0.6.0:
+    version "0.6.6"
+    resolved "https://registry.yarnpkg.com/svgo/-/svgo-0.6.6.tgz#b340889036f20f9b447543077d0f5573ed044c08"
+    integrity sha1-s0CIkDbyD5tEdUMHfQ9Vc+0ETAg=
+    dependencies:
+      coa "~1.0.1"
+      colors "~1.1.2"
+      csso "~2.0.0"
+      js-yaml "~3.6.0"
+      mkdirp "~0.5.1"
+      sax "~1.2.1"
+      whet.extend "~0.9.9"
+  
+  symbol-observable@1.0.1:
+    version "1.0.1"
+    resolved "https://registry.yarnpkg.com/symbol-observable/-/symbol-observable-1.0.1.tgz#8340fc4702c3122df5d22288f88283f513d3fdd4"
+    integrity sha1-g0D8RwLDEi310iKI+IKD9RPT/dQ=
+  
+  tar-stream@^1.1.1:
+    version "1.6.2"
+    resolved "https://registry.yarnpkg.com/tar-stream/-/tar-stream-1.6.2.tgz#8ea55dab37972253d9a9af90fdcd559ae435c555"
+    integrity sha512-rzS0heiNf8Xn7/mpdSVVSMAWAoy9bfb1WOTYC78Z0UQKeKa/CWS8FOq0lKGNa8DWKAn9gxjCvMLYc5PGXYlK2A==
+    dependencies:
+      bl "^1.0.0"
+      buffer-alloc "^1.2.0"
+      end-of-stream "^1.0.0"
+      fs-constants "^1.0.0"
+      readable-stream "^2.3.0"
+      to-buffer "^1.1.1"
+      xtend "^4.0.0"
+  
+  tempfile@^1.0.0:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/tempfile/-/tempfile-1.1.1.tgz#5bcc4eaecc4ab2c707d8bc11d99ccc9a2cb287f2"
+    integrity sha1-W8xOrsxKsscH2LwR2ZzMmiyyh/I=
+    dependencies:
+      os-tmpdir "^1.0.0"
+      uuid "^2.0.1"
+  
+  through2-filter@^2.0.0:
+    version "2.0.0"
+    resolved "https://registry.yarnpkg.com/through2-filter/-/through2-filter-2.0.0.tgz#60bc55a0dacb76085db1f9dae99ab43f83d622ec"
+    integrity sha1-YLxVoNrLdghdsfna6Zq0P4PWIuw=
+    dependencies:
+      through2 "~2.0.0"
+      xtend "~4.0.0"
+  
+  through2-filter@^3.0.0:
+    version "3.0.0"
+    resolved "https://registry.yarnpkg.com/through2-filter/-/through2-filter-3.0.0.tgz#700e786df2367c2c88cd8aa5be4cf9c1e7831254"
+    integrity sha512-jaRjI2WxN3W1V8/FMZ9HKIBXixtiqs3SQSX4/YGIiP3gL6djW48VoZq9tDqeCWs3MT8YY5wb/zli8VW8snY1CA==
+    dependencies:
+      through2 "~2.0.0"
+      xtend "~4.0.0"
+  
+  through2@^0.6.0, through2@^0.6.1:
+    version "0.6.5"
+    resolved "https://registry.yarnpkg.com/through2/-/through2-0.6.5.tgz#41ab9c67b29d57209071410e1d7a7a968cd3ad48"
+    integrity sha1-QaucZ7KdVyCQcUEOHXp6lozTrUg=
+    dependencies:
+      readable-stream ">=1.0.33-1 <1.1.0-0"
+      xtend ">=4.0.0 <4.1.0-0"
+  
+  through2@^2.0.0, through2@~2.0.0:
+    version "2.0.5"
+    resolved "https://registry.yarnpkg.com/through2/-/through2-2.0.5.tgz#01c1e39eb31d07cb7d03a96a70823260b23132cd"
+    integrity sha512-/mrRod8xqpA+IHSLyGCQ2s8SPHiCDEeQJSep1jqLYeEUClOFG2Qsh+4FU6G9VeqpZnGW/Su8LQGc4YKni5rYSQ==
+    dependencies:
+      readable-stream "~2.3.6"
+      xtend "~4.0.1"
+  
+  time-stamp@^1.0.0:
+    version "1.1.0"
+    resolved "https://registry.yarnpkg.com/time-stamp/-/time-stamp-1.1.0.tgz#764a5a11af50561921b133f3b44e618687e0f5c3"
+    integrity sha1-dkpaEa9QVhkhsTPztE5hhofg9cM=
+  
+  timed-out@^3.0.0:
+    version "3.1.3"
+    resolved "https://registry.yarnpkg.com/timed-out/-/timed-out-3.1.3.tgz#95860bfcc5c76c277f8f8326fd0f5b2e20eba217"
+    integrity sha1-lYYL/MXHbCd/j4Mm/Q9bLiDrohc=
+  
+  to-absolute-glob@^0.1.1:
+    version "0.1.1"
+    resolved "https://registry.yarnpkg.com/to-absolute-glob/-/to-absolute-glob-0.1.1.tgz#1cdfa472a9ef50c239ee66999b662ca0eb39937f"
+    integrity sha1-HN+kcqnvUMI57maZm2YsoOs5k38=
+    dependencies:
+      extend-shallow "^2.0.1"
+  
+  to-buffer@^1.1.1:
+    version "1.1.1"
+    resolved "https://registry.yarnpkg.com/to-buffer/-/to-buffer-1.1.1.tgz#493bd48f62d7c43fcded313a03dcadb2e1213a80"
+    integrity sha512-lx9B5iv7msuFYE3dytT+KE5tap+rNYw+K4jVkb9R/asAb+pbBSM17jtunHplhBe6RRJdZx3Pn2Jph24O32mOVg==
+  
+  trim-newlines@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/trim-newlines/-/trim-newlines-1.0.0.tgz#5887966bb582a4503a41eb524f7d35011815a613"
+    integrity sha1-WIeWa7WCpFA6QetST301ARgVphM=
+  
+  trim-repeated@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/trim-repeated/-/trim-repeated-1.0.0.tgz#e3646a2ea4e891312bf7eace6cfb05380bc01c21"
+    integrity sha1-42RqLqTokTEr9+rObPsFOAvAHCE=
+    dependencies:
+      escape-string-regexp "^1.0.2"
+  
+  tunnel-agent@^0.4.0:
+    version "0.4.3"
+    resolved "https://registry.yarnpkg.com/tunnel-agent/-/tunnel-agent-0.4.3.tgz#6373db76909fe570e08d73583365ed828a74eeeb"
+    integrity sha1-Y3PbdpCf5XDgjXNYM2Xtgop07us=
+  
+  typedarray@^0.0.6:
+    version "0.0.6"
+    resolved "https://registry.yarnpkg.com/typedarray/-/typedarray-0.0.6.tgz#867ac74e3864187b1d3d47d996a78ec5c8830777"
+    integrity sha1-hnrHTjhkGHsdPUfZlqeOxciDB3c=
+  
+  uc.micro@^1.0.1, uc.micro@^1.0.5:
+    version "1.0.6"
+    resolved "https://registry.yarnpkg.com/uc.micro/-/uc.micro-1.0.6.tgz#9c411a802a409a91fc6cf74081baba34b24499ac"
+    integrity sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==
+  
+  unique-stream@^2.0.2:
+    version "2.3.1"
+    resolved "https://registry.yarnpkg.com/unique-stream/-/unique-stream-2.3.1.tgz#c65d110e9a4adf9a6c5948b28053d9a8d04cbeac"
+    integrity sha512-2nY4TnBE70yoxHkDli7DMazpWiP7xMdCYqU2nBRO0UB+ZpEkGsSija7MvmvnZFUeC+mrgiUfcHSr3LmRFIg4+A==
+    dependencies:
+      json-stable-stringify-without-jsonify "^1.0.1"
+      through2-filter "^3.0.0"
+  
+  unzip-response@^1.0.2:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/unzip-response/-/unzip-response-1.0.2.tgz#b984f0877fc0a89c2c773cc1ef7b5b232b5b06fe"
+    integrity sha1-uYTwh3/AqJwsdzzB73tbIytbBv4=
+  
+  url-parse-lax@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/url-parse-lax/-/url-parse-lax-1.0.0.tgz#7af8f303645e9bd79a272e7a14ac68bc0609da73"
+    integrity sha1-evjzA2Rem9eaJy56FKxovAYJ2nM=
+    dependencies:
+      prepend-http "^1.0.1"
+  
+  url-regex@^3.0.0:
+    version "3.2.0"
+    resolved "https://registry.yarnpkg.com/url-regex/-/url-regex-3.2.0.tgz#dbad1e0c9e29e105dd0b1f09f6862f7fdb482724"
+    integrity sha1-260eDJ4p4QXdCx8J9oYvf9tIJyQ=
+    dependencies:
+      ip-regex "^1.0.1"
+  
+  util-deprecate@~1.0.1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf"
+    integrity sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8=
+  
+  uuid@^2.0.1:
+    version "2.0.3"
+    resolved "https://registry.yarnpkg.com/uuid/-/uuid-2.0.3.tgz#67e2e863797215530dff318e5bf9dcebfd47b21a"
+    integrity sha1-Z+LoY3lyFVMN/zGOW/nc6/1Hsho=
+  
+  vali-date@^1.0.0:
+    version "1.0.0"
+    resolved "https://registry.yarnpkg.com/vali-date/-/vali-date-1.0.0.tgz#1b904a59609fb328ef078138420934f6b86709a6"
+    integrity sha1-G5BKWWCfsyjvB4E4Qgk09rhnCaY=
+  
+  validate-npm-package-license@^3.0.1:
+    version "3.0.4"
+    resolved "https://registry.yarnpkg.com/validate-npm-package-license/-/validate-npm-package-license-3.0.4.tgz#fc91f6b9c7ba15c857f4cb2c5defeec39d4f410a"
+    integrity sha512-DpKm2Ui/xN7/HQKCtpZxoRWBhZ9Z0kqtygG8XCgNQ8ZlDnxuQmWhj566j8fN4Cu3/JmbhsDo7fcAJq4s9h27Ew==
+    dependencies:
+      spdx-correct "^3.0.0"
+      spdx-expression-parse "^3.0.0"
+  
+  vinyl-assign@^1.0.1:
+    version "1.2.1"
+    resolved "https://registry.yarnpkg.com/vinyl-assign/-/vinyl-assign-1.2.1.tgz#4d198891b5515911d771a8cd9c5480a46a074a45"
+    integrity sha1-TRmIkbVRWRHXcajNnFSApGoHSkU=
+    dependencies:
+      object-assign "^4.0.1"
+      readable-stream "^2.0.0"
+  
+  vinyl-fs@^2.1.1, vinyl-fs@^2.2.0:
+    version "2.4.4"
+    resolved "https://registry.yarnpkg.com/vinyl-fs/-/vinyl-fs-2.4.4.tgz#be6ff3270cb55dfd7d3063640de81f25d7532239"
+    integrity sha1-vm/zJwy1Xf19MGNkDegfJddTIjk=
+    dependencies:
+      duplexify "^3.2.0"
+      glob-stream "^5.3.2"
+      graceful-fs "^4.0.0"
+      gulp-sourcemaps "1.6.0"
+      is-valid-glob "^0.3.0"
+      lazystream "^1.0.0"
+      lodash.isequal "^4.0.0"
+      merge-stream "^1.0.0"
+      mkdirp "^0.5.0"
+      object-assign "^4.0.0"
+      readable-stream "^2.0.4"
+      strip-bom "^2.0.0"
+      strip-bom-stream "^1.0.0"
+      through2 "^2.0.0"
+      through2-filter "^2.0.0"
+      vali-date "^1.0.0"
+      vinyl "^1.0.0"
+  
+  vinyl@^0.4.3:
+    version "0.4.6"
+    resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-0.4.6.tgz#2f356c87a550a255461f36bbeb2a5ba8bf784847"
+    integrity sha1-LzVsh6VQolVGHza76ypbqL94SEc=
+    dependencies:
+      clone "^0.2.0"
+      clone-stats "^0.0.1"
+  
+  vinyl@^0.5.0:
+    version "0.5.3"
+    resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-0.5.3.tgz#b0455b38fc5e0cf30d4325132e461970c2091cde"
+    integrity sha1-sEVbOPxeDPMNQyUTLkYZcMIJHN4=
+    dependencies:
+      clone "^1.0.0"
+      clone-stats "^0.0.1"
+      replace-ext "0.0.1"
+  
+  vinyl@^1.0.0:
+    version "1.2.0"
+    resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-1.2.0.tgz#5c88036cf565e5df05558bfc911f8656df218884"
+    integrity sha1-XIgDbPVl5d8FVYv8kR+GVt8hiIQ=
+    dependencies:
+      clone "^1.0.0"
+      clone-stats "^0.0.1"
+      replace-ext "0.0.1"
+  
+  ware@^1.2.0:
+    version "1.3.0"
+    resolved "https://registry.yarnpkg.com/ware/-/ware-1.3.0.tgz#d1b14f39d2e2cb4ab8c4098f756fe4b164e473d4"
+    integrity sha1-0bFPOdLiy0q4xAmPdW/ksWTkc9Q=
+    dependencies:
+      wrap-fn "^0.1.0"
+  
+  whet.extend@~0.9.9:
+    version "0.9.9"
+    resolved "https://registry.yarnpkg.com/whet.extend/-/whet.extend-0.9.9.tgz#f877d5bf648c97e5aa542fadc16d6a259b9c11a1"
+    integrity sha1-+HfVv2SMl+WqVC+twW1qJZucEaE=
+  
+  which@^1.2.10, which@^1.2.9:
+    version "1.3.1"
+    resolved "https://registry.yarnpkg.com/which/-/which-1.3.1.tgz#a45043d54f5805316da8d62f9f50918d3da70b0a"
+    integrity sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==
+    dependencies:
+      isexe "^2.0.0"
+  
+  wrap-fn@^0.1.0:
+    version "0.1.5"
+    resolved "https://registry.yarnpkg.com/wrap-fn/-/wrap-fn-0.1.5.tgz#f21b6e41016ff4a7e31720dbc63a09016bdf9845"
+    integrity sha1-8htuQQFv9KfjFyDbxjoJAWvfmEU=
+    dependencies:
+      co "3.1.0"
+  
+  wrappy@1:
+    version "1.0.2"
+    resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"
+    integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=
+  
+  "xtend@>=4.0.0 <4.1.0-0", xtend@^4.0.0, xtend@~4.0.0, xtend@~4.0.1:
+    version "4.0.1"
+    resolved "https://registry.yarnpkg.com/xtend/-/xtend-4.0.1.tgz#a5c6d532be656e23db820efb943a1f04998d63af"
+    integrity sha1-pcbVMr5lbiPbgg77lDofBJmNY68=
+  
+  yallist@^2.1.2:
+    version "2.1.2"
+    resolved "https://registry.yarnpkg.com/yallist/-/yallist-2.1.2.tgz#1c11f9218f076089a47dd512f93c6699a6a81d52"
+    integrity sha1-HBH5IY8HYImkfdUS+TxmmaaoHVI=
+  
+  yauzl@^2.2.1:
+    version "2.10.0"
+    resolved "https://registry.yarnpkg.com/yauzl/-/yauzl-2.10.0.tgz#c7eb17c93e112cb1086fa6d8e51fb0667b79a5f9"
+    integrity sha1-x+sXyT4RLLEIb6bY5R+wZnt5pfk=
+    dependencies:
+      buffer-crc32 "~0.2.3"
+      fd-slicer "~1.1.0"
+
+Trace: 
+  Error: Command "dev" not found.
+      at new MessageError (/usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:186:110)
+      at /usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:87307:17
+      at Generator.next ()
+      at step (/usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:98:30)
+      at /usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:116:14
+      at new Promise ()
+      at new F (/usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:23451:28)
+      at /usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:95:12
+      at runCommand (/usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:87312:22)
+      at Object. (/usr/local/Cellar/yarn/1.5.1_1/libexec/lib/cli.js:87412:14)
diff --git a/yarn.lock b/yarn.lock
new file mode 100644
index 0000000000..4d55786411
--- /dev/null
+++ b/yarn.lock
@@ -0,0 +1,3996 @@
+# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
+# yarn lockfile v1
+
+
+"@babel/code-frame@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/code-frame/-/code-frame-7.16.0.tgz#0dfc80309beec8411e65e706461c408b0bb9b431"
+  integrity sha512-IF4EOMEV+bfYwOmNxGzSnjR2EmQod7f1UXOpZM3l4i4o4QNwzjtJAu/HxdjHq0aYBvdqMuQEY1eg0nqW9ZPORA==
+  dependencies:
+    "@babel/highlight" "^7.16.0"
+
+"@babel/compat-data@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/compat-data/-/compat-data-7.16.0.tgz#ea269d7f78deb3a7826c39a4048eecda541ebdaa"
+  integrity sha512-DGjt2QZse5SGd9nfOSqO4WLJ8NN/oHkijbXbPrxuoJO3oIPJL3TciZs9FX+cOHNiY9E9l0opL8g7BmLe3T+9ew==
+
+"@babel/core@^7.13.16":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/core/-/core-7.16.0.tgz#c4ff44046f5fe310525cc9eb4ef5147f0c5374d4"
+  integrity sha512-mYZEvshBRHGsIAiyH5PzCFTCfbWfoYbO/jcSdXQSUQu1/pW0xDZAUP7KEc32heqWTAfAHhV9j1vH8Sav7l+JNQ==
+  dependencies:
+    "@babel/code-frame" "^7.16.0"
+    "@babel/generator" "^7.16.0"
+    "@babel/helper-compilation-targets" "^7.16.0"
+    "@babel/helper-module-transforms" "^7.16.0"
+    "@babel/helpers" "^7.16.0"
+    "@babel/parser" "^7.16.0"
+    "@babel/template" "^7.16.0"
+    "@babel/traverse" "^7.16.0"
+    "@babel/types" "^7.16.0"
+    convert-source-map "^1.7.0"
+    debug "^4.1.0"
+    gensync "^1.0.0-beta.2"
+    json5 "^2.1.2"
+    semver "^6.3.0"
+    source-map "^0.5.0"
+
+"@babel/generator@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/generator/-/generator-7.16.0.tgz#d40f3d1d5075e62d3500bccb67f3daa8a95265b2"
+  integrity sha512-RR8hUCfRQn9j9RPKEVXo9LiwoxLPYn6hNZlvUOR8tSnaxlD0p0+la00ZP9/SnRt6HchKr+X0fO2r8vrETiJGew==
+  dependencies:
+    "@babel/types" "^7.16.0"
+    jsesc "^2.5.1"
+    source-map "^0.5.0"
+
+"@babel/helper-annotate-as-pure@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.16.0.tgz#9a1f0ebcda53d9a2d00108c4ceace6a5d5f1f08d"
+  integrity sha512-ItmYF9vR4zA8cByDocY05o0LGUkp1zhbTQOH1NFyl5xXEqlTJQCEJjieriw+aFpxo16swMxUnUiKS7a/r4vtHg==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-compilation-targets@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-compilation-targets/-/helper-compilation-targets-7.16.0.tgz#01d615762e796c17952c29e3ede9d6de07d235a8"
+  integrity sha512-S7iaOT1SYlqK0sQaCi21RX4+13hmdmnxIEAnQUB/eh7GeAnRjOUgTYpLkUOiRXzD+yog1JxP0qyAQZ7ZxVxLVg==
+  dependencies:
+    "@babel/compat-data" "^7.16.0"
+    "@babel/helper-validator-option" "^7.14.5"
+    browserslist "^4.16.6"
+    semver "^6.3.0"
+
+"@babel/helper-create-class-features-plugin@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.16.0.tgz#090d4d166b342a03a9fec37ef4fd5aeb9c7c6a4b"
+  integrity sha512-XLwWvqEaq19zFlF5PTgOod4bUA+XbkR4WLQBct1bkzmxJGB0ZEJaoKF4c8cgH9oBtCDuYJ8BP5NB9uFiEgO5QA==
+  dependencies:
+    "@babel/helper-annotate-as-pure" "^7.16.0"
+    "@babel/helper-function-name" "^7.16.0"
+    "@babel/helper-member-expression-to-functions" "^7.16.0"
+    "@babel/helper-optimise-call-expression" "^7.16.0"
+    "@babel/helper-replace-supers" "^7.16.0"
+    "@babel/helper-split-export-declaration" "^7.16.0"
+
+"@babel/helper-function-name@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-function-name/-/helper-function-name-7.16.0.tgz#b7dd0797d00bbfee4f07e9c4ea5b0e30c8bb1481"
+  integrity sha512-BZh4mEk1xi2h4HFjWUXRQX5AEx4rvaZxHgax9gcjdLWdkjsY7MKt5p0otjsg5noXw+pB+clMCjw+aEVYADMjog==
+  dependencies:
+    "@babel/helper-get-function-arity" "^7.16.0"
+    "@babel/template" "^7.16.0"
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-get-function-arity@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-get-function-arity/-/helper-get-function-arity-7.16.0.tgz#0088c7486b29a9cb5d948b1a1de46db66e089cfa"
+  integrity sha512-ASCquNcywC1NkYh/z7Cgp3w31YW8aojjYIlNg4VeJiHkqyP4AzIvr4qx7pYDb4/s8YcsZWqqOSxgkvjUz1kpDQ==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-hoist-variables@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-hoist-variables/-/helper-hoist-variables-7.16.0.tgz#4c9023c2f1def7e28ff46fc1dbcd36a39beaa81a"
+  integrity sha512-1AZlpazjUR0EQZQv3sgRNfM9mEVWPK3M6vlalczA+EECcPz3XPh6VplbErL5UoMpChhSck5wAJHthlj1bYpcmg==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-member-expression-to-functions@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.16.0.tgz#29287040efd197c77636ef75188e81da8bccd5a4"
+  integrity sha512-bsjlBFPuWT6IWhl28EdrQ+gTvSvj5tqVP5Xeftp07SEuz5pLnsXZuDkDD3Rfcxy0IsHmbZ+7B2/9SHzxO0T+sQ==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-module-imports@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-module-imports/-/helper-module-imports-7.16.0.tgz#90538e60b672ecf1b448f5f4f5433d37e79a3ec3"
+  integrity sha512-kkH7sWzKPq0xt3H1n+ghb4xEMP8k0U7XV3kkB+ZGy69kDk2ySFW1qPi06sjKzFY3t1j6XbJSqr4mF9L7CYVyhg==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-module-transforms@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-module-transforms/-/helper-module-transforms-7.16.0.tgz#1c82a8dd4cb34577502ebd2909699b194c3e9bb5"
+  integrity sha512-My4cr9ATcaBbmaEa8M0dZNA74cfI6gitvUAskgDtAFmAqyFKDSHQo5YstxPbN+lzHl2D9l/YOEFqb2mtUh4gfA==
+  dependencies:
+    "@babel/helper-module-imports" "^7.16.0"
+    "@babel/helper-replace-supers" "^7.16.0"
+    "@babel/helper-simple-access" "^7.16.0"
+    "@babel/helper-split-export-declaration" "^7.16.0"
+    "@babel/helper-validator-identifier" "^7.15.7"
+    "@babel/template" "^7.16.0"
+    "@babel/traverse" "^7.16.0"
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-optimise-call-expression@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.16.0.tgz#cecdb145d70c54096b1564f8e9f10cd7d193b338"
+  integrity sha512-SuI467Gi2V8fkofm2JPnZzB/SUuXoJA5zXe/xzyPP2M04686RzFKFHPK6HDVN6JvWBIEW8tt9hPR7fXdn2Lgpw==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-plugin-utils@^7.14.5", "@babel/helper-plugin-utils@^7.8.0":
+  version "7.14.5"
+  resolved "https://registry.yarnpkg.com/@babel/helper-plugin-utils/-/helper-plugin-utils-7.14.5.tgz#5ac822ce97eec46741ab70a517971e443a70c5a9"
+  integrity sha512-/37qQCE3K0vvZKwoK4XU/irIJQdIfCJuhU5eKnNxpFDsOkgFaUAwbv+RYw6eYgsC0E4hS7r5KqGULUogqui0fQ==
+
+"@babel/helper-replace-supers@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-replace-supers/-/helper-replace-supers-7.16.0.tgz#73055e8d3cf9bcba8ddb55cad93fedc860f68f17"
+  integrity sha512-TQxuQfSCdoha7cpRNJvfaYxxxzmbxXw/+6cS7V02eeDYyhxderSoMVALvwupA54/pZcOTtVeJ0xccp1nGWladA==
+  dependencies:
+    "@babel/helper-member-expression-to-functions" "^7.16.0"
+    "@babel/helper-optimise-call-expression" "^7.16.0"
+    "@babel/traverse" "^7.16.0"
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-simple-access@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-simple-access/-/helper-simple-access-7.16.0.tgz#21d6a27620e383e37534cf6c10bba019a6f90517"
+  integrity sha512-o1rjBT/gppAqKsYfUdfHq5Rk03lMQrkPHG1OWzHWpLgVXRH4HnMM9Et9CVdIqwkCQlobnGHEJMsgWP/jE1zUiw==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-skip-transparent-expression-wrappers@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.16.0.tgz#0ee3388070147c3ae051e487eca3ebb0e2e8bb09"
+  integrity sha512-+il1gTy0oHwUsBQZyJvukbB4vPMdcYBrFHa0Uc4AizLxbq6BOYC51Rv4tWocX9BLBDLZ4kc6qUFpQ6HRgL+3zw==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-split-export-declaration@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helper-split-export-declaration/-/helper-split-export-declaration-7.16.0.tgz#29672f43663e936df370aaeb22beddb3baec7438"
+  integrity sha512-0YMMRpuDFNGTHNRiiqJX19GjNXA4H0E8jZ2ibccfSxaCogbm3am5WN/2nQNj0YnQwGWM1J06GOcQ2qnh3+0paw==
+  dependencies:
+    "@babel/types" "^7.16.0"
+
+"@babel/helper-validator-identifier@^7.15.7":
+  version "7.15.7"
+  resolved "https://registry.yarnpkg.com/@babel/helper-validator-identifier/-/helper-validator-identifier-7.15.7.tgz#220df993bfe904a4a6b02ab4f3385a5ebf6e2389"
+  integrity sha512-K4JvCtQqad9OY2+yTU8w+E82ywk/fe+ELNlt1G8z3bVGlZfn/hOcQQsUhGhW/N+tb3fxK800wLtKOE/aM0m72w==
+
+"@babel/helper-validator-option@^7.14.5":
+  version "7.14.5"
+  resolved "https://registry.yarnpkg.com/@babel/helper-validator-option/-/helper-validator-option-7.14.5.tgz#6e72a1fff18d5dfcb878e1e62f1a021c4b72d5a3"
+  integrity sha512-OX8D5eeX4XwcroVW45NMvoYaIuFI+GQpA2a8Gi+X/U/cDUIRsV37qQfF905F0htTRCREQIB4KqPeaveRJUl3Ow==
+
+"@babel/helpers@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/helpers/-/helpers-7.16.0.tgz#875519c979c232f41adfbd43a3b0398c2e388183"
+  integrity sha512-dVRM0StFMdKlkt7cVcGgwD8UMaBfWJHl3A83Yfs8GQ3MO0LHIIIMvK7Fa0RGOGUQ10qikLaX6D7o5htcQWgTMQ==
+  dependencies:
+    "@babel/template" "^7.16.0"
+    "@babel/traverse" "^7.16.0"
+    "@babel/types" "^7.16.0"
+
+"@babel/highlight@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/highlight/-/highlight-7.16.0.tgz#6ceb32b2ca4b8f5f361fb7fd821e3fddf4a1725a"
+  integrity sha512-t8MH41kUQylBtu2+4IQA3atqevA2lRgqA2wyVB/YiWmsDSuylZZuXOUy9ric30hfzauEFfdsuk/eXTRrGrfd0g==
+  dependencies:
+    "@babel/helper-validator-identifier" "^7.15.7"
+    chalk "^2.0.0"
+    js-tokens "^4.0.0"
+
+"@babel/parser@^7.13.16", "@babel/parser@^7.16.0":
+  version "7.16.2"
+  resolved "https://registry.yarnpkg.com/@babel/parser/-/parser-7.16.2.tgz#3723cd5c8d8773eef96ce57ea1d9b7faaccd12ac"
+  integrity sha512-RUVpT0G2h6rOZwqLDTrKk7ksNv7YpAilTnYe1/Q+eDjxEceRMKVWbCsX7t8h6C1qCFi/1Y8WZjcEPBAFG27GPw==
+
+"@babel/plugin-proposal-class-properties@^7.13.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-class-properties/-/plugin-proposal-class-properties-7.16.0.tgz#c029618267ddebc7280fa286e0f8ca2a278a2d1a"
+  integrity sha512-mCF3HcuZSY9Fcx56Lbn+CGdT44ioBMMvjNVldpKtj8tpniETdLjnxdHI1+sDWXIM1nNt+EanJOZ3IG9lzVjs7A==
+  dependencies:
+    "@babel/helper-create-class-features-plugin" "^7.16.0"
+    "@babel/helper-plugin-utils" "^7.14.5"
+
+"@babel/plugin-proposal-nullish-coalescing-operator@^7.13.8":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-nullish-coalescing-operator/-/plugin-proposal-nullish-coalescing-operator-7.16.0.tgz#44e1cce08fe2427482cf446a91bb451528ed0596"
+  integrity sha512-3bnHA8CAFm7cG93v8loghDYyQ8r97Qydf63BeYiGgYbjKKB/XP53W15wfRC7dvKfoiJ34f6Rbyyx2btExc8XsQ==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/plugin-syntax-nullish-coalescing-operator" "^7.8.3"
+
+"@babel/plugin-proposal-optional-chaining@^7.13.12":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-optional-chaining/-/plugin-proposal-optional-chaining-7.16.0.tgz#56dbc3970825683608e9efb55ea82c2a2d6c8dc0"
+  integrity sha512-Y4rFpkZODfHrVo70Uaj6cC1JJOt3Pp0MdWSwIKtb8z1/lsjl9AmnB7ErRFV+QNGIfcY1Eruc2UMx5KaRnXjMyg==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.16.0"
+    "@babel/plugin-syntax-optional-chaining" "^7.8.3"
+
+"@babel/plugin-syntax-flow@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-flow/-/plugin-syntax-flow-7.16.0.tgz#07427021d093ed77019408221beaf0272bbcfaec"
+  integrity sha512-dH91yCo0RyqfzWgoM5Ji9ir8fQ+uFbt9KHM3d2x4jZOuHS6wNA+CRmRUP/BWCsHG2bjc7A2Way6AvH1eQk0wig==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+
+"@babel/plugin-syntax-nullish-coalescing-operator@^7.8.3":
+  version "7.8.3"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-nullish-coalescing-operator/-/plugin-syntax-nullish-coalescing-operator-7.8.3.tgz#167ed70368886081f74b5c36c65a88c03b66d1a9"
+  integrity sha512-aSff4zPII1u2QD7y+F8oDsz19ew4IGEJg9SVW+bqwpwtfFleiQDMdzA/R+UlWDzfnHFCxxleFT0PMIrR36XLNQ==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.8.0"
+
+"@babel/plugin-syntax-optional-chaining@^7.8.3":
+  version "7.8.3"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-optional-chaining/-/plugin-syntax-optional-chaining-7.8.3.tgz#4f69c2ab95167e0180cd5336613f8c5788f7d48a"
+  integrity sha512-KoK9ErH1MBlCPxV0VANkXW2/dw4vlbGDrFgz8bmUsBGYkFRcbRwMh6cIJubdPrkxRwuGdtCk0v/wPTKbQgBjkg==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.8.0"
+
+"@babel/plugin-syntax-typescript@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-typescript/-/plugin-syntax-typescript-7.16.0.tgz#2feeb13d9334cc582ea9111d3506f773174179bb"
+  integrity sha512-Xv6mEXqVdaqCBfJFyeab0fH2DnUoMsDmhamxsSi4j8nLd4Vtw213WMJr55xxqipC/YVWyPY3K0blJncPYji+dQ==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+
+"@babel/plugin-transform-flow-strip-types@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-transform-flow-strip-types/-/plugin-transform-flow-strip-types-7.16.0.tgz#edd968dc2041c1b69e451a262e948d6654a79dc2"
+  integrity sha512-vs/F5roOaO/+WxKfp9PkvLsAyj0G+Q0zbFimHm9X2KDgabN2XmNFoAafmeGEYspUlIF9+MvVmyek9UyHiqeG/w==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/plugin-syntax-flow" "^7.16.0"
+
+"@babel/plugin-transform-modules-commonjs@^7.13.8":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.16.0.tgz#add58e638c8ddc4875bd9a9ecb5c594613f6c922"
+  integrity sha512-Dzi+NWqyEotgzk/sb7kgQPJQf7AJkQBWsVp1N6JWc1lBVo0vkElUnGdr1PzUBmfsCCN5OOFya3RtpeHk15oLKQ==
+  dependencies:
+    "@babel/helper-module-transforms" "^7.16.0"
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/helper-simple-access" "^7.16.0"
+    babel-plugin-dynamic-import-node "^2.3.3"
+
+"@babel/plugin-transform-typescript@^7.16.0":
+  version "7.16.1"
+  resolved "https://registry.yarnpkg.com/@babel/plugin-transform-typescript/-/plugin-transform-typescript-7.16.1.tgz#cc0670b2822b0338355bc1b3d2246a42b8166409"
+  integrity sha512-NO4XoryBng06jjw/qWEU2LhcLJr1tWkhpMam/H4eas/CDKMX/b2/Ylb6EI256Y7+FVPCawwSM1rrJNOpDiz+Lg==
+  dependencies:
+    "@babel/helper-create-class-features-plugin" "^7.16.0"
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/plugin-syntax-typescript" "^7.16.0"
+
+"@babel/preset-flow@^7.13.13":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/preset-flow/-/preset-flow-7.16.0.tgz#9f1f6e72714d79460d48058cb5658fc87da7150b"
+  integrity sha512-e5NE1EoPMpoHFkyFkMSj2h9tu7OolARcUHki8mnBv4NiFK9so+UrhbvT9mV99tMJOUEx8BOj67T6dXvGcTeYeQ==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/helper-validator-option" "^7.14.5"
+    "@babel/plugin-transform-flow-strip-types" "^7.16.0"
+
+"@babel/preset-typescript@^7.13.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/preset-typescript/-/preset-typescript-7.16.0.tgz#b0b4f105b855fb3d631ec036cdc9d1ffd1fa5eac"
+  integrity sha512-txegdrZYgO9DlPbv+9QOVpMnKbOtezsLHWsnsRF4AjbSIsVaujrq1qg8HK0mxQpWv0jnejt0yEoW1uWpvbrDTg==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.14.5"
+    "@babel/helper-validator-option" "^7.14.5"
+    "@babel/plugin-transform-typescript" "^7.16.0"
+
+"@babel/register@^7.13.16":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/register/-/register-7.16.0.tgz#f5d2aa14df37cf7146b9759f7c53818360f24ec6"
+  integrity sha512-lzl4yfs0zVXnooeLE0AAfYaT7F3SPA8yB2Bj4W1BiZwLbMS3MZH35ZvCWSRHvneUugwuM+Wsnrj7h0F7UmU3NQ==
+  dependencies:
+    clone-deep "^4.0.1"
+    find-cache-dir "^2.0.0"
+    make-dir "^2.1.0"
+    pirates "^4.0.0"
+    source-map-support "^0.5.16"
+
+"@babel/template@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/template/-/template-7.16.0.tgz#d16a35ebf4cd74e202083356fab21dd89363ddd6"
+  integrity sha512-MnZdpFD/ZdYhXwiunMqqgyZyucaYsbL0IrjoGjaVhGilz+x8YB++kRfygSOIj1yOtWKPlx7NBp+9I1RQSgsd5A==
+  dependencies:
+    "@babel/code-frame" "^7.16.0"
+    "@babel/parser" "^7.16.0"
+    "@babel/types" "^7.16.0"
+
+"@babel/traverse@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/traverse/-/traverse-7.16.0.tgz#965df6c6bfc0a958c1e739284d3c9fa4a6e3c45b"
+  integrity sha512-qQ84jIs1aRQxaGaxSysII9TuDaguZ5yVrEuC0BN2vcPlalwfLovVmCjbFDPECPXcYM/wLvNFfp8uDOliLxIoUQ==
+  dependencies:
+    "@babel/code-frame" "^7.16.0"
+    "@babel/generator" "^7.16.0"
+    "@babel/helper-function-name" "^7.16.0"
+    "@babel/helper-hoist-variables" "^7.16.0"
+    "@babel/helper-split-export-declaration" "^7.16.0"
+    "@babel/parser" "^7.16.0"
+    "@babel/types" "^7.16.0"
+    debug "^4.1.0"
+    globals "^11.1.0"
+
+"@babel/types@^7.16.0":
+  version "7.16.0"
+  resolved "https://registry.yarnpkg.com/@babel/types/-/types-7.16.0.tgz#db3b313804f96aadd0b776c4823e127ad67289ba"
+  integrity sha512-PJgg/k3SdLsGb3hhisFvtLOw5ts113klrpLuIPtCJIU+BB24fqq6lf8RWqKJEjzqXR9AEH1rIb5XTqwBHB+kQg==
+  dependencies:
+    "@babel/helper-validator-identifier" "^7.15.7"
+    to-fast-properties "^2.0.0"
+
+ansi-escapes@^1.0.0:
+  version "1.4.0"
+  resolved "https://registry.yarnpkg.com/ansi-escapes/-/ansi-escapes-1.4.0.tgz#d3a8a83b319aa67793662b13e761c7911422306e"
+  integrity sha1-06ioOzGapneTZisT52HHkRQiMG4=
+
+ansi-gray@^0.1.1:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/ansi-gray/-/ansi-gray-0.1.1.tgz#2962cf54ec9792c48510a3deb524436861ef7251"
+  integrity sha1-KWLPVOyXksSFEKPetSRDaGHvclE=
+  dependencies:
+    ansi-wrap "0.1.0"
+
+ansi-regex@^2.0.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df"
+  integrity sha1-w7M6te42DYbg5ijwRorn7yfWVN8=
+
+ansi-styles@^2.2.1:
+  version "2.2.1"
+  resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe"
+  integrity sha1-tDLdM1i2NM914eRmQ2gkBTPB3b4=
+
+ansi-styles@^3.2.1:
+  version "3.2.1"
+  resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-3.2.1.tgz#41fbb20243e50b12be0f04b8dedbf07520ce841d"
+  integrity sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==
+  dependencies:
+    color-convert "^1.9.0"
+
+ansi-wrap@0.1.0:
+  version "0.1.0"
+  resolved "https://registry.yarnpkg.com/ansi-wrap/-/ansi-wrap-0.1.0.tgz#a82250ddb0015e9a27ca82e82ea603bbfa45efaf"
+  integrity sha1-qCJQ3bABXponyoLoLqYDu/pF768=
+
+app-root-path@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/app-root-path/-/app-root-path-2.1.0.tgz#98bf6599327ecea199309866e8140368fd2e646a"
+  integrity sha1-mL9lmTJ+zqGZMJhm6BQDaP0uZGo=
+
+archive-type@^3.0.0, archive-type@^3.0.1:
+  version "3.2.0"
+  resolved "https://registry.yarnpkg.com/archive-type/-/archive-type-3.2.0.tgz#9cd9c006957ebe95fadad5bd6098942a813737f6"
+  integrity sha1-nNnABpV+vpX62tW9YJiUKoE3N/Y=
+  dependencies:
+    file-type "^3.1.0"
+
+argparse@^1.0.7:
+  version "1.0.10"
+  resolved "https://registry.yarnpkg.com/argparse/-/argparse-1.0.10.tgz#bcd6791ea5ae09725e17e5ad988134cd40b3d911"
+  integrity sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==
+  dependencies:
+    sprintf-js "~1.0.2"
+
+arr-diff@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/arr-diff/-/arr-diff-2.0.0.tgz#8f3b827f955a8bd669697e4a4256ac3ceae356cf"
+  integrity sha1-jzuCf5Vai9ZpaX5KQlasPOrjVs8=
+  dependencies:
+    arr-flatten "^1.0.1"
+
+arr-diff@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/arr-diff/-/arr-diff-4.0.0.tgz#d6461074febfec71e7e15235761a329a5dc7c520"
+  integrity sha1-1kYQdP6/7HHn4VI1dhoyml3HxSA=
+
+arr-flatten@^1.0.1, arr-flatten@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/arr-flatten/-/arr-flatten-1.1.0.tgz#36048bbff4e7b47e136644316c99669ea5ae91f1"
+  integrity sha512-L3hKV5R/p5o81R7O02IGnwpDmkp6E982XhtbuwSe3O4qOtMMMtodicASA1Cny2U+aCXcNpml+m4dPsvsJ3jatg==
+
+arr-union@^3.1.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/arr-union/-/arr-union-3.1.0.tgz#e39b09aea9def866a8f206e288af63919bae39c4"
+  integrity sha1-45sJrqne+Gao8gbiiK9jkZuuOcQ=
+
+array-differ@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/array-differ/-/array-differ-1.0.0.tgz#eff52e3758249d33be402b8bb8e564bb2b5d4031"
+  integrity sha1-7/UuN1gknTO+QCuLuOVkuytdQDE=
+
+array-find-index@^1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/array-find-index/-/array-find-index-1.0.2.tgz#df010aa1287e164bbda6f9723b0a96a1ec4187a1"
+  integrity sha1-3wEKoSh+Fku9pvlyOwqWoexBh6E=
+
+array-uniq@^1.0.0, array-uniq@^1.0.2:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/array-uniq/-/array-uniq-1.0.3.tgz#af6ac877a25cc7f74e058894753858dfdb24fdb6"
+  integrity sha1-r2rId6Jcx/dOBYiUdThY39sk/bY=
+
+array-unique@^0.2.1:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/array-unique/-/array-unique-0.2.1.tgz#a1d97ccafcbc2625cc70fadceb36a50c58b01a53"
+  integrity sha1-odl8yvy8JiXMcPrc6zalDFiwGlM=
+
+array-unique@^0.3.2:
+  version "0.3.2"
+  resolved "https://registry.yarnpkg.com/array-unique/-/array-unique-0.3.2.tgz#a894b75d4bc4f6cd679ef3244a9fd8f46ae2d428"
+  integrity sha1-qJS3XUvE9s1nnvMkSp/Y9Gri1Cg=
+
+assign-symbols@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/assign-symbols/-/assign-symbols-1.0.0.tgz#59667f41fadd4f20ccbc2bb96b8d4f7f78ec0367"
+  integrity sha1-WWZ/QfrdTyDMvCu5a41Pf3jsA2c=
+
+ast-types@0.14.2:
+  version "0.14.2"
+  resolved "https://registry.yarnpkg.com/ast-types/-/ast-types-0.14.2.tgz#600b882df8583e3cd4f2df5fa20fa83759d4bdfd"
+  integrity sha512-O0yuUDnZeQDL+ncNGlJ78BiO4jnYI3bvMsD5prT0/nsgijG/LpNBIr63gTjVTNsiGkgQhiyCShTgxt8oXOrklA==
+  dependencies:
+    tslib "^2.0.1"
+
+async-each-series@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/async-each-series/-/async-each-series-1.1.0.tgz#f42fd8155d38f21a5b8ea07c28e063ed1700b138"
+  integrity sha1-9C/YFV048hpbjqB8KOBj7RcAsTg=
+
+atob@^2.1.2:
+  version "2.1.2"
+  resolved "https://registry.yarnpkg.com/atob/-/atob-2.1.2.tgz#6d9517eb9e030d2436666651e86bd9f6f13533c9"
+  integrity sha512-Wm6ukoaOGJi/73p/cl2GvLjTI5JM1k/O14isD73YML8StrH/7/lRFgmg8nICZgD3bZZvjwCGxtMOD3wWNAu8cg==
+
+babel-core@^7.0.0-bridge.0:
+  version "7.0.0-bridge.0"
+  resolved "https://registry.yarnpkg.com/babel-core/-/babel-core-7.0.0-bridge.0.tgz#95a492ddd90f9b4e9a4a1da14eb335b87b634ece"
+  integrity sha512-poPX9mZH/5CSanm50Q+1toVci6pv5KSRv/5TWCwtzQS5XEwn40BcCrgIeMFWP9CKKIniKXNxoIOnOq4VVlGXhg==
+
+babel-plugin-dynamic-import-node@^2.3.3:
+  version "2.3.3"
+  resolved "https://registry.yarnpkg.com/babel-plugin-dynamic-import-node/-/babel-plugin-dynamic-import-node-2.3.3.tgz#84fda19c976ec5c6defef57f9427b3def66e17a3"
+  integrity sha512-jZVI+s9Zg3IqA/kdi0i6UDCybUI3aSBLnglhYbSSjKlV7yF1F/5LWv8MakQmvYpnbJDS6fcBL2KzHSxNCMtWSQ==
+  dependencies:
+    object.assign "^4.1.0"
+
+balanced-match@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.0.tgz#89b4d199ab2bee49de164ea02b89ce462d71b767"
+  integrity sha1-ibTRmasr7kneFk6gK4nORi1xt2c=
+
+base@^0.11.1:
+  version "0.11.2"
+  resolved "https://registry.yarnpkg.com/base/-/base-0.11.2.tgz#7bde5ced145b6d551a90db87f83c558b4eb48a8f"
+  integrity sha512-5T6P4xPgpp0YDFvSWwEZ4NoE3aM4QBQXDzmVbraCkFj8zHM+mba8SyqB5DbZWyR7mYHo6Y7BdQo3MoA4m0TeQg==
+  dependencies:
+    cache-base "^1.0.1"
+    class-utils "^0.3.5"
+    component-emitter "^1.2.1"
+    define-property "^1.0.0"
+    isobject "^3.0.1"
+    mixin-deep "^1.2.0"
+    pascalcase "^0.1.1"
+
+beeper@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/beeper/-/beeper-1.1.1.tgz#e6d5ea8c5dad001304a70b22638447f69cb2f809"
+  integrity sha1-5tXqjF2tABMEpwsiY4RH9pyy+Ak=
+
+bin-build@^2.0.0:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/bin-build/-/bin-build-2.2.0.tgz#11f8dd61f70ffcfa2bdcaa5b46f5e8fedd4221cc"
+  integrity sha1-EfjdYfcP/Por3KpbRvXo/t1CIcw=
+  dependencies:
+    archive-type "^3.0.1"
+    decompress "^3.0.0"
+    download "^4.1.2"
+    exec-series "^1.0.0"
+    rimraf "^2.2.6"
+    tempfile "^1.0.0"
+    url-regex "^3.0.0"
+
+bin-check@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/bin-check/-/bin-check-2.0.0.tgz#86f8e6f4253893df60dc316957f5af02acb05930"
+  integrity sha1-hvjm9CU4k99g3DFpV/WvAqywWTA=
+  dependencies:
+    executable "^1.0.0"
+
+bin-version-check@^2.1.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/bin-version-check/-/bin-version-check-2.1.0.tgz#e4e5df290b9069f7d111324031efc13fdd11a5b0"
+  integrity sha1-5OXfKQuQaffRETJAMe/BP90RpbA=
+  dependencies:
+    bin-version "^1.0.0"
+    minimist "^1.1.0"
+    semver "^4.0.3"
+    semver-truncate "^1.0.0"
+
+bin-version@^1.0.0:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/bin-version/-/bin-version-1.0.4.tgz#9eb498ee6fd76f7ab9a7c160436f89579435d78e"
+  integrity sha1-nrSY7m/Xb3q5p8FgQ2+JV5Q1144=
+  dependencies:
+    find-versions "^1.0.0"
+
+bin-wrapper@^3.0.0:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/bin-wrapper/-/bin-wrapper-3.0.2.tgz#67d3306262e4b1a5f2f88ee23464f6a655677aeb"
+  integrity sha1-Z9MwYmLksaXy+I7iNGT2plVneus=
+  dependencies:
+    bin-check "^2.0.0"
+    bin-version-check "^2.1.0"
+    download "^4.0.0"
+    each-async "^1.1.1"
+    lazy-req "^1.0.0"
+    os-filter-obj "^1.0.0"
+
+bl@^1.0.0:
+  version "1.2.3"
+  resolved "https://registry.yarnpkg.com/bl/-/bl-1.2.3.tgz#1e8dd80142eac80d7158c9dccc047fb620e035e7"
+  integrity sha512-pvcNpa0UU69UT341rO6AYy4FVAIkUHuZXRIWbq+zHnsVcRzDDjIAhGuuYoi0d//cwIwtt4pkpKycWEfjdV+vww==
+  dependencies:
+    readable-stream "^2.3.5"
+    safe-buffer "^5.1.1"
+
+brace-expansion@^1.1.7:
+  version "1.1.11"
+  resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
+  integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
+  dependencies:
+    balanced-match "^1.0.0"
+    concat-map "0.0.1"
+
+braces@^1.8.2:
+  version "1.8.5"
+  resolved "https://registry.yarnpkg.com/braces/-/braces-1.8.5.tgz#ba77962e12dff969d6b76711e914b737857bf6a7"
+  integrity sha1-uneWLhLf+WnWt2cR6RS3N4V79qc=
+  dependencies:
+    expand-range "^1.8.1"
+    preserve "^0.2.0"
+    repeat-element "^1.1.2"
+
+braces@^2.3.1:
+  version "2.3.2"
+  resolved "https://registry.yarnpkg.com/braces/-/braces-2.3.2.tgz#5979fd3f14cd531565e5fa2df1abfff1dfaee729"
+  integrity sha512-aNdbnj9P8PjdXU4ybaWLK2IF3jc/EoDYbC7AazW6to3TRsfXxscC9UXOB5iDiEQrkyIbWp2SLQda4+QAa7nc3w==
+  dependencies:
+    arr-flatten "^1.1.0"
+    array-unique "^0.3.2"
+    extend-shallow "^2.0.1"
+    fill-range "^4.0.0"
+    isobject "^3.0.1"
+    repeat-element "^1.1.2"
+    snapdragon "^0.8.1"
+    snapdragon-node "^2.0.1"
+    split-string "^3.0.2"
+    to-regex "^3.0.1"
+
+browserslist@^4.16.6:
+  version "4.17.6"
+  resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.17.6.tgz#c76be33e7786b497f66cad25a73756c8b938985d"
+  integrity sha512-uPgz3vyRTlEiCv4ee9KlsKgo2V6qPk7Jsn0KAn2OBqbqKo3iNcPEC1Ti6J4dwnz+aIRfEEEuOzC9IBk8tXUomw==
+  dependencies:
+    caniuse-lite "^1.0.30001274"
+    electron-to-chromium "^1.3.886"
+    escalade "^3.1.1"
+    node-releases "^2.0.1"
+    picocolors "^1.0.0"
+
+buffer-alloc-unsafe@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/buffer-alloc-unsafe/-/buffer-alloc-unsafe-1.1.0.tgz#bd7dc26ae2972d0eda253be061dba992349c19f0"
+  integrity sha512-TEM2iMIEQdJ2yjPJoSIsldnleVaAk1oW3DBVUykyOLsEsFmEc9kn+SFFPz+gl54KQNxlDnAwCXosOS9Okx2xAg==
+
+buffer-alloc@^1.2.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/buffer-alloc/-/buffer-alloc-1.2.0.tgz#890dd90d923a873e08e10e5fd51a57e5b7cce0ec"
+  integrity sha512-CFsHQgjtW1UChdXgbyJGtnm+O/uLQeZdtbDo8mfUgYXCHSM1wgrVxXm6bSyrUuErEb+4sYVGCzASBRot7zyrow==
+  dependencies:
+    buffer-alloc-unsafe "^1.1.0"
+    buffer-fill "^1.0.0"
+
+buffer-crc32@~0.2.3:
+  version "0.2.13"
+  resolved "https://registry.yarnpkg.com/buffer-crc32/-/buffer-crc32-0.2.13.tgz#0d333e3f00eac50aa1454abd30ef8c2a5d9a7242"
+  integrity sha1-DTM+PwDqxQqhRUq9MO+MKl2ackI=
+
+buffer-fill@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/buffer-fill/-/buffer-fill-1.0.0.tgz#f8f78b76789888ef39f205cd637f68e702122b2c"
+  integrity sha1-+PeLdniYiO858gXNY39o5wISKyw=
+
+buffer-from@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/buffer-from/-/buffer-from-1.1.1.tgz#32713bc028f75c02fdb710d7c7bcec1f2c6070ef"
+  integrity sha512-MQcXEUbCKtEo7bhqEs6560Hyd4XaovZlO/k9V3hjVUF/zwW7KBVdSK4gIt/bzwS9MbR5qob+F5jusZsb0YQK2A==
+
+buffer-to-vinyl@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/buffer-to-vinyl/-/buffer-to-vinyl-1.1.0.tgz#00f15faee3ab7a1dda2cde6d9121bffdd07b2262"
+  integrity sha1-APFfruOreh3aLN5tkSG//dB7ImI=
+  dependencies:
+    file-type "^3.1.0"
+    readable-stream "^2.0.2"
+    uuid "^2.0.1"
+    vinyl "^1.0.0"
+
+cache-base@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/cache-base/-/cache-base-1.0.1.tgz#0a7f46416831c8b662ee36fe4e7c59d76f666ab2"
+  integrity sha512-AKcdTnFSWATd5/GCPRxr2ChwIJ85CeyrEyjRHlKxQ56d4XJMGym0uAiKn0xbLOGOl3+yRpOTi484dVCEc5AUzQ==
+  dependencies:
+    collection-visit "^1.0.0"
+    component-emitter "^1.2.1"
+    get-value "^2.0.6"
+    has-value "^1.0.0"
+    isobject "^3.0.1"
+    set-value "^2.0.0"
+    to-object-path "^0.3.0"
+    union-value "^1.0.0"
+    unset-value "^1.0.0"
+
+call-bind@^1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/call-bind/-/call-bind-1.0.2.tgz#b1d4e89e688119c3c9a903ad30abb2f6a919be3c"
+  integrity sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==
+  dependencies:
+    function-bind "^1.1.1"
+    get-intrinsic "^1.0.2"
+
+camelcase-keys@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/camelcase-keys/-/camelcase-keys-2.1.0.tgz#308beeaffdf28119051efa1d932213c91b8f92e7"
+  integrity sha1-MIvur/3ygRkFHvodkyITyRuPkuc=
+  dependencies:
+    camelcase "^2.0.0"
+    map-obj "^1.0.0"
+
+camelcase@^2.0.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/camelcase/-/camelcase-2.1.1.tgz#7c1d16d679a1bbe59ca02cacecfb011e201f5a1f"
+  integrity sha1-fB0W1nmhu+WcoCys7PsBHiAfWh8=
+
+caniuse-lite@^1.0.30001274:
+  version "1.0.30001278"
+  resolved "https://registry.yarnpkg.com/caniuse-lite/-/caniuse-lite-1.0.30001278.tgz#51cafc858df77d966b17f59b5839250b24417fff"
+  integrity sha512-mpF9KeH8u5cMoEmIic/cr7PNS+F5LWBk0t2ekGT60lFf0Wq+n9LspAj0g3P+o7DQhD3sUdlMln4YFAWhFYn9jg==
+
+capture-stack-trace@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/capture-stack-trace/-/capture-stack-trace-1.0.1.tgz#a6c0bbe1f38f3aa0b92238ecb6ff42c344d4135d"
+  integrity sha512-mYQLZnx5Qt1JgB1WEiMCf2647plpGeQ2NMR/5L0HNZzGQo4fuSPnK+wjfPnKZV0aiJDgzmWqqkV/g7JD+DW0qw==
+
+caw@^1.0.1:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/caw/-/caw-1.2.0.tgz#ffb226fe7efc547288dc62ee3e97073c212d1034"
+  integrity sha1-/7Im/n78VHKI3GLuPpcHPCEtEDQ=
+  dependencies:
+    get-proxy "^1.0.1"
+    is-obj "^1.0.0"
+    object-assign "^3.0.0"
+    tunnel-agent "^0.4.0"
+
+chalk@^1.0.0, chalk@^1.1.1, chalk@^1.1.3:
+  version "1.1.3"
+  resolved "https://registry.yarnpkg.com/chalk/-/chalk-1.1.3.tgz#a8115c55e4a702fe4d150abd3872822a7e09fc98"
+  integrity sha1-qBFcVeSnAv5NFQq9OHKCKn4J/Jg=
+  dependencies:
+    ansi-styles "^2.2.1"
+    escape-string-regexp "^1.0.2"
+    has-ansi "^2.0.0"
+    strip-ansi "^3.0.0"
+    supports-color "^2.0.0"
+
+chalk@^2.0.0:
+  version "2.4.2"
+  resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.4.2.tgz#cd42541677a54333cf541a49108c1432b44c9424"
+  integrity sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==
+  dependencies:
+    ansi-styles "^3.2.1"
+    escape-string-regexp "^1.0.5"
+    supports-color "^5.3.0"
+
+ci-info@^1.5.0:
+  version "1.6.0"
+  resolved "https://registry.yarnpkg.com/ci-info/-/ci-info-1.6.0.tgz#2ca20dbb9ceb32d4524a683303313f0304b1e497"
+  integrity sha512-vsGdkwSCDpWmP80ncATX7iea5DWQemg1UgCW5J8tqjU3lYw4FBYuj89J0CTVomA7BEfvSZd84GmHko+MxFQU2A==
+
+clap@^1.0.9:
+  version "1.2.3"
+  resolved "https://registry.yarnpkg.com/clap/-/clap-1.2.3.tgz#4f36745b32008492557f46412d66d50cb99bce51"
+  integrity sha512-4CoL/A3hf90V3VIEjeuhSvlGFEHKzOz+Wfc2IVZc+FaUgU0ZQafJTP49fvnULipOPcAfqhyI2duwQyns6xqjYA==
+  dependencies:
+    chalk "^1.1.3"
+
+class-utils@^0.3.5:
+  version "0.3.6"
+  resolved "https://registry.yarnpkg.com/class-utils/-/class-utils-0.3.6.tgz#f93369ae8b9a7ce02fd41faad0ca83033190c463"
+  integrity sha512-qOhPa/Fj7s6TY8H8esGu5QNpMMQxz79h+urzrNYN6mn+9BnxlDGf5QZ+XeCDsxSjPqsSR56XOZOJmpeurnLMeg==
+  dependencies:
+    arr-union "^3.1.0"
+    define-property "^0.2.5"
+    isobject "^3.0.0"
+    static-extend "^0.1.1"
+
+cli-cursor@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/cli-cursor/-/cli-cursor-1.0.2.tgz#64da3f7d56a54412e59794bd62dc35295e8f2987"
+  integrity sha1-ZNo/fValRBLll5S9Ytw1KV6PKYc=
+  dependencies:
+    restore-cursor "^1.0.1"
+
+cli-spinners@^0.1.2:
+  version "0.1.2"
+  resolved "https://registry.yarnpkg.com/cli-spinners/-/cli-spinners-0.1.2.tgz#bb764d88e185fb9e1e6a2a1f19772318f605e31c"
+  integrity sha1-u3ZNiOGF+54eaiofGXcjGPYF4xw=
+
+cli-truncate@^0.2.1:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/cli-truncate/-/cli-truncate-0.2.1.tgz#9f15cfbb0705005369216c626ac7d05ab90dd574"
+  integrity sha1-nxXPuwcFAFNpIWxiasfQWrkN1XQ=
+  dependencies:
+    slice-ansi "0.0.4"
+    string-width "^1.0.1"
+
+clone-deep@^4.0.1:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/clone-deep/-/clone-deep-4.0.1.tgz#c19fd9bdbbf85942b4fd979c84dcf7d5f07c2387"
+  integrity sha512-neHB9xuzh/wk0dIHweyAXv2aPGZIVk3pLMe+/RNzINf17fe0OG96QroktYAUm7SM1PBnzTabaLboqqxDyMU+SQ==
+  dependencies:
+    is-plain-object "^2.0.4"
+    kind-of "^6.0.2"
+    shallow-clone "^3.0.0"
+
+clone-stats@^0.0.1:
+  version "0.0.1"
+  resolved "https://registry.yarnpkg.com/clone-stats/-/clone-stats-0.0.1.tgz#b88f94a82cf38b8791d58046ea4029ad88ca99d1"
+  integrity sha1-uI+UqCzzi4eR1YBG6kAprYjKmdE=
+
+clone@^0.2.0:
+  version "0.2.0"
+  resolved "https://registry.yarnpkg.com/clone/-/clone-0.2.0.tgz#c6126a90ad4f72dbf5acdb243cc37724fe93fc1f"
+  integrity sha1-xhJqkK1Pctv1rNskPMN3JP6T/B8=
+
+clone@^1.0.0:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/clone/-/clone-1.0.4.tgz#da309cc263df15994c688ca902179ca3c7cd7c7e"
+  integrity sha1-2jCcwmPfFZlMaIypAheco8fNfH4=
+
+co@3.1.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/co/-/co-3.1.0.tgz#4ea54ea5a08938153185e15210c68d9092bc1b78"
+  integrity sha1-TqVOpaCJOBUxheFSEMaNkJK8G3g=
+
+coa@~1.0.1:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/coa/-/coa-1.0.4.tgz#a9ef153660d6a86a8bdec0289a5c684d217432fd"
+  integrity sha1-qe8VNmDWqGqL3sAomlxoTSF0Mv0=
+  dependencies:
+    q "^1.1.2"
+
+code-point-at@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/code-point-at/-/code-point-at-1.1.0.tgz#0d070b4d043a5bea33a2f1a40e2edb3d9a4ccf77"
+  integrity sha1-DQcLTQQ6W+ozovGkDi7bPZpMz3c=
+
+collection-visit@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/collection-visit/-/collection-visit-1.0.0.tgz#4bc0373c164bc3291b4d368c829cf1a80a59dca0"
+  integrity sha1-S8A3PBZLwykbTTaMgpzxqApZ3KA=
+  dependencies:
+    map-visit "^1.0.0"
+    object-visit "^1.0.0"
+
+color-convert@^1.9.0:
+  version "1.9.3"
+  resolved "https://registry.yarnpkg.com/color-convert/-/color-convert-1.9.3.tgz#bb71850690e1f136567de629d2d5471deda4c1e8"
+  integrity sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==
+  dependencies:
+    color-name "1.1.3"
+
+color-name@1.1.3:
+  version "1.1.3"
+  resolved "https://registry.yarnpkg.com/color-name/-/color-name-1.1.3.tgz#a7d0558bd89c42f795dd42328f740831ca53bc25"
+  integrity sha1-p9BVi9icQveV3UIyj3QIMcpTvCU=
+
+color-support@^1.1.3:
+  version "1.1.3"
+  resolved "https://registry.yarnpkg.com/color-support/-/color-support-1.1.3.tgz#93834379a1cc9a0c61f82f52f0d04322251bd5a2"
+  integrity sha512-qiBjkpbMLO/HL68y+lh4q0/O1MZFj2RX6X/KmMa3+gJD3z+WwI1ZzDHysvqHGS3mP6mznPckpXmw1nI9cJjyRg==
+
+colors@^1.1.2:
+  version "1.4.0"
+  resolved "https://registry.yarnpkg.com/colors/-/colors-1.4.0.tgz#c50491479d4c1bdaed2c9ced32cf7c7dc2360f78"
+  integrity sha512-a+UqTh4kgZg/SlGvfbzDHpgRu7AAQOmmqRHJnxhRZICKFUT91brVhNNt58CMWU9PsBbv3PDCZUHbVxuDiH2mtA==
+
+colors@~1.1.2:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/colors/-/colors-1.1.2.tgz#168a4701756b6a7f51a12ce0c97bfa28c084ed63"
+  integrity sha1-FopHAXVran9RoSzgyXv6KMCE7WM=
+
+commander@^2.8.1, commander@^2.9.0:
+  version "2.19.0"
+  resolved "https://registry.yarnpkg.com/commander/-/commander-2.19.0.tgz#f6198aa84e5b83c46054b94ddedbfed5ee9ff12a"
+  integrity sha512-6tvAOO+D6OENvRAh524Dh9jcfKTYDQAqvqezbCW82xj5X0pSrcpxtvRKHLG0yBY6SD7PSDrJaj+0AiOcKVd1Xg==
+
+commander@~2.8.1:
+  version "2.8.1"
+  resolved "https://registry.yarnpkg.com/commander/-/commander-2.8.1.tgz#06be367febfda0c330aa1e2a072d3dc9762425d4"
+  integrity sha1-Br42f+v9oMMwqh4qBy09yXYkJdQ=
+  dependencies:
+    graceful-readlink ">= 1.0.0"
+
+commander@~2.9.0:
+  version "2.9.0"
+  resolved "https://registry.yarnpkg.com/commander/-/commander-2.9.0.tgz#9c99094176e12240cb22d6c5146098400fe0f7d4"
+  integrity sha1-nJkJQXbhIkDLItbFFGCYQA/g99Q=
+  dependencies:
+    graceful-readlink ">= 1.0.0"
+
+commondir@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/commondir/-/commondir-1.0.1.tgz#ddd800da0c66127393cca5950ea968a3aaf1253b"
+  integrity sha1-3dgA2gxmEnOTzKWVDqloo6rxJTs=
+
+component-emitter@^1.2.1:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.3.0.tgz#16e4070fba8ae29b679f2215853ee181ab2eabc0"
+  integrity sha512-Rd3se6QB+sO1TwqZjscQrurpEPIfO0/yYnSin6Q/rD3mOutHvUrCAhJub3r90uNb+SESBuE0QYoB90YdfatsRg==
+
+concat-map@0.0.1:
+  version "0.0.1"
+  resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
+  integrity sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=
+
+concat-stream@^1.4.6, concat-stream@^1.4.7:
+  version "1.6.2"
+  resolved "https://registry.yarnpkg.com/concat-stream/-/concat-stream-1.6.2.tgz#904bdf194cd3122fc675c77fc4ac3d4ff0fd1a34"
+  integrity sha512-27HBghJxjiZtIk3Ycvn/4kbJk/1uZuJFfuPEns6LaEvpvG1f0hTea8lilrouyo9mVc2GWdcEZ8OLoGmSADlrCw==
+  dependencies:
+    buffer-from "^1.0.0"
+    inherits "^2.0.3"
+    readable-stream "^2.2.2"
+    typedarray "^0.0.6"
+
+console-stream@^0.1.1:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/console-stream/-/console-stream-0.1.1.tgz#a095fe07b20465955f2fafd28b5d72bccd949d44"
+  integrity sha1-oJX+B7IEZZVfL6/Si11yvM2UnUQ=
+
+convert-source-map@^1.1.1:
+  version "1.6.0"
+  resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.6.0.tgz#51b537a8c43e0f04dec1993bffcdd504e758ac20"
+  integrity sha512-eFu7XigvxdZ1ETfbgPBohgyQ/Z++C0eEhTor0qRwBw9unw+L0/6V8wkSuGgzdThkiS5lSpdptOQPD8Ak40a+7A==
+  dependencies:
+    safe-buffer "~5.1.1"
+
+convert-source-map@^1.7.0:
+  version "1.8.0"
+  resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.8.0.tgz#f3373c32d21b4d780dd8004514684fb791ca4369"
+  integrity sha512-+OQdjP49zViI/6i7nIJpA8rAl4sV/JdPfU9nZs3VqOwGIgizICvuN2ru6fMd+4llL0tar18UYJXfZ/TWtmhUjA==
+  dependencies:
+    safe-buffer "~5.1.1"
+
+copy-descriptor@^0.1.0:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/copy-descriptor/-/copy-descriptor-0.1.1.tgz#676f6eb3c39997c2ee1ac3a924fd6124748f578d"
+  integrity sha1-Z29us8OZl8LuGsOpJP1hJHSPV40=
+
+core-util-is@~1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/core-util-is/-/core-util-is-1.0.2.tgz#b5fd54220aa2bc5ab57aab7140c940754503c1a7"
+  integrity sha1-tf1UIgqivFq1eqtxQMlAdUUDwac=
+
+cosmiconfig@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/cosmiconfig/-/cosmiconfig-1.1.0.tgz#0dea0f9804efdfb929fbb1b188e25553ea053d37"
+  integrity sha1-DeoPmATv37kp+7GxiOJVU+oFPTc=
+  dependencies:
+    graceful-fs "^4.1.2"
+    js-yaml "^3.4.3"
+    minimist "^1.2.0"
+    object-assign "^4.0.1"
+    os-homedir "^1.0.1"
+    parse-json "^2.2.0"
+    pinkie-promise "^2.0.0"
+    require-from-string "^1.1.0"
+
+create-error-class@^3.0.1:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/create-error-class/-/create-error-class-3.0.2.tgz#06be7abef947a3f14a30fd610671d401bca8b7b6"
+  integrity sha1-Br56vvlHo/FKMP1hBnHUAbyot7Y=
+  dependencies:
+    capture-stack-trace "^1.0.0"
+
+cross-spawn@^5.0.1:
+  version "5.1.0"
+  resolved "https://registry.yarnpkg.com/cross-spawn/-/cross-spawn-5.1.0.tgz#e8bd0efee58fcff6f8f94510a0a554bbfa235449"
+  integrity sha1-6L0O/uWPz/b4+UUQoKVUu/ojVEk=
+  dependencies:
+    lru-cache "^4.0.1"
+    shebang-command "^1.2.0"
+    which "^1.2.9"
+
+csso@~2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/csso/-/csso-2.0.0.tgz#178b43a44621221c27756086f531e02f42900ee8"
+  integrity sha1-F4tDpEYhIhwndWCG9THgL0KQDug=
+  dependencies:
+    clap "^1.0.9"
+    source-map "^0.5.3"
+
+currently-unhandled@^0.4.1:
+  version "0.4.1"
+  resolved "https://registry.yarnpkg.com/currently-unhandled/-/currently-unhandled-0.4.1.tgz#988df33feab191ef799a61369dd76c17adf957ea"
+  integrity sha1-mI3zP+qxke95mmE2nddsF635V+o=
+  dependencies:
+    array-find-index "^1.0.1"
+
+date-fns@^1.27.2:
+  version "1.30.1"
+  resolved "https://registry.yarnpkg.com/date-fns/-/date-fns-1.30.1.tgz#2e71bf0b119153dbb4cc4e88d9ea5acfb50dc05c"
+  integrity sha512-hBSVCvSmWC+QypYObzwGOd9wqdDpOt+0wl0KbU+R+uuZBS1jN8VsD1ss3irQDknRj5NvxiTF6oj/nDRnN/UQNw==
+
+dateformat@^2.0.0:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/dateformat/-/dateformat-2.2.0.tgz#4065e2013cf9fb916ddfd82efb506ad4c6769062"
+  integrity sha1-QGXiATz5+5Ft39gu+1Bq1MZ2kGI=
+
+debug@^2.2.0, debug@^2.3.3:
+  version "2.6.9"
+  resolved "https://registry.yarnpkg.com/debug/-/debug-2.6.9.tgz#5d128515df134ff327e90a4c93f4e077a536341f"
+  integrity sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==
+  dependencies:
+    ms "2.0.0"
+
+debug@^4.1.0:
+  version "4.3.2"
+  resolved "https://registry.yarnpkg.com/debug/-/debug-4.3.2.tgz#f0a49c18ac8779e31d4a0c6029dfb76873c7428b"
+  integrity sha512-mOp8wKcvj7XxC78zLgw/ZA+6TSgkoE2C/ienthhRD298T7UNwAg9diBpLRxC0mOezLl4B0xV7M0cCO6P/O0Xhw==
+  dependencies:
+    ms "2.1.2"
+
+decamelize@^1.1.2:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/decamelize/-/decamelize-1.2.0.tgz#f6534d15148269b20352e7bee26f501f9a191290"
+  integrity sha1-9lNNFRSCabIDUue+4m9QH5oZEpA=
+
+decode-uri-component@^0.2.0:
+  version "0.2.0"
+  resolved "https://registry.yarnpkg.com/decode-uri-component/-/decode-uri-component-0.2.0.tgz#eb3913333458775cb84cd1a1fae062106bb87545"
+  integrity sha1-6zkTMzRYd1y4TNGh+uBiEGu4dUU=
+
+decompress-tar@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/decompress-tar/-/decompress-tar-3.1.0.tgz#217c789f9b94450efaadc5c5e537978fc333c466"
+  integrity sha1-IXx4n5uURQ76rcXF5TeXj8MzxGY=
+  dependencies:
+    is-tar "^1.0.0"
+    object-assign "^2.0.0"
+    strip-dirs "^1.0.0"
+    tar-stream "^1.1.1"
+    through2 "^0.6.1"
+    vinyl "^0.4.3"
+
+decompress-tarbz2@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/decompress-tarbz2/-/decompress-tarbz2-3.1.0.tgz#8b23935681355f9f189d87256a0f8bdd96d9666d"
+  integrity sha1-iyOTVoE1X58YnYclag+L3ZbZZm0=
+  dependencies:
+    is-bzip2 "^1.0.0"
+    object-assign "^2.0.0"
+    seek-bzip "^1.0.3"
+    strip-dirs "^1.0.0"
+    tar-stream "^1.1.1"
+    through2 "^0.6.1"
+    vinyl "^0.4.3"
+
+decompress-targz@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/decompress-targz/-/decompress-targz-3.1.0.tgz#b2c13df98166268991b715d6447f642e9696f5a0"
+  integrity sha1-ssE9+YFmJomRtxXWRH9kLpaW9aA=
+  dependencies:
+    is-gzip "^1.0.0"
+    object-assign "^2.0.0"
+    strip-dirs "^1.0.0"
+    tar-stream "^1.1.1"
+    through2 "^0.6.1"
+    vinyl "^0.4.3"
+
+decompress-unzip@^3.0.0:
+  version "3.4.0"
+  resolved "https://registry.yarnpkg.com/decompress-unzip/-/decompress-unzip-3.4.0.tgz#61475b4152066bbe3fee12f9d629d15fe6478eeb"
+  integrity sha1-YUdbQVIGa74/7hL51inRX+ZHjus=
+  dependencies:
+    is-zip "^1.0.0"
+    read-all-stream "^3.0.0"
+    stat-mode "^0.2.0"
+    strip-dirs "^1.0.0"
+    through2 "^2.0.0"
+    vinyl "^1.0.0"
+    yauzl "^2.2.1"
+
+decompress@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/decompress/-/decompress-3.0.0.tgz#af1dd50d06e3bfc432461d37de11b38c0d991bed"
+  integrity sha1-rx3VDQbjv8QyRh033hGzjA2ZG+0=
+  dependencies:
+    buffer-to-vinyl "^1.0.0"
+    concat-stream "^1.4.6"
+    decompress-tar "^3.0.0"
+    decompress-tarbz2 "^3.0.0"
+    decompress-targz "^3.0.0"
+    decompress-unzip "^3.0.0"
+    stream-combiner2 "^1.1.1"
+    vinyl-assign "^1.0.1"
+    vinyl-fs "^2.2.0"
+
+deep-extend@^0.6.0:
+  version "0.6.0"
+  resolved "https://registry.yarnpkg.com/deep-extend/-/deep-extend-0.6.0.tgz#c4fa7c95404a17a9c3e8ca7e1537312b736330ac"
+  integrity sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==
+
+deep-extend@~0.5.1:
+  version "0.5.1"
+  resolved "https://registry.yarnpkg.com/deep-extend/-/deep-extend-0.5.1.tgz#b894a9dd90d3023fbf1c55a394fb858eb2066f1f"
+  integrity sha512-N8vBdOa+DF7zkRrDCsaOXoCs/E2fJfx9B9MrKnnSiHNh4ws7eSys6YQE4KvT1cecKmOASYQBhbKjeuDD9lT81w==
+
+define-properties@^1.1.3:
+  version "1.1.3"
+  resolved "https://registry.yarnpkg.com/define-properties/-/define-properties-1.1.3.tgz#cf88da6cbee26fe6db7094f61d870cbd84cee9f1"
+  integrity sha512-3MqfYKj2lLzdMSf8ZIZE/V+Zuy+BgD6f164e8K2w7dgnpKArBDerGYpM46IYYcjnkdPNMjPk9A6VFB8+3SKlXQ==
+  dependencies:
+    object-keys "^1.0.12"
+
+define-property@^0.2.5:
+  version "0.2.5"
+  resolved "https://registry.yarnpkg.com/define-property/-/define-property-0.2.5.tgz#c35b1ef918ec3c990f9a5bc57be04aacec5c8116"
+  integrity sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=
+  dependencies:
+    is-descriptor "^0.1.0"
+
+define-property@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/define-property/-/define-property-1.0.0.tgz#769ebaaf3f4a63aad3af9e8d304c9bbe79bfb0e6"
+  integrity sha1-dp66rz9KY6rTr56NMEybvnm/sOY=
+  dependencies:
+    is-descriptor "^1.0.0"
+
+define-property@^2.0.2:
+  version "2.0.2"
+  resolved "https://registry.yarnpkg.com/define-property/-/define-property-2.0.2.tgz#d459689e8d654ba77e02a817f8710d702cb16e9d"
+  integrity sha512-jwK2UV4cnPpbcG7+VRARKTZPUWowwXA8bzH5NP6ud0oeAxyYPuGZUAC7hMugpCdz4BeSZl2Dl9k66CHJ/46ZYQ==
+  dependencies:
+    is-descriptor "^1.0.2"
+    isobject "^3.0.1"
+
+download@^4.0.0, download@^4.1.2:
+  version "4.4.3"
+  resolved "https://registry.yarnpkg.com/download/-/download-4.4.3.tgz#aa55fdad392d95d4b68e8c2be03e0c2aa21ba9ac"
+  integrity sha1-qlX9rTktldS2jowr4D4MKqIbqaw=
+  dependencies:
+    caw "^1.0.1"
+    concat-stream "^1.4.7"
+    each-async "^1.0.0"
+    filenamify "^1.0.1"
+    got "^5.0.0"
+    gulp-decompress "^1.2.0"
+    gulp-rename "^1.2.0"
+    is-url "^1.2.0"
+    object-assign "^4.0.1"
+    read-all-stream "^3.0.0"
+    readable-stream "^2.0.2"
+    stream-combiner2 "^1.1.1"
+    vinyl "^1.0.0"
+    vinyl-fs "^2.2.0"
+    ware "^1.2.0"
+
+duplexer2@0.0.2:
+  version "0.0.2"
+  resolved "https://registry.yarnpkg.com/duplexer2/-/duplexer2-0.0.2.tgz#c614dcf67e2fb14995a91711e5a617e8a60a31db"
+  integrity sha1-xhTc9n4vsUmVqRcR5aYX6KYKMds=
+  dependencies:
+    readable-stream "~1.1.9"
+
+duplexer2@^0.1.4, duplexer2@~0.1.0:
+  version "0.1.4"
+  resolved "https://registry.yarnpkg.com/duplexer2/-/duplexer2-0.1.4.tgz#8b12dab878c0d69e3e7891051662a32fc6bddcc1"
+  integrity sha1-ixLauHjA1p4+eJEFFmKjL8a93ME=
+  dependencies:
+    readable-stream "^2.0.2"
+
+duplexify@^3.2.0:
+  version "3.7.1"
+  resolved "https://registry.yarnpkg.com/duplexify/-/duplexify-3.7.1.tgz#2a4df5317f6ccfd91f86d6fd25d8d8a103b88309"
+  integrity sha512-07z8uv2wMyS51kKhD1KsdXJg5WQ6t93RneqRxUHnskXVtlYYkLqM0gqStQZ3pj073g687jPCHrqNfCzawLYh5g==
+  dependencies:
+    end-of-stream "^1.0.0"
+    inherits "^2.0.1"
+    readable-stream "^2.0.0"
+    stream-shift "^1.0.0"
+
+each-async@^1.0.0, each-async@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/each-async/-/each-async-1.1.1.tgz#dee5229bdf0ab6ba2012a395e1b869abf8813473"
+  integrity sha1-3uUim98KtrogEqOV4bhpq/iBNHM=
+  dependencies:
+    onetime "^1.0.0"
+    set-immediate-shim "^1.0.0"
+
+electron-to-chromium@^1.3.886:
+  version "1.3.891"
+  resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.3.891.tgz#51d7224e64157656276f152a0b3361708fde1bf9"
+  integrity sha512-3cpwR82QkIS01CN/dup/4Yr3BiOiRLlZlcAFn/5FbNCunMO9ojqDgEP9JEo1QNLflu3pEnPWve50gHOEKc7r6w==
+
+elegant-spinner@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/elegant-spinner/-/elegant-spinner-1.0.1.tgz#db043521c95d7e303fd8f345bedc3349cfb0729e"
+  integrity sha1-2wQ1IcldfjA/2PNFvtwzSc+wcp4=
+
+end-of-stream@^1.0.0:
+  version "1.4.1"
+  resolved "https://registry.yarnpkg.com/end-of-stream/-/end-of-stream-1.4.1.tgz#ed29634d19baba463b6ce6b80a37213eab71ec43"
+  integrity sha512-1MkrZNvWTKCaigbn+W15elq2BB/L22nqrSY5DKlo3X6+vclJm8Bb5djXJBmEX6fS3+zCh/F4VBK5Z2KxJt4s2Q==
+  dependencies:
+    once "^1.4.0"
+
+entities@~1.1.1:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/entities/-/entities-1.1.2.tgz#bdfa735299664dfafd34529ed4f8522a275fea56"
+  integrity sha512-f2LZMYl1Fzu7YSBKg+RoROelpOaNrcGmE9AZubeDfrCEia483oW4MI4VyFd5VNHIgQ/7qm1I0wUHK1eJnn2y2w==
+
+error-ex@^1.2.0:
+  version "1.3.2"
+  resolved "https://registry.yarnpkg.com/error-ex/-/error-ex-1.3.2.tgz#b4ac40648107fdcdcfae242f428bea8a14d4f1bf"
+  integrity sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==
+  dependencies:
+    is-arrayish "^0.2.1"
+
+escalade@^3.1.1:
+  version "3.1.1"
+  resolved "https://registry.yarnpkg.com/escalade/-/escalade-3.1.1.tgz#d8cfdc7000965c5a0174b4a82eaa5c0552742e40"
+  integrity sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==
+
+escape-string-regexp@^1.0.2, escape-string-regexp@^1.0.5:
+  version "1.0.5"
+  resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz#1b61c0562190a8dff6ae3bb2cf0200ca130b86d4"
+  integrity sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=
+
+esprima@^2.6.0:
+  version "2.7.3"
+  resolved "https://registry.yarnpkg.com/esprima/-/esprima-2.7.3.tgz#96e3b70d5779f6ad49cd032673d1c312767ba581"
+  integrity sha1-luO3DVd59q1JzQMmc9HDEnZ7pYE=
+
+esprima@^4.0.0, esprima@~4.0.0:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/esprima/-/esprima-4.0.1.tgz#13b04cdb3e6c5d19df91ab6987a8695619b0aa71"
+  integrity sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==
+
+exec-buffer@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/exec-buffer/-/exec-buffer-2.0.1.tgz#0028a31be0b1460b61d075f96af4583b9e335ea0"
+  integrity sha1-ACijG+CxRgth0HX5avRYO54zXqA=
+  dependencies:
+    rimraf "^2.2.6"
+    tempfile "^1.0.0"
+
+exec-series@^1.0.0:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/exec-series/-/exec-series-1.0.3.tgz#6d257a9beac482a872c7783bc8615839fc77143a"
+  integrity sha1-bSV6m+rEgqhyx3g7yGFYOfx3FDo=
+  dependencies:
+    async-each-series "^1.1.0"
+    object-assign "^4.1.0"
+
+execa@^0.7.0:
+  version "0.7.0"
+  resolved "https://registry.yarnpkg.com/execa/-/execa-0.7.0.tgz#944becd34cc41ee32a63a9faf27ad5a65fc59777"
+  integrity sha1-lEvs00zEHuMqY6n68nrVpl/Fl3c=
+  dependencies:
+    cross-spawn "^5.0.1"
+    get-stream "^3.0.0"
+    is-stream "^1.1.0"
+    npm-run-path "^2.0.0"
+    p-finally "^1.0.0"
+    signal-exit "^3.0.0"
+    strip-eof "^1.0.0"
+
+executable@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/executable/-/executable-1.1.0.tgz#877980e9112f3391066da37265de7ad8434ab4d9"
+  integrity sha1-h3mA6REvM5EGbaNyZd562ENKtNk=
+  dependencies:
+    meow "^3.1.0"
+
+exit-hook@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/exit-hook/-/exit-hook-1.1.1.tgz#f05ca233b48c05d54fff07765df8507e95c02ff8"
+  integrity sha1-8FyiM7SMBdVP/wd2XfhQfpXAL/g=
+
+expand-brackets@^0.1.4:
+  version "0.1.5"
+  resolved "https://registry.yarnpkg.com/expand-brackets/-/expand-brackets-0.1.5.tgz#df07284e342a807cd733ac5af72411e581d1177b"
+  integrity sha1-3wcoTjQqgHzXM6xa9yQR5YHRF3s=
+  dependencies:
+    is-posix-bracket "^0.1.0"
+
+expand-brackets@^2.1.4:
+  version "2.1.4"
+  resolved "https://registry.yarnpkg.com/expand-brackets/-/expand-brackets-2.1.4.tgz#b77735e315ce30f6b6eff0f83b04151a22449622"
+  integrity sha1-t3c14xXOMPa27/D4OwQVGiJEliI=
+  dependencies:
+    debug "^2.3.3"
+    define-property "^0.2.5"
+    extend-shallow "^2.0.1"
+    posix-character-classes "^0.1.0"
+    regex-not "^1.0.0"
+    snapdragon "^0.8.1"
+    to-regex "^3.0.1"
+
+expand-range@^1.8.1:
+  version "1.8.2"
+  resolved "https://registry.yarnpkg.com/expand-range/-/expand-range-1.8.2.tgz#a299effd335fe2721ebae8e257ec79644fc85337"
+  integrity sha1-opnv/TNf4nIeuujiV+x5ZE/IUzc=
+  dependencies:
+    fill-range "^2.1.0"
+
+extend-shallow@^2.0.1:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/extend-shallow/-/extend-shallow-2.0.1.tgz#51af7d614ad9a9f610ea1bafbb989d6b1c56890f"
+  integrity sha1-Ua99YUrZqfYQ6huvu5idaxxWiQ8=
+  dependencies:
+    is-extendable "^0.1.0"
+
+extend-shallow@^3.0.0, extend-shallow@^3.0.2:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/extend-shallow/-/extend-shallow-3.0.2.tgz#26a71aaf073b39fb2127172746131c2704028db8"
+  integrity sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=
+  dependencies:
+    assign-symbols "^1.0.0"
+    is-extendable "^1.0.1"
+
+extend@^3.0.0:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.2.tgz#f8b1136b4071fbd8eb140aff858b1019ec2915fa"
+  integrity sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==
+
+extglob@^0.3.1:
+  version "0.3.2"
+  resolved "https://registry.yarnpkg.com/extglob/-/extglob-0.3.2.tgz#2e18ff3d2f49ab2765cec9023f011daa8d8349a1"
+  integrity sha1-Lhj/PS9JqydlzskCPwEdqo2DSaE=
+  dependencies:
+    is-extglob "^1.0.0"
+
+extglob@^2.0.4:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/extglob/-/extglob-2.0.4.tgz#ad00fe4dc612a9232e8718711dc5cb5ab0285543"
+  integrity sha512-Nmb6QXkELsuBr24CJSkilo6UHHgbekK5UiZgfE6UHD3Eb27YC6oD+bhcT+tJ6cl8dmsgdQxnWlcry8ksBIBLpw==
+  dependencies:
+    array-unique "^0.3.2"
+    define-property "^1.0.0"
+    expand-brackets "^2.1.4"
+    extend-shallow "^2.0.1"
+    fragment-cache "^0.2.1"
+    regex-not "^1.0.0"
+    snapdragon "^0.8.1"
+    to-regex "^3.0.1"
+
+fancy-log@^1.1.0:
+  version "1.3.3"
+  resolved "https://registry.yarnpkg.com/fancy-log/-/fancy-log-1.3.3.tgz#dbc19154f558690150a23953a0adbd035be45fc7"
+  integrity sha512-k9oEhlyc0FrVh25qYuSELjr8oxsCoc4/LEZfg2iJJrfEk/tZL9bCoJE47gqAvI2m/AUjluCS4+3I0eTx8n3AEw==
+  dependencies:
+    ansi-gray "^0.1.1"
+    color-support "^1.1.3"
+    parse-node-version "^1.0.0"
+    time-stamp "^1.0.0"
+
+fd-slicer@~1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/fd-slicer/-/fd-slicer-1.1.0.tgz#25c7c89cb1f9077f8891bbe61d8f390eae256f1e"
+  integrity sha1-JcfInLH5B3+IkbvmHY85Dq4lbx4=
+  dependencies:
+    pend "~1.2.0"
+
+figures@^1.3.5, figures@^1.7.0:
+  version "1.7.0"
+  resolved "https://registry.yarnpkg.com/figures/-/figures-1.7.0.tgz#cbe1e3affcf1cd44b80cadfed28dc793a9701d2e"
+  integrity sha1-y+Hjr/zxzUS4DK3+0o3Hk6lwHS4=
+  dependencies:
+    escape-string-regexp "^1.0.5"
+    object-assign "^4.1.0"
+
+file-type@^3.1.0:
+  version "3.9.0"
+  resolved "https://registry.yarnpkg.com/file-type/-/file-type-3.9.0.tgz#257a078384d1db8087bc449d107d52a52672b9e9"
+  integrity sha1-JXoHg4TR24CHvESdEH1SpSZyuek=
+
+filename-regex@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/filename-regex/-/filename-regex-2.0.1.tgz#c1c4b9bee3e09725ddb106b75c1e301fe2f18b26"
+  integrity sha1-wcS5vuPglyXdsQa3XB4wH+LxiyY=
+
+filename-reserved-regex@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/filename-reserved-regex/-/filename-reserved-regex-1.0.0.tgz#e61cf805f0de1c984567d0386dc5df50ee5af7e4"
+  integrity sha1-5hz4BfDeHJhFZ9A4bcXfUO5a9+Q=
+
+filenamify@^1.0.1:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/filenamify/-/filenamify-1.2.1.tgz#a9f2ffd11c503bed300015029272378f1f1365a5"
+  integrity sha1-qfL/0RxQO+0wABUCknI3jx8TZaU=
+  dependencies:
+    filename-reserved-regex "^1.0.0"
+    strip-outer "^1.0.0"
+    trim-repeated "^1.0.0"
+
+fill-range@^2.1.0:
+  version "2.2.4"
+  resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-2.2.4.tgz#eb1e773abb056dcd8df2bfdf6af59b8b3a936565"
+  integrity sha512-cnrcCbj01+j2gTG921VZPnHbjmdAf8oQV/iGeV2kZxGSyfYjjTyY79ErsK1WJWMpw6DaApEX72binqJE+/d+5Q==
+  dependencies:
+    is-number "^2.1.0"
+    isobject "^2.0.0"
+    randomatic "^3.0.0"
+    repeat-element "^1.1.2"
+    repeat-string "^1.5.2"
+
+fill-range@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-4.0.0.tgz#d544811d428f98eb06a63dc402d2403c328c38f7"
+  integrity sha1-1USBHUKPmOsGpj3EAtJAPDKMOPc=
+  dependencies:
+    extend-shallow "^2.0.1"
+    is-number "^3.0.0"
+    repeat-string "^1.6.1"
+    to-regex-range "^2.1.0"
+
+find-cache-dir@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/find-cache-dir/-/find-cache-dir-2.1.0.tgz#8d0f94cd13fe43c6c7c261a0d86115ca918c05f7"
+  integrity sha512-Tq6PixE0w/VMFfCgbONnkiQIVol/JJL7nRMi20fqzA4NRs9AfeqMGeRdPi3wIhYkxjeBaWh2rxwapn5Tu3IqOQ==
+  dependencies:
+    commondir "^1.0.1"
+    make-dir "^2.0.0"
+    pkg-dir "^3.0.0"
+
+find-parent-dir@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/find-parent-dir/-/find-parent-dir-0.3.0.tgz#33c44b429ab2b2f0646299c5f9f718f376ff8d54"
+  integrity sha1-M8RLQpqysvBkYpnF+fcY83b/jVQ=
+
+find-up@^1.0.0:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/find-up/-/find-up-1.1.2.tgz#6b2e9822b1a2ce0a60ab64d610eccad53cb24d0f"
+  integrity sha1-ay6YIrGizgpgq2TWEOzK1TyyTQ8=
+  dependencies:
+    path-exists "^2.0.0"
+    pinkie-promise "^2.0.0"
+
+find-up@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/find-up/-/find-up-3.0.0.tgz#49169f1d7993430646da61ecc5ae355c21c97b73"
+  integrity sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==
+  dependencies:
+    locate-path "^3.0.0"
+
+find-versions@^1.0.0:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/find-versions/-/find-versions-1.2.1.tgz#cbde9f12e38575a0af1be1b9a2c5d5fd8f186b62"
+  integrity sha1-y96fEuOFdaCvG+G5osXV/Y8Ya2I=
+  dependencies:
+    array-uniq "^1.0.0"
+    get-stdin "^4.0.1"
+    meow "^3.5.0"
+    semver-regex "^1.0.0"
+
+first-chunk-stream@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/first-chunk-stream/-/first-chunk-stream-1.0.0.tgz#59bfb50cd905f60d7c394cd3d9acaab4e6ad934e"
+  integrity sha1-Wb+1DNkF9g18OUzT2ayqtOatk04=
+
+flow-parser@0.*:
+  version "0.163.0"
+  resolved "https://registry.yarnpkg.com/flow-parser/-/flow-parser-0.163.0.tgz#c2d5c77c57c53e8357016a837f3e3af04a0c87a6"
+  integrity sha512-txOsBcZ1nKsKtoAsBFnArFdq0cnPCmEHI5S2jQIgU1ZO1xtWpg64TsZSRktsaOyoWLpAvVxPap4Qbdd/TCJ3FQ==
+
+for-in@^1.0.1, for-in@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80"
+  integrity sha1-gQaNKVqBQuwKxybG4iAMMPttXoA=
+
+for-own@^0.1.4:
+  version "0.1.5"
+  resolved "https://registry.yarnpkg.com/for-own/-/for-own-0.1.5.tgz#5265c681a4f294dabbf17c9509b6763aa84510ce"
+  integrity sha1-UmXGgaTylNq78XyVCbZ2OqhFEM4=
+  dependencies:
+    for-in "^1.0.1"
+
+fragment-cache@^0.2.1:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/fragment-cache/-/fragment-cache-0.2.1.tgz#4290fad27f13e89be7f33799c6bc5a0abfff0d19"
+  integrity sha1-QpD60n8T6Jvn8zeZxrxaCr//DRk=
+  dependencies:
+    map-cache "^0.2.2"
+
+fs-constants@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/fs-constants/-/fs-constants-1.0.0.tgz#6be0de9be998ce16af8afc24497b9ee9b7ccd9ad"
+  integrity sha512-y6OAwoSIf7FyjMIv94u+b5rdheZEjzR63GTyZJm5qh4Bi+2YgwLCcI/fPFZkL5PSixOt6ZNKm+w+Hfp/Bciwow==
+
+fs.realpath@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
+  integrity sha1-FQStJSMVjKpA20onh8sBQRmU6k8=
+
+function-bind@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/function-bind/-/function-bind-1.1.1.tgz#a56899d3ea3c9bab874bb9773b7c5ede92f4895d"
+  integrity sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==
+
+gensync@^1.0.0-beta.2:
+  version "1.0.0-beta.2"
+  resolved "https://registry.yarnpkg.com/gensync/-/gensync-1.0.0-beta.2.tgz#32a6ee76c3d7f52d46b2b1ae5d93fea8580a25e0"
+  integrity sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg==
+
+get-intrinsic@^1.0.2:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/get-intrinsic/-/get-intrinsic-1.1.1.tgz#15f59f376f855c446963948f0d24cd3637b4abc6"
+  integrity sha512-kWZrnVM42QCiEA2Ig1bG8zjoIMOgxWwYCEeNdwY6Tv/cOSeGpcoX4pXHfKUxNKVoArnrEr2e9srnAxxGIraS9Q==
+  dependencies:
+    function-bind "^1.1.1"
+    has "^1.0.3"
+    has-symbols "^1.0.1"
+
+get-proxy@^1.0.1:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/get-proxy/-/get-proxy-1.1.0.tgz#894854491bc591b0f147d7ae570f5c678b7256eb"
+  integrity sha1-iUhUSRvFkbDxR9euVw9cZ4tyVus=
+  dependencies:
+    rc "^1.1.2"
+
+get-stdin@^4.0.1:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/get-stdin/-/get-stdin-4.0.1.tgz#b968c6b0a04384324902e8bf1a5df32579a450fe"
+  integrity sha1-uWjGsKBDhDJJAui/Gl3zJXmkUP4=
+
+get-stdin@~5.0.1:
+  version "5.0.1"
+  resolved "https://registry.yarnpkg.com/get-stdin/-/get-stdin-5.0.1.tgz#122e161591e21ff4c52530305693f20e6393a398"
+  integrity sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g=
+
+get-stream@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/get-stream/-/get-stream-3.0.0.tgz#8e943d1358dc37555054ecbe2edb05aa174ede14"
+  integrity sha1-jpQ9E1jcN1VQVOy+LtsFqhdO3hQ=
+
+get-value@^2.0.3, get-value@^2.0.6:
+  version "2.0.6"
+  resolved "https://registry.yarnpkg.com/get-value/-/get-value-2.0.6.tgz#dc15ca1c672387ca76bd37ac0a395ba2042a2c28"
+  integrity sha1-3BXKHGcjh8p2vTesCjlbogQqLCg=
+
+gifsicle@^3.0.0:
+  version "3.0.4"
+  resolved "https://registry.yarnpkg.com/gifsicle/-/gifsicle-3.0.4.tgz#f45cb5ed10165b665dc929e0e9328b6c821dfa3b"
+  integrity sha1-9Fy17RAWW2ZdySng6TKLbIId+js=
+  dependencies:
+    bin-build "^2.0.0"
+    bin-wrapper "^3.0.0"
+    logalot "^2.0.0"
+
+glob-base@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/glob-base/-/glob-base-0.3.0.tgz#dbb164f6221b1c0b1ccf82aea328b497df0ea3c4"
+  integrity sha1-27Fk9iIbHAscz4Kuoyi0l98Oo8Q=
+  dependencies:
+    glob-parent "^2.0.0"
+    is-glob "^2.0.0"
+
+glob-parent@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-2.0.0.tgz#81383d72db054fcccf5336daa902f182f6edbb28"
+  integrity sha1-gTg9ctsFT8zPUzbaqQLxgvbtuyg=
+  dependencies:
+    is-glob "^2.0.0"
+
+glob-parent@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-3.1.0.tgz#9e6af6299d8d3bd2bd40430832bd113df906c5ae"
+  integrity sha1-nmr2KZ2NO9K9QEMIMr0RPfkGxa4=
+  dependencies:
+    is-glob "^3.1.0"
+    path-dirname "^1.0.0"
+
+glob-stream@^5.3.2:
+  version "5.3.5"
+  resolved "https://registry.yarnpkg.com/glob-stream/-/glob-stream-5.3.5.tgz#a55665a9a8ccdc41915a87c701e32d4e016fad22"
+  integrity sha1-pVZlqajM3EGRWofHAeMtTgFvrSI=
+  dependencies:
+    extend "^3.0.0"
+    glob "^5.0.3"
+    glob-parent "^3.0.0"
+    micromatch "^2.3.7"
+    ordered-read-streams "^0.3.0"
+    through2 "^0.6.0"
+    to-absolute-glob "^0.1.1"
+    unique-stream "^2.0.2"
+
+glob@^5.0.3:
+  version "5.0.15"
+  resolved "https://registry.yarnpkg.com/glob/-/glob-5.0.15.tgz#1bc936b9e02f4a603fcc222ecf7633d30b8b93b1"
+  integrity sha1-G8k2ueAvSmA/zCIuz3Yz0wuLk7E=
+  dependencies:
+    inflight "^1.0.4"
+    inherits "2"
+    minimatch "2 || 3"
+    once "^1.3.0"
+    path-is-absolute "^1.0.0"
+
+glob@^7.1.3, glob@~7.1.2:
+  version "7.1.3"
+  resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.3.tgz#3960832d3f1574108342dafd3a67b332c0969df1"
+  integrity sha512-vcfuiIxogLV4DlGBHIUOwI0IbrJ8HWPc4MU7HzviGeNho/UJDfi6B5p3sHeWIQ0KGIU0Jpxi5ZHxemQfLkkAwQ==
+  dependencies:
+    fs.realpath "^1.0.0"
+    inflight "^1.0.4"
+    inherits "2"
+    minimatch "^3.0.4"
+    once "^1.3.0"
+    path-is-absolute "^1.0.0"
+
+globals@^11.1.0:
+  version "11.12.0"
+  resolved "https://registry.yarnpkg.com/globals/-/globals-11.12.0.tgz#ab8795338868a0babd8525758018c2a7eb95c42e"
+  integrity sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==
+
+glogg@^1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/glogg/-/glogg-1.0.2.tgz#2d7dd702beda22eb3bffadf880696da6d846313f"
+  integrity sha512-5mwUoSuBk44Y4EshyiqcH95ZntbDdTQqA3QYSrxmzj28Ai0vXBGMH1ApSANH14j2sIRtqCEyg6PfsuP7ElOEDA==
+  dependencies:
+    sparkles "^1.0.0"
+
+got@^5.0.0:
+  version "5.7.1"
+  resolved "https://registry.yarnpkg.com/got/-/got-5.7.1.tgz#5f81635a61e4a6589f180569ea4e381680a51f35"
+  integrity sha1-X4FjWmHkplifGAVp6k44FoClHzU=
+  dependencies:
+    create-error-class "^3.0.1"
+    duplexer2 "^0.1.4"
+    is-redirect "^1.0.0"
+    is-retry-allowed "^1.0.0"
+    is-stream "^1.0.0"
+    lowercase-keys "^1.0.0"
+    node-status-codes "^1.0.0"
+    object-assign "^4.0.1"
+    parse-json "^2.1.0"
+    pinkie-promise "^2.0.0"
+    read-all-stream "^3.0.0"
+    readable-stream "^2.0.5"
+    timed-out "^3.0.0"
+    unzip-response "^1.0.2"
+    url-parse-lax "^1.0.0"
+
+graceful-fs@^4.0.0, graceful-fs@^4.1.2:
+  version "4.1.15"
+  resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-4.1.15.tgz#ffb703e1066e8a0eeaa4c8b80ba9253eeefbfb00"
+  integrity sha512-6uHUhOPEBgQ24HM+r6b/QwWfZq+yiFcipKFrOFiBEnWdy5sdzYoi+pJeQaPI5qOLRFqWmAXUPQNsielzdLoecA==
+
+graceful-fs@^4.1.11, graceful-fs@^4.2.4:
+  version "4.2.8"
+  resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-4.2.8.tgz#e412b8d33f5e006593cbd3cee6df9f2cebbe802a"
+  integrity sha512-qkIilPUYcNhJpd33n0GBXTB1MMPp14TxEsEs0pTrsSVucApsYzW5V+Q8Qxhik6KU3evy+qkAAowTByymK0avdg==
+
+"graceful-readlink@>= 1.0.0":
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/graceful-readlink/-/graceful-readlink-1.0.1.tgz#4cafad76bc62f02fa039b2f94e9a3dd3a391a725"
+  integrity sha1-TK+tdrxi8C+gObL5Tpo906ORpyU=
+
+gulp-decompress@^1.2.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/gulp-decompress/-/gulp-decompress-1.2.0.tgz#8eeb65a5e015f8ed8532cafe28454960626f0dc7"
+  integrity sha1-jutlpeAV+O2FMsr+KEVJYGJvDcc=
+  dependencies:
+    archive-type "^3.0.0"
+    decompress "^3.0.0"
+    gulp-util "^3.0.1"
+    readable-stream "^2.0.2"
+
+gulp-rename@^1.2.0:
+  version "1.4.0"
+  resolved "https://registry.yarnpkg.com/gulp-rename/-/gulp-rename-1.4.0.tgz#de1c718e7c4095ae861f7296ef4f3248648240bd"
+  integrity sha512-swzbIGb/arEoFK89tPY58vg3Ok1bw+d35PfUNwWqdo7KM4jkmuGA78JiDNqR+JeZFaeeHnRg9N7aihX3YPmsyg==
+
+gulp-sourcemaps@1.6.0:
+  version "1.6.0"
+  resolved "https://registry.yarnpkg.com/gulp-sourcemaps/-/gulp-sourcemaps-1.6.0.tgz#b86ff349d801ceb56e1d9e7dc7bbcb4b7dee600c"
+  integrity sha1-uG/zSdgBzrVuHZ59x7vLS33uYAw=
+  dependencies:
+    convert-source-map "^1.1.1"
+    graceful-fs "^4.1.2"
+    strip-bom "^2.0.0"
+    through2 "^2.0.0"
+    vinyl "^1.0.0"
+
+gulp-util@^3.0.1:
+  version "3.0.8"
+  resolved "https://registry.yarnpkg.com/gulp-util/-/gulp-util-3.0.8.tgz#0054e1e744502e27c04c187c3ecc505dd54bbb4f"
+  integrity sha1-AFTh50RQLifATBh8PsxQXdVLu08=
+  dependencies:
+    array-differ "^1.0.0"
+    array-uniq "^1.0.2"
+    beeper "^1.0.0"
+    chalk "^1.0.0"
+    dateformat "^2.0.0"
+    fancy-log "^1.1.0"
+    gulplog "^1.0.0"
+    has-gulplog "^0.1.0"
+    lodash._reescape "^3.0.0"
+    lodash._reevaluate "^3.0.0"
+    lodash._reinterpolate "^3.0.0"
+    lodash.template "^3.0.0"
+    minimist "^1.1.0"
+    multipipe "^0.1.2"
+    object-assign "^3.0.0"
+    replace-ext "0.0.1"
+    through2 "^2.0.0"
+    vinyl "^0.5.0"
+
+gulplog@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/gulplog/-/gulplog-1.0.0.tgz#e28c4d45d05ecbbed818363ce8f9c5926229ffe5"
+  integrity sha1-4oxNRdBey77YGDY86PnFkmIp/+U=
+  dependencies:
+    glogg "^1.0.0"
+
+has-ansi@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91"
+  integrity sha1-NPUEnOHs3ysGSa8+8k5F7TVBbZE=
+  dependencies:
+    ansi-regex "^2.0.0"
+
+has-flag@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/has-flag/-/has-flag-3.0.0.tgz#b5d454dc2199ae225699f3467e5a07f3b955bafd"
+  integrity sha1-tdRU3CGZriJWmfNGfloH87lVuv0=
+
+has-gulplog@^0.1.0:
+  version "0.1.0"
+  resolved "https://registry.yarnpkg.com/has-gulplog/-/has-gulplog-0.1.0.tgz#6414c82913697da51590397dafb12f22967811ce"
+  integrity sha1-ZBTIKRNpfaUVkDl9r7EvIpZ4Ec4=
+  dependencies:
+    sparkles "^1.0.0"
+
+has-symbols@^1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/has-symbols/-/has-symbols-1.0.2.tgz#165d3070c00309752a1236a479331e3ac56f1423"
+  integrity sha512-chXa79rL/UC2KlX17jo3vRGz0azaWEx5tGqZg5pO3NUyEJVB17dMruQlzCCOfUvElghKcm5194+BCRvi2Rv/Gw==
+
+has-value@^0.3.1:
+  version "0.3.1"
+  resolved "https://registry.yarnpkg.com/has-value/-/has-value-0.3.1.tgz#7b1f58bada62ca827ec0a2078025654845995e1f"
+  integrity sha1-ex9YutpiyoJ+wKIHgCVlSEWZXh8=
+  dependencies:
+    get-value "^2.0.3"
+    has-values "^0.1.4"
+    isobject "^2.0.0"
+
+has-value@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/has-value/-/has-value-1.0.0.tgz#18b281da585b1c5c51def24c930ed29a0be6b177"
+  integrity sha1-GLKB2lhbHFxR3vJMkw7SmgvmsXc=
+  dependencies:
+    get-value "^2.0.6"
+    has-values "^1.0.0"
+    isobject "^3.0.0"
+
+has-values@^0.1.4:
+  version "0.1.4"
+  resolved "https://registry.yarnpkg.com/has-values/-/has-values-0.1.4.tgz#6d61de95d91dfca9b9a02089ad384bff8f62b771"
+  integrity sha1-bWHeldkd/Km5oCCJrThL/49it3E=
+
+has-values@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/has-values/-/has-values-1.0.0.tgz#95b0b63fec2146619a6fe57fe75628d5a39efe4f"
+  integrity sha1-lbC2P+whRmGab+V/51Yo1aOe/k8=
+  dependencies:
+    is-number "^3.0.0"
+    kind-of "^4.0.0"
+
+has@^1.0.3:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/has/-/has-1.0.3.tgz#722d7cbfc1f6aa8241f16dd814e011e1f41e8796"
+  integrity sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==
+  dependencies:
+    function-bind "^1.1.1"
+
+hosted-git-info@^2.1.4:
+  version "2.7.1"
+  resolved "https://registry.yarnpkg.com/hosted-git-info/-/hosted-git-info-2.7.1.tgz#97f236977bd6e125408930ff6de3eec6281ec047"
+  integrity sha512-7T/BxH19zbcCTa8XkMlbK5lTo1WtgkFi3GvdWEyNuc4Vex7/9Dqbnpsf4JMydcfj9HCg4zUWFTL3Za6lapg5/w==
+
+husky@^0.13.3:
+  version "0.13.4"
+  resolved "https://registry.yarnpkg.com/husky/-/husky-0.13.4.tgz#48785c5028de3452a51c48c12c4f94b2124a1407"
+  integrity sha1-SHhcUCjeNFKlHEjBLE+UshJKFAc=
+  dependencies:
+    chalk "^1.1.3"
+    find-parent-dir "^0.3.0"
+    is-ci "^1.0.9"
+    normalize-path "^1.0.0"
+
+imagemin-gifsicle@^4.0.0:
+  version "4.2.0"
+  resolved "https://registry.yarnpkg.com/imagemin-gifsicle/-/imagemin-gifsicle-4.2.0.tgz#0fef9bbad3476e6b76885736cc5b0b87a08757ca"
+  integrity sha1-D++butNHbmt2iFc2zFsLh6CHV8o=
+  dependencies:
+    gifsicle "^3.0.0"
+    is-gif "^1.0.0"
+    through2 "^0.6.1"
+
+imagemin-jpegtran@^4.0.0:
+  version "4.3.2"
+  resolved "https://registry.yarnpkg.com/imagemin-jpegtran/-/imagemin-jpegtran-4.3.2.tgz#1bc6d1e2bd13fdb64d245526d635a7e5dfeb12fc"
+  integrity sha1-G8bR4r0T/bZNJFUm1jWn5d/rEvw=
+  dependencies:
+    is-jpg "^1.0.0"
+    jpegtran-bin "^3.0.0"
+    through2 "^2.0.0"
+
+imagemin-optipng@^4.0.0, imagemin-optipng@^4.3.0:
+  version "4.3.0"
+  resolved "https://registry.yarnpkg.com/imagemin-optipng/-/imagemin-optipng-4.3.0.tgz#7604663ab2ee315733274726fd1c374d2b44adb6"
+  integrity sha1-dgRmOrLuMVczJ0cm/Rw3TStErbY=
+  dependencies:
+    exec-buffer "^2.0.0"
+    is-png "^1.0.0"
+    optipng-bin "^3.0.0"
+    through2 "^0.6.1"
+
+imagemin-svgo@^4.0.0:
+  version "4.2.1"
+  resolved "https://registry.yarnpkg.com/imagemin-svgo/-/imagemin-svgo-4.2.1.tgz#54f07dc56f47260462df6a61c54befb44b57be55"
+  integrity sha1-VPB9xW9HJgRi32phxUvvtEtXvlU=
+  dependencies:
+    is-svg "^1.0.0"
+    svgo "^0.6.0"
+    through2 "^2.0.0"
+
+imagemin@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/imagemin/-/imagemin-4.0.0.tgz#e90e7f0936836595f18fa15fe906f4fa259ea847"
+  integrity sha1-6Q5/CTaDZZXxj6Ff6Qb0+iWeqEc=
+  dependencies:
+    buffer-to-vinyl "^1.0.0"
+    concat-stream "^1.4.6"
+    optional "^0.1.0"
+    readable-stream "^2.0.0"
+    stream-combiner2 "^1.1.1"
+    vinyl-fs "^2.1.1"
+  optionalDependencies:
+    imagemin-gifsicle "^4.0.0"
+    imagemin-jpegtran "^4.0.0"
+    imagemin-optipng "^4.0.0"
+    imagemin-svgo "^4.0.0"
+
+imurmurhash@^0.1.4:
+  version "0.1.4"
+  resolved "https://registry.yarnpkg.com/imurmurhash/-/imurmurhash-0.1.4.tgz#9218b9b2b928a238b13dc4fb6b6d576f231453ea"
+  integrity sha1-khi5srkoojixPcT7a21XbyMUU+o=
+
+indent-string@^2.1.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/indent-string/-/indent-string-2.1.0.tgz#8e2d48348742121b4a8218b7a137e9a52049dc80"
+  integrity sha1-ji1INIdCEhtKghi3oTfppSBJ3IA=
+  dependencies:
+    repeating "^2.0.0"
+
+indent-string@^3.0.0:
+  version "3.2.0"
+  resolved "https://registry.yarnpkg.com/indent-string/-/indent-string-3.2.0.tgz#4a5fd6d27cc332f37e5419a504dbb837105c9289"
+  integrity sha1-Sl/W0nzDMvN+VBmlBNu4NxBckok=
+
+inflight@^1.0.4:
+  version "1.0.6"
+  resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
+  integrity sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=
+  dependencies:
+    once "^1.3.0"
+    wrappy "1"
+
+inherits@2, inherits@^2.0.1, inherits@^2.0.3, inherits@~2.0.1:
+  version "2.0.3"
+  resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.3.tgz#633c2c83e3da42a502f52466022480f4208261de"
+  integrity sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=
+
+inherits@~2.0.3:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.4.tgz#0fa2c64f932917c3433a0ded55363aae37416b7c"
+  integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==
+
+ini@~1.3.0:
+  version "1.3.5"
+  resolved "https://registry.yarnpkg.com/ini/-/ini-1.3.5.tgz#eee25f56db1c9ec6085e0c22778083f596abf927"
+  integrity sha512-RZY5huIKCMRWDUqZlEi72f/lmXKMvuszcMBduliQ3nnWbx9X/ZBQO7DijMEYS9EhHBb2qacRUMtC7svLwe0lcw==
+
+ip-regex@^1.0.1:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/ip-regex/-/ip-regex-1.0.3.tgz#dc589076f659f419c222039a33316f1c7387effd"
+  integrity sha1-3FiQdvZZ9BnCIgOaMzFvHHOH7/0=
+
+is-absolute@^0.1.5:
+  version "0.1.7"
+  resolved "https://registry.yarnpkg.com/is-absolute/-/is-absolute-0.1.7.tgz#847491119fccb5fb436217cc737f7faad50f603f"
+  integrity sha1-hHSREZ/MtftDYhfMc39/qtUPYD8=
+  dependencies:
+    is-relative "^0.1.0"
+
+is-accessor-descriptor@^0.1.6:
+  version "0.1.6"
+  resolved "https://registry.yarnpkg.com/is-accessor-descriptor/-/is-accessor-descriptor-0.1.6.tgz#a9e12cb3ae8d876727eeef3843f8a0897b5c98d6"
+  integrity sha1-qeEss66Nh2cn7u84Q/igiXtcmNY=
+  dependencies:
+    kind-of "^3.0.2"
+
+is-accessor-descriptor@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz#169c2f6d3df1f992618072365c9b0ea1f6878656"
+  integrity sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==
+  dependencies:
+    kind-of "^6.0.0"
+
+is-arrayish@^0.2.1:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/is-arrayish/-/is-arrayish-0.2.1.tgz#77c99840527aa8ecb1a8ba697b80645a7a926a9d"
+  integrity sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=
+
+is-buffer@^1.1.5:
+  version "1.1.6"
+  resolved "https://registry.yarnpkg.com/is-buffer/-/is-buffer-1.1.6.tgz#efaa2ea9daa0d7ab2ea13a97b2b8ad51fefbe8be"
+  integrity sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==
+
+is-bzip2@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-bzip2/-/is-bzip2-1.0.0.tgz#5ee58eaa5a2e9c80e21407bedf23ae5ac091b3fc"
+  integrity sha1-XuWOqlounIDiFAe+3yOuWsCRs/w=
+
+is-ci@^1.0.9:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/is-ci/-/is-ci-1.2.1.tgz#e3779c8ee17fccf428488f6e281187f2e632841c"
+  integrity sha512-s6tfsaQaQi3JNciBH6shVqEDvhGut0SUXr31ag8Pd8BBbVVlcGfWhpPmEOoM6RJ5TFhbypvf5yyRw/VXW1IiWg==
+  dependencies:
+    ci-info "^1.5.0"
+
+is-data-descriptor@^0.1.4:
+  version "0.1.4"
+  resolved "https://registry.yarnpkg.com/is-data-descriptor/-/is-data-descriptor-0.1.4.tgz#0b5ee648388e2c860282e793f1856fec3f301b56"
+  integrity sha1-C17mSDiOLIYCgueT8YVv7D8wG1Y=
+  dependencies:
+    kind-of "^3.0.2"
+
+is-data-descriptor@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz#d84876321d0e7add03990406abbbbd36ba9268c7"
+  integrity sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==
+  dependencies:
+    kind-of "^6.0.0"
+
+is-descriptor@^0.1.0:
+  version "0.1.6"
+  resolved "https://registry.yarnpkg.com/is-descriptor/-/is-descriptor-0.1.6.tgz#366d8240dde487ca51823b1ab9f07a10a78251ca"
+  integrity sha512-avDYr0SB3DwO9zsMov0gKCESFYqCnE4hq/4z3TdUlukEy5t9C0YRq7HLrsN52NAcqXKaepeCD0n+B0arnVG3Hg==
+  dependencies:
+    is-accessor-descriptor "^0.1.6"
+    is-data-descriptor "^0.1.4"
+    kind-of "^5.0.0"
+
+is-descriptor@^1.0.0, is-descriptor@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/is-descriptor/-/is-descriptor-1.0.2.tgz#3b159746a66604b04f8c81524ba365c5f14d86ec"
+  integrity sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==
+  dependencies:
+    is-accessor-descriptor "^1.0.0"
+    is-data-descriptor "^1.0.0"
+    kind-of "^6.0.2"
+
+is-dotfile@^1.0.0:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/is-dotfile/-/is-dotfile-1.0.3.tgz#a6a2f32ffd2dfb04f5ca25ecd0f6b83cf798a1e1"
+  integrity sha1-pqLzL/0t+wT1yiXs0Pa4PPeYoeE=
+
+is-equal-shallow@^0.1.3:
+  version "0.1.3"
+  resolved "https://registry.yarnpkg.com/is-equal-shallow/-/is-equal-shallow-0.1.3.tgz#2238098fc221de0bcfa5d9eac4c45d638aa1c534"
+  integrity sha1-IjgJj8Ih3gvPpdnqxMRdY4qhxTQ=
+  dependencies:
+    is-primitive "^2.0.0"
+
+is-extendable@^0.1.0, is-extendable@^0.1.1:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/is-extendable/-/is-extendable-0.1.1.tgz#62b110e289a471418e3ec36a617d472e301dfc89"
+  integrity sha1-YrEQ4omkcUGOPsNqYX1HLjAd/Ik=
+
+is-extendable@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/is-extendable/-/is-extendable-1.0.1.tgz#a7470f9e426733d81bd81e1155264e3a3507cab4"
+  integrity sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==
+  dependencies:
+    is-plain-object "^2.0.4"
+
+is-extglob@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-extglob/-/is-extglob-1.0.0.tgz#ac468177c4943405a092fc8f29760c6ffc6206c0"
+  integrity sha1-rEaBd8SUNAWgkvyPKXYMb/xiBsA=
+
+is-extglob@^2.1.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/is-extglob/-/is-extglob-2.1.1.tgz#a88c02535791f02ed37c76a1b9ea9773c833f8c2"
+  integrity sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=
+
+is-finite@^1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/is-finite/-/is-finite-1.0.2.tgz#cc6677695602be550ef11e8b4aa6305342b6d0aa"
+  integrity sha1-zGZ3aVYCvlUO8R6LSqYwU0K20Ko=
+  dependencies:
+    number-is-nan "^1.0.0"
+
+is-fullwidth-code-point@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-fullwidth-code-point/-/is-fullwidth-code-point-1.0.0.tgz#ef9e31386f031a7f0d643af82fde50c457ef00cb"
+  integrity sha1-754xOG8DGn8NZDr4L95QxFfvAMs=
+  dependencies:
+    number-is-nan "^1.0.0"
+
+is-gif@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-gif/-/is-gif-1.0.0.tgz#a6d2ae98893007bffa97a1d8c01d63205832097e"
+  integrity sha1-ptKumIkwB7/6l6HYwB1jIFgyCX4=
+
+is-glob@^2.0.0, is-glob@^2.0.1:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-2.0.1.tgz#d096f926a3ded5600f3fdfd91198cb0888c2d863"
+  integrity sha1-0Jb5JqPe1WAPP9/ZEZjLCIjC2GM=
+  dependencies:
+    is-extglob "^1.0.0"
+
+is-glob@^3.1.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-3.1.0.tgz#7ba5ae24217804ac70707b96922567486cc3e84a"
+  integrity sha1-e6WuJCF4BKxwcHuWkiVnSGzD6Eo=
+  dependencies:
+    is-extglob "^2.1.0"
+
+is-gzip@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-gzip/-/is-gzip-1.0.0.tgz#6ca8b07b99c77998025900e555ced8ed80879a83"
+  integrity sha1-bKiwe5nHeZgCWQDlVc7Y7YCHmoM=
+
+is-jpg@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/is-jpg/-/is-jpg-1.0.1.tgz#296d57fdd99ce010434a7283e346ab9a1035e975"
+  integrity sha1-KW1X/dmc4BBDSnKD40armhA16XU=
+
+is-natural-number@^2.0.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/is-natural-number/-/is-natural-number-2.1.1.tgz#7d4c5728377ef386c3e194a9911bf57c6dc335e7"
+  integrity sha1-fUxXKDd+84bD4ZSpkRv1fG3DNec=
+
+is-number@^2.1.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/is-number/-/is-number-2.1.0.tgz#01fcbbb393463a548f2f466cce16dece49db908f"
+  integrity sha1-Afy7s5NGOlSPL0ZszhbezknbkI8=
+  dependencies:
+    kind-of "^3.0.2"
+
+is-number@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/is-number/-/is-number-3.0.0.tgz#24fd6201a4782cf50561c810276afc7d12d71195"
+  integrity sha1-JP1iAaR4LPUFYcgQJ2r8fRLXEZU=
+  dependencies:
+    kind-of "^3.0.2"
+
+is-number@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/is-number/-/is-number-4.0.0.tgz#0026e37f5454d73e356dfe6564699867c6a7f0ff"
+  integrity sha512-rSklcAIlf1OmFdyAqbnWTLVelsQ58uvZ66S/ZyawjWqIviTWCjg2PzVGw8WUA+nNuPTqb4wgA+NszrJ+08LlgQ==
+
+is-obj@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/is-obj/-/is-obj-1.0.1.tgz#3e4729ac1f5fde025cd7d83a896dab9f4f67db0f"
+  integrity sha1-PkcprB9f3gJc19g6iW2rn09n2w8=
+
+is-plain-object@^2.0.3, is-plain-object@^2.0.4:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/is-plain-object/-/is-plain-object-2.0.4.tgz#2c163b3fafb1b606d9d17928f05c2a1c38e07677"
+  integrity sha512-h5PpgXkWitc38BBMYawTYMWJHFZJVnBquFE57xFpjB8pJFiF6gZ+bU+WyI/yqXiFR5mdLsgYNaPe8uao6Uv9Og==
+  dependencies:
+    isobject "^3.0.1"
+
+is-png@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/is-png/-/is-png-1.1.0.tgz#d574b12bf275c0350455570b0e5b57ab062077ce"
+  integrity sha1-1XSxK/J1wDUEVVcLDltXqwYgd84=
+
+is-posix-bracket@^0.1.0:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/is-posix-bracket/-/is-posix-bracket-0.1.1.tgz#3334dc79774368e92f016e6fbc0a88f5cd6e6bc4"
+  integrity sha1-MzTceXdDaOkvAW5vvAqI9c1ua8Q=
+
+is-primitive@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/is-primitive/-/is-primitive-2.0.0.tgz#207bab91638499c07b2adf240a41a87210034575"
+  integrity sha1-IHurkWOEmcB7Kt8kCkGochADRXU=
+
+is-promise@^2.1.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/is-promise/-/is-promise-2.1.0.tgz#79a2a9ece7f096e80f36d2b2f3bc16c1ff4bf3fa"
+  integrity sha1-eaKp7OfwlugPNtKy87wWwf9L8/o=
+
+is-redirect@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-redirect/-/is-redirect-1.0.0.tgz#1d03dded53bd8db0f30c26e4f95d36fc7c87dc24"
+  integrity sha1-HQPd7VO9jbDzDCbk+V02/HyH3CQ=
+
+is-relative@^0.1.0:
+  version "0.1.3"
+  resolved "https://registry.yarnpkg.com/is-relative/-/is-relative-0.1.3.tgz#905fee8ae86f45b3ec614bc3c15c869df0876e82"
+  integrity sha1-kF/uiuhvRbPsYUvDwVyGnfCHboI=
+
+is-retry-allowed@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/is-retry-allowed/-/is-retry-allowed-1.1.0.tgz#11a060568b67339444033d0125a61a20d564fb34"
+  integrity sha1-EaBgVotnM5REAz0BJaYaINVk+zQ=
+
+is-stream@^1.0.0, is-stream@^1.0.1, is-stream@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/is-stream/-/is-stream-1.1.0.tgz#12d4a3dd4e68e0b79ceb8dbc84173ae80d91ca44"
+  integrity sha1-EtSj3U5o4Lec6428hBc66A2RykQ=
+
+is-svg@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/is-svg/-/is-svg-1.1.1.tgz#ac0efaafb653ac58473708b1f873636ca110e31b"
+  integrity sha1-rA76r7ZTrFhHNwix+HNjbKEQ4xs=
+
+is-tar@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-tar/-/is-tar-1.0.0.tgz#2f6b2e1792c1f5bb36519acaa9d65c0d26fe853d"
+  integrity sha1-L2suF5LB9bs2UZrKqdZcDSb+hT0=
+
+is-url@^1.2.0:
+  version "1.2.4"
+  resolved "https://registry.yarnpkg.com/is-url/-/is-url-1.2.4.tgz#04a4df46d28c4cff3d73d01ff06abeb318a1aa52"
+  integrity sha512-ITvGim8FhRiYe4IQ5uHSkj7pVaPDrCTkNd3yq3cV7iZAcJdHTUMPMEHcqSOy9xZ9qFenQCvi+2wjH9a1nXqHww==
+
+is-utf8@^0.2.0:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/is-utf8/-/is-utf8-0.2.1.tgz#4b0da1442104d1b336340e80797e865cf39f7d72"
+  integrity sha1-Sw2hRCEE0bM2NA6AeX6GXPOffXI=
+
+is-valid-glob@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/is-valid-glob/-/is-valid-glob-0.3.0.tgz#d4b55c69f51886f9b65c70d6c2622d37e29f48fe"
+  integrity sha1-1LVcafUYhvm2XHDWwmItN+KfSP4=
+
+is-windows@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/is-windows/-/is-windows-1.0.2.tgz#d1850eb9791ecd18e6182ce12a30f396634bb19d"
+  integrity sha512-eXK1UInq2bPmjyX6e3VHIzMLobc4J94i4AWn+Hpq3OU5KkrRC96OAcR3PRJ/pGu6m8TRnBHP9dkXQVsT/COVIA==
+
+is-zip@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/is-zip/-/is-zip-1.0.0.tgz#47b0a8ff4d38a76431ccfd99a8e15a4c86ba2325"
+  integrity sha1-R7Co/004p2QxzP2ZqOFaTIa6IyU=
+
+isarray@0.0.1:
+  version "0.0.1"
+  resolved "https://registry.yarnpkg.com/isarray/-/isarray-0.0.1.tgz#8a18acfca9a8f4177e09abfc6038939b05d1eedf"
+  integrity sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=
+
+isarray@1.0.0, isarray@~1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/isarray/-/isarray-1.0.0.tgz#bb935d48582cba168c06834957a54a3e07124f11"
+  integrity sha1-u5NdSFgsuhaMBoNJV6VKPgcSTxE=
+
+isexe@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/isexe/-/isexe-2.0.0.tgz#e8fbf374dc556ff8947a10dcb0572d633f2cfa10"
+  integrity sha1-6PvzdNxVb/iUehDcsFctYz8s+hA=
+
+isobject@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/isobject/-/isobject-2.1.0.tgz#f065561096a3f1da2ef46272f815c840d87e0c89"
+  integrity sha1-8GVWEJaj8dou9GJy+BXIQNh+DIk=
+  dependencies:
+    isarray "1.0.0"
+
+isobject@^3.0.0, isobject@^3.0.1:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/isobject/-/isobject-3.0.1.tgz#4e431e92b11a9731636aa1f9c8d1ccbcfdab78df"
+  integrity sha1-TkMekrEalzFjaqH5yNHMvP2reN8=
+
+jpegtran-bin@^3.0.0:
+  version "3.2.0"
+  resolved "https://registry.yarnpkg.com/jpegtran-bin/-/jpegtran-bin-3.2.0.tgz#f60ecf4ae999c0bdad2e9fbcdf2b6f0981e7a29b"
+  integrity sha1-9g7PSumZwL2tLp+83ytvCYHnops=
+  dependencies:
+    bin-build "^2.0.0"
+    bin-wrapper "^3.0.0"
+    logalot "^2.0.0"
+
+js-tokens@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/js-tokens/-/js-tokens-4.0.0.tgz#19203fb59991df98e3a287050d4647cdeaf32499"
+  integrity sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==
+
+js-yaml@^3.4.3:
+  version "3.12.2"
+  resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.12.2.tgz#ef1d067c5a9d9cb65bd72f285b5d8105c77f14fc"
+  integrity sha512-QHn/Lh/7HhZ/Twc7vJYQTkjuCa0kaCcDcjK5Zlk2rvnUpy7DxMJ23+Jc2dcyvltwQVg1nygAVlB2oRDFHoRS5Q==
+  dependencies:
+    argparse "^1.0.7"
+    esprima "^4.0.0"
+
+js-yaml@~3.13.0:
+  version "3.13.1"
+  resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.13.1.tgz#aff151b30bfdfa8e49e05da22e7415e9dfa37847"
+  integrity sha512-YfbcO7jXDdyj0DGxYVSlSeQNHbD7XPWvrVWeVUujrQEoZzWJIRrCPoyk6kL6IAjAG2IolMK4T0hNUe0HOUs5Jw==
+  dependencies:
+    argparse "^1.0.7"
+    esprima "^4.0.0"
+
+js-yaml@~3.6.0:
+  version "3.6.1"
+  resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.6.1.tgz#6e5fe67d8b205ce4d22fad05b7781e8dadcc4b30"
+  integrity sha1-bl/mfYsgXOTSL60Ft3geja3MSzA=
+  dependencies:
+    argparse "^1.0.7"
+    esprima "^2.6.0"
+
+jscodeshift@^0.13.0:
+  version "0.13.0"
+  resolved "https://registry.yarnpkg.com/jscodeshift/-/jscodeshift-0.13.0.tgz#4b3835c3755ea86bc4910ac80acd4acd230b53ee"
+  integrity sha512-FNHLuwh7TeI0F4EzNVIRwUSxSqsGWM5nTv596FK4NfBnEEKFpIcyFeG559DMFGHSTIYA5AY4Fqh2cBrJx0EAwg==
+  dependencies:
+    "@babel/core" "^7.13.16"
+    "@babel/parser" "^7.13.16"
+    "@babel/plugin-proposal-class-properties" "^7.13.0"
+    "@babel/plugin-proposal-nullish-coalescing-operator" "^7.13.8"
+    "@babel/plugin-proposal-optional-chaining" "^7.13.12"
+    "@babel/plugin-transform-modules-commonjs" "^7.13.8"
+    "@babel/preset-flow" "^7.13.13"
+    "@babel/preset-typescript" "^7.13.0"
+    "@babel/register" "^7.13.16"
+    babel-core "^7.0.0-bridge.0"
+    colors "^1.1.2"
+    flow-parser "0.*"
+    graceful-fs "^4.2.4"
+    micromatch "^3.1.10"
+    neo-async "^2.5.0"
+    node-dir "^0.1.17"
+    recast "^0.20.4"
+    temp "^0.8.4"
+    write-file-atomic "^2.3.0"
+
+jsesc@^2.5.1:
+  version "2.5.2"
+  resolved "https://registry.yarnpkg.com/jsesc/-/jsesc-2.5.2.tgz#80564d2e483dacf6e8ef209650a67df3f0c283a4"
+  integrity sha512-OYu7XEzjkCQ3C5Ps3QIZsQfNpqoJyZZA99wd9aWd05NCtC5pWOkShK2mkL6HXQR6/Cy2lbNdPlZBpuQHXE63gA==
+
+json-stable-stringify-without-jsonify@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz#9db7b59496ad3f3cfef30a75142d2d930ad72651"
+  integrity sha1-nbe1lJatPzz+8wp1FC0tkwrXJlE=
+
+json5@^2.1.2:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/json5/-/json5-2.2.0.tgz#2dfefe720c6ba525d9ebd909950f0515316c89a3"
+  integrity sha512-f+8cldu7X/y7RAJurMEJmdoKXGB/X550w2Nr3tTbezL6RwEE/iMcm+tZnXeoZtKuOq6ft8+CqzEkrIgx1fPoQA==
+  dependencies:
+    minimist "^1.2.5"
+
+kind-of@^3.0.2, kind-of@^3.0.3, kind-of@^3.2.0:
+  version "3.2.2"
+  resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-3.2.2.tgz#31ea21a734bab9bbb0f32466d893aea51e4a3c64"
+  integrity sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=
+  dependencies:
+    is-buffer "^1.1.5"
+
+kind-of@^4.0.0:
+  version "4.0.0"
+  resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-4.0.0.tgz#20813df3d712928b207378691a45066fae72dd57"
+  integrity sha1-IIE989cSkosgc3hpGkUGb65y3Vc=
+  dependencies:
+    is-buffer "^1.1.5"
+
+kind-of@^5.0.0:
+  version "5.1.0"
+  resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-5.1.0.tgz#729c91e2d857b7a419a1f9aa65685c4c33f5845d"
+  integrity sha512-NGEErnH6F2vUuXDh+OlbcKW7/wOcfdRHaZ7VWtqCztfHri/++YKmP51OdWeGPuqCOba6kk2OTe5d02VmTB80Pw==
+
+kind-of@^6.0.0:
+  version "6.0.2"
+  resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.2.tgz#01146b36a6218e64e58f3a8d66de5d7fc6f6d051"
+  integrity sha512-s5kLOcnH0XqDO+FvuaLX8DDjZ18CGFk7VygH40QoKPUQhW4e2rvM0rwUq0t8IQDOwYSeLK01U90OjzBTme2QqA==
+
+kind-of@^6.0.2:
+  version "6.0.3"
+  resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.3.tgz#07c05034a6c349fa06e24fa35aa76db4580ce4dd"
+  integrity sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==
+
+lazy-req@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/lazy-req/-/lazy-req-1.1.0.tgz#bdaebead30f8d824039ce0ce149d4daa07ba1fac"
+  integrity sha1-va6+rTD42CQDnODOFJ1Nqge6H6w=
+
+lazystream@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/lazystream/-/lazystream-1.0.0.tgz#f6995fe0f820392f61396be89462407bb77168e4"
+  integrity sha1-9plf4PggOS9hOWvolGJAe7dxaOQ=
+  dependencies:
+    readable-stream "^2.0.5"
+
+linkify-it@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/linkify-it/-/linkify-it-2.1.0.tgz#c4caf38a6cd7ac2212ef3c7d2bde30a91561f9db"
+  integrity sha512-4REs8/062kV2DSHxNfq5183zrqXMl7WP0WzABH9IeJI+NLm429FgE1PDecltYfnOoFDFlZGh2T8PfZn0r+GTRg==
+  dependencies:
+    uc.micro "^1.0.1"
+
+lint-staged@^3.4.2:
+  version "3.6.1"
+  resolved "https://registry.yarnpkg.com/lint-staged/-/lint-staged-3.6.1.tgz#24423c8b7bd99d96e15acd1ac8cb392a78e58582"
+  integrity sha1-JEI8i3vZnZbhWs0ayMs5KnjlhYI=
+  dependencies:
+    app-root-path "^2.0.0"
+    cosmiconfig "^1.1.0"
+    execa "^0.7.0"
+    listr "^0.12.0"
+    lodash.chunk "^4.2.0"
+    minimatch "^3.0.0"
+    npm-which "^3.0.1"
+    p-map "^1.1.1"
+    staged-git-files "0.0.4"
+
+listr-silent-renderer@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/listr-silent-renderer/-/listr-silent-renderer-1.1.1.tgz#924b5a3757153770bf1a8e3fbf74b8bbf3f9242e"
+  integrity sha1-kktaN1cVN3C/Go4/v3S4u/P5JC4=
+
+listr-update-renderer@^0.2.0:
+  version "0.2.0"
+  resolved "https://registry.yarnpkg.com/listr-update-renderer/-/listr-update-renderer-0.2.0.tgz#ca80e1779b4e70266807e8eed1ad6abe398550f9"
+  integrity sha1-yoDhd5tOcCZoB+ju0a1qvjmFUPk=
+  dependencies:
+    chalk "^1.1.3"
+    cli-truncate "^0.2.1"
+    elegant-spinner "^1.0.1"
+    figures "^1.7.0"
+    indent-string "^3.0.0"
+    log-symbols "^1.0.2"
+    log-update "^1.0.2"
+    strip-ansi "^3.0.1"
+
+listr-verbose-renderer@^0.4.0:
+  version "0.4.1"
+  resolved "https://registry.yarnpkg.com/listr-verbose-renderer/-/listr-verbose-renderer-0.4.1.tgz#8206f4cf6d52ddc5827e5fd14989e0e965933a35"
+  integrity sha1-ggb0z21S3cWCfl/RSYng6WWTOjU=
+  dependencies:
+    chalk "^1.1.3"
+    cli-cursor "^1.0.2"
+    date-fns "^1.27.2"
+    figures "^1.7.0"
+
+listr@^0.12.0:
+  version "0.12.0"
+  resolved "https://registry.yarnpkg.com/listr/-/listr-0.12.0.tgz#6bce2c0f5603fa49580ea17cd6a00cc0e5fa451a"
+  integrity sha1-a84sD1YD+klYDqF81qAMwOX6RRo=
+  dependencies:
+    chalk "^1.1.3"
+    cli-truncate "^0.2.1"
+    figures "^1.7.0"
+    indent-string "^2.1.0"
+    is-promise "^2.1.0"
+    is-stream "^1.1.0"
+    listr-silent-renderer "^1.1.1"
+    listr-update-renderer "^0.2.0"
+    listr-verbose-renderer "^0.4.0"
+    log-symbols "^1.0.2"
+    log-update "^1.0.2"
+    ora "^0.2.3"
+    p-map "^1.1.1"
+    rxjs "^5.0.0-beta.11"
+    stream-to-observable "^0.1.0"
+    strip-ansi "^3.0.1"
+
+load-json-file@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/load-json-file/-/load-json-file-1.1.0.tgz#956905708d58b4bab4c2261b04f59f31c99374c0"
+  integrity sha1-lWkFcI1YtLq0wiYbBPWfMcmTdMA=
+  dependencies:
+    graceful-fs "^4.1.2"
+    parse-json "^2.2.0"
+    pify "^2.0.0"
+    pinkie-promise "^2.0.0"
+    strip-bom "^2.0.0"
+
+locate-path@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/locate-path/-/locate-path-3.0.0.tgz#dbec3b3ab759758071b58fe59fc41871af21400e"
+  integrity sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==
+  dependencies:
+    p-locate "^3.0.0"
+    path-exists "^3.0.0"
+
+lodash._basecopy@^3.0.0:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/lodash._basecopy/-/lodash._basecopy-3.0.1.tgz#8da0e6a876cf344c0ad8a54882111dd3c5c7ca36"
+  integrity sha1-jaDmqHbPNEwK2KVIghEd08XHyjY=
+
+lodash._basetostring@^3.0.0:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/lodash._basetostring/-/lodash._basetostring-3.0.1.tgz#d1861d877f824a52f669832dcaf3ee15566a07d5"
+  integrity sha1-0YYdh3+CSlL2aYMtyvPuFVZqB9U=
+
+lodash._basevalues@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/lodash._basevalues/-/lodash._basevalues-3.0.0.tgz#5b775762802bde3d3297503e26300820fdf661b7"
+  integrity sha1-W3dXYoAr3j0yl1A+JjAIIP32Ybc=
+
+lodash._getnative@^3.0.0:
+  version "3.9.1"
+  resolved "https://registry.yarnpkg.com/lodash._getnative/-/lodash._getnative-3.9.1.tgz#570bc7dede46d61cdcde687d65d3eecbaa3aaff5"
+  integrity sha1-VwvH3t5G1hzc3mh9ZdPuy6o6r/U=
+
+lodash._isiterateecall@^3.0.0:
+  version "3.0.9"
+  resolved "https://registry.yarnpkg.com/lodash._isiterateecall/-/lodash._isiterateecall-3.0.9.tgz#5203ad7ba425fae842460e696db9cf3e6aac057c"
+  integrity sha1-UgOte6Ql+uhCRg5pbbnPPmqsBXw=
+
+lodash._reescape@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/lodash._reescape/-/lodash._reescape-3.0.0.tgz#2b1d6f5dfe07c8a355753e5f27fac7f1cde1616a"
+  integrity sha1-Kx1vXf4HyKNVdT5fJ/rH8c3hYWo=
+
+lodash._reevaluate@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/lodash._reevaluate/-/lodash._reevaluate-3.0.0.tgz#58bc74c40664953ae0b124d806996daca431e2ed"
+  integrity sha1-WLx0xAZklTrgsSTYBpltrKQx4u0=
+
+lodash._reinterpolate@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/lodash._reinterpolate/-/lodash._reinterpolate-3.0.0.tgz#0ccf2d89166af03b3663c796538b75ac6e114d9d"
+  integrity sha1-DM8tiRZq8Ds2Y8eWU4t1rG4RTZ0=
+
+lodash._root@^3.0.0:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/lodash._root/-/lodash._root-3.0.1.tgz#fba1c4524c19ee9a5f8136b4609f017cf4ded692"
+  integrity sha1-+6HEUkwZ7ppfgTa0YJ8BfPTe1pI=
+
+lodash.chunk@^4.2.0:
+  version "4.2.0"
+  resolved "https://registry.yarnpkg.com/lodash.chunk/-/lodash.chunk-4.2.0.tgz#66e5ce1f76ed27b4303d8c6512e8d1216e8106bc"
+  integrity sha1-ZuXOH3btJ7QwPYxlEujRIW6BBrw=
+
+lodash.differencewith@~4.5.0:
+  version "4.5.0"
+  resolved "https://registry.yarnpkg.com/lodash.differencewith/-/lodash.differencewith-4.5.0.tgz#bafafbc918b55154e179176a00bb0aefaac854b7"
+  integrity sha1-uvr7yRi1UVTheRdqALsK76rIVLc=
+
+lodash.escape@^3.0.0:
+  version "3.2.0"
+  resolved "https://registry.yarnpkg.com/lodash.escape/-/lodash.escape-3.2.0.tgz#995ee0dc18c1b48cc92effae71a10aab5b487698"
+  integrity sha1-mV7g3BjBtIzJLv+ucaEKq1tIdpg=
+  dependencies:
+    lodash._root "^3.0.0"
+
+lodash.flatten@~4.4.0:
+  version "4.4.0"
+  resolved "https://registry.yarnpkg.com/lodash.flatten/-/lodash.flatten-4.4.0.tgz#f31c22225a9632d2bbf8e4addbef240aa765a61f"
+  integrity sha1-8xwiIlqWMtK7+OSt2+8kCqdlph8=
+
+lodash.isarguments@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/lodash.isarguments/-/lodash.isarguments-3.1.0.tgz#2f573d85c6a24289ff00663b491c1d338ff3458a"
+  integrity sha1-L1c9hcaiQon/AGY7SRwdM4/zRYo=
+
+lodash.isarray@^3.0.0:
+  version "3.0.4"
+  resolved "https://registry.yarnpkg.com/lodash.isarray/-/lodash.isarray-3.0.4.tgz#79e4eb88c36a8122af86f844aa9bcd851b5fbb55"
+  integrity sha1-eeTriMNqgSKvhvhEqpvNhRtfu1U=
+
+lodash.isequal@^4.0.0:
+  version "4.5.0"
+  resolved "https://registry.yarnpkg.com/lodash.isequal/-/lodash.isequal-4.5.0.tgz#415c4478f2bcc30120c22ce10ed3226f7d3e18e0"
+  integrity sha1-QVxEePK8wwEgwizhDtMib30+GOA=
+
+lodash.keys@^3.0.0:
+  version "3.1.2"
+  resolved "https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a"
+  integrity sha1-TbwEcrFWvlCgsoaFXRvQsMZWCYo=
+  dependencies:
+    lodash._getnative "^3.0.0"
+    lodash.isarguments "^3.0.0"
+    lodash.isarray "^3.0.0"
+
+lodash.restparam@^3.0.0:
+  version "3.6.1"
+  resolved "https://registry.yarnpkg.com/lodash.restparam/-/lodash.restparam-3.6.1.tgz#936a4e309ef330a7645ed4145986c85ae5b20805"
+  integrity sha1-k2pOMJ7zMKdkXtQUWYbIWuWyCAU=
+
+lodash.template@^3.0.0:
+  version "3.6.2"
+  resolved "https://registry.yarnpkg.com/lodash.template/-/lodash.template-3.6.2.tgz#f8cdecc6169a255be9098ae8b0c53d378931d14f"
+  integrity sha1-+M3sxhaaJVvpCYrosMU9N4kx0U8=
+  dependencies:
+    lodash._basecopy "^3.0.0"
+    lodash._basetostring "^3.0.0"
+    lodash._basevalues "^3.0.0"
+    lodash._isiterateecall "^3.0.0"
+    lodash._reinterpolate "^3.0.0"
+    lodash.escape "^3.0.0"
+    lodash.keys "^3.0.0"
+    lodash.restparam "^3.0.0"
+    lodash.templatesettings "^3.0.0"
+
+lodash.templatesettings@^3.0.0:
+  version "3.1.1"
+  resolved "https://registry.yarnpkg.com/lodash.templatesettings/-/lodash.templatesettings-3.1.1.tgz#fb307844753b66b9f1afa54e262c745307dba8e5"
+  integrity sha1-+zB4RHU7Zrnxr6VOJix0UwfbqOU=
+  dependencies:
+    lodash._reinterpolate "^3.0.0"
+    lodash.escape "^3.0.0"
+
+log-symbols@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/log-symbols/-/log-symbols-1.0.2.tgz#376ff7b58ea3086a0f09facc74617eca501e1a18"
+  integrity sha1-N2/3tY6jCGoPCfrMdGF+ylAeGhg=
+  dependencies:
+    chalk "^1.0.0"
+
+log-update@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/log-update/-/log-update-1.0.2.tgz#19929f64c4093d2d2e7075a1dad8af59c296b8d1"
+  integrity sha1-GZKfZMQJPS0ucHWh2tivWcKWuNE=
+  dependencies:
+    ansi-escapes "^1.0.0"
+    cli-cursor "^1.0.2"
+
+logalot@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/logalot/-/logalot-2.1.0.tgz#5f8e8c90d304edf12530951a5554abb8c5e3f552"
+  integrity sha1-X46MkNME7fElMJUaVVSruMXj9VI=
+  dependencies:
+    figures "^1.3.5"
+    squeak "^1.0.0"
+
+longest@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/longest/-/longest-1.0.1.tgz#30a0b2da38f73770e8294a0d22e6625ed77d0097"
+  integrity sha1-MKCy2jj3N3DoKUoNIuZiXtd9AJc=
+
+loud-rejection@^1.0.0:
+  version "1.6.0"
+  resolved "https://registry.yarnpkg.com/loud-rejection/-/loud-rejection-1.6.0.tgz#5b46f80147edee578870f086d04821cf998e551f"
+  integrity sha1-W0b4AUft7leIcPCG0Eghz5mOVR8=
+  dependencies:
+    currently-unhandled "^0.4.1"
+    signal-exit "^3.0.0"
+
+lowercase-keys@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/lowercase-keys/-/lowercase-keys-1.0.1.tgz#6f9e30b47084d971a7c820ff15a6c5167b74c26f"
+  integrity sha512-G2Lj61tXDnVFFOi8VZds+SoQjtQC3dgokKdDG2mTm1tx4m50NUHBOZSBwQQHyy0V12A0JTG4icfZQH+xPyh8VA==
+
+lpad-align@^1.0.1:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/lpad-align/-/lpad-align-1.1.2.tgz#21f600ac1c3095c3c6e497ee67271ee08481fe9e"
+  integrity sha1-IfYArBwwlcPG5JfuZyce4ISB/p4=
+  dependencies:
+    get-stdin "^4.0.1"
+    indent-string "^2.1.0"
+    longest "^1.0.0"
+    meow "^3.3.0"
+
+lru-cache@^4.0.1:
+  version "4.1.5"
+  resolved "https://registry.yarnpkg.com/lru-cache/-/lru-cache-4.1.5.tgz#8bbe50ea85bed59bc9e33dcab8235ee9bcf443cd"
+  integrity sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==
+  dependencies:
+    pseudomap "^1.0.2"
+    yallist "^2.1.2"
+
+make-dir@^2.0.0, make-dir@^2.1.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/make-dir/-/make-dir-2.1.0.tgz#5f0310e18b8be898cc07009295a30ae41e91e6f5"
+  integrity sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==
+  dependencies:
+    pify "^4.0.1"
+    semver "^5.6.0"
+
+map-cache@^0.2.2:
+  version "0.2.2"
+  resolved "https://registry.yarnpkg.com/map-cache/-/map-cache-0.2.2.tgz#c32abd0bd6525d9b051645bb4f26ac5dc98a0dbf"
+  integrity sha1-wyq9C9ZSXZsFFkW7TyasXcmKDb8=
+
+map-obj@^1.0.0, map-obj@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/map-obj/-/map-obj-1.0.1.tgz#d933ceb9205d82bdcf4886f6742bdc2b4dea146d"
+  integrity sha1-2TPOuSBdgr3PSIb2dCvcK03qFG0=
+
+map-visit@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/map-visit/-/map-visit-1.0.0.tgz#ecdca8f13144e660f1b5bd41f12f3479d98dfb8f"
+  integrity sha1-7Nyo8TFE5mDxtb1B8S80edmN+48=
+  dependencies:
+    object-visit "^1.0.0"
+
+markdown-it@8.4.2:
+  version "8.4.2"
+  resolved "https://registry.yarnpkg.com/markdown-it/-/markdown-it-8.4.2.tgz#386f98998dc15a37722aa7722084f4020bdd9b54"
+  integrity sha512-GcRz3AWTqSUphY3vsUqQSFMbgR38a4Lh3GWlHRh/7MRwz8mcu9n2IO7HOh+bXHrR9kOPDl5RNCaEsrneb+xhHQ==
+  dependencies:
+    argparse "^1.0.7"
+    entities "~1.1.1"
+    linkify-it "^2.0.0"
+    mdurl "^1.0.1"
+    uc.micro "^1.0.5"
+
+markdownlint-cli@^0.15.0:
+  version "0.15.0"
+  resolved "https://registry.yarnpkg.com/markdownlint-cli/-/markdownlint-cli-0.15.0.tgz#12a820d3745a955cff2877157d132248e9d3802b"
+  integrity sha512-UTstPEXMix4CO1RIgjX3Bd1M+xklc4KXMP2309Zfp5y3UJOASWLSXnTnzkztBn5aZRt7bzLZmxTaR8M4J8cbbQ==
+  dependencies:
+    commander "~2.9.0"
+    deep-extend "~0.5.1"
+    get-stdin "~5.0.1"
+    glob "~7.1.2"
+    js-yaml "~3.13.0"
+    lodash.differencewith "~4.5.0"
+    lodash.flatten "~4.4.0"
+    markdownlint "~0.13.0"
+    minimatch "~3.0.4"
+    rc "~1.2.7"
+
+markdownlint@^0.13.0, markdownlint@~0.13.0:
+  version "0.13.0"
+  resolved "https://registry.yarnpkg.com/markdownlint/-/markdownlint-0.13.0.tgz#39ffd5ffbf1198c761a5ef3e28c195e5eb8dd669"
+  integrity sha512-mGeDEbvmRk2T8f043lK7Lhcdi7mr68hQqGsJCS4p52uvEyOLym28s3r7GA6aaFQFtwT0MfFaJ/7Ex4n/HVPUnQ==
+  dependencies:
+    markdown-it "8.4.2"
+
+math-random@^1.0.1:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/math-random/-/math-random-1.0.4.tgz#5dd6943c938548267016d4e34f057583080c514c"
+  integrity sha512-rUxjysqif/BZQH2yhd5Aaq7vXMSx9NdEsQcyA07uEzIvxgI7zIr33gGsh+RU0/XjmQpCW7RsVof1vlkvQVCK5A==
+
+mdurl@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/mdurl/-/mdurl-1.0.1.tgz#fe85b2ec75a59037f2adfec100fd6c601761152e"
+  integrity sha1-/oWy7HWlkDfyrf7BAP1sYBdhFS4=
+
+meow@^3.1.0, meow@^3.3.0, meow@^3.5.0:
+  version "3.7.0"
+  resolved "https://registry.yarnpkg.com/meow/-/meow-3.7.0.tgz#72cb668b425228290abbfa856892587308a801fb"
+  integrity sha1-cstmi0JSKCkKu/qFaJJYcwioAfs=
+  dependencies:
+    camelcase-keys "^2.0.0"
+    decamelize "^1.1.2"
+    loud-rejection "^1.0.0"
+    map-obj "^1.0.1"
+    minimist "^1.1.3"
+    normalize-package-data "^2.3.4"
+    object-assign "^4.0.1"
+    read-pkg-up "^1.0.1"
+    redent "^1.0.0"
+    trim-newlines "^1.0.0"
+
+merge-stream@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/merge-stream/-/merge-stream-1.0.1.tgz#4041202d508a342ba00174008df0c251b8c135e1"
+  integrity sha1-QEEgLVCKNCugAXQAjfDCUbjBNeE=
+  dependencies:
+    readable-stream "^2.0.1"
+
+micromatch@^2.3.7:
+  version "2.3.11"
+  resolved "https://registry.yarnpkg.com/micromatch/-/micromatch-2.3.11.tgz#86677c97d1720b363431d04d0d15293bd38c1565"
+  integrity sha1-hmd8l9FyCzY0MdBNDRUpO9OMFWU=
+  dependencies:
+    arr-diff "^2.0.0"
+    array-unique "^0.2.1"
+    braces "^1.8.2"
+    expand-brackets "^0.1.4"
+    extglob "^0.3.1"
+    filename-regex "^2.0.0"
+    is-extglob "^1.0.0"
+    is-glob "^2.0.1"
+    kind-of "^3.0.2"
+    normalize-path "^2.0.1"
+    object.omit "^2.0.0"
+    parse-glob "^3.0.4"
+    regex-cache "^0.4.2"
+
+micromatch@^3.1.10:
+  version "3.1.10"
+  resolved "https://registry.yarnpkg.com/micromatch/-/micromatch-3.1.10.tgz#70859bc95c9840952f359a068a3fc49f9ecfac23"
+  integrity sha512-MWikgl9n9M3w+bpsY3He8L+w9eF9338xRl8IAO5viDizwSzziFEyUzo2xrrloB64ADbTf8uA8vRqqttDTOmccg==
+  dependencies:
+    arr-diff "^4.0.0"
+    array-unique "^0.3.2"
+    braces "^2.3.1"
+    define-property "^2.0.2"
+    extend-shallow "^3.0.2"
+    extglob "^2.0.4"
+    fragment-cache "^0.2.1"
+    kind-of "^6.0.2"
+    nanomatch "^1.2.9"
+    object.pick "^1.3.0"
+    regex-not "^1.0.0"
+    snapdragon "^0.8.1"
+    to-regex "^3.0.2"
+
+"minimatch@2 || 3", minimatch@^3.0.0, minimatch@^3.0.2, minimatch@^3.0.4, minimatch@~3.0.4:
+  version "3.0.4"
+  resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.4.tgz#5166e286457f03306064be5497e8dbb0c3d32083"
+  integrity sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==
+  dependencies:
+    brace-expansion "^1.1.7"
+
+minimist@0.0.8:
+  version "0.0.8"
+  resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d"
+  integrity sha1-hX/Kv8M5fSYluCKCYuhqp6ARsF0=
+
+minimist@^1.1.0, minimist@^1.1.3, minimist@^1.2.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.0.tgz#a35008b20f41383eec1fb914f4cd5df79a264284"
+  integrity sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=
+
+minimist@^1.2.5:
+  version "1.2.5"
+  resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.5.tgz#67d66014b66a6a8aaa0c083c5fd58df4e4e97602"
+  integrity sha512-FM9nNUYrRBAELZQT3xeZQ7fmMOBg6nWNmJKTcgsJeaLstP/UODVpGsr5OhXhhXg6f+qtJ8uiZ+PUxkDWcgIXLw==
+
+mixin-deep@^1.2.0:
+  version "1.3.2"
+  resolved "https://registry.yarnpkg.com/mixin-deep/-/mixin-deep-1.3.2.tgz#1120b43dc359a785dce65b55b82e257ccf479566"
+  integrity sha512-WRoDn//mXBiJ1H40rqa3vH0toePwSsGb45iInWlTySa+Uu4k3tYUSxa2v1KqAiLtvlrSzaExqS1gtk96A9zvEA==
+  dependencies:
+    for-in "^1.0.2"
+    is-extendable "^1.0.1"
+
+mkdirp@^0.5.0, mkdirp@~0.5.1:
+  version "0.5.1"
+  resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903"
+  integrity sha1-MAV0OOrGz3+MR2fzhkjWaX11yQM=
+  dependencies:
+    minimist "0.0.8"
+
+ms@2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/ms/-/ms-2.0.0.tgz#5608aeadfc00be6c2901df5f9861788de0d597c8"
+  integrity sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=
+
+ms@2.1.2:
+  version "2.1.2"
+  resolved "https://registry.yarnpkg.com/ms/-/ms-2.1.2.tgz#d09d1f357b443f493382a8eb3ccd183872ae6009"
+  integrity sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==
+
+multipipe@^0.1.2:
+  version "0.1.2"
+  resolved "https://registry.yarnpkg.com/multipipe/-/multipipe-0.1.2.tgz#2a8f2ddf70eed564dff2d57f1e1a137d9f05078b"
+  integrity sha1-Ko8t33Du1WTf8tV/HhoTfZ8FB4s=
+  dependencies:
+    duplexer2 "0.0.2"
+
+nanomatch@^1.2.9:
+  version "1.2.13"
+  resolved "https://registry.yarnpkg.com/nanomatch/-/nanomatch-1.2.13.tgz#b87a8aa4fc0de8fe6be88895b38983ff265bd119"
+  integrity sha512-fpoe2T0RbHwBTBUOftAfBPaDEi06ufaUai0mE6Yn1kacc3SnTErfb/h+X94VXzI64rKFHYImXSvdwGGCmwOqCA==
+  dependencies:
+    arr-diff "^4.0.0"
+    array-unique "^0.3.2"
+    define-property "^2.0.2"
+    extend-shallow "^3.0.2"
+    fragment-cache "^0.2.1"
+    is-windows "^1.0.2"
+    kind-of "^6.0.2"
+    object.pick "^1.3.0"
+    regex-not "^1.0.0"
+    snapdragon "^0.8.1"
+    to-regex "^3.0.1"
+
+neo-async@^2.5.0:
+  version "2.6.2"
+  resolved "https://registry.yarnpkg.com/neo-async/-/neo-async-2.6.2.tgz#b4aafb93e3aeb2d8174ca53cf163ab7d7308305f"
+  integrity sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==
+
+node-dir@^0.1.17:
+  version "0.1.17"
+  resolved "https://registry.yarnpkg.com/node-dir/-/node-dir-0.1.17.tgz#5f5665d93351335caabef8f1c554516cf5f1e4e5"
+  integrity sha1-X1Zl2TNRM1yqvvjxxVRRbPXx5OU=
+  dependencies:
+    minimatch "^3.0.2"
+
+node-modules-regexp@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/node-modules-regexp/-/node-modules-regexp-1.0.0.tgz#8d9dbe28964a4ac5712e9131642107c71e90ec40"
+  integrity sha1-jZ2+KJZKSsVxLpExZCEHxx6Q7EA=
+
+node-releases@^2.0.1:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/node-releases/-/node-releases-2.0.1.tgz#3d1d395f204f1f2f29a54358b9fb678765ad2fc5"
+  integrity sha512-CqyzN6z7Q6aMeF/ktcMVTzhAHCEpf8SOarwpzpf8pNBY2k5/oM34UHldUwp8VKI7uxct2HxSRdJjBaZeESzcxA==
+
+node-status-codes@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/node-status-codes/-/node-status-codes-1.0.0.tgz#5ae5541d024645d32a58fcddc9ceecea7ae3ac2f"
+  integrity sha1-WuVUHQJGRdMqWPzdyc7s6nrjrC8=
+
+normalize-package-data@^2.3.2, normalize-package-data@^2.3.4:
+  version "2.5.0"
+  resolved "https://registry.yarnpkg.com/normalize-package-data/-/normalize-package-data-2.5.0.tgz#e66db1838b200c1dfc233225d12cb36520e234a8"
+  integrity sha512-/5CMN3T0R4XTj4DcGaexo+roZSdSFW/0AOOTROrjxzCG1wrWXEsGbRKevjlIL+ZDE4sZlJr5ED4YW0yqmkK+eA==
+  dependencies:
+    hosted-git-info "^2.1.4"
+    resolve "^1.10.0"
+    semver "2 || 3 || 4 || 5"
+    validate-npm-package-license "^3.0.1"
+
+normalize-path@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/normalize-path/-/normalize-path-1.0.0.tgz#32d0e472f91ff345701c15a8311018d3b0a90379"
+  integrity sha1-MtDkcvkf80VwHBWoMRAY07CpA3k=
+
+normalize-path@^2.0.1:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/normalize-path/-/normalize-path-2.1.1.tgz#1ab28b556e198363a8c1a6f7e6fa20137fe6aed9"
+  integrity sha1-GrKLVW4Zg2Oowab35vogE3/mrtk=
+  dependencies:
+    remove-trailing-separator "^1.0.1"
+
+npm-path@^2.0.2:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/npm-path/-/npm-path-2.0.4.tgz#c641347a5ff9d6a09e4d9bce5580c4f505278e64"
+  integrity sha512-IFsj0R9C7ZdR5cP+ET342q77uSRdtWOlWpih5eC+lu29tIDbNEgDbzgVJ5UFvYHWhxDZ5TFkJafFioO0pPQjCw==
+  dependencies:
+    which "^1.2.10"
+
+npm-run-path@^2.0.0:
+  version "2.0.2"
+  resolved "https://registry.yarnpkg.com/npm-run-path/-/npm-run-path-2.0.2.tgz#35a9232dfa35d7067b4cb2ddf2357b1871536c5f"
+  integrity sha1-NakjLfo11wZ7TLLd8jV7GHFTbF8=
+  dependencies:
+    path-key "^2.0.0"
+
+npm-which@^3.0.1:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/npm-which/-/npm-which-3.0.1.tgz#9225f26ec3a285c209cae67c3b11a6b4ab7140aa"
+  integrity sha1-kiXybsOihcIJyuZ8OxGmtKtxQKo=
+  dependencies:
+    commander "^2.9.0"
+    npm-path "^2.0.2"
+    which "^1.2.10"
+
+number-is-nan@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/number-is-nan/-/number-is-nan-1.0.1.tgz#097b602b53422a522c1afb8790318336941a011d"
+  integrity sha1-CXtgK1NCKlIsGvuHkDGDNpQaAR0=
+
+object-assign@^2.0.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-2.1.1.tgz#43c36e5d569ff8e4816c4efa8be02d26967c18aa"
+  integrity sha1-Q8NuXVaf+OSBbE76i+AtJpZ8GKo=
+
+object-assign@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-3.0.0.tgz#9bedd5ca0897949bca47e7ff408062d549f587f2"
+  integrity sha1-m+3VygiXlJvKR+f/QIBi1Un1h/I=
+
+object-assign@^4.0.0, object-assign@^4.0.1, object-assign@^4.1.0:
+  version "4.1.1"
+  resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-4.1.1.tgz#2109adc7965887cfc05cbbd442cac8bfbb360863"
+  integrity sha1-IQmtx5ZYh8/AXLvUQsrIv7s2CGM=
+
+object-copy@^0.1.0:
+  version "0.1.0"
+  resolved "https://registry.yarnpkg.com/object-copy/-/object-copy-0.1.0.tgz#7e7d858b781bd7c991a41ba975ed3812754e998c"
+  integrity sha1-fn2Fi3gb18mRpBupde04EnVOmYw=
+  dependencies:
+    copy-descriptor "^0.1.0"
+    define-property "^0.2.5"
+    kind-of "^3.0.3"
+
+object-keys@^1.0.12, object-keys@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/object-keys/-/object-keys-1.1.1.tgz#1c47f272df277f3b1daf061677d9c82e2322c60e"
+  integrity sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==
+
+object-visit@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/object-visit/-/object-visit-1.0.1.tgz#f79c4493af0c5377b59fe39d395e41042dd045bb"
+  integrity sha1-95xEk68MU3e1n+OdOV5BBC3QRbs=
+  dependencies:
+    isobject "^3.0.0"
+
+object.assign@^4.1.0:
+  version "4.1.2"
+  resolved "https://registry.yarnpkg.com/object.assign/-/object.assign-4.1.2.tgz#0ed54a342eceb37b38ff76eb831a0e788cb63940"
+  integrity sha512-ixT2L5THXsApyiUPYKmW+2EHpXXe5Ii3M+f4e+aJFAHao5amFRW6J0OO6c/LU8Be47utCx2GL89hxGB6XSmKuQ==
+  dependencies:
+    call-bind "^1.0.0"
+    define-properties "^1.1.3"
+    has-symbols "^1.0.1"
+    object-keys "^1.1.1"
+
+object.omit@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/object.omit/-/object.omit-2.0.1.tgz#1a9c744829f39dbb858c76ca3579ae2a54ebd1fa"
+  integrity sha1-Gpx0SCnznbuFjHbKNXmuKlTr0fo=
+  dependencies:
+    for-own "^0.1.4"
+    is-extendable "^0.1.1"
+
+object.pick@^1.3.0:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/object.pick/-/object.pick-1.3.0.tgz#87a10ac4c1694bd2e1cbf53591a66141fb5dd747"
+  integrity sha1-h6EKxMFpS9Lhy/U1kaZhQftd10c=
+  dependencies:
+    isobject "^3.0.1"
+
+once@^1.3.0, once@^1.4.0:
+  version "1.4.0"
+  resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
+  integrity sha1-WDsap3WWHUsROsF9nFC6753Xa9E=
+  dependencies:
+    wrappy "1"
+
+onetime@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/onetime/-/onetime-1.1.0.tgz#a1f7838f8314c516f05ecefcbc4ccfe04b4ed789"
+  integrity sha1-ofeDj4MUxRbwXs78vEzP4EtO14k=
+
+optional@^0.1.0:
+  version "0.1.4"
+  resolved "https://registry.yarnpkg.com/optional/-/optional-0.1.4.tgz#cdb1a9bedc737d2025f690ceeb50e049444fd5b3"
+  integrity sha512-gtvrrCfkE08wKcgXaVwQVgwEQ8vel2dc5DDBn9RLQZ3YtmtkBss6A2HY6BnJH4N/4Ku97Ri/SF8sNWE2225WJw==
+
+optipng-bin@^3.0.0:
+  version "3.1.4"
+  resolved "https://registry.yarnpkg.com/optipng-bin/-/optipng-bin-3.1.4.tgz#95d34f2c488704f6fd70606bfea0c659f1d95d84"
+  integrity sha1-ldNPLEiHBPb9cGBr/qDGWfHZXYQ=
+  dependencies:
+    bin-build "^2.0.0"
+    bin-wrapper "^3.0.0"
+    logalot "^2.0.0"
+
+ora@^0.2.3:
+  version "0.2.3"
+  resolved "https://registry.yarnpkg.com/ora/-/ora-0.2.3.tgz#37527d220adcd53c39b73571d754156d5db657a4"
+  integrity sha1-N1J9Igrc1Tw5tzVx11QVbV22V6Q=
+  dependencies:
+    chalk "^1.1.1"
+    cli-cursor "^1.0.2"
+    cli-spinners "^0.1.2"
+    object-assign "^4.0.1"
+
+ordered-read-streams@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/ordered-read-streams/-/ordered-read-streams-0.3.0.tgz#7137e69b3298bb342247a1bbee3881c80e2fd78b"
+  integrity sha1-cTfmmzKYuzQiR6G77jiByA4v14s=
+  dependencies:
+    is-stream "^1.0.1"
+    readable-stream "^2.0.1"
+
+os-filter-obj@^1.0.0:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/os-filter-obj/-/os-filter-obj-1.0.3.tgz#5915330d90eced557d2d938a31c6dd214d9c63ad"
+  integrity sha1-WRUzDZDs7VV9LZOKMcbdIU2cY60=
+
+os-homedir@^1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/os-homedir/-/os-homedir-1.0.2.tgz#ffbc4988336e0e833de0c168c7ef152121aa7fb3"
+  integrity sha1-/7xJiDNuDoM94MFox+8VISGqf7M=
+
+os-tmpdir@^1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/os-tmpdir/-/os-tmpdir-1.0.2.tgz#bbe67406c79aa85c5cfec766fe5734555dfa1274"
+  integrity sha1-u+Z0BseaqFxc/sdm/lc0VV36EnQ=
+
+p-finally@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/p-finally/-/p-finally-1.0.0.tgz#3fbcfb15b899a44123b34b6dcc18b724336a2cae"
+  integrity sha1-P7z7FbiZpEEjs0ttzBi3JDNqLK4=
+
+p-limit@^2.0.0:
+  version "2.3.0"
+  resolved "https://registry.yarnpkg.com/p-limit/-/p-limit-2.3.0.tgz#3dd33c647a214fdfffd835933eb086da0dc21db1"
+  integrity sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==
+  dependencies:
+    p-try "^2.0.0"
+
+p-locate@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/p-locate/-/p-locate-3.0.0.tgz#322d69a05c0264b25997d9f40cd8a891ab0064a4"
+  integrity sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==
+  dependencies:
+    p-limit "^2.0.0"
+
+p-map@^1.1.1:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/p-map/-/p-map-1.2.0.tgz#e4e94f311eabbc8633a1e79908165fca26241b6b"
+  integrity sha512-r6zKACMNhjPJMTl8KcFH4li//gkrXWfbD6feV8l6doRHlzljFWGJ2AP6iKaCJXyZmAUMOPtvbW7EXkbWO/pLEA==
+
+p-try@^2.0.0:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/p-try/-/p-try-2.2.0.tgz#cb2868540e313d61de58fafbe35ce9004d5540e6"
+  integrity sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==
+
+parse-glob@^3.0.4:
+  version "3.0.4"
+  resolved "https://registry.yarnpkg.com/parse-glob/-/parse-glob-3.0.4.tgz#b2c376cfb11f35513badd173ef0bb6e3a388391c"
+  integrity sha1-ssN2z7EfNVE7rdFz7wu246OIORw=
+  dependencies:
+    glob-base "^0.3.0"
+    is-dotfile "^1.0.0"
+    is-extglob "^1.0.0"
+    is-glob "^2.0.0"
+
+parse-json@^2.1.0, parse-json@^2.2.0:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-2.2.0.tgz#f480f40434ef80741f8469099f8dea18f55a4dc9"
+  integrity sha1-9ID0BDTvgHQfhGkJn43qGPVaTck=
+  dependencies:
+    error-ex "^1.2.0"
+
+parse-node-version@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/parse-node-version/-/parse-node-version-1.0.1.tgz#e2b5dbede00e7fa9bc363607f53327e8b073189b"
+  integrity sha512-3YHlOa/JgH6Mnpr05jP9eDG254US9ek25LyIxZlDItp2iJtwyaXQb57lBYLdT3MowkUFYEV2XXNAYIPlESvJlA==
+
+pascalcase@^0.1.1:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/pascalcase/-/pascalcase-0.1.1.tgz#b363e55e8006ca6fe21784d2db22bd15d7917f14"
+  integrity sha1-s2PlXoAGym/iF4TS2yK9FdeRfxQ=
+
+path-dirname@^1.0.0:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/path-dirname/-/path-dirname-1.0.2.tgz#cc33d24d525e099a5388c0336c6e32b9160609e0"
+  integrity sha1-zDPSTVJeCZpTiMAzbG4yuRYGCeA=
+
+path-exists@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/path-exists/-/path-exists-2.1.0.tgz#0feb6c64f0fc518d9a754dd5efb62c7022761f4b"
+  integrity sha1-D+tsZPD8UY2adU3V77YscCJ2H0s=
+  dependencies:
+    pinkie-promise "^2.0.0"
+
+path-exists@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/path-exists/-/path-exists-3.0.0.tgz#ce0ebeaa5f78cb18925ea7d810d7b59b010fd515"
+  integrity sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=
+
+path-is-absolute@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
+  integrity sha1-F0uSaHNVNP+8es5r9TpanhtcX18=
+
+path-key@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/path-key/-/path-key-2.0.1.tgz#411cadb574c5a140d3a4b1910d40d80cc9f40b40"
+  integrity sha1-QRyttXTFoUDTpLGRDUDYDMn0C0A=
+
+path-parse@^1.0.6:
+  version "1.0.6"
+  resolved "https://registry.yarnpkg.com/path-parse/-/path-parse-1.0.6.tgz#d62dbb5679405d72c4737ec58600e9ddcf06d24c"
+  integrity sha512-GSmOT2EbHrINBf9SR7CDELwlJ8AENk3Qn7OikK4nFYAu3Ote2+JYNVvkpAEQm3/TLNEJFD/xZJjzyxg3KBWOzw==
+
+path-type@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/path-type/-/path-type-1.1.0.tgz#59c44f7ee491da704da415da5a4070ba4f8fe441"
+  integrity sha1-WcRPfuSR2nBNpBXaWkBwuk+P5EE=
+  dependencies:
+    graceful-fs "^4.1.2"
+    pify "^2.0.0"
+    pinkie-promise "^2.0.0"
+
+pend@~1.2.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/pend/-/pend-1.2.0.tgz#7a57eb550a6783f9115331fcf4663d5c8e007a50"
+  integrity sha1-elfrVQpng/kRUzH89GY9XI4AelA=
+
+picocolors@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/picocolors/-/picocolors-1.0.0.tgz#cb5bdc74ff3f51892236eaf79d68bc44564ab81c"
+  integrity sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==
+
+pify@^2.0.0:
+  version "2.3.0"
+  resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c"
+  integrity sha1-7RQaasBDqEnqWISY59yosVMw6Qw=
+
+pify@^4.0.1:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/pify/-/pify-4.0.1.tgz#4b2cd25c50d598735c50292224fd8c6df41e3231"
+  integrity sha512-uB80kBFb/tfd68bVleG9T5GGsGPjJrLAUpR5PZIrhBnIaRTQRjqdJSsIKkOP6OAIFbj7GOrcudc5pNjZ+geV2g==
+
+pinkie-promise@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/pinkie-promise/-/pinkie-promise-2.0.1.tgz#2135d6dfa7a358c069ac9b178776288228450ffa"
+  integrity sha1-ITXW36ejWMBprJsXh3YogihFD/o=
+  dependencies:
+    pinkie "^2.0.0"
+
+pinkie@^2.0.0:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/pinkie/-/pinkie-2.0.4.tgz#72556b80cfa0d48a974e80e77248e80ed4f7f870"
+  integrity sha1-clVrgM+g1IqXToDnckjoDtT3+HA=
+
+pirates@^4.0.0:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/pirates/-/pirates-4.0.1.tgz#643a92caf894566f91b2b986d2c66950a8e2fb87"
+  integrity sha512-WuNqLTbMI3tmfef2TKxlQmAiLHKtFhlsCZnPIpuv2Ow0RDVO8lfy1Opf4NUzlMXLjPl+Men7AuVdX6TA+s+uGA==
+  dependencies:
+    node-modules-regexp "^1.0.0"
+
+pkg-dir@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/pkg-dir/-/pkg-dir-3.0.0.tgz#2749020f239ed990881b1f71210d51eb6523bea3"
+  integrity sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==
+  dependencies:
+    find-up "^3.0.0"
+
+posix-character-classes@^0.1.0:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/posix-character-classes/-/posix-character-classes-0.1.1.tgz#01eac0fe3b5af71a2a6c02feabb8c1fef7e00eab"
+  integrity sha1-AerA/jta9xoqbAL+q7jB/vfgDqs=
+
+prepend-http@^1.0.1:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/prepend-http/-/prepend-http-1.0.4.tgz#d4f4562b0ce3696e41ac52d0e002e57a635dc6dc"
+  integrity sha1-1PRWKwzjaW5BrFLQ4ALlemNdxtw=
+
+preserve@^0.2.0:
+  version "0.2.0"
+  resolved "https://registry.yarnpkg.com/preserve/-/preserve-0.2.0.tgz#815ed1f6ebc65926f865b310c0713bcb3315ce4b"
+  integrity sha1-gV7R9uvGWSb4ZbMQwHE7yzMVzks=
+
+prettier@^2.4.1:
+  version "2.4.1"
+  resolved "https://registry.yarnpkg.com/prettier/-/prettier-2.4.1.tgz#671e11c89c14a4cfc876ce564106c4a6726c9f5c"
+  integrity sha512-9fbDAXSBcc6Bs1mZrDYb3XKzDLm4EXXL9sC1LqKP5rZkT6KRr/rf9amVUcODVXgguK/isJz0d0hP72WeaKWsvA==
+
+process-nextick-args@~2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/process-nextick-args/-/process-nextick-args-2.0.1.tgz#7820d9b16120cc55ca9ae7792680ae7dba6d7fe2"
+  integrity sha512-3ouUOpQhtgrbOa17J7+uxOTpITYWaGP7/AhoR3+A+/1e9skrzelGi/dXzEYyvbxubEF6Wn2ypscTKiKJFFn1ag==
+
+pseudomap@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/pseudomap/-/pseudomap-1.0.2.tgz#f052a28da70e618917ef0a8ac34c1ae5a68286b3"
+  integrity sha1-8FKijacOYYkX7wqKw0wa5aaChrM=
+
+q@^1.1.2:
+  version "1.5.1"
+  resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7"
+  integrity sha1-fjL3W0E4EpHQRhHxvxQQmsAGUdc=
+
+randomatic@^3.0.0:
+  version "3.1.1"
+  resolved "https://registry.yarnpkg.com/randomatic/-/randomatic-3.1.1.tgz#b776efc59375984e36c537b2f51a1f0aff0da1ed"
+  integrity sha512-TuDE5KxZ0J461RVjrJZCJc+J+zCkTb1MbH9AQUq68sMhOMcy9jLcb3BrZKgp9q9Ncltdg4QVqWrH02W2EFFVYw==
+  dependencies:
+    is-number "^4.0.0"
+    kind-of "^6.0.0"
+    math-random "^1.0.1"
+
+rc@^1.1.2, rc@~1.2.7:
+  version "1.2.8"
+  resolved "https://registry.yarnpkg.com/rc/-/rc-1.2.8.tgz#cd924bf5200a075b83c188cd6b9e211b7fc0d3ed"
+  integrity sha512-y3bGgqKj3QBdxLbLkomlohkvsA8gdAiUQlSBJnBhfn+BPxg4bc62d8TcBW15wavDfgexCgccckhcZvywyQYPOw==
+  dependencies:
+    deep-extend "^0.6.0"
+    ini "~1.3.0"
+    minimist "^1.2.0"
+    strip-json-comments "~2.0.1"
+
+read-all-stream@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/read-all-stream/-/read-all-stream-3.1.0.tgz#35c3e177f2078ef789ee4bfafa4373074eaef4fa"
+  integrity sha1-NcPhd/IHjveJ7kv6+kNzB06u9Po=
+  dependencies:
+    pinkie-promise "^2.0.0"
+    readable-stream "^2.0.0"
+
+read-pkg-up@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/read-pkg-up/-/read-pkg-up-1.0.1.tgz#9d63c13276c065918d57f002a57f40a1b643fb02"
+  integrity sha1-nWPBMnbAZZGNV/ACpX9AobZD+wI=
+  dependencies:
+    find-up "^1.0.0"
+    read-pkg "^1.0.0"
+
+read-pkg@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/read-pkg/-/read-pkg-1.1.0.tgz#f5ffaa5ecd29cb31c0474bca7d756b6bb29e3f28"
+  integrity sha1-9f+qXs0pyzHAR0vKfXVra7KePyg=
+  dependencies:
+    load-json-file "^1.0.0"
+    normalize-package-data "^2.3.2"
+    path-type "^1.0.0"
+
+"readable-stream@>=1.0.33-1 <1.1.0-0":
+  version "1.0.34"
+  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-1.0.34.tgz#125820e34bc842d2f2aaafafe4c2916ee32c157c"
+  integrity sha1-Elgg40vIQtLyqq+v5MKRbuMsFXw=
+  dependencies:
+    core-util-is "~1.0.0"
+    inherits "~2.0.1"
+    isarray "0.0.1"
+    string_decoder "~0.10.x"
+
+readable-stream@^2.0.0, readable-stream@^2.0.1, readable-stream@^2.0.2, readable-stream@^2.0.4, readable-stream@^2.0.5, readable-stream@^2.2.2, readable-stream@^2.3.0, readable-stream@^2.3.5, readable-stream@~2.3.6:
+  version "2.3.7"
+  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.3.7.tgz#1eca1cf711aef814c04f62252a36a62f6cb23b57"
+  integrity sha512-Ebho8K4jIbHAxnuxi7o42OrZgF/ZTNcsZj6nRKyUmkhLFq8CHItp/fy6hQZuZmP/n3yZ9VBUbp4zz/mX8hmYPw==
+  dependencies:
+    core-util-is "~1.0.0"
+    inherits "~2.0.3"
+    isarray "~1.0.0"
+    process-nextick-args "~2.0.0"
+    safe-buffer "~5.1.1"
+    string_decoder "~1.1.1"
+    util-deprecate "~1.0.1"
+
+readable-stream@~1.1.9:
+  version "1.1.14"
+  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-1.1.14.tgz#7cf4c54ef648e3813084c636dd2079e166c081d9"
+  integrity sha1-fPTFTvZI44EwhMY23SB54WbAgdk=
+  dependencies:
+    core-util-is "~1.0.0"
+    inherits "~2.0.1"
+    isarray "0.0.1"
+    string_decoder "~0.10.x"
+
+recast@^0.20.4:
+  version "0.20.5"
+  resolved "https://registry.yarnpkg.com/recast/-/recast-0.20.5.tgz#8e2c6c96827a1b339c634dd232957d230553ceae"
+  integrity sha512-E5qICoPoNL4yU0H0NoBDntNB0Q5oMSNh9usFctYniLBluTthi3RsQVBXIJNbApOlvSwW/RGxIuokPcAc59J5fQ==
+  dependencies:
+    ast-types "0.14.2"
+    esprima "~4.0.0"
+    source-map "~0.6.1"
+    tslib "^2.0.1"
+
+redent@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/redent/-/redent-1.0.0.tgz#cf916ab1fd5f1f16dfb20822dd6ec7f730c2afde"
+  integrity sha1-z5Fqsf1fHxbfsggi3W7H9zDCr94=
+  dependencies:
+    indent-string "^2.1.0"
+    strip-indent "^1.0.1"
+
+regex-cache@^0.4.2:
+  version "0.4.4"
+  resolved "https://registry.yarnpkg.com/regex-cache/-/regex-cache-0.4.4.tgz#75bdc58a2a1496cec48a12835bc54c8d562336dd"
+  integrity sha512-nVIZwtCjkC9YgvWkpM55B5rBhBYRZhAaJbgcFYXXsHnbZ9UZI9nnVWYZpBlCqv9ho2eZryPnWrZGsOdPwVWXWQ==
+  dependencies:
+    is-equal-shallow "^0.1.3"
+
+regex-not@^1.0.0, regex-not@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/regex-not/-/regex-not-1.0.2.tgz#1f4ece27e00b0b65e0247a6810e6a85d83a5752c"
+  integrity sha512-J6SDjUgDxQj5NusnOtdFxDwN/+HWykR8GELwctJ7mdqhcyy1xEc4SRFHUXvxTp661YaVKAjfRLZ9cCqS6tn32A==
+  dependencies:
+    extend-shallow "^3.0.2"
+    safe-regex "^1.1.0"
+
+remove-trailing-separator@^1.0.1:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/remove-trailing-separator/-/remove-trailing-separator-1.1.0.tgz#c24bce2a283adad5bc3f58e0d48249b92379d8ef"
+  integrity sha1-wkvOKig62tW8P1jg1IJJuSN52O8=
+
+repeat-element@^1.1.2:
+  version "1.1.3"
+  resolved "https://registry.yarnpkg.com/repeat-element/-/repeat-element-1.1.3.tgz#782e0d825c0c5a3bb39731f84efee6b742e6b1ce"
+  integrity sha512-ahGq0ZnV5m5XtZLMb+vP76kcAM5nkLqk0lpqAuojSKGgQtn4eRi4ZZGm2olo2zKFH+sMsWaqOCW1dqAnOru72g==
+
+repeat-string@^1.5.2, repeat-string@^1.6.1:
+  version "1.6.1"
+  resolved "https://registry.yarnpkg.com/repeat-string/-/repeat-string-1.6.1.tgz#8dcae470e1c88abc2d600fff4a776286da75e637"
+  integrity sha1-jcrkcOHIirwtYA//Sndihtp15jc=
+
+repeating@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/repeating/-/repeating-2.0.1.tgz#5214c53a926d3552707527fbab415dbc08d06dda"
+  integrity sha1-UhTFOpJtNVJwdSf7q0FdvAjQbdo=
+  dependencies:
+    is-finite "^1.0.0"
+
+replace-ext@0.0.1:
+  version "0.0.1"
+  resolved "https://registry.yarnpkg.com/replace-ext/-/replace-ext-0.0.1.tgz#29bbd92078a739f0bcce2b4ee41e837953522924"
+  integrity sha1-KbvZIHinOfC8zitO5B6DeVNSKSQ=
+
+require-from-string@^1.1.0:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/require-from-string/-/require-from-string-1.2.1.tgz#529c9ccef27380adfec9a2f965b649bbee636418"
+  integrity sha1-UpyczvJzgK3+yaL5ZbZJu+5jZBg=
+
+resolve-url@^0.2.1:
+  version "0.2.1"
+  resolved "https://registry.yarnpkg.com/resolve-url/-/resolve-url-0.2.1.tgz#2c637fe77c893afd2a663fe21aa9080068e2052a"
+  integrity sha1-LGN/53yJOv0qZj/iGqkIAGjiBSo=
+
+resolve@^1.10.0:
+  version "1.10.0"
+  resolved "https://registry.yarnpkg.com/resolve/-/resolve-1.10.0.tgz#3bdaaeaf45cc07f375656dfd2e54ed0810b101ba"
+  integrity sha512-3sUr9aq5OfSg2S9pNtPA9hL1FVEAjvfOC4leW0SNf/mpnaakz2a9femSd6LqAww2RaFctwyf1lCqnTHuF1rxDg==
+  dependencies:
+    path-parse "^1.0.6"
+
+restore-cursor@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/restore-cursor/-/restore-cursor-1.0.1.tgz#34661f46886327fed2991479152252df92daa541"
+  integrity sha1-NGYfRohjJ/7SmRR5FSJS35LapUE=
+  dependencies:
+    exit-hook "^1.0.0"
+    onetime "^1.0.0"
+
+ret@~0.1.10:
+  version "0.1.15"
+  resolved "https://registry.yarnpkg.com/ret/-/ret-0.1.15.tgz#b8a4825d5bdb1fc3f6f53c2bc33f81388681c7bc"
+  integrity sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==
+
+rimraf@^2.2.6, rimraf@~2.6.2:
+  version "2.6.3"
+  resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.6.3.tgz#b2d104fe0d8fb27cf9e0a1cda8262dd3833c6cab"
+  integrity sha512-mwqeW5XsA2qAejG46gYdENaxXjx9onRNCfn7L0duuP4hCuTIi/QO7PDK07KJfp1d+izWPrzEJDcSqBa0OZQriA==
+  dependencies:
+    glob "^7.1.3"
+
+rxjs@^5.0.0-beta.11:
+  version "5.5.12"
+  resolved "https://registry.yarnpkg.com/rxjs/-/rxjs-5.5.12.tgz#6fa61b8a77c3d793dbaf270bee2f43f652d741cc"
+  integrity sha512-xx2itnL5sBbqeeiVgNPVuQQ1nC8Jp2WfNJhXWHmElW9YmrpS9UVnNzhP3EH3HFqexO5Tlp8GhYY+WEcqcVMvGw==
+  dependencies:
+    symbol-observable "1.0.1"
+
+safe-buffer@^5.1.1:
+  version "5.2.1"
+  resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.2.1.tgz#1eaf9fa9bdb1fdd4ec75f58f9cdb4e6b7827eec6"
+  integrity sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==
+
+safe-buffer@~5.1.0, safe-buffer@~5.1.1:
+  version "5.1.2"
+  resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.1.2.tgz#991ec69d296e0313747d59bdfd2b745c35f8828d"
+  integrity sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==
+
+safe-regex@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/safe-regex/-/safe-regex-1.1.0.tgz#40a3669f3b077d1e943d44629e157dd48023bf2e"
+  integrity sha1-QKNmnzsHfR6UPURinhV91IAjvy4=
+  dependencies:
+    ret "~0.1.10"
+
+sax@~1.2.1:
+  version "1.2.4"
+  resolved "https://registry.yarnpkg.com/sax/-/sax-1.2.4.tgz#2816234e2378bddc4e5354fab5caa895df7100d9"
+  integrity sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==
+
+seek-bzip@^1.0.3:
+  version "1.0.5"
+  resolved "https://registry.yarnpkg.com/seek-bzip/-/seek-bzip-1.0.5.tgz#cfe917cb3d274bcffac792758af53173eb1fabdc"
+  integrity sha1-z+kXyz0nS8/6x5J1ivUxc+sfq9w=
+  dependencies:
+    commander "~2.8.1"
+
+semver-regex@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/semver-regex/-/semver-regex-1.0.0.tgz#92a4969065f9c70c694753d55248fc68f8f652c9"
+  integrity sha1-kqSWkGX5xwxpR1PVUkj8aPj2Usk=
+
+semver-truncate@^1.0.0:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/semver-truncate/-/semver-truncate-1.1.2.tgz#57f41de69707a62709a7e0104ba2117109ea47e8"
+  integrity sha1-V/Qd5pcHpicJp+AQS6IRcQnqR+g=
+  dependencies:
+    semver "^5.3.0"
+
+"semver@2 || 3 || 4 || 5", semver@^5.3.0:
+  version "5.6.0"
+  resolved "https://registry.yarnpkg.com/semver/-/semver-5.6.0.tgz#7e74256fbaa49c75aa7c7a205cc22799cac80004"
+  integrity sha512-RS9R6R35NYgQn++fkDWaOmqGoj4Ek9gGs+DPxNUZKuwE183xjJroKvyo1IzVFeXvUrvmALy6FWD5xrdJT25gMg==
+
+semver@^4.0.3:
+  version "4.3.6"
+  resolved "https://registry.yarnpkg.com/semver/-/semver-4.3.6.tgz#300bc6e0e86374f7ba61068b5b1ecd57fc6532da"
+  integrity sha1-MAvG4OhjdPe6YQaLWx7NV/xlMto=
+
+semver@^5.6.0:
+  version "5.7.1"
+  resolved "https://registry.yarnpkg.com/semver/-/semver-5.7.1.tgz#a954f931aeba508d307bbf069eff0c01c96116f7"
+  integrity sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==
+
+semver@^6.3.0:
+  version "6.3.0"
+  resolved "https://registry.yarnpkg.com/semver/-/semver-6.3.0.tgz#ee0a64c8af5e8ceea67687b133761e1becbd1d3d"
+  integrity sha512-b39TBaTSfV6yBrapU89p5fKekE2m/NwnDocOVruQFS1/veMgdzuPcnOM34M6CwxW8jH/lxEa5rBoDeUwu5HHTw==
+
+set-immediate-shim@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/set-immediate-shim/-/set-immediate-shim-1.0.1.tgz#4b2b1b27eb808a9f8dcc481a58e5e56f599f3f61"
+  integrity sha1-SysbJ+uAip+NzEgaWOXlb1mfP2E=
+
+set-value@^2.0.0, set-value@^2.0.1:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/set-value/-/set-value-2.0.1.tgz#a18d40530e6f07de4228c7defe4227af8cad005b"
+  integrity sha512-JxHc1weCN68wRY0fhCoXpyK55m/XPHafOmK4UWD7m2CI14GMcFypt4w/0+NV5f/ZMby2F6S2wwA7fgynh9gWSw==
+  dependencies:
+    extend-shallow "^2.0.1"
+    is-extendable "^0.1.1"
+    is-plain-object "^2.0.3"
+    split-string "^3.0.1"
+
+shallow-clone@^3.0.0:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/shallow-clone/-/shallow-clone-3.0.1.tgz#8f2981ad92531f55035b01fb230769a40e02efa3"
+  integrity sha512-/6KqX+GVUdqPuPPd2LxDDxzX6CAbjJehAAOKlNpqqUpAqPM6HeL8f+o3a+JsyGjn2lv0WY8UsTgUJjU9Ok55NA==
+  dependencies:
+    kind-of "^6.0.2"
+
+shebang-command@^1.2.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/shebang-command/-/shebang-command-1.2.0.tgz#44aac65b695b03398968c39f363fee5deafdf1ea"
+  integrity sha1-RKrGW2lbAzmJaMOfNj/uXer98eo=
+  dependencies:
+    shebang-regex "^1.0.0"
+
+shebang-regex@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/shebang-regex/-/shebang-regex-1.0.0.tgz#da42f49740c0b42db2ca9728571cb190c98efea3"
+  integrity sha1-2kL0l0DAtC2yypcoVxyxkMmO/qM=
+
+signal-exit@^3.0.0:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/signal-exit/-/signal-exit-3.0.2.tgz#b5fdc08f1287ea1178628e415e25132b73646c6d"
+  integrity sha1-tf3AjxKH6hF4Yo5BXiUTK3NkbG0=
+
+signal-exit@^3.0.2:
+  version "3.0.5"
+  resolved "https://registry.yarnpkg.com/signal-exit/-/signal-exit-3.0.5.tgz#9e3e8cc0c75a99472b44321033a7702e7738252f"
+  integrity sha512-KWcOiKeQj6ZyXx7zq4YxSMgHRlod4czeBQZrPb8OKcohcqAXShm7E20kEMle9WBt26hFcAf0qLOcp5zmY7kOqQ==
+
+slice-ansi@0.0.4:
+  version "0.0.4"
+  resolved "https://registry.yarnpkg.com/slice-ansi/-/slice-ansi-0.0.4.tgz#edbf8903f66f7ce2f8eafd6ceed65e264c831b35"
+  integrity sha1-7b+JA/ZvfOL46v1s7tZeJkyDGzU=
+
+snapdragon-node@^2.0.1:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/snapdragon-node/-/snapdragon-node-2.1.1.tgz#6c175f86ff14bdb0724563e8f3c1b021a286853b"
+  integrity sha512-O27l4xaMYt/RSQ5TR3vpWCAB5Kb/czIcqUFOM/C4fYcLnbZUc1PkjTAMjof2pBWaSTwOUd6qUHcFGVGj7aIwnw==
+  dependencies:
+    define-property "^1.0.0"
+    isobject "^3.0.0"
+    snapdragon-util "^3.0.1"
+
+snapdragon-util@^3.0.1:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/snapdragon-util/-/snapdragon-util-3.0.1.tgz#f956479486f2acd79700693f6f7b805e45ab56e2"
+  integrity sha512-mbKkMdQKsjX4BAL4bRYTj21edOf8cN7XHdYUJEe+Zn99hVEYcMvKPct1IqNe7+AZPirn8BCDOQBHQZknqmKlZQ==
+  dependencies:
+    kind-of "^3.2.0"
+
+snapdragon@^0.8.1:
+  version "0.8.2"
+  resolved "https://registry.yarnpkg.com/snapdragon/-/snapdragon-0.8.2.tgz#64922e7c565b0e14204ba1aa7d6964278d25182d"
+  integrity sha512-FtyOnWN/wCHTVXOMwvSv26d+ko5vWlIDD6zoUJ7LW8vh+ZBC8QdljveRP+crNrtBwioEUWy/4dMtbBjA4ioNlg==
+  dependencies:
+    base "^0.11.1"
+    debug "^2.2.0"
+    define-property "^0.2.5"
+    extend-shallow "^2.0.1"
+    map-cache "^0.2.2"
+    source-map "^0.5.6"
+    source-map-resolve "^0.5.0"
+    use "^3.1.0"
+
+source-map-resolve@^0.5.0:
+  version "0.5.3"
+  resolved "https://registry.yarnpkg.com/source-map-resolve/-/source-map-resolve-0.5.3.tgz#190866bece7553e1f8f267a2ee82c606b5509a1a"
+  integrity sha512-Htz+RnsXWk5+P2slx5Jh3Q66vhQj1Cllm0zvnaY98+NFx+Dv2CF/f5O/t8x+KaNdrdIAsruNzoh/KpialbqAnw==
+  dependencies:
+    atob "^2.1.2"
+    decode-uri-component "^0.2.0"
+    resolve-url "^0.2.1"
+    source-map-url "^0.4.0"
+    urix "^0.1.0"
+
+source-map-support@^0.5.16:
+  version "0.5.20"
+  resolved "https://registry.yarnpkg.com/source-map-support/-/source-map-support-0.5.20.tgz#12166089f8f5e5e8c56926b377633392dd2cb6c9"
+  integrity sha512-n1lZZ8Ve4ksRqizaBQgxXDgKwttHDhyfQjA6YZZn8+AroHbsIz+JjwxQDxbp+7y5OYCI8t1Yk7etjD9CRd2hIw==
+  dependencies:
+    buffer-from "^1.0.0"
+    source-map "^0.6.0"
+
+source-map-url@^0.4.0:
+  version "0.4.1"
+  resolved "https://registry.yarnpkg.com/source-map-url/-/source-map-url-0.4.1.tgz#0af66605a745a5a2f91cf1bbf8a7afbc283dec56"
+  integrity sha512-cPiFOTLUKvJFIg4SKVScy4ilPPW6rFgMgfuZJPNoDuMs3nC1HbMUycBoJw77xFIp6z1UJQJOfx6C9GMH80DiTw==
+
+source-map@^0.5.0, source-map@^0.5.3, source-map@^0.5.6:
+  version "0.5.7"
+  resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.5.7.tgz#8a039d2d1021d22d1ea14c80d8ea468ba2ef3fcc"
+  integrity sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=
+
+source-map@^0.6.0, source-map@~0.6.1:
+  version "0.6.1"
+  resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.6.1.tgz#74722af32e9614e9c287a8d0bbde48b5e2f1a263"
+  integrity sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==
+
+sparkles@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/sparkles/-/sparkles-1.0.1.tgz#008db65edce6c50eec0c5e228e1945061dd0437c"
+  integrity sha512-dSO0DDYUahUt/0/pD/Is3VIm5TGJjludZ0HVymmhYF6eNA53PVLhnUk0znSYbH8IYBuJdCE+1luR22jNLMaQdw==
+
+spdx-correct@^3.0.0:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/spdx-correct/-/spdx-correct-3.1.0.tgz#fb83e504445268f154b074e218c87c003cd31df4"
+  integrity sha512-lr2EZCctC2BNR7j7WzJ2FpDznxky1sjfxvvYEyzxNyb6lZXHODmEoJeFu4JupYlkfha1KZpJyoqiJ7pgA1qq8Q==
+  dependencies:
+    spdx-expression-parse "^3.0.0"
+    spdx-license-ids "^3.0.0"
+
+spdx-exceptions@^2.1.0:
+  version "2.2.0"
+  resolved "https://registry.yarnpkg.com/spdx-exceptions/-/spdx-exceptions-2.2.0.tgz#2ea450aee74f2a89bfb94519c07fcd6f41322977"
+  integrity sha512-2XQACfElKi9SlVb1CYadKDXvoajPgBVPn/gOQLrTvHdElaVhr7ZEbqJaRnJLVNeaI4cMEAgVCeBMKF6MWRDCRA==
+
+spdx-expression-parse@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/spdx-expression-parse/-/spdx-expression-parse-3.0.0.tgz#99e119b7a5da00e05491c9fa338b7904823b41d0"
+  integrity sha512-Yg6D3XpRD4kkOmTpdgbUiEJFKghJH03fiC1OPll5h/0sO6neh2jqRDVHOQ4o/LMea0tgCkbMgea5ip/e+MkWyg==
+  dependencies:
+    spdx-exceptions "^2.1.0"
+    spdx-license-ids "^3.0.0"
+
+spdx-license-ids@^3.0.0:
+  version "3.0.3"
+  resolved "https://registry.yarnpkg.com/spdx-license-ids/-/spdx-license-ids-3.0.3.tgz#81c0ce8f21474756148bbb5f3bfc0f36bf15d76e"
+  integrity sha512-uBIcIl3Ih6Phe3XHK1NqboJLdGfwr1UN3k6wSD1dZpmPsIkb8AGNbZYJ1fOBk834+Gxy8rpfDxrS6XLEMZMY2g==
+
+split-string@^3.0.1, split-string@^3.0.2:
+  version "3.1.0"
+  resolved "https://registry.yarnpkg.com/split-string/-/split-string-3.1.0.tgz#7cb09dda3a86585705c64b39a6466038682e8fe2"
+  integrity sha512-NzNVhJDYpwceVVii8/Hu6DKfD2G+NrQHlS/V/qgv763EYudVwEcMQNxd2lh+0VrUByXN/oJkl5grOhYWvQUYiw==
+  dependencies:
+    extend-shallow "^3.0.0"
+
+sprintf-js@~1.0.2:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/sprintf-js/-/sprintf-js-1.0.3.tgz#04e6926f662895354f3dd015203633b857297e2c"
+  integrity sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=
+
+squeak@^1.0.0:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/squeak/-/squeak-1.3.0.tgz#33045037b64388b567674b84322a6521073916c3"
+  integrity sha1-MwRQN7ZDiLVnZ0uEMiplIQc5FsM=
+  dependencies:
+    chalk "^1.0.0"
+    console-stream "^0.1.1"
+    lpad-align "^1.0.1"
+
+staged-git-files@0.0.4:
+  version "0.0.4"
+  resolved "https://registry.yarnpkg.com/staged-git-files/-/staged-git-files-0.0.4.tgz#d797e1b551ca7a639dec0237dc6eb4bb9be17d35"
+  integrity sha1-15fhtVHKemOd7AI33G60u5vhfTU=
+
+stat-mode@^0.2.0:
+  version "0.2.2"
+  resolved "https://registry.yarnpkg.com/stat-mode/-/stat-mode-0.2.2.tgz#e6c80b623123d7d80cf132ce538f346289072502"
+  integrity sha1-5sgLYjEj19gM8TLOU480YokHJQI=
+
+static-extend@^0.1.1:
+  version "0.1.2"
+  resolved "https://registry.yarnpkg.com/static-extend/-/static-extend-0.1.2.tgz#60809c39cbff55337226fd5e0b520f341f1fb5c6"
+  integrity sha1-YICcOcv/VTNyJv1eC1IPNB8ftcY=
+  dependencies:
+    define-property "^0.2.5"
+    object-copy "^0.1.0"
+
+stream-combiner2@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/stream-combiner2/-/stream-combiner2-1.1.1.tgz#fb4d8a1420ea362764e21ad4780397bebcb41cbe"
+  integrity sha1-+02KFCDqNidk4hrUeAOXvry0HL4=
+  dependencies:
+    duplexer2 "~0.1.0"
+    readable-stream "^2.0.2"
+
+stream-shift@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/stream-shift/-/stream-shift-1.0.0.tgz#d5c752825e5367e786f78e18e445ea223a155952"
+  integrity sha1-1cdSgl5TZ+eG944Y5EXqIjoVWVI=
+
+stream-to-observable@^0.1.0:
+  version "0.1.0"
+  resolved "https://registry.yarnpkg.com/stream-to-observable/-/stream-to-observable-0.1.0.tgz#45bf1d9f2d7dc09bed81f1c307c430e68b84cffe"
+  integrity sha1-Rb8dny19wJvtgfHDB8Qw5ouEz/4=
+
+string-width@^1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/string-width/-/string-width-1.0.2.tgz#118bdf5b8cdc51a2a7e70d211e07e2b0b9b107d3"
+  integrity sha1-EYvfW4zcUaKn5w0hHgfisLmxB9M=
+  dependencies:
+    code-point-at "^1.0.0"
+    is-fullwidth-code-point "^1.0.0"
+    strip-ansi "^3.0.0"
+
+string_decoder@~0.10.x:
+  version "0.10.31"
+  resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-0.10.31.tgz#62e203bc41766c6c28c9fc84301dab1c5310fa94"
+  integrity sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=
+
+string_decoder@~1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-1.1.1.tgz#9cf1611ba62685d7030ae9e4ba34149c3af03fc8"
+  integrity sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==
+  dependencies:
+    safe-buffer "~5.1.0"
+
+strip-ansi@^3.0.0, strip-ansi@^3.0.1:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/strip-ansi/-/strip-ansi-3.0.1.tgz#6a385fb8853d952d5ff05d0e8aaf94278dc63dcf"
+  integrity sha1-ajhfuIU9lS1f8F0Oiq+UJ43GPc8=
+  dependencies:
+    ansi-regex "^2.0.0"
+
+strip-bom-stream@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/strip-bom-stream/-/strip-bom-stream-1.0.0.tgz#e7144398577d51a6bed0fa1994fa05f43fd988ee"
+  integrity sha1-5xRDmFd9Uaa+0PoZlPoF9D/ZiO4=
+  dependencies:
+    first-chunk-stream "^1.0.0"
+    strip-bom "^2.0.0"
+
+strip-bom@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/strip-bom/-/strip-bom-2.0.0.tgz#6219a85616520491f35788bdbf1447a99c7e6b0e"
+  integrity sha1-YhmoVhZSBJHzV4i9vxRHqZx+aw4=
+  dependencies:
+    is-utf8 "^0.2.0"
+
+strip-dirs@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/strip-dirs/-/strip-dirs-1.1.1.tgz#960bbd1287844f3975a4558aa103a8255e2456a0"
+  integrity sha1-lgu9EoeETzl1pFWKoQOoJV4kVqA=
+  dependencies:
+    chalk "^1.0.0"
+    get-stdin "^4.0.1"
+    is-absolute "^0.1.5"
+    is-natural-number "^2.0.0"
+    minimist "^1.1.0"
+    sum-up "^1.0.1"
+
+strip-eof@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/strip-eof/-/strip-eof-1.0.0.tgz#bb43ff5598a6eb05d89b59fcd129c983313606bf"
+  integrity sha1-u0P/VZim6wXYm1n80SnJgzE2Br8=
+
+strip-indent@^1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/strip-indent/-/strip-indent-1.0.1.tgz#0c7962a6adefa7bbd4ac366460a638552ae1a0a2"
+  integrity sha1-DHlipq3vp7vUrDZkYKY4VSrhoKI=
+  dependencies:
+    get-stdin "^4.0.1"
+
+strip-json-comments@~2.0.1:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/strip-json-comments/-/strip-json-comments-2.0.1.tgz#3c531942e908c2697c0ec344858c286c7ca0a60a"
+  integrity sha1-PFMZQukIwml8DsNEhYwobHygpgo=
+
+strip-outer@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/strip-outer/-/strip-outer-1.0.1.tgz#b2fd2abf6604b9d1e6013057195df836b8a9d631"
+  integrity sha512-k55yxKHwaXnpYGsOzg4Vl8+tDrWylxDEpknGjhTiZB8dFRU5rTo9CAzeycivxV3s+zlTKwrs6WxMxR95n26kwg==
+  dependencies:
+    escape-string-regexp "^1.0.2"
+
+sum-up@^1.0.1:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/sum-up/-/sum-up-1.0.3.tgz#1c661f667057f63bcb7875aa1438bc162525156e"
+  integrity sha1-HGYfZnBX9jvLeHWqFDi8FiUlFW4=
+  dependencies:
+    chalk "^1.0.0"
+
+supports-color@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-2.0.0.tgz#535d045ce6b6363fa40117084629995e9df324c7"
+  integrity sha1-U10EXOa2Nj+kARcIRimZXp3zJMc=
+
+supports-color@^5.3.0:
+  version "5.5.0"
+  resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-5.5.0.tgz#e2e69a44ac8772f78a1ec0b35b689df6530efc8f"
+  integrity sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==
+  dependencies:
+    has-flag "^3.0.0"
+
+svgo@^0.6.0:
+  version "0.6.6"
+  resolved "https://registry.yarnpkg.com/svgo/-/svgo-0.6.6.tgz#b340889036f20f9b447543077d0f5573ed044c08"
+  integrity sha1-s0CIkDbyD5tEdUMHfQ9Vc+0ETAg=
+  dependencies:
+    coa "~1.0.1"
+    colors "~1.1.2"
+    csso "~2.0.0"
+    js-yaml "~3.6.0"
+    mkdirp "~0.5.1"
+    sax "~1.2.1"
+    whet.extend "~0.9.9"
+
+symbol-observable@1.0.1:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/symbol-observable/-/symbol-observable-1.0.1.tgz#8340fc4702c3122df5d22288f88283f513d3fdd4"
+  integrity sha1-g0D8RwLDEi310iKI+IKD9RPT/dQ=
+
+tar-stream@^1.1.1:
+  version "1.6.2"
+  resolved "https://registry.yarnpkg.com/tar-stream/-/tar-stream-1.6.2.tgz#8ea55dab37972253d9a9af90fdcd559ae435c555"
+  integrity sha512-rzS0heiNf8Xn7/mpdSVVSMAWAoy9bfb1WOTYC78Z0UQKeKa/CWS8FOq0lKGNa8DWKAn9gxjCvMLYc5PGXYlK2A==
+  dependencies:
+    bl "^1.0.0"
+    buffer-alloc "^1.2.0"
+    end-of-stream "^1.0.0"
+    fs-constants "^1.0.0"
+    readable-stream "^2.3.0"
+    to-buffer "^1.1.1"
+    xtend "^4.0.0"
+
+temp@^0.8.4:
+  version "0.8.4"
+  resolved "https://registry.yarnpkg.com/temp/-/temp-0.8.4.tgz#8c97a33a4770072e0a05f919396c7665a7dd59f2"
+  integrity sha512-s0ZZzd0BzYv5tLSptZooSjK8oj6C+c19p7Vqta9+6NPOf7r+fxq0cJe6/oN4LTC79sy5NY8ucOJNgwsKCSbfqg==
+  dependencies:
+    rimraf "~2.6.2"
+
+tempfile@^1.0.0:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/tempfile/-/tempfile-1.1.1.tgz#5bcc4eaecc4ab2c707d8bc11d99ccc9a2cb287f2"
+  integrity sha1-W8xOrsxKsscH2LwR2ZzMmiyyh/I=
+  dependencies:
+    os-tmpdir "^1.0.0"
+    uuid "^2.0.1"
+
+through2-filter@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/through2-filter/-/through2-filter-2.0.0.tgz#60bc55a0dacb76085db1f9dae99ab43f83d622ec"
+  integrity sha1-YLxVoNrLdghdsfna6Zq0P4PWIuw=
+  dependencies:
+    through2 "~2.0.0"
+    xtend "~4.0.0"
+
+through2-filter@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.yarnpkg.com/through2-filter/-/through2-filter-3.0.0.tgz#700e786df2367c2c88cd8aa5be4cf9c1e7831254"
+  integrity sha512-jaRjI2WxN3W1V8/FMZ9HKIBXixtiqs3SQSX4/YGIiP3gL6djW48VoZq9tDqeCWs3MT8YY5wb/zli8VW8snY1CA==
+  dependencies:
+    through2 "~2.0.0"
+    xtend "~4.0.0"
+
+through2@^0.6.0, through2@^0.6.1:
+  version "0.6.5"
+  resolved "https://registry.yarnpkg.com/through2/-/through2-0.6.5.tgz#41ab9c67b29d57209071410e1d7a7a968cd3ad48"
+  integrity sha1-QaucZ7KdVyCQcUEOHXp6lozTrUg=
+  dependencies:
+    readable-stream ">=1.0.33-1 <1.1.0-0"
+    xtend ">=4.0.0 <4.1.0-0"
+
+through2@^2.0.0, through2@~2.0.0:
+  version "2.0.5"
+  resolved "https://registry.yarnpkg.com/through2/-/through2-2.0.5.tgz#01c1e39eb31d07cb7d03a96a70823260b23132cd"
+  integrity sha512-/mrRod8xqpA+IHSLyGCQ2s8SPHiCDEeQJSep1jqLYeEUClOFG2Qsh+4FU6G9VeqpZnGW/Su8LQGc4YKni5rYSQ==
+  dependencies:
+    readable-stream "~2.3.6"
+    xtend "~4.0.1"
+
+time-stamp@^1.0.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/time-stamp/-/time-stamp-1.1.0.tgz#764a5a11af50561921b133f3b44e618687e0f5c3"
+  integrity sha1-dkpaEa9QVhkhsTPztE5hhofg9cM=
+
+timed-out@^3.0.0:
+  version "3.1.3"
+  resolved "https://registry.yarnpkg.com/timed-out/-/timed-out-3.1.3.tgz#95860bfcc5c76c277f8f8326fd0f5b2e20eba217"
+  integrity sha1-lYYL/MXHbCd/j4Mm/Q9bLiDrohc=
+
+to-absolute-glob@^0.1.1:
+  version "0.1.1"
+  resolved "https://registry.yarnpkg.com/to-absolute-glob/-/to-absolute-glob-0.1.1.tgz#1cdfa472a9ef50c239ee66999b662ca0eb39937f"
+  integrity sha1-HN+kcqnvUMI57maZm2YsoOs5k38=
+  dependencies:
+    extend-shallow "^2.0.1"
+
+to-buffer@^1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/to-buffer/-/to-buffer-1.1.1.tgz#493bd48f62d7c43fcded313a03dcadb2e1213a80"
+  integrity sha512-lx9B5iv7msuFYE3dytT+KE5tap+rNYw+K4jVkb9R/asAb+pbBSM17jtunHplhBe6RRJdZx3Pn2Jph24O32mOVg==
+
+to-fast-properties@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/to-fast-properties/-/to-fast-properties-2.0.0.tgz#dc5e698cbd079265bc73e0377681a4e4e83f616e"
+  integrity sha1-3F5pjL0HkmW8c+A3doGk5Og/YW4=
+
+to-object-path@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/to-object-path/-/to-object-path-0.3.0.tgz#297588b7b0e7e0ac08e04e672f85c1f4999e17af"
+  integrity sha1-KXWIt7Dn4KwI4E5nL4XB9JmeF68=
+  dependencies:
+    kind-of "^3.0.2"
+
+to-regex-range@^2.1.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/to-regex-range/-/to-regex-range-2.1.1.tgz#7c80c17b9dfebe599e27367e0d4dd5590141db38"
+  integrity sha1-fIDBe53+vlmeJzZ+DU3VWQFB2zg=
+  dependencies:
+    is-number "^3.0.0"
+    repeat-string "^1.6.1"
+
+to-regex@^3.0.1, to-regex@^3.0.2:
+  version "3.0.2"
+  resolved "https://registry.yarnpkg.com/to-regex/-/to-regex-3.0.2.tgz#13cfdd9b336552f30b51f33a8ae1b42a7a7599ce"
+  integrity sha512-FWtleNAtZ/Ki2qtqej2CXTOayOH9bHDQF+Q48VpWyDXjbYxA4Yz8iDB31zXOBUlOHHKidDbqGVrTUvQMPmBGBw==
+  dependencies:
+    define-property "^2.0.2"
+    extend-shallow "^3.0.2"
+    regex-not "^1.0.2"
+    safe-regex "^1.1.0"
+
+trim-newlines@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/trim-newlines/-/trim-newlines-1.0.0.tgz#5887966bb582a4503a41eb524f7d35011815a613"
+  integrity sha1-WIeWa7WCpFA6QetST301ARgVphM=
+
+trim-repeated@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/trim-repeated/-/trim-repeated-1.0.0.tgz#e3646a2ea4e891312bf7eace6cfb05380bc01c21"
+  integrity sha1-42RqLqTokTEr9+rObPsFOAvAHCE=
+  dependencies:
+    escape-string-regexp "^1.0.2"
+
+tslib@^2.0.1:
+  version "2.3.1"
+  resolved "https://registry.yarnpkg.com/tslib/-/tslib-2.3.1.tgz#e8a335add5ceae51aa261d32a490158ef042ef01"
+  integrity sha512-77EbyPPpMz+FRFRuAFlWMtmgUWGe9UOG2Z25NqCwiIjRhOf5iKGuzSe5P2w1laq+FkRy4p+PCuVkJSGkzTEKVw==
+
+tunnel-agent@^0.4.0:
+  version "0.4.3"
+  resolved "https://registry.yarnpkg.com/tunnel-agent/-/tunnel-agent-0.4.3.tgz#6373db76909fe570e08d73583365ed828a74eeeb"
+  integrity sha1-Y3PbdpCf5XDgjXNYM2Xtgop07us=
+
+typedarray@^0.0.6:
+  version "0.0.6"
+  resolved "https://registry.yarnpkg.com/typedarray/-/typedarray-0.0.6.tgz#867ac74e3864187b1d3d47d996a78ec5c8830777"
+  integrity sha1-hnrHTjhkGHsdPUfZlqeOxciDB3c=
+
+uc.micro@^1.0.1, uc.micro@^1.0.5:
+  version "1.0.6"
+  resolved "https://registry.yarnpkg.com/uc.micro/-/uc.micro-1.0.6.tgz#9c411a802a409a91fc6cf74081baba34b24499ac"
+  integrity sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==
+
+union-value@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/union-value/-/union-value-1.0.1.tgz#0b6fe7b835aecda61c6ea4d4f02c14221e109847"
+  integrity sha512-tJfXmxMeWYnczCVs7XAEvIV7ieppALdyepWMkHkwciRpZraG/xwT+s2JN8+pr1+8jCRf80FFzvr+MpQeeoF4Xg==
+  dependencies:
+    arr-union "^3.1.0"
+    get-value "^2.0.6"
+    is-extendable "^0.1.1"
+    set-value "^2.0.1"
+
+unique-stream@^2.0.2:
+  version "2.3.1"
+  resolved "https://registry.yarnpkg.com/unique-stream/-/unique-stream-2.3.1.tgz#c65d110e9a4adf9a6c5948b28053d9a8d04cbeac"
+  integrity sha512-2nY4TnBE70yoxHkDli7DMazpWiP7xMdCYqU2nBRO0UB+ZpEkGsSija7MvmvnZFUeC+mrgiUfcHSr3LmRFIg4+A==
+  dependencies:
+    json-stable-stringify-without-jsonify "^1.0.1"
+    through2-filter "^3.0.0"
+
+unset-value@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/unset-value/-/unset-value-1.0.0.tgz#8376873f7d2335179ffb1e6fc3a8ed0dfc8ab559"
+  integrity sha1-g3aHP30jNRef+x5vw6jtDfyKtVk=
+  dependencies:
+    has-value "^0.3.1"
+    isobject "^3.0.0"
+
+unzip-response@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/unzip-response/-/unzip-response-1.0.2.tgz#b984f0877fc0a89c2c773cc1ef7b5b232b5b06fe"
+  integrity sha1-uYTwh3/AqJwsdzzB73tbIytbBv4=
+
+urix@^0.1.0:
+  version "0.1.0"
+  resolved "https://registry.yarnpkg.com/urix/-/urix-0.1.0.tgz#da937f7a62e21fec1fd18d49b35c2935067a6c72"
+  integrity sha1-2pN/emLiH+wf0Y1Js1wpNQZ6bHI=
+
+url-parse-lax@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/url-parse-lax/-/url-parse-lax-1.0.0.tgz#7af8f303645e9bd79a272e7a14ac68bc0609da73"
+  integrity sha1-evjzA2Rem9eaJy56FKxovAYJ2nM=
+  dependencies:
+    prepend-http "^1.0.1"
+
+url-regex@^3.0.0:
+  version "3.2.0"
+  resolved "https://registry.yarnpkg.com/url-regex/-/url-regex-3.2.0.tgz#dbad1e0c9e29e105dd0b1f09f6862f7fdb482724"
+  integrity sha1-260eDJ4p4QXdCx8J9oYvf9tIJyQ=
+  dependencies:
+    ip-regex "^1.0.1"
+
+use@^3.1.0:
+  version "3.1.1"
+  resolved "https://registry.yarnpkg.com/use/-/use-3.1.1.tgz#d50c8cac79a19fbc20f2911f56eb973f4e10070f"
+  integrity sha512-cwESVXlO3url9YWlFW/TA9cshCEhtu7IKJ/p5soJ/gGpj7vbvFrAY/eIioQ6Dw23KjZhYgiIo8HOs1nQ2vr/oQ==
+
+util-deprecate@~1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf"
+  integrity sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8=
+
+uuid@^2.0.1:
+  version "2.0.3"
+  resolved "https://registry.yarnpkg.com/uuid/-/uuid-2.0.3.tgz#67e2e863797215530dff318e5bf9dcebfd47b21a"
+  integrity sha1-Z+LoY3lyFVMN/zGOW/nc6/1Hsho=
+
+vali-date@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/vali-date/-/vali-date-1.0.0.tgz#1b904a59609fb328ef078138420934f6b86709a6"
+  integrity sha1-G5BKWWCfsyjvB4E4Qgk09rhnCaY=
+
+validate-npm-package-license@^3.0.1:
+  version "3.0.4"
+  resolved "https://registry.yarnpkg.com/validate-npm-package-license/-/validate-npm-package-license-3.0.4.tgz#fc91f6b9c7ba15c857f4cb2c5defeec39d4f410a"
+  integrity sha512-DpKm2Ui/xN7/HQKCtpZxoRWBhZ9Z0kqtygG8XCgNQ8ZlDnxuQmWhj566j8fN4Cu3/JmbhsDo7fcAJq4s9h27Ew==
+  dependencies:
+    spdx-correct "^3.0.0"
+    spdx-expression-parse "^3.0.0"
+
+vinyl-assign@^1.0.1:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/vinyl-assign/-/vinyl-assign-1.2.1.tgz#4d198891b5515911d771a8cd9c5480a46a074a45"
+  integrity sha1-TRmIkbVRWRHXcajNnFSApGoHSkU=
+  dependencies:
+    object-assign "^4.0.1"
+    readable-stream "^2.0.0"
+
+vinyl-fs@^2.1.1, vinyl-fs@^2.2.0:
+  version "2.4.4"
+  resolved "https://registry.yarnpkg.com/vinyl-fs/-/vinyl-fs-2.4.4.tgz#be6ff3270cb55dfd7d3063640de81f25d7532239"
+  integrity sha1-vm/zJwy1Xf19MGNkDegfJddTIjk=
+  dependencies:
+    duplexify "^3.2.0"
+    glob-stream "^5.3.2"
+    graceful-fs "^4.0.0"
+    gulp-sourcemaps "1.6.0"
+    is-valid-glob "^0.3.0"
+    lazystream "^1.0.0"
+    lodash.isequal "^4.0.0"
+    merge-stream "^1.0.0"
+    mkdirp "^0.5.0"
+    object-assign "^4.0.0"
+    readable-stream "^2.0.4"
+    strip-bom "^2.0.0"
+    strip-bom-stream "^1.0.0"
+    through2 "^2.0.0"
+    through2-filter "^2.0.0"
+    vali-date "^1.0.0"
+    vinyl "^1.0.0"
+
+vinyl@^0.4.3:
+  version "0.4.6"
+  resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-0.4.6.tgz#2f356c87a550a255461f36bbeb2a5ba8bf784847"
+  integrity sha1-LzVsh6VQolVGHza76ypbqL94SEc=
+  dependencies:
+    clone "^0.2.0"
+    clone-stats "^0.0.1"
+
+vinyl@^0.5.0:
+  version "0.5.3"
+  resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-0.5.3.tgz#b0455b38fc5e0cf30d4325132e461970c2091cde"
+  integrity sha1-sEVbOPxeDPMNQyUTLkYZcMIJHN4=
+  dependencies:
+    clone "^1.0.0"
+    clone-stats "^0.0.1"
+    replace-ext "0.0.1"
+
+vinyl@^1.0.0:
+  version "1.2.0"
+  resolved "https://registry.yarnpkg.com/vinyl/-/vinyl-1.2.0.tgz#5c88036cf565e5df05558bfc911f8656df218884"
+  integrity sha1-XIgDbPVl5d8FVYv8kR+GVt8hiIQ=
+  dependencies:
+    clone "^1.0.0"
+    clone-stats "^0.0.1"
+    replace-ext "0.0.1"
+
+ware@^1.2.0:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/ware/-/ware-1.3.0.tgz#d1b14f39d2e2cb4ab8c4098f756fe4b164e473d4"
+  integrity sha1-0bFPOdLiy0q4xAmPdW/ksWTkc9Q=
+  dependencies:
+    wrap-fn "^0.1.0"
+
+whet.extend@~0.9.9:
+  version "0.9.9"
+  resolved "https://registry.yarnpkg.com/whet.extend/-/whet.extend-0.9.9.tgz#f877d5bf648c97e5aa542fadc16d6a259b9c11a1"
+  integrity sha1-+HfVv2SMl+WqVC+twW1qJZucEaE=
+
+which@^1.2.10, which@^1.2.9:
+  version "1.3.1"
+  resolved "https://registry.yarnpkg.com/which/-/which-1.3.1.tgz#a45043d54f5805316da8d62f9f50918d3da70b0a"
+  integrity sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==
+  dependencies:
+    isexe "^2.0.0"
+
+wrap-fn@^0.1.0:
+  version "0.1.5"
+  resolved "https://registry.yarnpkg.com/wrap-fn/-/wrap-fn-0.1.5.tgz#f21b6e41016ff4a7e31720dbc63a09016bdf9845"
+  integrity sha1-8htuQQFv9KfjFyDbxjoJAWvfmEU=
+  dependencies:
+    co "3.1.0"
+
+wrappy@1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"
+  integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=
+
+write-file-atomic@^2.3.0:
+  version "2.4.3"
+  resolved "https://registry.yarnpkg.com/write-file-atomic/-/write-file-atomic-2.4.3.tgz#1fd2e9ae1df3e75b8d8c367443c692d4ca81f481"
+  integrity sha512-GaETH5wwsX+GcnzhPgKcKjJ6M2Cq3/iZp1WyY/X1CSqrW+jVNM9Y7D8EC2sM4ZG/V8wZlSniJnCKWPmBYAucRQ==
+  dependencies:
+    graceful-fs "^4.1.11"
+    imurmurhash "^0.1.4"
+    signal-exit "^3.0.2"
+
+"xtend@>=4.0.0 <4.1.0-0", xtend@^4.0.0, xtend@~4.0.0, xtend@~4.0.1:
+  version "4.0.1"
+  resolved "https://registry.yarnpkg.com/xtend/-/xtend-4.0.1.tgz#a5c6d532be656e23db820efb943a1f04998d63af"
+  integrity sha1-pcbVMr5lbiPbgg77lDofBJmNY68=
+
+yallist@^2.1.2:
+  version "2.1.2"
+  resolved "https://registry.yarnpkg.com/yallist/-/yallist-2.1.2.tgz#1c11f9218f076089a47dd512f93c6699a6a81d52"
+  integrity sha1-HBH5IY8HYImkfdUS+TxmmaaoHVI=
+
+yauzl@^2.2.1:
+  version "2.10.0"
+  resolved "https://registry.yarnpkg.com/yauzl/-/yauzl-2.10.0.tgz#c7eb17c93e112cb1086fa6d8e51fb0667b79a5f9"
+  integrity sha1-x+sXyT4RLLEIb6bY5R+wZnt5pfk=
+  dependencies:
+    buffer-crc32 "~0.2.3"
+    fd-slicer "~1.1.0"